What does a developer gain by embracing Scrum? I’m a strong believer of Scrum, but some time ago, I got my beliefs questioned. That is always good because it forces one to think them over again and reason about why one believe in certain things.
It was not until several months later that I realised how much I learnt from having my beliefs questioned. At the time, I guess it was too painful for me to find out that things I thought were universal truths where merely my own beliefs. Working on a project with a plan that is constantly moving (even on things where coding has started) makes me feel uncomfortable, so for me as a developer, scrum is a way to make me feel better. I don’t need any more arguments for why I should embrace scrum. When I was faced with the question “why” it was an awkward experience, because I didn’t have any good answer.
To be honest, my first instinct was that becoming more professional is sufficient as an argument. But when I think deeper of it, that is not a good answer. Just because I find it so important to be professional that I see it as a value in itself, that doesn’t mean that everyone else does. No, I have to answer the question:
What’s in it for me as a developer, if we adopt scrum?
Agile focus on flexibility and the ability to change directions during the project, but it is not the same as working unplanned and rushing to do anything that comes up. For some people new to agile methodologies, this might be a bit of a surprise.
An experienced project manager, that at the time was new to agile processes once said to me:
I thought scrum was supposed to be agile, but the fixed sprints makes it a loss less flexible than what I’m used to. When something new, urgent comes up, I can no longer go ask someone on the team to fix it.
At the time, I was mostly upset with the comment, but with some spacetime distance to the project I can now look back and learn something from it.
The first thing that was obvious was that the project manager was not at all as used to plans and following plans as he thought. Of course there had been project plans before, but only on a high level. There had not been the detailed plans that are prepared in a scrum sprint planning meeting, where the team and the product owner negotiates a deal on what to commit to for the next sprint.
The second conclusion is that the project manager was not used to self organizing teams, that do their own planning. In an agile project, the role of the project manager and product owner is to give the team a clear goal and then let the team work in the best way they see fit to reach that goal. To do that, plans are indeed required, but that’s a different kind of plans than the normal project plan.
With scrum practices getting the development team’s work under control and out of an ad hoc process, the problem is often just moved to the product owner. From a developer’s perspective that’s good, because it makes it clear to everybody what the product owner’s responsibilities are.
Introducing scrum practices to a development team is always valuable and improves the development process, even if the project as a whole isn’t agile. For a project to be truly agile it needs to be agile all the way. It needs to be agile before it’s even a project, when it’s first planned. The project governance and project management must be agile. The development team of course needs to be agile. Last but not least, the requirements handling and interactions with stake holders and users must be agile. Unless everybody involved are following the agile principles, the project is not agile.
Nevertheless, a development team will benefit from adopting scrum practices and making an offer to the rest of the project to become agile. In non-agile projects, the developers are run (over) by management rather than being allowed to self organize. When (and I mean when, not if) bad requirements or impossible deadlines are presented to the team, they are pushed onto the team. With bad requirements and impossible deadlines, it doesn’t matter if the team are doing wonders – they will still fail. When they fail it will be their fault. Do you recognize the situation? As a developer, I certainly do.
Keeping track of the backlog in a Scrum project is a challenge. It quickly grows to hundreds of items that are in various state of readiness for inclusion in a sprint. In my current project, we’ve setup a Kanban board to help managing the backlog and make our backlog grooming sessions efficient.
I think that in many ways the product backlog and the product owner role are Scrum’s weak spot. Scrum brings order to the development process and sets clear demand on the specifications input into the development process. That helps to make visible what we developers have known all the time: It isn’t our fault that projects screw up, because we can’t do a good job on bad requirements. So with Scrum having helped to make the requirement problem visible to everyone it’s time to address the requirements handling.
In my current project, there are a number of distinctive steps that a product backlog item goes through.
- A new request from someone is noted as a product backlog item.
- The PO decides to trash it right away, or to go forward with more detailed analysis.
- The PO (or a BA helping the PO) makes an analysis.
- The product backlog items is presented to the developers in a backlog grooming meeting.
- The developers have questions and send the item back for further detailing.
- The developers approve the item and make an estimate of the entire product backlog item.
- Only items approved by the developers are eligible for inclusion in a sprint at the sprint planning meeting.
To keep track of this process we use a Kanban board.
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.