Scrumorakel - Blog

Almost every team I have coached so far has made the same mistake. This was treating the Sprint Review as "demo" or "approval meeting". It is neither of those. The Scrum Guide says:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

So the Sprint Review should be a informal, collaborative working session. Lot's of interaction with the stakeholders is sought for, not the passive acceptance of whatever drizzles down from the stage.

A good Sprint Review could have the following format:

1. The Product Owner welcomes all attendees (especially the stakeholders) and reminds everybody of the product vision and the value he is trying to achieve (he shows the "big picture")


2. Then, the PO shows the release target and the Sprint goal. He also states if the goal was reached or not, maybe even giving a reason in the latter case.


3. The the Product Owner passes the ball over to the Development Team. They show very briefly what they have accomplished. They do not show anything that isn't completely "Done".


4. After the short "demo" element, the true fun starts: The stakeholders get to try the product increment. They use it, touch it, feel it. Only then they notice if what they are holding in their hands (or clicking with their mouse) is what they actually wanted. The developers walk around and give a hand whenever needed. When new requirements are identified or changes to the Product Backlog are seen as necessary, the Product Owner records these.


5. Together, the Product Owner and stakeholders examine the Product Backlog and the impact of what they have just seen. If deemed valuable, the Product Owner adapts the Product Backlog


6. The Product Owner thanks everybody for their input and closes the meeting

This flow is not prescribed by Scrum. However, I personally find it very useful.

You might still ask yourself when the work of the Development Team is formally accepted. Well, the Sprint Review is the last possible moment for this, not the only one. And it is a bad point in time to do it. After all, the stakeholders are present in the meeting - if the Product Owner is surprised by his Team's results, he is standing on the stage with his pants dropped. No chance at all to gather more information or rectify a mistake. So instead of accepting this huge risk, good Product Owners will accept or reject the team's results during the Sprint. Usually, Product Backlog Item by Product Backlog Item and on the day when the Team claims they are "Done". The PO works with the team on a daily basis, so this shouldn't pose a problem.
Scrum does not define when the stakeholders formally accept the results of the Product Owner (he is the "single wringable neck", so he is on the line for his stakeholders), so it can be defined by each product/project. It can be done during the Sprint Review, but this usually diminishes the quality of the meeting because everybody is trying to look good instead of collaborating on what has to be done next. Smart Product Owners will try to detach formal acceptance from meetings and connect it to KPIs instead, e.g. the primary value KPI. If the primary reason why this project is conducted is a sales number (e.g. 1 million), then actually count sales. Who cares if the initial plan or certain "gates" are achieved when sales skyrocket?

Ben Linders reviewed "The Scrum Culture" and published the results of our Q&A session on InfoQ. Enjoy the read!

If you participated in the "Nature of Scrum" Survey (see here, here and here for more details), you just received an email with the survey results. In fact, you received a digital copy of my new book "The Scrum Culture". Unfortunately, I received quite a few server errors, telling me people are working for different employers now or have misspelled their addresses. So if you did participate in the study but are still waiting for your email, first check your Spam folder and then ping me with your full name and current email address. I will double-check the result data and send you your copy right away.

Enjoy the read!

During the last year, more and more customers asked about „how to scale Scrum“. Usually, what they wanted to say was: “We have many teams here, working on several products. How can we make sure they all do the same thing?”
Generally, the term “scaling” applies to having multiple teams working on the same thing. Some nuggets for you right from the start:

Three golden Rules

1. No matter which scenario you encounter, there is one golden rule of Agile you always have to heed: Use your primary tool (which is the grey mass between your ears) to find a suitable solution for your specific context. You will have a hard time finding an out-of-the-box solution that really fits you 100%. There is no “one size fits all” when it comes to organizational development.


2. Start small and get it right first. Whatever you have when you start scaling will be scaled. That means, if you have a crappy “Scrum But” implementation for one team, you will get to an even crappier “Scrum But” implementation for 20 teams after scaling. If you have a well-working implementation of Scrum for one team, your chances are good to get to a well-working scaled situation.


3. Take one step at a time. While there are examples where changing 800 (and more) people at once actually worked, it usually doesn’t. If you have one well-working team, add one to three and get them to work as well. Once they do, add more teams or practices.

Unfortunately, people sometimes mean very different things when they talk about “scaling”. There are different scenarios you might encounter:

1. One Team is working on several products at the same time


2. There are several sites involved in the development effort, no matter with how many teams (virtual teams)


3. There are 2-10 Scrum Teams working on the same product


4. There are >10 Scrum Teams working on the same product


5. There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies


6. There are 2-10 Teams (with Scrum or without) working on different products, with dependencies


7. There are >10 Teams (with Scrum or without) working on different products, with dependencies


8. The development department is working Agile and now the rest of the organization should align

For all of these eight scenarios, I will give you some explanations and hints how to handle them. If you have additional examples, let me know. I will try to incorporate them.

1. One Team is working on several products at the same time

Personally, I wouldn’t consider this a “scaled” scenario. It is plain multitasking. It is what we usually try to get rid of when we introduce agile methods. While this can be okay in service environments, it is not in development. Your people will lose focus and traction if they have to switch between tasks. The way to do this “properly” is to define several Sprints for one product and only start work on additional products later (e.g. three months product A followed by three months product B).

2. There are several sites involved in the development effort, no matter with how many teams (virtual teams)

Yes, you can work with distributed (separate teams at separate locations) and dispersed (members of one team at separate locations) teams in Scrum. However, this is usually not cost-effective, if not managed properly (also see this for the reasons: http://scrumorakel.de/blog/index.php?/archives/32-The-reasons-why-distributed-teams-are-less-effective.html). If you refrain from just looking at the hourly rates and start calculating coordination time and result quality, chances are that outsourcing doesn’t pay off.
So what you have to do is to reduce the virtual distance. This means you have to make sure infrastructure and technology fit the job and people know each other on a personal level. So, fly everyone to every location once in a while and use a month or two in the beginning of the project to have everybody work together in person. While they are not working together, send ambassadors over to each location and make sure technology is always working with a single click so people have their colleagues at their fingertips. The intensity of your measures depends on the degree of virtual distance you are facing and on the question if you are working distributed or dispersed (dispersed teams need more attention than distributed ones).

3. There are 2-10 Scrum Teams working on the same product

Having more than one team working on a product is what usually is meant by the term “scaling”. Two teams rarely need special attention since people just talk – especially if they are sitting in the same room. Three to ten teams do need your attention in several areas:

• a. Roles


• b. Knowledge sharing


• Meetings


• Artifacts


• Quality


• Architecture


• Development tools


• Coding guidelines


• Team rules / charters

Mind the first golden rule: Use your brain and find your own way!
You will have to decide if your Product Owner (there is one product, so there should be a single Product Owner) can handle 10 teams at once the way he used to. You will also discuss the need for “central” roles or hierarchies (“Chief Product Owner” or “Super Scrum Master”). My personal experience is that you should refrain from such hierarchies if at all possible. They introduce a command and control element you tried to get rid of earlier. Instead, let the teams self-organize around the problems that are introduced with scaling. Quite often, teams will just introduce a community of practice to solve the roles and knowledge-sharing aspects. They will also be able to find the right amount of meetings: Maybe one joint Sprint Planning and joint Sprint Review (instead of 10 individual meetings) is enough for all teams? Maybe you still need separate meetings, but can shorten them? Maybe people want to listen in on their respective Daily Scrums? Maybe they find this unnecessary? One thing is sure, however: There is one Product Increment, so there must be one Product Backlog, a common understanding of quality and an overarching architecture (not necessarily design). This might lead to a need for common development tools and coding guidelines. However, I have seen many teams that did not use the exact same tools or exact same guidelines and still succeeded. In fact, they made a conscious decision for the better – which you should do as well. Let the people having the problems figure out the solutions!

4. There are >10 Scrum Teams working on the same product

For some reason, having more than 10 teams working on the same product seems to be a natural boundary of some sort. In my personal experience, the coping mechanisms described above did not work as well here as they did in smaller scaled environments. On top of that, I experienced a massive performance drop over and over again when more than ten teams were working in the same code base. Communication needs and coordination overhead seems to grow exponentially. Whenever I have the choice, I prefer 7 to 70 teams mingling in the same code base. My honest belief is that 7 teams can accomplish more in the same time than 70 do. If you do it anyway you will have to introduce some sort of structure. The exact nature of that structure is very specific to your context though – I cannot just draw you the silver bullet here. Just make sure to involve the people affected and try to replace controlling hierarchies with servant leaders, coaching the “subordinated” teams instead of incapacitating them. If you try to use defined frameworks for this scaling approach, make sure you don’t apply them without having reflected over every single aspect first. You might do more harm than good.

5. There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies

Well, if they do not have any dependencies, what do you want to scale? If there is actually an answer popping up in your head, try to figure out if this is just a relic from a time when you still could control everything. For example, some customers claim they need a “common architecture” across multiple products. However, when they take a closer look they usually figure out they neither have nor need this.

6. There are 2-10 Teams (with Scrum or without) working on different products, with dependencies

Different products, but dependencies are what I encounter most often. So this is not about managing many teams on one code base, this is about managing interfaces. You probably have been doing this for years already. The difference with Scrum is that you no longer have silo groups of people but rather cross-functional teams. This can mean that every team having to interact with other products is allowed and capable to touch those products - if they make sure they don’t break anything (automated regression testing comes in handy here). Maybe coordination through communities of practice is enough. Maybe you need a “Scrum of Scrums”. Whatever you do, sit down with your teams and figure out what the problem is. Then use your primary tool (remember the grey mass?) to find solutions together with them. Try to keep it simple – scaling several products through several teams is not necessarily rocket science.

7. There are >10 Teams (with Scrum or without) working on different products, with dependencies

Here the same rules apply. Usually, not all (say, 50) teams have dependencies with all other teams. Especially not if they are truly cross-functional. So it is not any more difficult than 6.
I only encounter such huge unmanageable dependencies if there are remains from the past: A joint “framework” team, providing some stuff for all other teams, not letting them change it themselves. A “core product” team, servicing a huge pile of failure from the past, so messy only these few cracks still understand it – kind of. Or some sort of back-end / front-end separation, resulting in teams always waiting for one another, always claiming “we adhered to the interface specification” and still not achieving a truly “done” product increment.
All these issues are symptoms that you didn’t do your homework. You scaled crap. No process on earth can make this work well without getting rid of the root causes first. This, however, is extremely hard work and not part of the “scaling” domain.

8. The development department is working Agile and now the rest of the organization should align

Most often, IT middle management asks this question. They implemented some sort of Water-Scrum-Fall (meaning programming happened in Sprints, but analysis and QA happened in separate phases) and at some point realized that while they could code better, the other processes did not keep up with their pace and quality. This is natural to happen and a good thing! It is not what I would consider “scaling”, but it definitely is worth discussing. Changing parts of the organization is called “organizational development”. You can only succeed here, if all affected parties have an urgency to change and support your solution (in this case: Scrum). If you accomplished this, you have to develop solutions with all affected parties and generate wins that prove you are on the right track. Do this and stick to the golden rules above (and read more about the topic of organizational change, e.g. here or here).

This article is just a brief overview on the topic of scaling, of course. To find appropriate answers for your specific situation, you will probably have to read and learn a lot (also see the reading recommendations below). In general, stick to the golden rules and always solve problems with your solutions rather than introducing some remedy without knowing your problem.
Enjoy the transition!



Reading recommendations:

Maximini – The Scrum Culture: This explains what cultural impact Scrum can have, how this culture can scale and how to apply Kotter’s model on Scrum introductions.
Kotter – Leading Change: Excellent book about how to go about organizational change.
Larman & Vodde - Practices for Scaling Lean & Agile Development: – One of the best books about scaling Scrum. Be aware though that you are reading an opinion, not a silver bullet.
Lojeski & Reilly - Uniting the Virtual Workforce: Everything you ever wanted to know about virtual teams, including the virtual distance model

When working with different customers, I encounter a pattern over and over again. This pattern is closely connected to the Agile maturity of the Team (and organization). I call it the "Pyramid of Impediments":



When I start working with a team, all impediments popping up are circling around the questions of what Scrum is, how it works and how it can be applied in the specific contexts encountered. For example, a distributed team might ask the question of how to conduct an efficient Daily Scrum. The questions vary, but they are always similar. They form the "base" of the pyramid.
Often starting simultaneously, I as a Scrum Master have to forge a Team out of individuals. So while learning Scrum, they also learn to trust each other and to act responsibly as a team. This team level stuff forms the 2nd layer of impediments.
Once the team is working together reasonably well and has understood Scrum, impediments often shift towards technology. Questions like, "Hey, we want to deliver every two weeks, but we do not have automated regression tests" or, "we need continuous integration facilities if we want to work together with these other teams" are usually coming up then. While I personally don't have a clue how to set these up, I still can coach the team to manage this themselves or escalate it throughout the organization. This is the third level of the pyramid and the first level visibly reaching out to other parts of the organization.
Once technology works well, the impediment focus shifts toward adjacent teams / functions / departments. Basically, the team now can truly deliver "Done" product every Sprint but the rest of the organization can't. So while the Development Team delivers every two weeks, requirements might take eight weeks to reach the team and QA might need another six weeks to put something into production. Understandably, the Dev Team then starts to ask why they should deliver so frequently if the others don't - and good Product Owners ask why the realization of value is deferred that long. So at this level the Scrum Master starts to work along the value chain of creating the product (usually something along the lines of ideation - innovation - requirements elicitation - Product Backlog refinement - product creation (usually already fixed at this point) - quality assurance (if it still has elements separated from product creation) - integration (with several teams or big products) - releasing). Individual cases vary of course, but this is roughly how it works.
Once the whole value chain is optimized, usually other process issues, affecting the whole organization, are hurting. Most often budgeting, career paths, compensation, portfolio management, etc. are focused on. Here, the Scrum Master has to fully act as a change agent throughout the whole organization.


Certainly no impediment is "solved" by the sole competence of the Scrum Master. Instead, he/she coaches the involved and affected parties to find their own solutions and to inspect these regularly. These parties change naturally when moving up through the pyramid of impediments. An excellent Scrum Master can handle them all. If you don't have one, use a team of Scrum Masters with different skills (maybe you have one team forming expert and one change agent working hand-in-hand while facilitating their respective Scrum Teams and influencing the organization...) to supplement each other. Be aware that all "levels" of the pyramid will stay relevant throughout the whole lifecycle of your product/team and one will often "fall back" on a lower level for a time. This is normal. Of course you cannot work on the organizational level if the team is back to "storming" again - you then have to address this impediment first. However, the time being spent on higher level issues increases with time and the maturity of the team.


While all models are wrong, some are helpful. Maybe this one supports you when you are looking for a Scrum Master, evaluating your Scrum implementation or being asked, what the "Scrum Master does all day".

Did you ever argue with a "Scrum Coach" who told you that your Scrum introduction was proceeding too slowly? That solutions you fought hard for were "not agile"? And did you at the same time have the feeling that so many changes were happening at once that you were overrun by them? Or have you been the coach in a transition project and had the feeling that "everything is moving into the wrong direction"?
If this is the case you are in the good company of most people who actively took care of a Scrum introduction.

First, one insight is essential: Neither Agility nor Scrum are ends in themselves. Nobody should try to introduce Scrum just to "have it". That's not the point. Scrum is a tool which helps you to gain transparency and become agile. You only should pursue the goal of Agility if this solves existing problems and improves the whole system at the same time. This means that the purpose of a Scrum introduction is always and without exception the improvement of your organization's ability to compete.
Therefore you have to ensure smoothly running regular operations during a Scrum introduction. This is especially important since such a big change can take months or even years to implement. No company can afford to stay unproductive for so long - and Agility does not just occur over night. As a rule of thumb you can say: The bigger the enterprise, the longer it takes to achieve Agility, as does every single step on this way.
The reason for this high demand of time is that people change slowly. This is a good thing! Imagine a world where every human being fundamentally changes his attitude every five minutes. Chaos would reach a degree most of us shouldn't want to strive for... The same is true for organizations: These systems are usually in an equilibrium that is disturbed by the introduction of agile methods. Now it is important to retain a sufficient amount of stability while allowing some evolution at the same time. Thus there is nothing else for it but to accept the slow speed of change and to adapt to it. Change never happens against the people concerned - it can only be successful together with people. This leads to two conclusions:

We have to make sure people involved in the change do not panic. Everybody will have to leave her comfort zone and move on into the "learning zone". The "panic zone" is then just a tiny step away and must be avoided since panicking people no longer think rationally and are not able to see or even value the positive aspects of this change.
The affected parties must generate successes and realize that they are successful indeed in order to keep their spirits up.
You only have a chance to successfully introduce Scrum and influence the organization's culture positively if both aspects are fulfilled.
"Hybrid approaches" - mixes of traditional and agile processes or ways of thinking - can help to pick people up where they are and take them along while not overstraining them. In practice this means that such hybrids are okay as long as they help the organization and are seen as an intermediate solution on the path to Agility. The introduction of agile methods is a journey - every step into the right direction helps, it doesn't always have to be a quantum leap. Agile Coaches must be aware of this. View the coach as some sort of midwife: She supports the mother-to-be with farsightedness and experience to give birth to her child. But the midwife does not have to go through the pain herself. Demanding to "finish pregnancy faster" or "get the child out quicker" does not help, no matter how fervently it is stated.

While the new book on this topic is still awaiting its publication I will try to explain the cultural aspects of Scrum to conference attendees at the Scrum Day Germany (1st and 2nd of July) and at the Scrum Day Europe (3rd of July). But how is it possible to convey such a complex topic within 40 minutes? How to explain what culture is, how to identify and analyze its components, what critical aspects might lead to conflict? I have no clue and thus decided to tackle this impediment empirically with an A/B Test.

The first approach (in Germany) will be the more traditional one. A fancy (well - more or less...) presentation following a clear path and not necessarily requiring any interaction with the audience. In Amsterdam (Scrum Day Europe) I will conduct a workshop on the topic. The participants will be heavily involved and won't be able to get away without collaborating. Only a couple of slides will set the stage before everybody gets to work. This workshop will be adapted and repeated on the same day.
So while the German conference sets a baseline in participant satisfaction, the new approach will measure twice if the collaborative workshop approach is superior.

The results will then help to improve the explanation method further. I will of course let you know how it went

Did you ever notice how hard it is for people to change? I constantly run into this phenomenon when introducing Scrum.
You don't have to go that far though. Take a look around, you can see it everywhere!

Last week I ate some breakfast at a hotel. The room was not crowded and a couple of other people shared my love for early food. At some point a couple came into the room and went into the direction of the table they supposedly had used the day before. Half way through they noticed that the seat was taken. They stalled and started a discussion about the fact that "their" table was taken. I listened and was kind of amused to see that such a thing could be the topic of a discussion. Interestingly, they did not stop. The couple continued to discuss this for the next 15 minutes. And they were not alone: Some more couples - probably all from the same party - encountered the same problem and reacted exactly the same way. I noticed three of those instances before I finished my breakfast and left.

Using the table next from the one you used before is only a tiny change. It does not outlive breakfast or change your life. Still, it can cause you to leave your comfort zone and thus cause an uneasy feeling. People like their habits. People enjoy their comfort zones. This is human. You never know how the comfort zone of any individual looks like until you exceed it.

If such small changes lead to (at least internal) conflicts you definitely should expect that introducing a cultural change trigger like Scrum (or Agile as such) causes a much higher level of uneasiness and conflict. Be prepared for this to happen and help people by showing them the urgency of the change and the strategy how to solve the riddle. Aid them through their journey. Help them find another - hopefully better - breakfast table!

In case you are wondering about the status of the survey, here is an update for you.
I just started to group and sort the data. Due to the open questions, this is a lot of work though. Please have a little more patience and do not expect a thorough result before late December or even early next year.

Let me know if you have any questions.

The Agile Tour comes to Stuttgart (Germany) next week (16th of October 2013). We took special care in selecting excellent speakers to provide you with an unmatched community conference experience. Ken Schwaber will join us for a virtual talk as well. The primary conference language is German (aside from Gunther's and Ken's talks); if that is fine with you and you haven't booked your ticket yet, you should do it right away. You most likely won't get more for your buck (72 EUR).