Scrum series
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.
Governance aka Politics
The single most important step we took was to add a project governance model on top of Scrum. When we compared scrum with the governance model dictated by the customer we expected to find conflicts. We didn’t. What we found were two models with different perspectives on the project that would support each other. We found that the governance model provided the framework needed to keep the political issues that scrum ignores away from the scrum process and team.
We were also fortunate to have a governance model that focus on the organisation, rather than dictating strict waterfall mile stones that conflict with scrum’s iterative model. With a governance model that more strictly regulates project phases it would have been harder.
Transparency
Scrum is transparent and there is nowhere to hide. The work of the developers, the backlog produced by the product owner and the customer’s prioritization is all done in the open. This project was a splendid example of where this worked in a positive manner. Everyone was open and shared their work – successes as well as the inevitable times when things go wrong.
The transparency made everyone more human. We all showed that we sometimes fail, but we also all got support from each other to cover up those situations and improve together. The transparency formed a strong team and a strong relationship with the customer.
The Business Perspective
The project created a very strong connection to the business we were developing the system for. Both when gathering requirements and after the system was delivered. In many ways we looked at the project not as one project, but as two. We had a greater outer project that was run by the customer, focusing on the business perspective. Embedded within the business project there is a software development project. The software development project is finished when the software is delivered and passed on to the maintenance team.
That’s when the hard part of the project starts for the business. They have the software and it’s time to get it into active usage. In this case it’s a system that will be used by 10000 people in the health care sector in the Stockholm County. Rolling out the software to all those people while keeping the strict security requirements with hard certificates for all authentication is a challenge.
A Holistic View of a Project
The project was in many ways a huge success. While this post mostly mentions the project management and political sides of the project, we also achieved the best code quality of my career.
I think that the major success factor was that we had a holistic view on the project. We did run the project mostly according to the scrum rule book, but we didn’t stop there. We took benefit of scrum’s strengths, added project governance and made sure that we addressed all the areas that could be a concern in this particular project with this particular team and this particular customer.
No two project are the same and the agile rules are meant to be bent and adapted to the specific circumstances of each project. With a little up front investment on setting up the right project organisation for a particular project before starting, a lot of time will be saved later.