This is part of Seven habits of highly effective scrum-teams, a book in seven parts about scrum for teams.

Seventh habit: power to the team

‘Now The Team is doing scrum, and it works well: our schedule is clear and dependable, our code has high quality, and our production is going up. Why doesn’t the organization around us get it?’ —The Team

In six habits it was explained how to do scrum effectively. Scrum is not a very complex method: there are only few things you have to do, and some simple rules to follow. ‘Not complex’ is not the same as ‘easy’, though. It takes a great deal of effort and attention to do it right.

The first six habits are all ‘tricks’ or ‘tools’ to make sure you perform the moves of scrum well. The seventh habit is different: it is the habit of doing scrum. And that requires the team to be aware of what they are doing, and to be confident that they are doing the right thing. A confident team will commit with confidence, work with confidence and deliver with confidence, and thus will be a dependable team within an organization.

The product owner role

The product owner is responsible for the product backlog. Do you have a product owner? If not, assign one. Organizing the backlog is a lot of work.

Technically, as a product owner you do the following:

• write user stories (or have them written)
• have them sized
• put them in priority order

In practice, there is a whole lot more a product owner has to take care of: keep an eye what is happening in the company, so you can see user stories coming; chase stakeholders to get more detailed requirements from them; bring stakeholders together so they can discuss priorities between them.

Apart from that, the product owner must be able to answer all questions the team asks. The better he or she can do that, the faster the team can move; if the team has to chase each stakeholder for questions they cannot work very well.

Ideally, the product owner has enough authority to make decisions about priority as well. Of course he or she should consult with the stakeholders about priorities, but if, for example, during a sprint planning a spot decision is necessary, the product owner should be able to take it.

If the product owner is doing it right, the team is shielded against interruptions of the stakeholders completely. Stakeholders talk to the product owner at any time , the product owner talks to the team when the time is right. This will allow the team to work autonomously.

Velocity is the only measurement

The only measurement that is taken about the team’s performance is velocity. It is no use measuring the hours of work spent by a certain person on a certain task. Working on stories is a team effort, and sizing stories is done by the team, so the only important piece of empirical data is the relation between them: how much of the team’s story points can the team do. Chasing people’s hours is not going to change that, and provides little useful data.

In effect, it even works counter-productive. Assume Jennifer is working on a task, but now John asks for help. This is really going to mess up Jennifer’s time sheet. Either she doesn’t book the time she helped John, making it look like she spent way more time on her task; or she decides to book half an hour here, and three and a half hour there, giving here more work filling in the sheets. Or she decides that it is easier that someone else helps John…

And what do you have in the end? In the best possible case, a time sheet that shows that everyone has worked all their available time on some tasks.  But that you have found out anyway by the end of the sprint.

Release planning

Still you can do a very good release planning using only velocity. If you know the velocity of the team and you know the size of a lot of stories ahead, you know exactly how many sprints it will take to finish those stories. And the good thing is that you can add stories, remove them or re-order them and see directly what the effect is on your planned release date. Instead of randomly cutting features when a project is running late, you can make an informed decision which features are more worthwhile then others.

There are a few things that can make a release planning like this very difficult or unprecise. One of them is a sloppy definition of done. If finished stories are not really finished, you can expect a lot of unplanned work and thus a very inconsistent velocity. That makes the release plan unreliable.

Another thing to beware off is lots of late user stories. If the user stories are not known well in advance, and if the stakeholders bring in many new user stories the day before the sprint planning, your release planning changes every sprint. It is up to the product owner to hunt down user stories as early as possible; but if the plans of the organization change very frequently, you still cannot plan very far in advance. But that is regardless of the planning method used.

‘Maximum sustainable pace’

The Team has been coding like madmen, adding feature after feature at the speed of light… The stakeholders were never happier! But now the code base is a mess. Loose ends, unfinished business, quick hacks, ad-hoc design decisions… With scrum you have to go so fast that you can never pay any attention to code cleanup!

Sometimes, scrum teams feel a lot of pressure they themselves created. The team actually became so much more efficient that they go into some sort of productivity frenzy, delivering as much as possible. This is different from hyper-productivity: the difference is that they don’t look forward how they can sustain this pace. Apart from the risk of burning out, you run the risk of leaving your code base in a big mess if you value speed over good coding practices.

Ideally, all the refactoring, improving and tidying up is done as part of all the tasks that you do. If you pay a lot of attention to good code it usually doesn’t backfire very hard. Finding the right balance between working fast and working well is an important part of good scrum practice.

The right balance is usually called the ‘maximum sustainable pace’. Work as fast as you can, but not faster. The ‘waveform’ of sprints will make sure you can keep up a fast pace for a long time.

Technical stories

But once in a while you spot a problem in your project that is too large to fix immediately, or that is entirely unrelated to the story you are working on at the moment.

For those problem the team can create technical stories: stories that are just fixing a problem before it is too late. Those stories usually don’t read like ‘As a <somebody>, I want <something> …’, because they are invisible to users. You can either write ‘As the team, we want …’, or abandon the ‘as a …’ format for a time.

The product owner can handle the story as any other story, and take the team as the stakeholder. Even though the business value of technical stories may not be apparent immediately, there is of course business value in the long run; the product owner needs to balance the needs carefully.

Sometimes, a business stakeholder can become a stakeholder to the technical story too, because a feature she wants depends on the technical story. That usually makes it a lot easier to get priority for a technical story. The product owner should try to find business stakeholders as early as possible to be the champion of the technical story.

The scrum master role

The scrum master is responsible for the scrum process. Do you have a scrum master? If not, assign one.

The scrum master’s mundane tasks are organizing all the meetings: sizing meetings, sprint planning meetings, stand-up meetings, sprint demos and retrospective meetings. Furthermore, he or she should make sure the scrum board is there and is kept up-to-date, the burndown chart is updated and any impediments are cleared. Those tasks are pretty well-defined. But the responsibility of the scrum master goes a lot further.

By virtue of being responsible for the scrum process, the scrum master must make sure that things happen. That doesn’t mean the scrum master should do it all; after all, it’s the team’s process. But it is certainly helpful for the team if there is someone who keeps track of things.

When the team is working on the stories, they concentrate on technical problems. And that’s what they should do. The scrum master, on the other hand, should keep an eye on the process. Is everybody on time in meetings? Are people working together well? Are team members unhappy? Are the good resolutions from the retrospective observed? In other words, is the scrum process working well? Is the team performing well, and improving?

If the scrum master sees anything that is not going well, he or she should make sure it is discussed in the team and a solution is found. Asking questions in the retrospective can be a very good way to make the team aware of the fact that something is not going well. It is important to let the team as a whole come up with solutions: for example, just ordering the team to ‘be nicer to each other’ is probably not going to work.

Say ‘no’ to disturbance

Apart from internal forces that prevent a good scrum process, there are also external forces. Stakeholders coming to the team to ask them questions or tell them to do things, managers that force work upon the team, or just a noisy or busy work environment. In fact, these are all impediments, but they might not be experienced as such.

Very task-specific blockers, like ‘my PC is broken’ or ‘we still don’t have those translations’ are easily recognized as impediments. More general things preventing you from doing work, like ‘Dean is constantly asking whether we are finished yet’, or ‘Carol wants me to attend that half-day meeting every week’, sometimes aren’t.

They are impediments, and they should be cleared. Again, the scrum master can be the right person to be extra keen on that kind of impediments.

Never commit to too much work

There can be a lot of pressure from stakeholders on the team to do certain stories. It can sometimes be hard to say ‘no’ to people. Still, the team should never commit to more work than they think they can handle.

When the velocity of the team is reasonably well established, you just know you are not going to make it. So when you say ‘Oh well, we can look into it,’ you don’t help the stakeholder at all. Instead of saying ‘no’ right away, you effectively say ‘yes’ now and ‘no’ later.

The funny thing is that most stakeholders don’t really care whether you say ‘no’ or ‘yes’, as long as that ‘yes’ really is yes. (If the ‘no’ is not really ‘no’ they usually don’t mind.) A real ‘yes’ or ‘no’ allows them to adjust their planning, and if you do what you promise then they can deliver what they promised.

And for yourself, it is actually easier to say ‘no’ right away then to be forced to apologize later, because then the effect for the stakeholders (and thus the disappointment) is much larger.

The team’s role

So what’s left for the team to do? Do the work, of course. But to be really successful at scrum, there’s a little bit more to it.

The key to scrum, (or any other method,) is to work together very well. And for that, you need to talk together very well. Scrum allows you to do that, or even prescribes that you do that, in planning meetings, stand-up meetings and retrospectives. But it doesn’t end there: you have to talk to each other all the time. Just imagine you are a rugby team: it’s not just planning, half-time chat and watching the video after the game. It’s also shouting and talking to help each other during the game.

And just like in a well-performing sports team, you will find out that after some time you just know what others are doing, or how they are doing it. That is when the team members can completely trust each other with the job they are doing, and that is working together very well.

Be responsible

If at any time, a team member is not doing what he or she said he or she would be doing, the trust in the team will be compromised. Also, if somebody sees that something is going wrong, but is not sharing it with the team, trust is not worth a lot.

As a team member, you are responsible for the success of the team, for the current sprint, and for the work you committed to. If you feel you cannot be responsible for a task, for example because you lack the knowledge, or you hate it too much, give it back. But don’t pretend you’re doing something that you don’t.

Continuous improvement

Things are always changing: new projects arrive, new people are hired, new things become important. It is up to the team to try to change for the better.

As a team, you should always try to improve. ‘Inspect and adapt’ is the motto of scrum: see what works well and keep on doing it, see what causes problems and avoid it in the future. But also: try out new things, and if you like it, keep it. Don’t try to improve by completely changing the way you work: that is very time-consuming and will also get rid of good things. Just try to continuously improve small things, until there is nothing left the same. You will be surprised how effective that can be.

Keep the team together

The team cannot improve if the team changes constantly. If people together can accomplish more than those people alone, that doesn’t happen just like that: it takes time for a team to perform better than the individuals.

All this investment is wasted if the team is disbanded. In an organization using scrum, resource management should never be based on the availability of persons, but always on the priority of work and the velocity of teams. The team as a whole can perform at a certain pace; the availability of a single person is largely irrelevant.

Actually, well-performing scrum teams sometimes don’t see a drop in velocity if a team member is on holiday for a full sprint. In the long run, the velocity will go down, but in the short term the team can make up for the lower availability, which clearly shows that the team is more important for release planning than the individuals.

Execute scrum very well

There is a lot of wisdom in scrum. All the simple elements of the methodology work together to bring out the best in teams, continuously. If you leave out one element, you’re missing out on an opportunity to do better.

The only way to make scrum work, is by doing it very well. The advice in all the chapters is aimed at that: execute it flawlessly, then see what it brings to the team.

While the team improves, they will perform better, and become more and more autonomous. When the trust in the team grows, they will really have created the power to do things well. It is one thing that agile teaches that the team should be empowered: in the end, the team will empower itself.

Have fun!

There is one thing that wasn’t mentioned a lot in the preceding chapters: when done well, scrum is a lot of fun. If the team grows to a level of autonomy that makes them well-performing, dependable and trusted, they enjoy a working climate that is interesting, fun and fulfilling.

Share and enjoy!