Seven sins of a Scrum Master

The Scrum Master will never be responsible for the success of the product. However, they have an important role in helping those who are, the product owner and the team.

A good Scrum Master can significantly increase the odds of success. Similarly, a bad Scrum Master can derail everything, causing disastrous failure. In this article, I will look at seven bad characteristics or behaviours of Scrum Masters I have witnessed.

  1. Not understanding Scrum
  2. Mixing or not understanding the Scrum Master role
  3. The curling parent
  4. Not understanding the work of the team
  5. Not being there
  6. Being busy doing the wrong thing
  7. Ignoring the bigger picture

Some of these, I’ve seen in other Scrum Masters but in other cases, I must admit, I have been the culprit myself.

Either way, the result wasn’t good!

1. Not understanding Scrum

The Scrum Guide introduces the role of the Scrum Master as follows:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

It should go without saying but to be able to do that, a Scrum Master must have a solid understanding of Scrum. Unfortunately, someone being a Certified Scrum Master (CSM) is no guarantee they will have more than a very basic understanding of Scrum. After all, there is only so much you can learn during a two-day course.

Becoming a Scrum Master requires a big mind-set switch for many people. I know from my own experience, starting as a project manager, that this can take time.

Bad Scrum Masters lead to bad Scrum

As is sometimes pointed out: Scrum is simple but not easy. If the Scrum Master doesn’t have a deep understanding of Scrum and why the different parts are important, one of the following is likely to happen:

  • It becomes very hard to coach someone you don’t understand yourself. Scrum risks turning into process for process’ sake, causing the team to experience the overhead of the framework without getting all of the benefits.
  • The Scrum Master and the team end up taking shortcuts or making damaging changes to the framework. Yes, there may be cases when it makes sense to break the rules of Scrum but if we do so, we need to make sure the spirit of the framework is followed.

When reading blog posts claiming that Scrum sucks or that Scrum doesn’t work, the arguments are in many cases built on a misunderstanding of what is or isn’t Scrum. With more than 400,000 Certified Scrum Masters out there, I think it’s fair to say that some of those are guilty of creating such misunderstandings.

A Scrum Master must always strive to learn more

Someone being a certified master at something may make it sound as if they know it all. To be successful as a Scrum Master, we need to realise as soon as possible that’s not the case. There are endless possibilities to increase our knowledge.

Sharing experiences with other Scrum Masters is a great way to learn. You may also be fortunate enough to live in a city with a thriving Meetup scene, with lots of free talks. The internet is full of blog posts, such as this one, just waiting to be read and there are obviously lots and lots of books too.

However, experience comes from doing. That’s when we really learn. Some things we do work well and others much less so. Whatever happens, don’t let valuable learnings go to waste!

2. Mixing or not understanding the Scrum Master role

The Scrum Master role is new to many companies. Often, it doesn’t even exist in the organisation chart. This can easily lead to the role getting misunderstood, diluted or combined with other roles. Either through the organisation having the wrong expectations on what a Scrum Master does or through the Scrum Master being hungry for more responsibility.

A couple of such unfortunate combinations are those of the Project Manager Scrum Master and the Deputy Product Owner Scrum Master.

The Project Manager Scrum Master

A project manager is responsible for the planning and execution of a project. This includes things like managing objectives, scope and dependencies, as well as people (often referred to as “resources”). In Scrum, however, this particular role doesn’t exist. Instead, the product owner is responsible for making sure the right product is being built, through setting objectives, managing the backlog and collaborating with the team to make sure their solutions meet the intentions of the product. The team decides how to deliver the work. This includes the technical approach as well as who does what and how to respond to day to day issues.

If a Scrum Master mix their role with that of a project manager, there is a big risk they will interfere with the other Scrum roles, preventing the framework working as intended. One such pitfall (and trust me, I’ve been there) is when the Scrum Master starts micro-managing the team, assigning tasks and thereby preventing their self-organisation.

The Deputy Product Owner Scrum Master

On some teams, the Product Owner doesn’t have enough time available to fulfil their responsibilities. Some may not have time to attend the sprint planning meeting or the sprint review. Others don’t have time to keep the backlog up to date or to get into the details of the features.

It may feel necessary for the Scrum Master to step in and take on the responsibilities that don’t get fulfilled. The problem, however, arises when these responsibilities start conflicting with those of the Scrum Master role. For example, if the Scrum Master will be the person getting the heat from the stakeholders when some feature isn’t finished in time, it is very easy for them to end up paying less attention to sustainable pace.

When the product owner is not sufficiently available, the solution should not be for the Scrum Master to take on a bigger responsibility for the product. Instead, they need to find ways to help the product owner to make more time available for the team.

3. The curling parent

Being a Scrum Master can sometimes feel like being a parent. The same way a parent want their offspring to do well in life, we want our teams to succeed. And that is obviously a very good thing! However, it can easily go too far.

In Sweden, we have an expression for a certain kind of parents: the curling parents. Just like curling players sweeping the ice in front of the stone, they do everything to remove all obstacles so that their kids can go through life without a bump. While well intended, this prevents the children from developing their necessary life skills and make them ill-equipped to deal with problems.

The Scrum Master equivalent is the one who spots and removes all impediments for the team. And whatever the team does, the Scrum Master accepts it or even encourages it.

The over-protective Scrum Master prevents learning

When a Scrum Master shields the team from reality too effectively, they will prevent the team from performing as well as they can.

Kids are tougher than some give them credit for and so are team members. For instance, if there is a deadline, the team needs to know. They also need to understand the consequences of missing the deadline. Obviously, I don’t mean in a “You will be sacked” kind of way but in a “We’d miss important business from the such-and-such tradeshow” one. Don’t hide from the team that what they do is important! Likewise, while it is probably not useful for the team to be shouted at by a stakeholder, they need to know if stakeholders are frustrated or disappointed.

Just like in the point above, where I pointed out that Scrum Masters learn through doing, so does the team. If they don’t have to deal with problems, we limit how much they can learn. And whenever a Scrum Master steps in to save the day, they prevent the team from self-organising.

Mind you, this is not to say the Scrum Master should watch silently if the team is about to walk into an unrecoverable disaster. After all, letting a child walk out in front of an approaching lorry is unlikely to teach them much.

Don’t remove all the impediments

The goal of a Scrum Master shouldn’t be to remove all the impediments for the team but rather that the impediments get removed. Otherwise, there will be a single point of failure; if the Scrum Master isn’t there, the impediments won’t get removed. Also, and equally important: the Scrum Master won’t be the best equipped person to deal with every impediment that comes up. Often, peers talking to peers is much more effective!

A Scrum Master needs to coach and mentor the team

A Scrum Master is not just a facilitator. They also need to coach and mentor the team. When the team is inexperienced with Scrum and agile, they won’t magically know how Scrum is supposed to work. In these cases, the Scrum Master will need to be more directive when it comes to processes than on an experienced team. Sometimes, the team needs to get a chance to see things in practice by the Scrum Master directing the process.

This can admittedly be tricky with an unconvinced team. A Scrum Master has no power to force anyone to do anything. Instead, they need to make their case and get the team on-board. When making suggestions, being able to share stories like “one team I worked with solved a similar problem by…” will be much more powerful than “according to the Scrum Guide…”. Another way to convince people to do something is to suggest it as an experiment for a sprint and see how it goes.

Another part of coaching the team is to help them hold themselves accountable. A Scrum Master should not be afraid to point out when something is wrong, if other team members don’t. For example:

“I’ve noticed that you’ve missed the sprint goal you set yourselves for the last three sprints. Why is that? What are you going to do about it?”

Or:

“Guys, delaying the testing until the next sprint means you don’t deliver anything shippable. That would be bad as blah blah blah”

4. Not understanding the work of the team

A Scrum Master doesn’t have to come from a developer background. However, I’ve certainly found it useful to understand on some level what the team are doing when I’m trying to help them. Both from a technical perspective and what the product is aiming to achieve. I wouldn’t be able to do the job of a developer these days but I strongly believe that having some developer skills makes me better at my own job as a Scrum Master.

Understanding what the team are working on helps me spot issues and better grasp what causes them. Being a Scrum Master also requires an amount of respect. Being knowledgeable is one way of building that respect. Otherwise, I’d risk being just a process guy.

Scrum doesn’t work in isolation

Not everyone is a developer, tester or designer and very few are skilled at everything. That’s fine! That’s why we’ve got those people on the team.

However, as Scrum Masters, we should strive to understand as much as we can of what’s going on:

  • We need to take interest in the work of the team. That includes spending time with them so we can see and hear what’s going on.
  • When there is something we don’t understand, we should try to learn more. Either we can get someone to explain or we can make a note and look it up on the web later.
  • Talk to the Product Owner to understand the product and its goals better (I also find I learn a lot about the product when I get a chance to go along to user testing).

And if you feel particularly brave, and if it’s not too disruptive to the work of the team, how about a bit of pairing?

5. Not being there

The first rule of being a Scrum Master is to be present. While I might have just made that rule up, a large part of the job is to hear and see what is going on. Much of the communication in a team will be verbal and that requires the Scrum Master to be there to hear it.

If the Scrum Master spends too much time away from the team, whether it is meeting stakeholders, working from home or attending conferences, they won’t be able to do their job as well as they could.

In my opinion, it is overly strict to say that every team needs their own, dedicated Scrum Master. Often, they do in the beginning but when the team and process is working well, their Scrum Master may well have some spare capacity. However, even so, Scrum Masters should not be spread too thinly. For me, the limit tends to be two teams. Beyond that, there is just too much meetings to be able to do much else.

6. Being busy doing the wrong thing

The purpose of a Scrum Master isn’t taking meeting notes or creating timesheet reports. Neither is it to keep the task board or Jira up to date. If a Scrum Master becomes the go-to person for everything or if a large part of their time is taken up by admin duties, it will limit how well they will be able to do fulfil their Scrum Master responsibilities. A Scrum Master spending their time doing the wrong things is troublingly similar to the previous point, not being there at all.

Some of these activities may be forced upon the Scrum Master. Others they happily take upon themselves. For instance, I can find it quite satisfying to create nice-looking charts or well-structured wiki-pages with lots of information. It is up to us as Scrum Master to ask ourselves frequently: is this really the most valuable thing I could be doing right now to help the team succeed?

7. Ignoring the bigger picture

Issues outside of the team may have a significant impact on what the team are able to achieve. However, it is often temptingly easy (and more comfortable!) for a Scrum Master to just focus on the team. They are the people we work with every day and we’ve hopefully had the chance to build up a certain amount of respect for each other. The factors outside of the team are harder to deal with, so we accept them as that’s how it’s always been.

The reach of a good Scrum Master goes far beyond the team

When solely focusing on improving things directly within the team’s control, the result likely result is sub-optimisation. The team ends up spending a lot of effort to achieve very small improvements, as they are only able to work around the problems rather than solving them. For instance, imagine a project needs to meet a fixed functional specification. Such a specification is in direct conflict with the concept of emerging requirements that are at the heart of Scrum. Sure, it is possible to optimise how to deliver what is asked for, but that won’t necessarily deliver the desired outcome of the project.

For an inexperienced Scrum Master or within a very hierarchical organisation, it can admittedly be easier said than done tackling problems outside of the team. It may take a lot of tools and techniques. Some examples:

  • Talk to people. Yes, it can be that easy – or hard, depending on how you look at it! Talking directly to someone can achieve things much quicker than a potentially contentious email. And sometimes a casual chat by the coffee machine is much easier than arranging a formal meeting.
  • Team up with other Scrum Masters. If an issue is affecting a lot of people in the company, chances are it will get more attention.
  • Use hard numbers to make the case, e.g. “The team lost a man-week just in the last sprint working around this problem”.
  • Coach people outside of the team, too. It’s not just the team who need to understand how and why Scrum works!
  • Find allies. Find the people we can make understand what we’re trying to achieve and make use of their support. Maybe the line manager of the team members? Or the product owner’s boss?

The good news is that sometimes, once we dare to take that step outside of our comfort zone, the change isn’t even that hard after all! Just because something has always been in a certain way doesn’t mean there is a good reason for it.

Conclusion

Does showing these behaviours make someone a bad Scrum Master? Well, they certainly won’t contribute as much to the team’s success as they should and could. However, in my opinion, the only genuinely bad Scrum Master is the one who doesn’t learn. Just like the processes in the teams, we need to continuously improve ourselves. That’s how we get great.

 

13 tips for an effective retrospective

According to the State of Scrum survey from 2015, almost one 1 out of 5 teams don’t bother having a sprint retrospective. This is a real shame as they miss out on one of the best and most important parts of Scrum: trying to make every sprint a little bit better than the one before.

A cautionary tale

The two main arguments against retrospectives I tend to hear are:

  • “We don’t have time for retrospectives. We’ve got real work to do!”
  • “Retrospectives are pointless. Nothing changes anyway!”

I’ve been there too. On one team in particular, I discovered the hard way what could happen if you scrap retrospectives. We didn’t actively set out to do it but we were up against a tight deadline a couple of sprints away. On a whole, we thought our process was working ok, so we said “Let’s not do a retrospective this sprint and use the extra hour to complete more work in the sprint!”.

The next sprint, the deadline was obviously even closer so we skipped the retrospective again. And again. The deadline came and we missed it. That meant we really had to finish things in the next sprint. Definitely no time for a retrospective!

The result wasn’t good. Not only did our process not improve but it deteriorated. It should have been obvious that we had a problem with the pace not being sustainable but rather than stopping up for a second and thinking about how we could make things right, we just kept rushing ahead, thinking that we could talk about the process once we’ve delivered what we needed.

Only that we didn’t deliver. It went so far that we finally had to stop and go back to basics, reintroducing Scrum almost like a team would introduce it in the first place. By then, we had wasted a lot of time and effort.

Better retrospectives

The second argument against retrospectives is that they are pointless and nothing ever changes anyway. That can certainly be true but it doesn’t have to be that way. In this blog post, I will list some of my learnings from facilitating retrospectives over the last 10 years.

1. Don’t let it get boring

Repetition is the enemy of a good retrospective as a boring retrospective makes it hard for people to engage. As a facilitator, it is important to try to shake things up and introduce a bit of variation.

Also, if we always ask the same questions in the retrospective (e.g. “What went well? What didn’t go so well? What will we do differently next time?”), there is a risk we will keep getting the same answers. Mixing things up will help identifying different problems and create more creative solutions.

Some ways to vary retrospectives:

  • Use different exercises. If you lack ideas, there are lots of sources of inspiration on the web and even whole books on the subject. I’ve found many good ideas on the website Retr-o-mat.
  • If you tend to always let people write ideas on sticky notes (and most retrospective exercises tend to do), how about once in a while getting them to just shout them out instead? Or just have a good old chat?
  • Take turns facilitating (see point 10)

2. Use a check-in exercise to get a feeling for what’s going on

A good way to start a retrospective is with a quick check-in exercise. This has two benefits:

  • The participants get warmed up and into the mood for the retrospective.
  • The facilitator can adjust the rest of the retrospective based on the mood of the team and the issues raised.

Basic examples of check-in exercises can be to let the participants rate the sprint by using a number between 1 and 5, an emoji or a word. The participants take turns revealing their answer and explain to the group their choice in just a sentence or two. Make sure to avoid any lengthy discussions at this point. A check-in should be quick. If something is worth talking about, someone will most likely bring it up in the main exercise.

3. Help people make themselves heard

Some people love talking while others are quite happy just listening. That doesn’t necessarily mean they are not engaging in the discussion. However, it is important that everyone gets plenty opportunities to make themselves heard.

Some tips that can help:

  • If only a few people talk, try to bring the others into the discussion. For example, simply ask “What do the rest of you think?”
  • Use exercises where participants get time to write down their points on sticky-notes. Rather than everyone putting their notes up on the wall in one go, let each participant put theirs up one by one and explain what they mean.
  • When there is a natural pause in the discussion, avoid stepping in to fill the silence by asking a question. Instead, wait for people to speak.
  • Sometimes, splitting the group into smaller groups can help (see the next point)
  • Don’t put people on the spot. People are perfectly entitled to choose to remain silent. Don’t call them out in the retrospective. Instead, talk to them individually afterwards to understand why they were silent.

4. Make room for discussions by splitting into smaller groups

One technique I’m starting to use more and more, particularly when the team is quite big, is to split it into smaller groups for part of the retrospective. I find this is particularly useful when coming up with suggestions for actions to a specific problem:

  1. Agree the problem to discuss
  2. Split into small groups to discuss why the problem is happening.
  3. After a while, switch to identifying solutions. Still in the small groups.
  4. Let the small groups report back to the whole group, discuss a bit further and agree which solutions to proceed with.

5. Sometimes, you may want to identify a topic beforehand

Occasionally, it can be a good idea to identify a topic beforehand and use the retrospective to dig deep into that topic. This can for example be the case if some issue was brought up earlier but there wasn’t time enough time to find a good solution. Another example is when a team is new to Scrum and some bit of the framework isn’t working as intended but the team don’t know enough about how it is supposed to work or why.

Whenever I prepare a topic beforehand, I follow these three rules I have set myself:

  1. Don’t do it too often. The retrospective is the team’s meeting. They are the ones who should be identifying and solving problems. If I keep telling the team what I think the problem is, chances are I will miss the real problem.
  2. Use a check-in exercise (see point 2) to make sure there are no other big burning issues.
  3. Ask the team for permission. They may have more pressing things they want to discuss. Again, it’s their meeting!

6. Get to the root cause

I’ve written about this before so I’ll keep it short. Before identifying solutions, make sure you are tackling the root cause of the issue you are seeing, rather than just the symptom. Otherwise, the problem may go away in the short term, but resurface later. Either the same issue again or some different problem caused by the same root cause.

One simple method for root cause analysis is the 5 Whys. If you’ve set aside a whole retrospective for a single topic, a method like cause flow diagrams can also be a good help.

7. Identify clear actions

Making the next sprint better than the previous one requires us to identify actions. What will we do differently next sprint?

Good actions are:

  • Clear and actionable. It is hard to complete an action like “Better acceptance criteria” as it’s far too vague. Where do we even start? “Schedule a weekly backlog grooming meeting to make sure stories have sufficient acceptance criteria ahead of the sprint planning meeting” is much clearer.
  • Within the team’s remit. “Improve the stability of the build server” is not an action the team can complete if the build server is maintained by an Ops team. “Meet with the Ops team to explain why the build server needs to be more stable”
  • Likely to solve the problem or at least contribute to solving it. This may seem obvious but it is easy for a discussion to go down a side track, coming up with unrelated actions.

However, I don’t think it’s fair to say that a retrospective without actions is pointless. For instance, if the sprint has been fraught with conflict, talking to each other to understand each other’s perspectives can be exactly what’s needed. Nevertheless, if not most retrospective identify concrete actions to improve the way of working, there is a problem.

8. Don’t list too many actions

You don’t have to capture actions for every single point raised in a retrospective. In fact, it’s much better if you don’t! As so often, less is more. If we only list the top few actions, chances are much bigger we complete them. It will also be easier to judge what changes are successful or not when there is not too much change going on at once.

The simplest method for narrowing down a list of actions is the ubiquitous dot voting:

  1. Merge any actions that are very similar, to avoid splitting the vote.
  2. Give the participants three sticky dots, or however many you prefer. If you are less equipped in the stationery department, a marker will work just as well!
  3. Let people place their dots on the three actions they vote for. If they feel strongly about a particular point, they can put more than one dot, and consequently vote for fewer actions.
  4. The actions with the most dots are your actions.

You can also use this method earlier on in the retrospective, to decide in which order to talk about the topics raised.

Finally, one surprisingly easy trap to fall into is to assume that just because someone is suggesting something, it is a good suggestion and we should do it. The originator of the idea obviously think their idea is worthwhile but don’t write it down as an action unless there’s been some discussion. If there seems to be different opinions, it is worth putting it to a vote.

9. Don’t bother with detailed notes

In terms of note taking, the important thing is to record the agreed actions. In my experience, anything above that doesn’t tend to be very useful.

At best, it is just busy-work, making the Scrum Master feel useful. It is quite rare for someone to refer to the old notes anyway. Worse, though, is that notes can also be in direct conflict with an important rule: whatever happens in the retrospective stays in the retrospective. For a retrospective to be worthwhile, people need to feel comfortable sharing their opinions. If there is meticulous note taking, making a record of everything that is said, this can limit what people are confident raising. Particularly if these notes are made available outside of the team, such as on a shared wiki.

10. Take turns facilitating (or get someone else to do it)

If the Scrum Master always facilitates the retrospectives, there can be a risk they feel like something that is done to the team rather than by the team. With a team used to having retrospectives, it can be a good idea to rotate the facilitation role in the team.

With someone else facilitating the retrospective, the Scrum Master can also take a somewhat more active part in the discussion. If no one in the team is up for facilitating, or if the team is too inexperienced to do so, getting a Scrum Master from another team to facilitate would also help with that.

Finally, different facilitators is a great way to create that important variation mentioned in point 1.

11. Don’t let the Scrum Master own all the actions

The default owner of the actions shouldn’t necessarily be the Scrum Master.

Most of the work going on in the sprint is not something that the Scrum framework describes but technical work. Unless the Scrum Master is also a hands-on developer, chances are the team members will be better equipped to carry out the actions.

12. Don’t forget about the actions

Just because something is agreed in a retrospective doesn’t mean that it will automatically happen. It is surprisingly easy to forget about the actions. Out of sight, out of mind. Suddenly, it’s the next retrospective and we have completed none of them!

That’s why it’s so important to make the actions visible somehow. A page on a wiki or an email is rarely enough as it requires people to actively go and look at it. Something more “in your face” is preferable. One way is to post the actions visibly on the wall. Another is to add them to the sprint backlog.

Also, make sure to follow up on the actions in the next retrospective. Did we complete the actions? Did they create an improvement?

13. Don’t wait for the retrospective!

Finally, don’t let the retrospective get in the way of continuous improvement. It’s not necessary to wait until the retrospective to raise issues or make suggestions. If something goes bad or someone has a great idea, it may well be better to deal with it there and then. Every time the team gets together is an opportunity to inspect and adapt!

Conclusion

With all the points above in mind, this is a structure I’ve found tends to work well for my teams:

  1. Start with a check-in exercise
  2. Go through the actions from the previous retrospective
  3. Gather opinions
  4. Identify what to focus on
  5. Discuss
  6. Agree actions
  7. Summarise the actions

5 situations when Scrum may not be your best choice

Not every story about Scrum is a success story. Scrum can fail.

One of the reasons why many teams don’t get the value out of Scrum they were hoping is that they are trying to use it in a situation or environment where it is not appropriate. No set of practices will work in every single context and Scrum is no exception.

Let’s look at some examples where Scrum will either be very hard to make work or provide little value compared to a simpler process.

1. When the requirements are not allowed to evolve

Scrum is aimed at solving complex problems. The kinds where we are unable to judge up front exactly what will be the best solution. That’s why Scrum takes an iterative approach, building something, getting feedback and adjusting the course.

Requirements emerge. Rather than working towards a fixed specification and scope, we learn what do deliver. If we’re used to having a detailed specification up front, Scrum will be a big change. Basically, we’re saying we don’t know quite what we will build or how much of the functionality we will be able to complete within the timeframe but believe us, it will be the best thing possible we could have done! That requires a large amount of trust.

Certainly, a fixed product specification may be no guarantee a project will be successful but it can give us a sense of reassurance that is hard to let go of. Not least for the customer signing a contract!

If we have no interest to learn what to deliver, and think we have it all mapped out already, Scrum won’t be of much use.

2. When the organisation is unwilling to adapt itself to Scrum

Scrum comes with a set of practices that work well together. Leave some out, however, and the result can be very different. Some of these practices are easy for most teams to adopt. Others can take a lot more effort to implement and have impacts outside the team. Some even make it necessary to make changes to the organisation itself.

Not only does Scrum bring with it new job roles in the form of the product owner and the scrum master. We also need cross-functional teams, meaning they need team members who together have all the skills needed to deliver the work from start to finish within a sprint.

Being cross-functional is how the team can reach a potentially shippable increment by the end of the sprint. Doing so allows them to adjust quickly to the emerging requirements, without needing to go back to other teams to request changes.

Cross-functional teams require people with skills who may not be part of the team today, e.g. skills in business analysis, user experience design, database administration, testing etc. This can be a fairly big organisational change.

If not willing to make that change, we won’t be able to get the full value out of Scrum.

3. When looking for a one-stop solution to all our problems

Scrum won’t solve all our problems. In fact, the State of Scrum survey from 2015 states that 38% of all Scrum projects fail (that is still a lot better than the average for software projects, though).

Some of those projects would have been doomed regardless of which approach they took. However, there will be a good few that could have been successful projects, where Scrum was both suitable and followed 100% but the project failed.

Scrum by itself won’t solve any of the following issues:

  • No product vision
  • Lack of good technical practices
  • Skill-shortage
  • Conflict in the team

Etc.

At best, it can help making these problems more visible.

To create a good product, we need to add other, more hands-on practices on top of Scrum. On the technical side, it is for example common to combine Scrum with various practices that are part of Extreme Programming, XP.

4. When frequently needing to respond quicker than a sprint allows

Scrum assumes that we can plan what to do in a sprint. When building a brand new product, this is often fairly straightforward. Once the product goes live, though, we tend to start getting requests from stakeholders and users that are affecting the live system and real users, right now. These can be bugs or requests for changes or additions. Some of them, we can simply add to our backlog and deal with in a future sprint. Others, though, are urgent and we need to address them. Now!

On a mature product, where we will have delivered a lot of functionality over a long time (or even several different products!), these kinds of requests can end up consuming a large proportion of the team’s time. Our sprints will no longer have the nice, clear focus we were able to have at the beginning and we need to allow for unpredictable, unplanned work popping up in the middle of the sprint. It’s just not good enough to say that we’ll schedule a bug fix for the next sprint if it prevents the users from using the product!

One common workaround is to set aside an amount of time in the sprint for these kinds of fixes, for example 20%. Another is to rotate the responsibility amongst developers to deal with the disruptive requests. Both these methods can work well, up to a point.

However, some teams find that a large part of their work ends up consisting of little tasks with no coherence. The problems they are solving are no longer complex and responding quickly is more important than creating innovative solutions.  In these cases, planning work into sprints the Scrum way will no longer give us much benefit. In fact, it would rather add unnecessary overhead.

5. When people have had bad experiences with Scrum already

Finally, let’s also acknowledge that a lot of weird stuff happens the name of Scrum. With so many people practicing it, many will have had experiences of Scrum not working. They might go as far as saying that Scrum sucks.

The reasons for their experiences may vary. Perhaps they were forced to use Scrum in an environment where it wasn’t appropriate. Maybe they did it wrong. Or they used something else that work better for them than Scrum did.

In these cases, it is useful to understand where the distaste for Scrum is coming from. Is it based on some misunderstanding we can clarify? However, forcing Scrum upon someone is unlikely to be very successful. After all, a self-managing team decides how to do the work. The ultimate consequence of this is that they can decide whether to use Scrum or not.

Let’s not limit ourselves to one framework

As scrum masters, it is important to understand that Scrum won’t work in every situation. We shouldn’t be tempted to introduce it wherever we can, without considering its suitability. Neither should we hang on to Scrum at all cost when it isn’t working.

In many cases, Scrum is an excellent framework. When it isn’t, let’s try to understand why it’s not working in that situation. Maybe people need a bit of training or there are impediments that can be removed? In some cases, however, Scrum just won’t the best solution.

After all, other frameworks are available.

Don’t lose track of the big picture

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where–” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

Alice’s Adventures in Wonderland, Lewis Carrol 1865

One of the most important things Scrum sets out to do is to increase our chance of building the right thing. We deliver working software in short sprints and make sure we get frequent feedback from our customers and/or users to see that we’re on the right track. If it turns out we’re not, we correct the course and adjust our product backlog.

That’s all well and good, but is it enough?

If we’re not careful, we risk focusing too much on getting our heads down and completing as much work as we can. If we don’t have a clear vision for what we’re trying to achieve, the danger is we might end up just a “bunch of stuff”. Albeit very efficiently.

Further, if our innovation only happens within the sprints, we also limit how innovative we can make the product. There is, after all, very much a limit to how ground-breaking our ideas can be if we also need to implement them, all within just a couple of weeks.

Product development requires us to see the big picture

Perhaps surprisingly to some, the Scrum framework doesn’t tell you anything about how to handle the product vision or strategy. Look for either of those in the Scrum Guide and you will find nothing.

However, for a product owner who is responsible for maximising the value of the product, they are essential.

Even, or particularly, in Scrum, we need to know what we are doing and why:

  • Product vision why are we doing what we’re doing?
  • Product strategy – what is the path to achieving our vision?
  • Roadmap – how do we implement the strategy?

Without these in place, the risk is that we just get too bogged down in the day-to-day, tactical delivery. We end up making small, incremental improvements that make things slightly better but fail to create that awesome product.

Product vision

The product vision answers why we’re doing what we are doing. A couple of examples:

  • Ikea: “To create a better everyday life for the many people”
  • Spotify: “Give people access to all the music they want all the time – in a completely legal & accessible way

Admittedly, these are corporate visions rather than product visions, but I like them nevertheless. They show how a good vision is short and memorable.

Product strategy

The strategy describes the path to reaching the product vision:

  • Who are we targeting?
  • What problem is our product solving for them? What benefits does it give them?
  • What is our product and how does it stand out from the competition?
  • What are the business goals of the product?

One way to formulate this strategy can be to use a Lean Canvas as template.

In contrast to the product vision, which is unlikely to change, the product strategy can and should be updated as we learn more about the product through the experiments and features we deliver in our sprints.

It can even turn out that our strategy is completely wrong and we need to replace it with something different. The sooner we find that out, the better!

Product roadmap

The roadmap describes the major steps we’re aiming to take to achieve our product strategy. 12 months is a typical timeframe as it is hard to try to predict too far into the future what we will be doing. After all, the product strategy (and the roadmap, obviously) may change as we learn more.

A roadmap should focus on the big picture and not contain too much detail. A too granular roadmap would not only waste our time but also risk locking down what we’re doing, too soon. If we say we will deliver the such-and-such widget in February, someone might assume that means we will! A roadmap needs to evolve as we learn more.

Therefore, it is a good idea to base the roadmap on bigger themes or goals. What are the main outcomes we’re aiming to achieve and how?

For example, for each of the next four quarters, list in a grid:

  • The overarching goal for the quarter, e.g. “increase the number of users”.
  • The main features, on a high level, e.g. “30 day free trial, simplified user registration, social media integration”
  • How we know if the goal has been met, e.g. “10,000 new active users”

A nice template for a roadmap like this is can be Roman Pichler’s GO Roadmap.

Involve the team and stakeholders in creating the roadmap

A roadmap is not of much use if it only lives inside the head of the product owner. It needs to be seen and talked about.

If the product owner drip-feeds work to the team, with no visibility of the roadmap, how would the team be able to make sure that they tackle their work in a way that aligns with the roadmap?

It would also be a mistake not to involve the team and stakeholders in the creation of the roadmap. We would not only miss out on the insights they could have contributed to make the product better. It would also make it much harder to get people’s buy-in into the roadmap later.

One useful exercise when creating the roadmap can be to identify the goals and key deliverables through Impact Mapping. This can also help us make sure that everything we add to the roadmap fits with the product strategy.

Where does the product backlog fit?

Finally, for completeness, where does the product backlog sit in all this?

The product backlog is the prioritised list of what the team will be (or could be – we don’t have to complete everything in the backlog). This also includes bugs that need fixing, as we need to be able to say whether fixing a particular bug is more important than completing some feature.

The top items in the backlog are very granular, so that they can be completed within a sprint. Items further down are bigger and will need to be broken down before we can work on them.

The items in the backlog should deliver the goals in the roadmap. Chances are there will also be some things for which it isn’t clear how they contribute to the goal. That should make us ask whether we should be doing them at all. Yet another reason to make sure everyone is familiar with the roadmap!

Summary

The product vision explains why our product exists and the product strategy describes the path to getting there. Based on these, we create a roadmap which describes the major steps, or goals, we need to take over ne next 12 months as we work to implement the strategy.

Together, they help us deliver a better, more focused product by preventing us from geting lost in all the detail in the backlog.

 

What is potentially shippable about anyway?

One of the core concepts of Scrum is to produce working software each sprint. The Scrum Guide is very clear:

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

This is what we often refer to as potentially shippable. It means that the features we’ve completed so far are not only code complete but have also been tested and are free from any critical bugs. At the end of the sprint, if the product owner says “awesome, let’s release this!”, we would be confident to do so. And that without us then having to integrate, do functional testing, code refactors, performance testing, bug fixing and so on.

Without potentially shippable software, we’re missing the point of sprints

There are several reasons why the potentially shippable increment is so important:

  • Shorter feedback loops. The most valuable feedback from customers and users is the one they give us once they can see and use the functionality we have built. Only then will they be able to say definitely “yes, this is what we need”. The less frequently we’re able to show them working software, the bigger the risk that we are building the wrong thing.
  • Creating value. Imagine that we run out of time in our project or that we have to move on to something else. Everything being 60% complete would mean we would have delivered nothing. “Oh, yeah, much of the functionality is there but there are a few horrible bugs and we need to build the UX”. In contrast, consider if we had built 60% of the features to a shippable state. We could ship and people would be able to use the product to do most of the things we intended.
  • Avoiding surprises. If we integration and testing to the end, or do it in bigger batches every few sprints, chances are we are in for some nasty surprises. We might well come across some quite fundamental bugs or incorrect assumptions, which will take significant time to fix. Our release burn-up that was showing we were on track to hit our deadline turns out to be a complete fabrication! This is why the Agile Manifesto states that working software is the primary measure of progress.

Release sprints could tempt us to defer technical debt

Some suggest having a “release sprint” or “snagging sprint” before going live, to complete those final things needed to be truly shippable. However, in addition to the risks described above, this could lead us into temptation. Why bother with bug fixes, refactoring and so on now if we could focus on building new functionality instead?

Technical debt, such as this, will not only make the code harder and slower to work with. The longer we leave bugs and bad code, the more expensive the fix will be. By that time, will we have moved on to other features and forgotten about the intricacies of the code. We will also have added additional complexity, making the issues harder to fix than if we did it sooner.

Potentially shippable doesn’t mean it must be shipped

One important thing to point out is that a potentially shippable increment doesn’t necessarily mean that we will ship it. Quite often, we need to complete additional functionality before something becomes valuable to the users.

For example, imagine we are building a room booking system. As our first sprint goal, we make it possible to book a room. You can’t yet choose which room to book and you can’t edit or delete your booking, though. And you can’t see whether the room is available before booking it.

We built this functionality as a potentially shippable increment so we could release it. If we did, it would allow people to book this one room. Awesome! Do we ship it? Probably not, as it wouldn’t be all that valuable to the users yet.

Not shipping must not mean not learning

What we must do, however, is to make sure we learn more about our product from each product increment. If we were to spend four sprints before finding out that our underlying assumptions were wrong, we will have wasted a lot of effort!

The ultimate learning is shipping the product and see how it performs in the wild. However, if that’s not possible, we should try to get as close as possible. This could for example include deploying the increment to a “like-live” environment where the customer and/or other stakeholders can play with it to confirm it does what they expect it to.

Getting to potentially shippable increments may take time

It can be hard and take time to become able to produce truly shippable features in each sprint. However, we shouldn’t let that stop us from trying to get as close as possible.

The three main things to work towards are:

  • A product backlog made up of user stories. The backlog items we bring into our sprints need to be “vertical slices” of user-facing functionality, rather than technical tasks, so that they can be shipped separately.
  • A sufficiently strict Definition of Done. The Definition of Done defines what needs to be completed for each story to be considered done. We need to work towards this including everything we need to do to for the story to be shippable. This will typically include things like code complete, unit tested, user acceptance tested, performance tested, signed off by product owner (or customer), relevant documentation updated etc. Start by including what is feasible now and keep improving the DoD until ‘done’ means ‘shippable’.
  • A cross-functional team. To be able to produce a potentially shippable increment, the team needs to be cross-functional, so that it doesn’t depend on anyone outside of the team in order to be able to do this. This means the team can’t just include people with programming skills. It also needs those with skills in requirements gathering, user experience design, testing etc.

Not always possible

In some cases, it won’t possible to get to a position where we can just press a button and ship. For example, to release an app to the Apple app store, the app needs to be approved by Apple. They may come back and say that we need to change something. Therefore, until the app has been approved, we’re not strictly done.

This approval used to take up to ten days, which would make it impossible to fit it into a sprint. In this case, the Definition of Done would probably include “ready to send to Apple for approval” rather than “approved by Apple”.

Wrapping up

Finally, how do we know we have reached a point where our product really is potentially shippable? I quite like Troy Magennis’ approach. He suggests doing an anonymous survey to ask the developers “would you ship tomorrow?”. If high percentage say no, you are not there yet.

A cross-functional team isn’t a bunch of generalists

For the first few years of my Scrum Master career, I had a fundamentally incorrect understanding of what the term “cross-functional team” means.

I thought it meant that everyone on the team could do everything. There was no room for specialised testers, database administrators or business analysts on a Scrum team. And just because someone is a JavaScript guru, that didn’t mean that they could expect to be writing JavaScript code.

Fair enough, I thought. Somehow, though, the team members were less than enthusiastic about the concept. It turned out that it was important to them to be brilliant at their craft. And to be able to be experts, they needed to specialise!

To build amazing products, we need amazing people. As simple as that. Luckily, I was wrong and a team being cross-functional doesn’t mean it shouldn’t include specialists.

This misunderstanding doesn’t seem uncommon. In this article, I will therefore explore the concept of the cross-functional team a bit further.

What does it mean for a team to be cross-functional?

If a team being cross-functional doesn’t mean that everyone on the team can complete every task, then what does it mean?

I quite like Henrik Kniberg’s definition:

Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

When a team is cross-functional, it doesn’t depend on anyone outside the team to be reach its sprint goal. This means that the team doesn’t only consist of people who are good at writing code. It also needs people who are good at understanding the users’ requirements, designing good user interfaces, making sure the functionality is thoroughly tested and so on.

Again, this doesn’t mean that everyone on the team can do all of that. Just that there’s someone who can perform those responsibilities.

The team is collectively responsible. Not the individuals.

In Scrum, a cross-functional team is collectively responsible for meeting the sprint goal. They all work towards the same goal and it is no room for people saying something isn’t their job.

“I did a brilliant UX design. It’s not my fault the developers couldn’t build it.”

“Well, I suppose technically I did introduce that bug when I wrote the code but it’s the testers job to pick those things up.”

“These requirements are bonkers but, hey ho, I just write the code”

Occasionally, people will need to step outside their main area to do something someone else might have been able to do quicker or better. Maybe that other person is busy or ill. Either way, if picking up that task will get the team closer to the sprint goal than doing something else, people need to be willing to do so.

Why is having a cross-functional team such a big deal?

There are several reasons why Scrum focuses so much on cross-functional teams.

A cross-functional team comes up with more creative solutions

In a traditional waterfall approach, innovation happens primarily at the very start of the project. Any ideas further down the chain are ignored and there are even change management processes in place to avoid such changes.

The cross-functional team, on the other hand, is responsible for all parts of the delivery, including the innovation. As the team members have a diverse set of skills, experiences and perspectives, the solutions they come up with are more likely to be creative.

Eliminating external dependencies helps the team to be more productive

It may seem as if having a business analyst team, a user experience team or a database administrator team, would be more efficient. That way, people would always be doing the things they do best, so their skills don’t go to waste.

The problem, however, with such a solution is the number of dependencies it creates. Avoiding dependencies whenever we can is marvellous as it enables us to:

  • Reduce waiting time. For instance, imagine the developers need a small change to the database. It they have to request that change from the database administrator team, chances are the DBAs have other, higher priority tasks.
  • Avoid work-arounds. When waiting for another team would mean we would miss our sprint goal, we might try and find a workaround instead. Such workarounds not only create extra work initially. They also add more complexity to our code and will require testing and maintenance in the future.
  • Create simpler solutions. If another team needs to do their work ahead of us, may build more or something different than we need, which will make things more complex, for no good reason.

Increased flexibility makes it easier to respond to change

As agile requirements evolve, it is important that we can respond to changes easily.

For instance, let’s say we realise through user feedback that we have missed a special case. Fixing this will require us to first clarify some minor details about the requirements. Then we need some small changes to the user interface and the database, update some of the logic. And, of cause, update the test cases.

If each of those small tasks must be solved sequentially, by a separate specialist team, chances are we’re looking at several weeks or even months to make this change. In contrast, a cross-functional team might well be able to complete all those little tasks in a sprint.

How do we make our team cross-functional?

Creating truly cross-functional teams can be hard and take time. However, by starting with where we are and making small incremental changes, we can increase the cross-functionality step by step. Ask: what can we do right now to reduce our dependencies on those outside of the team?

Don’t try to keep people busy with tasks within their core skills in the sprint

Trying to utilise everyone’s specialist skills to the maximum may seem efficient but will lead to sub-optimisation.

For example, creating a lot of backend functionality that will just sit and wait for a front-end developer to become available is wasteful. Likewise, if the testing is running behind already, pulling in even more development work from the next sprint would just reinforce that problem.

And when everyone is busy doing their own stuff means, they won’t get a chance to learn from each other.

Building up the skills in the team

The ideal team member of a cross-functional team has a deep knowledge in a certain area but also some knowledge in other areas. This is often referred to as “T-shaped skills”. Again, not everyone has to be able to do everything.

One way to find out where the team needs more skills is to help them create a skills matrix.

  1. Let the team to identify the skills needed to do the work.
  2. Create a grid with skills on one axis and team members on the other.
  3. Let each team member grade themselves.
  4. Look at the grid together with the team to see what gaps there are.

For each skill, you’ll want at least two people who can do it. At least one of them should be really good at it.

How to fill these gaps depends on what they are. In some cases, it may be sufficient for people to pair with each other to spread their skills. In other cases, they may need training.

Get rid of single points of failure and bottlenecks.

I recently came across a team who had lost their only tester a few months earlier and the remaining team members were uncomfortable picking up the testing. Instead, they had simply updated their definition of done to exclude testing. “Done”, to them, now meant “The code has been merged to trunk, ready for test”.

Maybe it made sense at the time, when they assumed they would be getting a new tester soon. Several months later, however, they had a huge pile of untested code and weren’t able to release anything at all.

This would have been easily avoided, had they only spread some the testing knowledge in the team while they had a tester on the team. This would also help addressing any bottlenecks just having one tester on the team would create.

Don’t waste people’s skills.

Finally, being flexible, avoiding single points of failure and so on is great but that doesn’t mean we shouldn’t make good use of people’s expert skills.

It would be silly having hard-core JavaScript developers spend most of their time doing manual device testing. That would be wasteful for the company and demotivating for the individuals.

Unless, of cause, they were looking to start a new career in that area.

Why your eyes and ears are the most important tools you have as a Scrum Master

What are your most important tool as a Scrum Master? Here are some ideas:

  • A task board. Helps the team coordinate their work and keep track of the progress.
  • Some sticky notes and sharpies. Quick and easy tools to make everything visible!
  • A burn-up or burn-down chart. Is the team and project on track?
  • A team barometer. Is the team happy?
  • A Scrum checklist. Are we following the rules of Scrum or are we taking shortcuts?

All of these can certainly be useful to help us do a good job, when we use them appropriately. However, there are two tools that trump them all:

Your eyes and ears.

A Scrum Master’s most important job

As a Scrum Master, the most important responsibility is to help the team and the product owner get the maximum value out of working in an agile way, so that they can create awesome products. This means that we always need to observe what is going on. It just isn’t enough to wait for the sprint retrospective to see what issues might come up. The issues don’t just appear during the retrospective, they happen during the sprint. That’s where we need to look out for them!

In this article, I’ll list just a few of those things to look out for. However, while checklists can be useful, they can easily make us focus on ticking boxes for the sake of ticking boxes. Therefore, don’t use the below as a guide what to look out for. Rather, consider it a bit of inspiration!

Listening to what is being said

Simply listening to what people say is an incredibly powerful tool.

  • Is the team aware of whether they are on track to meet the sprint goal? If not, do they care and what, if anything, are they doing about it?
  • Do people seem to understand the true purpose of the various Scrum events? Or do they treat them as process for process sake, with no real value?
  • Does the team self-organise around the work or are they being micro-managed by the product owner or a team member? Or, indeed, by their Scrum Master?
  • Is the product owner on the team’s side or do they hang them out to dry in front of the stakeholders in the sprint review?
  • Is the team working to find the best solutions to the users’ needs? Or is there a lot of up-front planning with the team just working from a fixed set of requirements and solutions, with no innovation?

Just listening in, without interfering, is a great way for getting a feeling for what is going on. I also find another bonus with this method. My brain needs time to process things. Listening without having to come up with answers right there and then saves me from occupying my mind with what I am going to respond, which would cause me to miss important details!

Not just passively observing

However, this passive listening, no matter how focused, won’t give us the whole picture. That’s why it is also important to talk to people. Not primarily to let them know what we think but to learn more about what they think. Talking to someone one-to-one is great for getting below what happens on the very surface of things. And don’t limit yourself to the team members – the product owner deserves to be heard too.

I know I’m not doing this quite as much as I should, so as my New Year’s resolution this year, I’m scheduling a catch up with a different person each week, making sure I get through everyone on the team, so that I don’t just talk to the people I always talk to.

Looking out for what isn’t said

Just listening to what people say isn’t enough, though. Some information isn’t spoken out loud but is still there for you to see if you keep a close eye to things.

  • Is the team working together as a team to meet the sprint goal or are they working as individuals, each focused on their own stories?
  • Does the team keep having to tackle urgent issues, preventing them from focusing on deliveriong product value?
  • Are people energetic and is the work engaging them or are they bored or frustrated?
  • Is the product owner involved with the team or are they frequently missing from daily stand ups or even sprint planning meetings or reviews?
  • Is the backlog made up features and solutions rather than user-focused needs?
  • Are the backlog items in the sprint planning sufficiently prepared and the most valuable things we could be doing right now?
  • Is the team delivering high-quality software, using suitable technical practices on top of Scrum, or do they take shortcuts, resulting in lots of bugs getting raised?

Turning observations into actions

So, what do we do with all this information we’ve gathered while observing everything that’s going on?

The first thing is to verify whether what we’ve observed is an actual thing or if it is just something we’ve made up. Yes, my mind does make things up sometimes!

There are two ways to do this. Ideally, use them both!

Firstly, we need to find out whether there is any evidence to support what we think we’ve observed. For example, if it seems lots of stories carry over from sprint to sprint, look at the numbers. How many stories did the team bring in and how many did they finish? Is there data from previous sprints to see if this has been going on for a while or whether it is a new issue?

Secondly, as a Scrum Master you needs to talk to people (yes, more talking!). Mind you, not to tell them “You have got this problem!” but to find out if they are making the same observation. Tell them what you’ve seen and ask what they make of it. For example, you might say “I saw in the sprint planning today that people were on their laptops and it felt to me as if there was very little energy in the room. Did you see that too or was it just me?”. And if they agree, dig deeper: “Why do you think that might have been?”.

Deal with it straight away or later

Some issues make the most sense to deal with straight away, for example if they put the sprint goal at risk. Others can wait until the retrospective. Whichever way makes sense in the particular case, remember that the Scrum Master isn’t necessarily the best person to solve the problem (the team may have better skills and knowledge). And before coming up with solutions, make sure we’re looking at the actual problem and not the symptoms of it.

For example, the problem is unlikely to be that the team is doing the work too slowly. Rather, something is preventing them from going as fast as they could. That is the thing that needs to be fixed.

A bonus tool

Oh, all of this leads to another set of tools I value in my Scrum Master toolbox: a good old notebook and a pen! When keeping my eyes and ears open, there is always a lot going on. I spot things all the time but am not always sure what they mean. I need to remind myself to look out for them in the future.

In other cases, the observations are on a more personal level. I did something and it worked well or it didn’t. Those things, I want to make sure I remember. I simply can’t trust my brain to keep track of all of them, so I need to write them down.

The two most important things about feedback loops in Scrum

Building complex products is unpredictable. We are forced to make a lot of assumptions (guesses). This is the why we use an agile framework like Scrum, as it allows us to verify our assumptions as early as possible, before we go too far down the wrong track.

At our service, we have feedback loops. These help us create a better product (are we building the right thing?) and increase our productivity, quality etc (are we building it right?).

A feedback loop has four basic steps:

  1. Plan something
  2. Do it
  3. Check the result and see if it is what we want
  4. Based on the result, adjust what we do the next cycle

There are two main feedback loops in Scrum:

  • The sprint
  • each day.

The sprint

Every sprint is a big feedback loop. We come up with a plan for what to build in the sprint and how. Then, we complete these items during the sprint (hopefully!), before we inspect in the sprint review and retrospective how we did.

In the sprint review, we get together with the customer and/or users (or, less ideal, just the product owner as a proxy for these) to get feedback on the features we implemented in the sprint. Now that we can see the software up and running, what should we do next?

Do we need to make any changes to what we have built so far? Perhaps, our requirements don’t quite make sense now that we can play with the resulting software. Or perhaps seeing the software gives us new ideas that are much better than those we initially had. Let’s add these changes to the backlog!

The sprint retrospective instead focuses on the process and how the work itself went. What worked well and what should we do differently next time?

Each day

The second feedback loop is the one starting and ending in the daily stand up. This is a chance for the team to adjust their plans, based on how the progress has been so far, with the goal to maximise the chance of reaching the sprint goal.

How did we progress yesterday? Are there any problems? What should we do today? Are we on track to deliver all the stories we thought in the sprint? If not, what should we do about it? Do we need to regroup somehow? Do we need to go back to the product owner to adjust the scope of the sprint?

Other feedback loops

On top of these loops, we are likely to have several others which are not strictly speaking part of Scrum itself but nevertheless essential to our success. A couple of examples could pair programming (here each feedback cycle could be just seconds or minutes) or the test-driven development cycle.

We can also have some much longer loops, where we inspect a whole project or a big release made up of several sprints’ work. This must be in addition to the loops described above, not instead of! This leads me on to the first main point:

1. If the feedback loops take to long, we learn too late

Feedback loops must be quick or by the time they give us crucial insights we will already have spent a lot of time doing the wrong thing. There are, however, several reasons why our cycles may not be as short as they should be:

  • Longer sprints than needed
  • Too big stories
  • Infrequent releases to production

Longer sprints than needed

The shorter the sprint, the quicker we learn. There is obviously a balance to be struck, though, as starting and finishing sprints involves some overhead. There will also be practical limitations for how quickly we’re able to produce something shippable and valuable.

The rules of Scrum tell us that sprints must be no longer than one month but even a month can be a costly learning experience if we went down the wrong track.

60% of Scrum teams do two-week sprints, which is great as it means they get feedback twice as frequently as those who do one-month sprints. Would a one-week sprint be even better? Maybe – give it a go and see!

Too big stories

Big stories spend a lot of time “under water” between when they are started and when they are finished. Small stories will surface problems quicker. However, for these small stories to deliver the maximal benefit, we can’t wait until the sprint review to get feedback on them. Otherwise, we might already have implemented other stories on top of them, which leads to extra rework. Much better then to call the product owner over and show the story as soon as we finish it or even sooner if there is already enough to see to tell if we’re on the right track.

Infrequent releases to production

If we’ve only got one big release at the end of our project, we run a big risk of delivering the wrong thing. Sure, we gather customer feedback in the sprint review and we might also do user testing to verify that we are on the right track. However, until we ship, there will always be a certain amount of guessing.

The ultimate learning is to see how useful our product is to real users out in the wild. To be able to do that, we need to deploy it into production and measure how real users use it.

Some teams release to production multiple times every day. Others release at the end of their sprint. Further some, particularly on new products, where they need to build up a certain amount of functionality before the product makes sense to the users, need several sprints to produce something releasable. The key is, no matter often you release, try to make it even more frequent to learn quicker (unless you’re Amazon and already release every 11.6 seconds).

2. If we don’t act upon what we learn, the feedback loops are pointless

My second main point may seem obvious but is important. Far too often I see how teams and their product owner either turn a blind eye to the learning or don’t act upon what they learn. I’d go as far as saying that this means they learn nothing!

Learning doesn’t come by itself. Just because we “do Scrum” and all the events that comes with it, there is no guarantee we will actually learn anything.

A few examples:

  • In the stand up, one team member is giving the same update day after day. It’s clear they are stuck on their story but no one steps in to offer help or try to find out what’s going on.
  • We’re four sprints into the project and the burn-up is clearly indicating we’re unlikely to hit the launch date. However, we do nothing about it, other than hope that things will go quicker from now on.
  • At the end of each sprint, we demonstrate the resulting functionality to the users but when they give feedback, we just nod politely, knowing we will never do anything about that feedback. Ain’t nobody got time for that! We’re about to move on to the next feature!

To maximise our learning, we need to be intentional about it. Each Scrum event is an opportunity to inspect and adapt. We can’t be agile if we’re not willing to act upon what we learn. That would be to try to follow a plan, rather than responding to change. That is very much something the Agile Manifesto frowns upon.


Speaking of feedback loops… What do you think? Do you agree with these two things being the most important or do you have any other experiences? Please share your thoughts in the comments below.

 

5 reasons why forecasting is hard and 6 things to do about it

I once interviewed a project manager whose CV claimed that she consistently delivered projects ahead of time and under budget. That is certainly no small achievement, so I asked her what her secret was. She answered, “I take the estimates from the developers and multiply by 5”.

I used that story as a funny anecdote for a long time. In “real life”, who would ever manage to sell something if they charged that much? However, I have since been working on some projects that have made me wonder if she was too conservative!

On paper, Agile forecasting is trivial:

  1. Measure how much the team can get done within a particular timeframe (in Scrum typically a sprint).
  2. Forecast, based on the work remaining and the progress so far. Either how long it will take to complete the desired functionality or far through the backlog you will get by a particular date or.

In practice, however, forecasting is very hard. As the popular quote points out: “Prediction is difficult, especially when dealing with the future”.

Why does forecasting go wrong?

1. We never know less than at the start of the project

There are many reasons why we need to know how long something will take: It worth doing this thing at all? How much should we charge the customer? When can we start this other thing?

Unfortunately, as we haven’t yet started the project, we are forced to base our estimate on a lot of assumptions:

  • The requirements won’t change
  • We will have the people in the team we think we will
  • We’ll be using a particular technology
  • There isn’t hidden complexity, at least not more than we think there is

Etc etc.

If just one of these assumptions are wrong, our forecast will be wrong. These early estimates will be highly unreliable but is still what we often measure the success of our project against.

2. We don’t start on time

When a project finishes later than we thought it would, it will have knock-on effects. In most cases, we will have scheduled another project to start right after that project, which means that the new project will be late from the start. How could we then expect to finish that project by the date we thought?

Further, if we don’t adjust the plan for the next project after that one, that project will be late too. It might even be that it won’t have started by the time we expect it to finish!

3. The velocity can be unpredictable

It doesn’t matter so much whether we measure our velocity as story points per sprint or (similarly-sized, small) user stories per sprint. The idea is still the same: do, measure and forecast.

However, there are still many reasons why we end up fooling ourselves:

  • By definition, estimates are guesses and will never be perfect. If we use story points, something the team estimated as a ‘three’ might well end up taking longer than a ‘five’. That’s normal and to be expected.
  • For our velocity to be consistent, we need a stable team. Often, despite our best attempts, this will not be the case. People leave and join, get ill and go on holiday. Such is life.
  • Dependencies can end up blocking us. If someone we’re depending on doesn’t finish in time, we are likely to be late too!
  • Defects and technical debt from things we’ve delivered before may come back and bite us.

And so on.

4. Things change

One of the main ideas in agile is to let requirements emerge. We will have a fairly good idea at the start what we will be delivering but it might well change as we learn more. That is a good thing! It means we deliver a better product than if we stuck to the original plan.

However, this makes forecasting hard. We estimate based on what we think we will be delivering. If that changes, the estimate will change.

Our desire to find out as much detail as early as possible, in order to provide accurate estimates, will always be in direct conflict with the need to respond to change. Creating a backlog where every item has got a lot of detail will lock down our requirements too soon. Once we’ve already spent all that effort generating requirements, it would feel (and be!) wasteful to throw all those requirements away.

5. People are optimists

Last but not least, people are optimists. I know – horrible people!

Developers tend to overestimate how much they can get done. Often, they are even encouraged to do so. If they give a big estimate, the product owner will be disappointed. If they give a small estimate, the product owner will be happy. Most people prefer to make others happy.

Also, people give in to peer pressure. If you think something might require a lot of work but the others say it will be quick, you don’t want to come across as negative. Even methods like planning poker suffer from this. Sometimes, people seem to focus on picking the “right” number, i.e. what they think the others will pick, rather than coming up with an estimate they think is right.

This optimism bias can also sneak into our supposedly empirical forecastsing. If the forecast looks worse than we were hoping, we may be tempted to say thinks like:

“Oh, that sprint was unusually screwed up, so let’s ignore that number”, or

“Yeah, this is what the forecast says but be should be able to increase the velocity as the team gets up to speed, so don’t worry too much about that”.

As the project progresses, we will learn more and more. Somehow, this tends to lead to estimates growing. For instance, when we break big stories down into smaller ones, the bits always seem to add up to more than the big story they originated from. I have never seen a burn-up chart where the scope doesn’t go up and up until the product owner eventually decides to descope some functionality.

What can we do about it?

1. Don’t give people a perception of the forecast being more reliable than it is

People believe precise numbers much more than rounded numbers. If today is the 2 February and I tell you I will post another blog post on the 1 March at 12:00, you’d expect that’s exactly when it will be available. If I instead tell you I will post it in a month’s time, you’d probably not hold it against me if I didn’t post it until the 5th of March.

Don’t make people put more faith into your numbers than they should by giving them what looks like a precise number.

Likewise, avoid giving dates before you are confident you will be able to start development when you think you will. As we saw above, the previous project might well run over. You are in a much better position forecasting as a number of sprints than an exact date.

2. Learn more before forecasting

If we know the least about our project at the start, how can we possibly make a forecast? Well, we need to find out more!

One trick we can use is to pick a few of your epics and analyse them in more detail, breaking them down into granular stories that we could implement. Estimate these smaller stories (or count them, if you’re a #noestimates kind of person). Then make a guess about the size of the other epics. Might they be roughly the same size?

But how long will the stories and epics take to implement? Well, we should have some idea after our first sprint. We can give you a guess but it’s just a guess.

3. Fix time, not scope

If estimating is so hard and we won’t know how long something takes until we’re done, how could we cost our project or plan our roadmap?

The unfortunate answer is that nothing in Scrum will help us produce better up front forecasts. Sure, once we have started work, the methods we have available will give us some indication. However, if anything changes, the forecast changes. It’s only a picture of how things look right now. The more work we have completed, the more reliable the picture we will get.

The purpose of Scrum is not to produce the best possible estimates. Instead, we’re maximising the value we deliver within the time we have available by starting with the most important features first. Rather than building our product layer by layer, where we’d get nothing of real business value until every layer has been completed, we build our product in thin, vertical slices. Each sprint, we’ve got a potentially shippable product.

This is really important. What this allows us to do is to turn the question around. Rather than asking “How long will it take?”, we can ask “When do we need it by?” or “How much is it worth?”. We create a time box and deliver the most possible value we can within that time box. Sure, we may not deliver every feature we thought but we will deliver the most important ones.

Once we have used up our budget, that’s as far as we got. Let’s move on to the next thing. Or we can keep delivering more of the features if they are more valuable than the next thing.

4. Use a velocity range

The most common forecasting method is probably to use the average velocity. Either since the start of the project or for, for instance, the last 3 sprints. Another option is to use the median velocity. Both these methods are simple but unfortunately not particularly reliable.

Let’s look at a couple of examples to illustrate this:

  • Sprint velocities: 3, 19, 7, 3, 3. The average velocity is 7 but I would be very hesitant forecasting based on this number. In most sprints, we’ve been nowhere near this velocity!
  • Sprint velocities: 3, 10, 10, 2, 10. The median velocity is 10 but that again seems very optimistic. The average is just 7 points so how can we assume we’ll do 10 points per sprint?

A better way is to use a range for the velocity. One tool I often use for this is Mike Cohn’s velocity range calculator. It’s a simple web tool where you enter the velocity for each of your sprints so far (you need at least 5 sprints’ data) and get a range within which you, in theory, could be 90% certain your velocity will be.

We can use this range to forecast a best case and a worst case, again with 90% confidence. It may feel uncomfortable to not be able to give a more precise number than 4 – 11 sprints but if that’s what the data tells us, it’s much more likely to be right than if we say 7 sprints.

After all, it’s better to be roughly right than precisely wrong.

5. Don’t give people the answer they want to hear

As mentioned above, it is easy to fall into the trap of giving someone the answer they want to hear. We prefer to make people happy. Therefore, we need to be very careful to stay honest.

  • We should never assume the velocity will increase as people get more familiar with the project. While this seems to be a fair assumption, quite the opposite could happen. There may be hidden complexity or dependencies we haven’t spotted, leading to the velocity falling.
  • A positive trend in velocity, where it has been going up for a few sprints in a row, is no reason to assume it will continue to increase. Maybe we’ve been able to sort out some fundamental process issues to increase our velocity but to increase it further would be much harder.
  • When we wish the estimates were lower, we need to be careful not to pressure the team or wear them down with repeated estimation sessions until they give us the answer we want.

6. Learn to live with the uncertainty

Finally, we need to get used to the idea that we will never be able to precisely predict how long something will take. The only time we can be 100% certain of the delivery date is when we are done.

Having a precise plan, which we have put a lot of effort into, can work like a comfort blanket and make us feel safe. However, this false sense of control is likely to create more damage than it fixes.

Rather than trying to find ways of creating more accurate estimates and precise forecasts, we need to learn to accept and work with uncertainty:

  • Don’t feel tempted to break down all the stories at the start, even if that might lead to more reliable estimates. As we’ve seen before, this locks down our requirements too soon. There is no point delivering on time if it turns out we’re delivering the wrong thing.
  • Don’t spend time getting a more precise estimate than you need. For example, when it comes to making decisions, if one option is sufficiently better than the other, chances are even very rough estimates will tell you this. If not, more detailed estimates probably won’t help you anyway. In this case, you may want to consider spiking the different options and base your decision on actual data.

After all, trying to produce accurate estimates is very expensive. Let’s focus our efforts on delivering value instead!


What are your thoughts about forecasting?  Have you got any methods to make it easier and more reliable? Please share your thoughts in the comments below.

Can we break the rules of Scrum?

One of the most common complaints I hear and read about Scrum is about Scrum being very strict and inflexible. Is that true?

Well, the Scrum Guide, which lists the rules of Scrum does say:

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety

That is pretty clear, isn’t it? Follow the rules or you’re not doing Scrum!

Scrum seems to be out of line if one of the principles of the Agile Manifesto is “People and interactions over tools and processes”?

Let’s take a look and see.

There are good reasons to stick to the rules of Scrum

The reason why we should follow the rules of Scrum laid out in the Scrum Guide isn’t as trivial as “The Scrum Guide says so!”. There are much better and more important reasons.

The rules of Scrum are there for a good reason

The first thing to understand is that the rules of Scrum exist not despite the Agile Manifesto but because of it.

For example, the various events exist because we believe that individuals and interactions are more important than processes and tools. Sure, these events are part of a process but one that focuses on individuals and interactions. Each event is an opportunity to interact, as well as to inspect and adapt.

Similarly, we do sprint planning because responding to change is more important than following a plan. That’s why we only plan a little bit at a time and not in great detail, so that we can be flexible and respond to change.

Many problems are due to misunderstandings

Unfortunately, many people have peculiar ideas what is or isn’t Scrum and there are a lot of misconceptions out there. In fact, even having a Scrum Master certification is no guarantee for understanding Scrum.

Scrum actually offers a great deal of flexibility. Some examples:

  • Sprints are not rigid and don’t “fail” if we are unable to finish each and every backlog item we thought we would. Yes, we do have a goal for the sprint but this should not be a list of backlog items. A sprint goal, as the Scrum Guide points out, “can be any other coherence that causes the Development Team to work together rather than on separate initiatives”.
  • Story point estimation and “an obsession with estimating” are not part of Scrum. Many teams do use story points and many find it useful. However, we might just as well use another forecasting method like #noestimates. The rules of Scrum say nothing about this.
  • The team doesn’t “commit” to delivering the backlog items in the sprint. They simply forecast what they believe they will be able to deliver. Pressure to stick to the plan at any cost will just tempt people to take shortcuts.

Don’t shoot the messenger

When implementing Scrum, issues are likely to surface that were there all the time and only became visible through the transparency of Scrum.

One example are those who claim that “in real life”, there will be a lot of urgent issues the team need to deal with so it’s just not possible to plan for a period as long as a sprint. Is dealing with these requests genuinely more valuable than delivering new functionality? It might be. If so, that’s perfectly fine! Scrum probably isn’t the best framework in this case. Otherwise, try to solve the root cause of why these urgent requests keep coming in so that you can focus on your product delivery. You will be getting a much better return of investment that way.

Others claim that they can’t deliver working software in a sprint. Their product is “too complex for that”. Well, Scrum can be used to deliver complex systems. In fact, that is where it excels. For example, the systems for the Swedish fighter jet Saab JAS 39E Gripen are delivered in three-week sprints. Instead of hiding behind your complexity, look at why your cycle time is so long.

Sure, it may be easier to “change Scrum” than to solve the actual problem. Unfortunately, that won’t help you deliver more value quicker.

Still, there are cases where breaking the rules makes sense

If the rules of Scrum are all there for a good reason, are there never cases when breaking them is the right thing to do? Sure there is.

Typically, these cases fall into two categories:

  • We can’t follow the rules right now
  • We have a better way of doing something

We can’t follow the rules right now

Sometimes, we will have to accept a compromise.

Let’s say, for instance, that we’re introducing Scrum to a new team. Unfortunately, they rely on a separate team of database administrators to make the necessary updates to the database. This means our team isn’t fully cross-functional, as they can’t complete all the work needed to deliver new functionality.

Does this mean we can’t go ahead and use Scrum? No, that shouldn’t stop us. Let’s do what we can now. Doing Scrum without a cross-functional team is probably better than doing waterfall without a cross-functional team.

However, let us not accept this compromise as “that’s just how things are here”. We need to keep trying to make the team cross-functional. Perhaps we can train up someone in the team or get a database administrator to join the team? If they hesitate, we can always call it an experiment!

We have a better way to do things

Once we have been using the artefacts, events and roles of Scrum for a while and fully understand their intentions and we spot a case where we think something else would work better to fulfil those intentions in our context, who can stop us from giving it a go?

More often than not, these changes will be fairly small. A common and trivial example is how many teams move from each team member answering the standard three questions in their Daily Scrum (“What did you do yesterday? What are you doing today? Do you have any impediments?”) to “walking the board”, discussing each backlog item instead.

Conclusion

Ultimately, our goal is to deliver the most value we can, not to do Scrum. It is possible to be agile without doing Scrum and without the right mind-set, it is certainly possible to “do Scrum” without being agile.

As agilists, we believe there are always better ways to do things. Scrum isn’t “done”. It evolves. For instance, the release plans and burn-downs, which were part of the original Scrum Guide, are no longer considered part of Scrum. If no one ever bends the rules, Scrum would stagnate.

The important thing is to not change Scrum because it is easier than solving our actual problem.


What do you think, do we have to stick to the rules? Which rules do you break? Share your experiences in the comments below.