“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. How can we keep this up?” –The Team
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.
You are doing Scrum; the only thing left to learn is to be effective at 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.
How do you become such a team? What properties has an effective Scrum team that sets them apart?
The Product Owner Role
The Team was happily coding when Joe from Marketing hopped in.
“Can you do me a favour? We have this big event next week and it would be really great if we could show the new user interface…”
The Team explained that they were already fully booked until next week Friday, but Joe wasn’t sent away that easily.
“What? The performance story? That really can wait until after the show. If we don’t sell our product, who cares about performance anyway?”
Then the phone rang: their biggest customer had a problem generating reports.
Fred sighed. “This is all very important. But is there anyone who can decide what we should do next?”
The Product Owner is responsible for the product backlog. Do you have a Product Owner? If not, assign one.
What the Product Owner Does
Technically, the Product Owner does 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 from interruptions of the stakeholders completely. Stakeholders can talk to the Product Owner at any time, the Product Owner talks to the team when the time is right.
Velocity Is the Only Measurement
The only measurement that is taken of 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 story points can the team do. Chasing individual’s hours is not going to change the amount, 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.
If you need to come up with a sheet of man-hours spent per feature or project, you can divide the number of story points of a finished story by the focus factor. This will give you the number of man-days you worked on that story.
The Product Owner 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 than others.
It is up to the Product Owner to translate this release planning to whatever the organization expects. But since the release plan is both reliable and flexible, it should fit any organization’s needs.
There are a few things that can make a release planning like this difficult or imprecise. 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.
Another thing to beware of is 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 plan 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. That is regardless of the planning method used.
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 about 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 this 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 its priority a lot more evident. 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 Team was happily coding when Joe from Marketing hopped in.
“When does your sprint end? And is my story actually in it? Where is your scrum board? Do you have your product backlog online somewhere? O, and can you reschedule your demos? I generally don’t work on Fridays. Can I be in your retrospective?”
Jeff sighed. “Get out of our team room!”
The Scrum Master is responsible for the Scrum process. Do you have a Scrum Master? If not, assign one.
What the Scrum Master Does
The Scrum Master’s mundane tasks include making sure all the meetings happen, and possibly chair them: 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 burn-down chart is updated and any impediments are cleared. 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.
The team concentrates 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 the good resolutions from the retrospective observed? Is the team performing well, and improving? In other words, is the Scrum process working well?
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 something not going well; mentioning problems in the stand-up can also help. 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-related blockers, like “my PC is broken” or “we still don’t have the artwork” 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 plans, 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
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!
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.
Just a Team, or a Scrum Team?
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.
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 are actually not doing.
Maximum Sustainable Pace
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, if you value speed over good coding practices you run the risk of leaving your code base in a big mess.
Ideally, all the refactoring, improving and tidying up is done as part of other tasks that you do. 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.
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. 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.
Scrum: Getting It Right
“Now The Team is doing Scrum!” –The Team
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. Pay attention to all the little details. Have a Product Owner who knows what his or her role is, and have a Scrum Master who knows what he or she is doing. Have a team that communicates well, and knows how to improve. The whole Scrum team will perform better, and become more and more autonomous. When the trust from others in the team grows, the team will really have created the power to do things well. Agile teaches us that the team should be empowered, but in the end, the team will empower itself.
There is one thing that can’t be repeated enough: 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 work that is interesting, fun and fulfilling.
So have fun!