Scaling Scrum With Scrum

Leadership Scrum Team

One of our clients recently reached out to us asking for advice about how to manage their organization’s scaled scrum adoption. They wanted to know if they could use scrum to manage the adoption of scrum in the organization. The short answer is yes.

Guiding an organization’s adoption of scrum is a big project. It’s a project that will require a cross-functional team. It’s a project where the full scope of work can’t be known when the work starts. It’s complex, exactly the kind of endeavor that you want to use scrum to implement. When I’m working with organizations that are adopting scrum at scale, I always start by recommending that they create a scrum adoption team, and that this team use scrum to do the work of rolling scrum out to the organization.

One of the many benefits of leaders using scrum to guide their organization’s adoption of scrum is that they are leading by doing, instead of telling. “Do as I do” is much more compelling than “Do as I say.” The leaders will also develop a much deeper understanding of what they are asking their people to do, and will be better able to understand the changes needed in order to be successful.

This team needs a product owner, someone who can answer the question “Why is this organization adopting scrum?” The organization’s management is seeking some kind of value, and they believe that investing in this scrum adoption will get them that value. Is the value faster time to market? Higher product quality? Happier customers? Happier employees? Something else? These are all laudable goals, but it’s important that the product owner for the scrum adoption team understand which of these is most important to the business. Based on this knowledge, the product owner can create and share a vision for how this scrum adoption will create value for the organization. This vision will guide the team’s work.

The scrum adoption team will need a product backlog filled with the deliverables of the scrum adoption itself. One product backlog item might be identifying a pilot project to try using scrum. Another product backlog item might be to pick the team members for that first scrum team. Yet another item might be to get scrum training from Agile Learning Labs for that first team (okay, that was shameless). As the organization starts to adopt scrum, the scrum adoption team will discover impediments that are preventing scrum from working well, such as middle managers that aren’t willing to let go of control. These impediments will lead to new items in the scrum adoption team’s backlog. Perhaps they’ll decide to bring in Agile Learning Labs to do some training and coaching with those middle managers (okay, I’ll stop now).

The team will need a scrum master. As with any team, the scrum master will focus on helping this team become high performing. The scrum master will coach the team and help them use scrum effectively to self-organize and continuously improve.

Most importantly, the team needs team members. These should be people from various parts of the organization who will do the work of guiding the organization’s adoption of scrum. I recommend that the team have some permanent members, perhaps high-level managers from engineering, test, product, and human resources. The team should also have a rotating group of people from the field. These are people who will be using scrum and/or be impacted by the organization’s adoption of scrum. Examples include: scrum masters, product owners, engineers, testers, managers and anyone who will interact with a scrum team. These rotating members should serve on the team for pre-defined terms, perhaps three to six months. These members of the scrum adoption team will provide the muscle to get the scrum adoption team’s work done. They will also act as eyes and ears, keeping the adoption team in touch with what’s really going on.

Here are a couple of things to be careful of. First is the role of the scrum adoption team itself. Scrum is about ‘doing it better and better’ not about ‘doing it right’ and so the scrum adoption team should not be the scrum police, telling the teams how they are doing it wrong. Their mission should be to help the organization learn, improve and drive toward the specific value that the organization is seeking from their scrum adoption. Focusing more on education and less on enforcement usually leads to better results.

Secondly, the scrum adoption team needs to guide the organization in the selection of appropriate metrics for the scrum adoption. Measure the wrong things, and that’s what you will get! For example, velocity (often measured in story points) is a terrible metric. No organization ever adopts scrum to get “more velocity.” What they probably want is to deliver more value or to reduce time to market. So create metrics that focus on these things, not velocity.

Obviously, I’ve just scratched the surface here. Hopefully it helps you get started creating your scrum adoption team.

Have you been a part of a scrum adoption team? Or perhaps you’ve worked at an organization that needed one, but didn’t have one? Leave a comment and let’s talk about it.



Posted in agile, scrum, teams | Leave a comment

World Café – Scaling Highly Interactive Meetings


World Café is a fun, flexible, and scalable technique for group conversations that leads to creative solutions to complex problems. World Café has some similarities to Open Space Technology: both techniques work for groups ranging from a few people to a few thousand; and both are frameworks that support individuals and interactions. World Café is useful for generating and communicating ideas, making decisions, and even doing hands-on work. We’ll be teaching product owners how to use it in our upcoming Advanced Certified Scrum Product Owner (A-CSPO) workshop.

How It Works

The facilitator breaks the room into groups, then sets them to explore a set of related topics, one per table. Each table has a host whose job it is to stay with the table and provide continuity while the groups discuss the topic. The other participants rotate between tables on a regular schedule, perhaps every 15-30 minutes. The idea is that those who travel between tables will cross-pollinate ideas between the topics and bring fresh perspectives. By participating in each topic, the participants come to have a holistic understanding of the main issue, and are able to understand each sub-issue within this context. In the last round, people have the option of returning to a previous table so that there is opportunity for closure and continuity.

How It Came To Be

World Café was created in 1995 when a group of business and academic leaders were meeting at the home of Juanita Brown and David Isaacs in Mill Valley, California. The plan was for a large-circle dialogue outdoors, but rain necessitated a change. Here’s what happened next.

Participants spontaneously formed into small, intimate table conversations about the questions that had drawn them together, recording their insights on makeshift paper “tablecloths.” They periodically interrupted these conversations to switch tables so the insights and ideas that stayed with them might circulate, deepen, and connect. Harvesting the table conversations enabled them to notice the emerging patterns in their thinking, which then enriched subsequent rounds of conversation. Over the course of the morning, the innovative process they improvised gave birth to an experience of collective intelligence that transformed the depth, scope, and quality of their collaboration.

I first facilitated a World Café at P-Camp 2009 with Ainsley Nies. I’m excited to be using it in my Advanced Scrum Product Owner (A-CSPO) workshop. It’s a technique that can really help product owners build an engaged stakeholder community, and get the development team and the stakeholders more engaged with each other.

You can learn more about the seven design principles behind the simple method of World Café at or by reading the Wikipedia page on World Cafe, or by enrolling in our next A-CSPO workshop.


Chris Sims

Posted in agile, project management, scrum | Leave a comment

Announcing Our Advanced Certified Scrum Product Owner Workshop

Product Action Plan

Agile Learning Labs is excited to announce the first public offering of our Advanced Certified Scrum Product Owner workshop (A-CSPO). This workshop is designed for people who have their CSPO and are ready to build a richer skillset, and earn the next level of Scrum Alliance certification. Chris Sims is one of only ten trainers in the world authorized to teach an A-CSPO workshop.

One of the highlights of this interactive workshop is the half-day product road mapping session. Participants will be guided through the creation of a series of minimal viable product (MVP) releases for their product, and learn how to adjust their MVP and their roadmap as market conditions and business needs change.

Another highlight is the use of the World Cafe framework to dive deeply into the skills a product owner needs to communicate effectively with the stakeholders and development team.

The workshop includes several topics taken from the world of lean product development, including the creation and testing of product hypotheses as well as creating a Lean Startup Canvas.

Additional topics covered include: defining and validating business value, crafting a product strategy and vision, how scaling impacts the product owner role, product backlog refinement, avoiding cognitive bias, and much more.

The course includes about 4 hours of self-paced pre-work, followed by a 2-day in-person workshop. In order to take the workshop, you will need to already hold a CSPO from the Scrum Alliance. In order to complete the A-CSPO certification process you will need to self-report at least one year of product owner experience. Details can be found here on the Scrum Alliance website.

If you are ready to take the leap and become an Advanced Certified Scrum Product Owner, then register for our upcoming A-CSPO workshop!


Chris Sims

Posted in agile | Leave a comment

How To Create Your Team’s Definition Of Done

A scrum team’s definition of done is an important tool that helps the team add new functionality while keeping the product in a releasable state. Here is one way of facilitating the creation and evolution of your scrum team’s definition of done.

Identify The Work Needed To Release Something

Have the development team identify all of the work items (often called tasks) needed to release a high quality product backlog item (often called a user story) to production. Each piece of work goes on a sticky note. Be as specific as possible. If a team member says “testing” get specific about what that entails and write specific sticky notes:

  • Each acceptance criteria has an automated regression test
  • Unit test coverage is greater than 80%
  • Manual exploratory testing has been done
  • All the tests are passing

Put all the sticky notes on the wall in an unsorted clump. Keep asking if there is additional work needed to release a product backlog item until the team feels they have captured it all.

Definition Of Done For A Product Backlog Item

Put a label that says “Definition Of Done For A Product Backlog Item” over an empty section of wall. One by one, team members pick a sticky note that they think would be reasonable to add to the team’s definition of done and they propose that this be added. Adding this means the development team can, and will, do that work for each product backlog item before declaring that item done. If the entire team agrees, then the sticky note gets added. If not, it’s returned to the group of unsorted sticky notes.

Eventually the nominations will stop; there are no additional sticky notes that the team is willing to consider for their definition of done. Have the team look at the list and reaffirm that they are willing and able to do each of these pieces of work for each product backlog item before they consider it done. Adjust as needed until there is consensus that this is their definition of done for a product backlog item.

Definition Of Done For A Product Increment

With the remaining unsorted sticky notes repeat the process from above, but this time have the team members select the work that they can do by the end of a sprint in order for the product increment (the collection of completed product backlog items) to be truly releasable. This becomes the team’s definition of done for a product increment.

Warning! Any items that can only be done at the sprint (product increment) level represent technical debt and increase the risk that the increment might not be releasable at the end of the sprint.

Definition Of Done For A Release

One the premises of scrum is that the team produces a releasable product increment at the end of each sprint. So there shouldn’t be any additional work left. In reality, your team may not be there yet. Perhaps there are still some sticky notes in the unsorted category. These remaining items are significant technical debt and greatly increase the risks related to shipping the product. For now, consider these your definition of done for a release.

Evolving The Definition Of Done

The ideal is having one definition of done, which applies at the product backlog item (A.K.A story) level. Each time a product backlog item is done the business has a releasable product increment and we are leaving no undone work behind. This allows the business to capture the value from the work the team has done as quickly as possible.

In pursuit of this goal, the team and perhaps the entire organization will want to do work in order to promote things from the release definition of done to the product increment definition of done and from the product increment definition of done to the product backlog item definition of done.

Another reason that the definition of done evolves over time is that the team will discover weaknesses or gaps in their definition of done over the course of their work. For example:

  • In product backlog refinement, the team might notice that a particular acceptance criteria is almost universal and so they add it to the definition of done.
  • In sprint planning, the team might notice some vital work that isn’t currently captured in the definition of done.
  • In the daily scrum, the team may surface impediments that could be avoided by a stronger definition of done.
  • In sprint review, the team might discover missed stakeholder expectations and decide to add stakeholder signoff or user acceptance testing (UAT) to the definition of done.
  • In retrospective, the team might identify some ways a stronger definition of done might have prevented the introduction of bugs during the sprint.

Do It Early And Often!

If you are working with a new team, facilitating the creation of their definition of done should be one of the first orders of business. Don’t worry about getting it perfect or ideal; it’s more important that it be realistic. Then you begin the journey of evolving and improving the definition of done over time.

Posted in agile | 2 Comments

Customer Interview For Product Discovery

Conducting customer interviews is a great way to validate, or invalidate, your product idea. Interviewing potential customers is almost always a cheaper and faster way to learn what your customers’ needs are, compared to building the product first and then discovering that you built the wrong thing. Even with an existing product, you can discover which new features will be most valuable through customer interviews. Here’s a great video that explains how to do it.

Posted in products, startups, tools, videos | Leave a comment

A Scrum Master Is A Teacher, Mentor, Coach, And Facilitator

A scrum master wears many hats including: teacher, mentor, coach, and facilitator. Part of the art of being an excellent scrum master is being able to flow between these roles fluidly, depending on the situation at hand and the needs of the people involved.


This is the act of showing or explaining something to someone so that they acquire new knowledge. The scrum master is an expert in scrum and related agile practices. The scrum master spreads this knowledge throughout the organization, enabling people to engage in their work more effectively.


This is a relationship in which a more experienced person helps to guide a less experienced person in the performance of their work. It includes the informal transmission of knowledge, social capital, as well as psychosocial support to enable broad on-going development. As the team is engaged in the daily use of scrum, the scrum master helps them use it more effectively. The goal of mentoring is to help the individuals become self-sufficient, and the team to become self-organizing.


In this activity the scrum master aims to improve the performance of an individual or team, in pursuit of an objective set by the individual or team. While it may include elements of teaching or mentoring, the focus is helping the individual or team to improve their own performance: in other words, helping them help themselves. One of the big differences between coaching and mentoring is who is setting the direction. When the scrum master is mentoring, it is the scrum master that is choosing the areas to focus on for improvement. In a coaching approach, the scrum master is helping the individual or team improve in an area of their choosing.


This is when the scrum master helps the team navigate a process or reach an agreement or solution without getting directly involved in the content of the process or discussion. Facilitate means to make something easier. The scrum master facilitates decisions, communication, and meetings. This aspect of the scrum master role supports the agile value of “Individuals and interactions over processes and tools.” The scrum master develops deep knowledge and skill in the use of processes and tools in order to support the individuals to have more effective interactions.



Posted in agile, coaching, scrum, teams | 2 Comments

Cathy Simpson Becomes A Certified Scrum Trainer

The big news from the Dublin Scrum Gathering is that Cathy Simpson has become a certified scrum trainer. This is a monumental accomplishment. She is one of less than 250 people in the world, and less than 30 women, who hold this certification. We have had the privilege of working with Cathy over the past 3+ years and supporting her as she climbed this mountain. It’s been inspiring to see her do all of the work required. We couldn’t be more proud of her.

Congratulations Cathy!

Chris, Betty, and Max

Posted in agile | Leave a comment

Turn The Ship Around – Intent Based Leadership

David Marquet was about to become a submarine commander. He spent a year learning everything about the boat he was going to command. Two weeks before he was to assume command he was given a different sub, and the only thing he knew was that it has the reputation for being the worst in the Navy. He made it the best. Here’s how.

Thanks to Peter Green for sharing this video with me in his Certified Agile Leadership workshop.

Posted in agile | Leave a comment

Don’t Finish Your Epics! Deliver More Value Instead.


Product team is starting to assign business values to epics so we can, along with effort estimates, set correct priorities. However, we also have quarterly goals. Once we reach the end of a quarter, if an epic is not completely done (all stories under it), how do we get partial credit?


I recommend rolling the value down from the epics into the stories themselves. This way, you can see what you delivered in the quarter. Keep in mind that value estimates, just like effort estimates, are really just a tool to help with planning and decision making. At the end of the quarter, I’d like to see you focusing on the awesome stuff you delivered and what your customers’ reactions were to that new functionality.

I also recommend not trying to complete all of the stories in the epic. That type of ‘completion thinking’ is often a holdover from the old way of thinking: “We must do all of the things that we said we would do.” It’s not usually the best approach. When a big epic is broken into smaller stories, it’s not the case that all of the stories are equally valuable. Some are very valuable, many are fairly valuable, and some are nice to have but not really all that valuable. Deliver the most valuable stuff, and then keep an eye out for when the rate of value delivery is falling off. At that point, there is usually other, more valuable stuff that the team could be working on. So you should have the team stop working on the current epic, and move on to the other more valuable stuff. Free yourselves from ‘completion thinking’ and focus on constantly delivering value at the fastest possible rate.



Posted in agile | Leave a comment

Smaller User Stories Podcast

I recently had a conversation with Dave, over at the Mastering Business Analysis podcast, about splitting big user stories down into smaller stories. The interview was a lot of fun and it’s available now. You can get it direct from the Mastering Business Analysis website, or point your podcatcher at one of these links:

You can also read about splitting user stories at


Chris Sims

Posted in agile, scrum, software | Leave a comment