A year ago, during the startup of a new project, I wrote a series about scrum and the context around a scrum project. The project is now can finished and it’s time for a retrospective, evaluating what worked well and what didn’t.
The major impression is that the project and the way we used scrum was a huge success, but of course there are areas that didn’t work so well. It’s always nice to look at the success stories, so let’s start with them.
I started the series by pointing out that scrum’s view of the world is very developer centric, focusing on making the developers as efficient as possible. That is a very different perspective from traditional project management that tends to have a deeply rooted top down perspective. In the project we kept scrum focused on the development team, but also acknowledged that there are important areas in a project that scrum doesn’t account for.
I’m definitely not saying that scrum is wrong, my experience is that scrum improves the success rate for projects considerably. But as good as scrum is, it isn’t perfect nor a complete project model. By addressing the parts of the project that are outside of scrum, the success rate is even more improved.
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.