tl;dr Codifying your process is useful as it guides others who come after you, but it may give them the impression that they’re using your process and therefore have no permission to change it. It may even leave them arguing over the detail of what you really meant rather than thinking for themselves.
I was listening to a BBC broadcast about the history of Islam the other day and a quote from Zaiuddin Sardar caught my attention:
Once you codify something you kind of make it permanent. You say, well, that’s the end of the question, you’ve answered everything.
The reason it caught my attention is that I think this is what has happened in some quarters with Agile. Not for all of its practitioners, and as far as I can tell certainly not for its creators. But I think for some of its critics and for many unfortunate practitioners (and their colleagues!) Agile is a done deal. It thinks it has all of the answers.
I find this odd. The drafters of the manifesto seem to have been very careful to word it in such a way as to avoid giving that impression. “We are uncovering”, for example, is present tense and the word “uncovering” seems to me to set the author very much in the space of an explorer on a journey rather than an all-knowing guide or expert. (Don’t worry, I don’t plan to analyse the manifesto statement by statement in this post, it was just the one phrase!)(But, actually, maybe do worry as all I will be doing in this post is offering my considered opinion with no evidence to support it.)
Thinking for myself is probably my most basic and essential need. Once upon a time, I believed in God. However, I think I had dispensed with the rules and regulations by the time I was about 11. I felt like I knew what God was about and what he would think was important. For example, I decided Jesus’ teachings probably indicated that praying and attendance at church were nowhere near as important as not being a dick to people. (Incidentally, I no longer believe in God, but happily I’ve found plenty of other reasons for not being a dick to people.)
These days, my need to think independently translates into my work, where I am rarely the first to jump on the bandwagon of the latest tech craze. I need to be convinced that it’s a good idea first.
Where Agile is concerned, I saw a little of it at university (on an Agile course run by a guy called Mark Van Harmelen, circa 2002) but then soon after I was swallowed by work environments where Agile was unknown. When I reintroduced myself to it years later, I can credit the manifesto and some of the writings around it with changing my perception of what software development is. I had believed it to be a primarily technical activity. In fact, it can be a collaborative effort in which the encoding of software functionality is only one (albeit difficult!) part.
But, for me, it stopped there. Each of the four values of the manifesto, and each of the accompanying twelve principles, mix together to leave me with a flavour of what Agile is and how it differs from what I’d been doing before. I was attracted to it because I could see it as a possible solution to problems and pressures I’d actually seen in software development. Every project since then has reinforced and deepened my understanding of that flavour, and convinced me that something like this is how I will always work.
Crucially, however, all that stuff other than the manifesto – the methodologies, the story points, the standups – are just resources I can look at and appraise, taking inspiration and ideas where I find them. None of them is a codex to be followed religiously.
I am not, therefore, in a position to say that Scrum doesn’t work. I’ve never spent enough time poring over the manual to be sure I was ever doing it right. However, I also don’t find myself being interested in arguments about whether something is or is not Scrum, or for that matter whether something is or is not Agile. For me it seems to miss the point.
Are you producing good solutions for your users in a timely fashion? Are they happy? Are you? Do you feel like you’re collaborating? Does everyone in your team take ownership? Do you feel listened to and encouraged to progress in your career? Do you think those in your team who look to you for leadership feel the same?
Those are all questions that would be important to me on any project. If I could answer an emphatic “yes” on all of them, I’d consider my team to be doing an awesome job and I’d be confident we could keep on doing that awesome job for a while yet. If you could answer them all in the affirmative, would you care if what you were doing was Agile?
Some people clearly do care. I think the reason they care is because some people wrote down clearly what Agile means. That is, I think the very thing that gave me inspiration to change how I worked and, I think, become a better professional, inspired in others a need to protect the word above all else. Or, in some cases, to hold the word accountable for the failures of the people who say they follow it and criticise it for everything it didn’t explicitly mention.
There’s an episode of the West Wing where several characters debate privacy protections conferred by the US constitution. The constitution doesn’t have any explicit language that protects privacy so one side argues it just isn’t there. The other side argues that it’s implicit. They provide examples of other constitutional protections that are obviously implicit in the constitution. They both have an argument. If the framers of the constitution thought privacy was so important, why isn’t it in there explicitly? Well, maybe they didn’t think it was important. Or maybe they thought it was so obvious it wasn’t worth mentioning.
What is really important is whether, on balance, we think privacy should be an inalienable right. But, instead of arguing about that, the characters argue about the constitution. I’d take a punt and say that those who argue privacy is implicit from the constitution also like the idea of privacy as an inalienable right, while those who argue it isn’t implicit don’t (or are looking to criticise the constitution itself).
This, I think, is the problem with codification of the Agile manifesto (or anything else for that matter). On the one hand, it spreads the word more quickly and clearly than anything else. It provides a clear way to show what we definitely do and what we definitely do not think. However, it’s also going to leave a lot of people arguing over the crinkly bits at the border when they really could spend their time more fruitfully doing something else.