Yassal Sundman

This guide explains the main ingredients necessary for facilitating a team start up and provides you with six example agendas. The guide includes questions to think about when you set up the facilitation and during the meeting.

The components needed for a team start up

1. Purpose or mission -> why does the team exist?
   • What is the business value?
   • What does success look like?
2. Understanding who the team members are:
   • Clearly defined membership list -> who is on the team?
   • Make sure that people get to know each other -> who are my team members as people?
   • What are people’s skill sets? What do they know now, what do they want to get better at?
3. Agree to how to work together
   • What do team members expect from each other
   • What behaviors does the team want to have
   • How to talk to each other?
   • How to split up work?
   • What meetings/sync/feedback is needed

Questions to consider for each area

Did you answer that question by saying: “I’m fine”? Maybe you aren’t fine, and answered that you were happy, sad, or angry? Did you stop to think about what you really mean by that answer? How are you really feeling? Why are you feeling this way and what do you want to do about it?

In his book, “Permission to Feel”, Marc Brackett talks about the importance of Emotional Intelligence and emotional skills. He shows you how you can develop a more varied emotional vocabulary. You learn how to deal with the actual challenges that you face by understanding how you feel. Here are my thoughts on how Brackett’s method will help you develop your emotional skills. By understanding how you feel, you can figure out what you need to do which in turn will influence how you feel, enabling you to create an upward emotional spiral.

Facilitating a workshop or class? Need to come up with working agreements? Are people still shy and quiet and is the tempo still low? Here’s an easy method to get a medium sized group, about 20 people, to come up with and agree to a set of working agreements, while energizing the room and getting people talking to each other.

Just like pair programming, there are a lot of benefits to pair coaching. In fact, the positives – two pairs of eyes, direct feedback, observation from two different perspectives – are even stronger motivators for pairing up when coaching! We see a lot of pairing when it comes to teaching classes, and larger facilitations, why not apply the same benefits to coaching as well!

The coaching context

In an individual coaching session, there are a lot of things going on. First, there is the content of the conversation. Then there are the thought processes and emotions within both the coach and the person being coached. As well as the communication and dynamics of the relationship between them. This is already a complex situation that can benefit from an added perspective. Imagine the complexity when we start talking about team or group coaching. 

Design studios are useful for helping a group of people converge on an idea. This post provides a PDF presentation for facilitating a design studio workshop, including an additional optional section for refining ideas when the desired result is to generate multiple ideas. The general pattern is:

• Generate ideas
• Present
• Get feedback
• Refine and converge the ideas

Agile 2019 in a nutshell: Jam packed with inspiring, informative talks! I tried to sum up my experience when I came home from DC a couple of weeks ago, but there were just too many good things to say! So I’ll leave you with the graphic above with some of the highlights, and I’ll share what I’ve actually followed up on since I’ve been back.

Meaningful inclusive retrospectives are possible with distributed teams. Let’s talk about the basics you need to have in place, how you can facilitate a distributed retrospective, and what to look out for. This guide is based on the retrospective format that we used at LRF Media. The retrospective participants included 5 team members at the office in Stockholm, one person working from home, and 2 people working at the Kraków office.

Continue reading

So how do you go about implementing a zero bug policy when you’ve got a long list of real bugs and users and stakeholders who want things fixed? I’ve been getting this question a lot after posting my blog entry Stop Managing Bugs, Start Focusing on Quality and creating the app and cards to help with the

“Fix It Now or Delete It” is a simple method that gives you two options for dealing with a bug: Fix It Now, or Delete It! I wrote a blog entry about this method a few months ago, and now there are lots of resources to help you talk to your team about simplifying the

Recruitment processes for agile team coaches differ greatly from one company to another. Jan Grape and Yassal Sundman share their insights on what makes for a good process based on their work recruiting coaches for their clients.Continue reading

You’re coaching a new team! Woohoo! You have so many ideas! You’re going to help make the team’s world a better place! All the things that you’ll do! Then you get there. The music stops, and the frustration sets in. You’re trying to help but team members come late to the daily scrums, they don’t update the information radiators and they’re zoning out during meetings. You’re not sure what to do anymore. What happened? You feel undermined and unappreciated. Aren’t you the expert? Isn’t that why you got this team to begin with? Why won’t they let you help them?

Let’s look at the journey of joining a team and how you can pave the way for a successful coaching experience!Continue reading

Do you have a long list of bugs? You definitely want to have a zero bug policy, but now you have all sorts of minors, majors, and criticals. You’re not really sure how to get to zero bugs (were you ever there to begin with?). You have spikes where you fix the bugs and your graphs show a steep downward drop, only for them to turn upwards again and reach new heights. Just maintaining the list of bugs is a full time job! To add insult to injury, when a team member finally gets around to looking at a bug, they usually find that it’s outdated, not reproducible or part of some long forgotten removed functionality.

There has to be a better way! How can you shift the focus from managing bugs to ensuring quality? Here’s a system that’s easy to start using, and rewarding when you follow it.Continue reading

One of the most exciting aspects of working as an Agile Coach is applying what we know to other industries. Especially when what we do serves the greater good. We’re both always actively looking for opportunities to work with integration initiatives, and in this case we supported an initiative to improve integration of newcomers. Here’s how we facilitated the 2018 kick off meeting for Järfälla municipality’s Interfaith Council.Continue reading

Have you worked with teams that don’t communicate well? Or teams that don’t collaborate? What about teams that deliver late or with poor quality? Or maybe teams that are in constant negative conflict?

How do you tackle these issues? It might feel like you can fix everything by changing some of the people on the team. Before you do that, consider how you’ve set the stage for your team. Will removing and adding some people really solve all your problems? Or will the new members find themselves in the middle of a dysfunctional team, and end up unhappy and not delivering to their full potential?

Here are some of the things you can think about when you work with teams to create an environment where they can succeed.

Continue reading

For the past four years I’ve consulted for King as an agile team coach. It’s been a whirlwind of personal growth, learning about mobile games and meeting awesome people. I wrote about my biggest takeaways in an article on Crisp’s website. I am grateful for all the connections and insights that I’ve gained. I’m also

Large group retrospectives are long, large, unwieldy facilitations. So much so that they’re typically done only at the end of a project. Holding a 1-2 day retro every few weeks for a large project is neither practical nor responsible, but continually improving the project is also important.  So, how do you hold light-weight retrospectives for large groups, while making sure that you:

• Have a common understanding
• Identify issues and strengths
• Reach a group agreement on action points
• Ensure that the group feels that they received a high return on time invested

This retrospective combines different techniques and technologies to achieve these results.Continue reading

This is a strong retrospective for bringing issues up to the surface. Instead of just one person expressing an issue as a positive or a negative, the whole team feedbacks about the importance of the issue. The team then decides which issues to tackle. The retrospective also exposes issues where there is not common view, and highlights areas of alignment. It also allows the team to ask tough questions in a safe environment.Continue reading

You have a team member who has a pressing issue. It’s the single most important thing that they need to resolve. They explain the problem to a coworker, suggest a solution and ask for support… and all they get is a tepid response. This is a situation that repeats itself across workplaces every day. There are many reasons why people refrain from helping. They might not have the competence, they might disagree with the solution/problem or maybe they just don’t have the time. But what happens when they have the competence, agree with the assessment and could easily make time, but choose not to? Why don’t they? How do you help your team navigate these situations?

Continue reading

As a high-performing tech professional, it’s useful to constantly fine-tune your ability to add value.

For example, you might ask yourself at work:

What is the one thing we can change in our product, service or in the way we work together that can bring more value to our customers or the team?

This philosophy of looking for things that can add value can also be used for your personal and professional development.

To give you some inspiration, here are some of the real life small changes and habits that our team members at Crisp have made that have added tremendous value to our personal and work lives.Continue reading

You have probably read about “at scale” implementations, activity based offices, globally distributed teams, SAFe, Agile transformations and outsourcing. Beware. Danger can be lurking beneath the surface of these popular phenomena.

Continue reading

When the BBC published their “No CEO” piece where Crisp is featured with an article and a 4 minute video, there were a lot of reactions. Friends cheered on Facebook. Colleagues gave a thumbs up on LinkedIn. The article was featured on Hacker News and Slashdot. Here are our reflections on some of the comments we found.

Continue reading

You have a feature to implement, and there are several implementation solutions available. How do you choose the best one?

Start out with all your potential solutions for a feature idea. Next, filter based on how the solutions perform using a set of verification methods. Finally, implement the feature knowing that you’ve found the solution that meets your needs.

Verification Methods

The following are the verification methods I’ve experienced most often on the projects:Continue reading

Conflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict. You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement. The following workshop is the one I use with my teams and organizations.

Continue reading

I gave a lightning talk at tonight’s Lean Tribe Gathering in Stockholm about A/B testing at King, how we develop games, features and decide which improvements to make. Here are my slides and notes from the presentation.

Continue reading

Candy Crush Soda releases a new version of the game on all platforms every other week, year round. I’ve written about the delivery pipeline and the challenges the team faces on King’s tech blog: https://techblog.king.com/candy-crush-soda-saga-delivery-pipeline/ Previous posts about working with the Soda team: How We Developed Candy Crush Soda Saga What Should We Build Next? Get in touch

I’m currently coaching a team with several stakeholders in different parts of the organization. It’s difficult to know who to talk to when decisions need to be made. The line between what the team can decide about and what the stakeholders need to be involved in is also blurry. To help create more clarity and a better collaborative environment with our stakeholders we decided to create a delegation board. The meetings we ran this week were appreciated by everybody, so I thought I would share what we did and what we learned.

Continue reading

Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.

You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?

Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do

Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision. 

So, what is mob programming anyway?

Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.

Continue reading

Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.

We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!

Continue reading

How do you decide what to build next? Who comes up with the ideas? How do you decide in what order to implement them? How do you keep track of what you’re working on, and what you want to work on?

Here’s a behind the scenes look at how the Candy Crush Soda team comes up with ideas and decides what to build next!

Continue reading

Curious about how we developed Candy Crush Soda at King? Like any project we’ve had our challenges. We developed the game on a framework that had never been tested live, while programming in two languages simultaneously to support multiple operating systems. Adding to the challenge, we started working without a prototyped game idea, within an existing Saga format that comes with a long list of features that players are used to. The project, code-named Stritz, was born in the spring of 2013. We soft launched a year later, and hard launched in the fall of 2014. This is our story.