Agile essentials 7: Own your own processI’m not a huge fan of orthodoxies and methodologies, but they have their merits. Agile is a mindset. I argue that if you put the mindset first then you are in a better position to judge the performance of a methodology in your team. I go on to define what I think are some core components of an Agile mindset, then I discuss them in more detail in follow on posts.
I first published this series of posts on another blog site before moving (and updating) them on this wordpress one. When I wrote the posts I was trying to define what I think makes for good software development processes without signing up all the way to a particular methodology.
Scrum, XP, Kanban and so on…
This isn’t a post about bashing methodologies. I actually think they all provide a sensible framework for building a solution in a team. However, there are some aspects of the way popular Agile methodologies are often used that I think can be unhelpful.
I read an article
written by Michael Sheen, the actor, a while ago in which he opens with a description of two different styles of acting class – one with strict rules and another with no rules at all. His reaction to the first was to feel unable to make the best of the experience because he was busy worrying about following all of the rules. His reaction to the second was to be paralysed by the ludicrous range of choices.
I think everyone leading a software team with even a modicum of self-reflection has felt that paralysis. Starting with a blank page, how on Earth do you begin to put together a set of processes for working together effectively?
My main gripe with popular methodologies is that most often the way we use methodologies seems to put us in the other state, worrying about whether we’re following all the rules properly. Of course, proponents of a methodology will argue that this feeling is the result of a misinterpretation of their methodology. Of course it is! Nobody sets out to develop a methodology that makes everyone feel incompetent! (Would anyone care to argue about how long a Sprint should be?)
I would argue that the more rules a methodology has, the more likely people are to feel disempowered by it. They need an expert to come and tell them how to do it right. They start asking if they’re doing DSDM/Scrum/XP/Kanban the “right way”, rather than asking if they are making good solutions, working effectively, or if everyone involved with the project is happy.
So what use are methodologies then?
I imagine methodologies usually arise where someone has established a set of processes in a company or on a particular project and it has worked well. Then, they generalise the process and turn it into something other people can implement.
I think the primary benefit of this is as a source of ideas for how to tackle some common problems in development projects. Find that your developers wander off for weeks on end without delivering anything? Try using Sprints or Iterations or Cycle times to track progress. Worried about communication? Maybe a daily standup will help.
Another benefit is in seeing what’s possible. Without Devops and its very public successes, I don’t think a lot of people would believe you could ship updates to your software several times a day. Some people still don’t.
When you’re starting out, it’s not a bad idea to follow a methodology you like the sound of. I think the trick is to plan right from the start to adapt the methodology to your specific team. That way, you never have to worry too much that you’re doing it the way the creator intended, because you’ll be changing it soon anyway. Here again, Scrum people will say “but that adaptation is an essential part of Scrum!”. And they’re right. But what does Scrum look like without a designated Scrum master? Or without sprints? Some of the stuff of Scrum is widely considered to be essential to Scrum.
Personally, I avoid calling my team a Scrum team or a DSDM team, we’re Agile and we’re happy to magpie tactics, strategies and tools from wherever we can. For me, the important thing is that my team understands the agile mindset. This way we can understand the goals of a particular idea and evaluate for ourselves whether it’s working or not without every having to have that meeting where you say “Guys, we’re not following Scrum/XP/DSDM/Kanban anymore”.
I mentioned at the top that I was going to state what I think are the most important aspects of an Agile mindset. Here goes:
If you’ve made it all the way down here then thank you for your time. If you have any views on this, particularly if you think I have something factually wrong, then please comment and I’ll do my best to respond.
After I started writing this I found this article
by Martin Fowler. It’s brilliant. In many ways it covers the same ground as I’m covering here – describe Agile in a way that gives you a feel for the qualities that are most important about it and why it works so well.