I’ll admit it right away. I do like scrum. I think it is a natural that I do, because I am a developer. Scrum is a lean methodology that focuses on making the developers as productive as possible. Working as a developer in a scrum project means spending most of the time writing code, with clearly defined tasks at hand. It is a developer’s dream. Even though I am in love with scrum, I have to admit that scrum isn’t a silver bullet making a complete software projects work. At the heart of a successful software development project there is code writing going on, that is perfectly well suited to be managed with scrum. To make the entire project succeed, a number of other things are needed too. In a series of posts I will be putting scrum in the context of a complete project. In this post I’ll start with scrum itself.
Scrum as a methodology is very transparent, everything is done in open sunlight where everyone can view. Following the spirit of scrum, everything is open for all stake holders to watch.
- The requirements must be detailed before the sprint planning, the team can reject a product backlog item that is not complete.
- The developers have to give an official time estimate on each work item.
- The sprint burndown chart that shows the progress of the current sprint should be on the wall, next to the developers’ work space.
- The daily standup should be open to any stake holder that wants to join and listen.
- The result of the sprint is shown in public, by the developers themselves.
The high degree of transparency effectively means that nobody in a Scrum project can hide. Successes are shown, but also failures. I think that it is good with the transparency. It ensures that problems are found and handled early.
As a developer I’ve been happy with scrum, but as I’ve been more involved in project management I’ve felt that there is something missing. When I talked to two of our most experienced project managers at Kentor; Susanne Ribbing and Cecilia Andersson I realized that what I was missing was project governance.
Looking thoroughly, it is enough with a single sentence description of a scrum project to identify the need for project governance.
Throughout a number of sprints the team focuses on the most prioritized items from the product backlog to reach the project’s goals
I’ve highlighted a number of terms that are very much treated as predefined constants by the scrum methodology. I think that’s right, because scrum focuses on the developers. Still, those terms need to be defined and that’s what project governance do.
Some time ago a colleague of mine, Monica Hervén, asked me for some advice. I was a bit surprised, because she’s a lot more experienced than I am and she’s someone who I have a lot to learn from. The issue she wanted to discuss was how to identify the requirements in a scrum project she’s involved in.
In the first post in this series I described how the requirements phase is generally treated in descriptions of scrum.
A scrum project starts with an almighty, all knowing product owner that has the entire list requirements prepared in a prioritized product backlog.
The problem Monica faced was that there was no clearly defined, prioritized product backlog produced by the appointed product owner. I don’t think that I had very much new to tell Monica that she didn’t already know, but we could share some experience of the challenges of getting a good product backlog produced.
The product backlog is the initiator for all work done in a scrum project. It’s the responsibility of the product owner to produce it. That makes the product owner role extremely demanding. It is impossible for a product owner to just conjure up a product backlog. Forming the backlog requires hard, structured work to ensure that all relevant user stories are identified.
Yesterday I got hold of a deck of cards, specially made for playing planning poker at sprint planning. I’ve been through many sprint plans before but never actually played planning poker with cards. I’m stunned by the difference it made.
Without the cards, I’ve always been careful that everyone settles their own opinion first, before anyone else tells what they think. I thought that was enough to get the same results as when using actual cards. I was wrong. I was completely wrong. I spoiled an opportunity to build the team spirit, the feeling of doing this together, the collective ownership of the estimates. The most important thing I missed was the possibility to get rid of the feeling of criticism when having a different opinion. The criticism that nags on the team spirit can be replaced with a good collective laugh, empowering the team spirit instead.