Last week I gave a short introductory presentation about Scrum at our company meeting. I explained how the team picks the highest priority user stories from the Product Backlog, and turns them into a potentially shippable product increment during a sprint. The question arose as to who would tell the team how to do this? The answer was quite simple, “No one does“. I briefly described how Scrum cherishes empowered teams. The team members will figure it out themselves, assuming, of course, the team has all of the required skills to achieve the task. The person who asked the question didn’t seem to be convinced. Obviously, I didn’t do a very good job of explaining it. I’ll try again with the following metaphor (I wish I had figured this out before the presentation).
Vision
Imagine two European explorers in the fifteenth century hiring crews to sail to India. Explorer A sends his crew into the woods to chop trees without any further explanations.
Explorer B, on the other hand, gathers his crew and tells them about their goal to be the first to sail to India to gain easier access to their riches (mainly spices). He instills in them a vision of something they can be proud of if they can achieve it.
Which crew do you think is more motivated? Which one will finish their ship first? Exactly, that’s my point. Teams don’t need step by step instructions of how to develop a software product. They’ve done it before (at least some team members should have). They know what it takes. What they need is a common goal to motivate them and the trust that they can do it. If the team members are not entrusted to determine their own work, they will never fully commit to the product vision, nor will they ever feel the desire to make the key decisions that they should be responsible for.
Leadership
A lot has been written about Scrum sprints replacing the traditional waterfall model, but what is less talked about is that Scrum is also about leadership versus management. According to Seth Godin, “The secret about leadership is simple: Do what you believe in. Paint a picture of the future. Go there. People will follow.” “Leaders have followers. Managers have employees.”
Of course this shines a bad light on management. We don’t even let anyone outside the development team speak at our daily Scrums because we don’t trust them not to tell us how to do our job. The team is, therefore, entrusted to deliver the Product Backlog on their own, and managers are (only) expected to assist the team to build the best product possible.
There is no doubt that each group of people needs leadership to achieve a goal. But this is just another one of the skills I mentioned above. There are undiscovered leaders within your team. They might not have the title on their business cards, but they are there. You don’t have to appoint them either, people will turn to them automatically when problems arise.
Responsibility
There is an issue that remains unresolved. I like to call it the “Spiderman Dilemma“: “With great power comes great responsibility“. What if members on your team don’t want to have this responsibility? What if they are too used to their factory life, where they have tasks assigned to them and they can go home after their eight-hour day without worrying about the product they are producing? I am afraid, I don’t have the answer. After all, I guess Scrum is not for everyone. I do believe, however, that these people are the exception. Generally team members like to have some authority over their time and effort and some input into what they do, because it gives them the chance to be proud of the product they create.
So, give your team a vision and the trust that they can achieve it, not a step by step instruction.
The above metaphor was inspired by a quote from Antoine de Saint-Exupery: “If you want to build a ship, then don’t drum up men to gather wood, give orders, and divide the work. Rather, teach them to yearn for the far and endless sea.”
Drawings by Nicole Day.
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
Quality Software Development with Ease 
Thanks for the good comprehension. Sounds good to me. The outcome might be better than having bad management. As far as I see, it can only work when all team members are at the same location and see each other on a regular basis. Otherwise a detailed task-management is necessary. Another disadvantage which I see is, that in the case when something goes wrong, scrum projects are probably less documented and it is hard to find out where the problem came from.
I agree. Co-location is essential. It certainly gets much harder otherwise. There are tools out there trying to make it work, but nothing can replace face to face conversations in front of a big visual board. Can you give me an example of when documentation ever helped you to find out what went wrong? I just can’t think of any situation.
I was thinking that a task which is in a task-management-tool can be assigned to several people over a period of time. Every person who works on that task writes hopefully a comment about what he has done and which problems he has discovered. That might be helpfull at the end when something isn’t working right.
OK, when I think deeply about it, it might be that you don’t find out what went wrong, but only who made something wrong.
Another thing which I find helpfull with task management is, that you can give a status report quickly by looking into your tool. I imagine that with scrum projects the status of the project is only in the mind of the team members.
Hey, but I don’t want badtalk scrum. I just want to have a healthy controversial discussion.
I think your idea of a task is different from mine, so let me give you my definition: A task is a small (<= 3 developer days) chunk of work and is part of a user story (<= 30 developer days).
These small tasks can be finished by one developer. There is usually no need for handovers or reassigning. User stories in turn need to fit within one sprint (<= 4 weeks). When they are done, there should be no reason why you need to come back to it trying to figure out who did what. This, of course, assumes you have a Defintion of Done and a test suite that make sure tasks are really done.
Scrum is not an excuse to not document any issues you came across during development. It is a common misconception that Scrum teams don't document what they are doing. The idea is to get rid of all the handover (sign-off) documents and the ones that no-one ever reads. That doesn't mean the team can't produce any documentation. I personally prefer keeping things in a project wiki. It's easy to access and share.
Status report. In my opinion that is one of the big advantages of a visual task board consisting of the user stories and tasks for the current sprint plus a burndown chart Have a look at this http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf. It's pretty much exactly the task board we use. By having the board an the wall where the team sits the status report for the current sprint is right in front of them (and everyone else who walks around the office). No need to open a tool and run report. It's right there. All the time. You may call it a continuous status report. Again, this assumes co-location of the team. For a status of the current release we just use a burndown chart of the sprints within the release created with Excell. I understand that many companies will need a more sophisticated way of doing this. Or at least they think they do.
I am always open for a bit of a discussion. So don't feel bad about it. If everyone just nods there is no discussion and no improvement. Looking forward to your response.
[…] have to tell the team members what to do from start to completion of the development effort. Empowered (Scrum) teams will handle this just […]
I’m glad that I’ve found your qualityswdev.com site. I’m so delighted by your way of thinking and writing. Have you thought about writing a book?