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.
When starting up a scrum project, I often use a sprint 0 to get started. The purpose of sprint 0 is to get all the prerequisites for the first sprint planning in place.
The need for a sprint 0 probably varies across different businesses. I’m working as a consultant which means that at the start of the project the team usually doesn’t know each other well, the customer doesn’t know the team, the business analyst doesn’t know the business and the team doesn’t know the inherited legacy code (if there is inherited code).
Every single one of those issues is an impediment for a successful sprint planning. Together they make an effective sprint planning impossible. The purpose of a sprint 0 is to overcome these issues. The purpose of a sprint 0 is not to work in an unstructured manner and postpone the planning.
Sprint 0 Goals and Planning
As every sprint, sprint 0 should be planned and have a sprint goal. In my opinion, there is only one valid sprint goal to set for sprint 0:
Sprint 0 Goal: Make proper planning of sprint 1 possible.
Fortunately only two things are required to plan a sprint: a prioritized backlog and enough knowledge of the domain, technical aspects etc to make relevant time estimates.
Unfortunately those two things can be really hard to get. Until you have them, you’re running sprint 0.
