I was recently asked about some introductory reading on agile requirements and working with agile at scale. This is the list of books, blog posts and a video I came up with.
- An absolutely fantastic 15 minute overview of the product owner role in scrum. (over 125.000 views for a film of scrum!) by Henrik Kniberg.
- A book I often see recommended (but that I unfortunately haven’t read myself) is Mike Cohn’s “User Stories Applied”.
- A book I’ve read parts of and that I like so far is Mike Cohn’s “Succeeding with Agile: Software Development Using Scrum”.
- A really interesting article about working agile at a larger scale: Scaling Agile at Spotify.
Of course I also recommended my own series about scrum, starting with the Scrum for Developers post.
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?
A friend of mine told me about an organisation in trouble: They were too firmly attached to their processes to improve when needed. The strict process that was followed? Agile (Scrum to be specific).
I’m sorry if I just caused some of you to swallow your coffee down the wrong pipe, but it’s true: Using an agile process the wrong way can give exactly the same problems as the agile movement try to extinguish.
The reason that this occurs is that most articles teaching agile practices (including my own) are very prescriptive. Do this! Don’t do that!
For beginners that’s great and that’s what they need, but for teams that have some experience it is time to bend the rules when needed. The best way to describe this that I’ve found is Shu Ha Ri. The term originates from Aikido, but is frequently used within the agile community to describe the different phases of agile adaption.
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.