Technical skills is the core of any development project. In the end it is the skilled programmers that write the code that forms the product. Everything else is just support to ensure the coders develop the right features in the right order. But somehow management tend to look at the developers as the lowest level in the project hierarchy. How come that the respect for developers and their technical skills get lost?
Having been on a number of projects it’s evident that technical skills matters. They not only matters but are crucial. All processes (agile or whatever) are only there to support the technically skilled who write the code. In fact, the more skilled developers, the less need for tight processes. The then ground breaking Extreme Programming Explained: Embrace Change argued for tearing down most of the then dominant, heavy weight processes and instead trust the developers. It was of course a success, but not only because of the process. It was a success mostly because of the people.
With Kent Beck and Martin Fowler on the same team the process doesn’t matter. They would probably succeed in a heavily regulated waterfall process, coding on punch cards with needles by hand.
But to really unleash the power of such a team it’s best to give them freedom to do their magic and stay out of the way.
That’s exactly what eXtreme Programming is about: Connect the users/customers directly to the development team and keep management out of the way. It worked in the Chrysler C3 project because of the skilled people involved. It works in any project with a skilled team.
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.