Do you have experience with agile processes
Anybody involved in the hiring of software development professionals has, no doubt, asked this question. Like myself, I am sure many are beginning to notice that the question is becoming redundant. The agile manifesto is now over twenty years old and almost all organisations that are in the business of building software systems have, (or at least believe they have) adopted its ideas. We now find ourselves in an environment where not only does every potential candidate have experience with agile approaches, but most do not have experience with anything else. Those of us with actual experience of alternatives such as ‘waterfall’, where waterfall was an actual lauded process, and not merely agile’s hypothetical evil twin, are the punch card engineers of our generation. If this paragraph makes you feel old, then it has had its intended effect.
However, just because everybody is doing it, does not mean everybody understands it. I recently asked a candidate who made something of a highlight of his agile experience to define exactly what it means to work within an agile process. The very first words he spoke were, “well, firstly, we do stand-ups religiously”. Religiously? Had I been asked to choose a word that does not belong in a description of agility, I don’t think I would have been able to choose a better candidate. Religiously indeed! This could have easily been filed as a mere turn of phrase, or slip of the tongue but I did leave the discussion feeling that a wider issue in today’s software development ecosystem had been uncovered, quite expertly, by the use of this one singular word.
In another such instance, I was presented with the CV of a candidate who insisted on capitalising agile into “Agile”. Is there a greater indictment of the consultant class than their ability, over time, to slowly convert an adjective into a noun? Agile is no longer a property, it has become an *entity*; an object. No longer are we traversing across a complex landscape of peaks and troughs; evolving and growing faced with ever more complex environments. Instead, we have picked our location and built a castle; fortified our walls and gone from nomads to settlers.
Rife now, are discussions of say, Scrum vs Kanban, but this is merely to chose two existing castles and compare the decor. The toolset of good ideas that these packaged methods contain are, at foundation, merely the published outcomes of somebody else’s successful experiments. As such, they represent a fantastic place for a team to start on their journey. They do not contain a solution for every problem, and for some problems, they are not the solution. If a team do not feel at liberty to leave the safety of the castle and make their own journey of process development, then in what sense are they considered to be agile? Adherents of any particular named agile methodology would certainly do well to differentiate those parts of the package that are designed to facilitate change, development and growth, vs those parts that are, more simply, the successful experiments of others. There is much value in the latter, but not nearly as much as in the former.
German physicist Werner Heisenberg, who recently shot to fame as the pseudonym of television anti-hero Walter White of Breaking Bad, presented us with the “uncertainty principle” in a 1927 paper. There is a firm tradition of unqualified lay interpreters abusing this idea to make a point; a traditional I intend to perpetuate:
The more precisely you know where you are, the less precisely you know where you are headed.
This is important. It is exactly why words such as “religiously” have no place in the discussion. What does “religiously” mean, except to express a position that you are so fundamentally attached to an idea or concept that it is *not* subject to change and development? That castle has high walls.
What we should be doing, at every step, is acknowledging the transitive nature of our process elements. What you are doing today is only something that you are currently doing. Were we having this conversions a month hence, the answer to questions related to where you currently are may very well be different. With this in mind, no proper assessment of a person’s understanding or commitment to an agile mindset can be made based upon their current location, just as Werner taught us. What is relevant in a discussion about agility is the means by which change is made, assessed and, crucially, how quickly bad decisions are reverted. There is little more paralysing to the decision making process than the feeling that you are stuck with whatever outcomes it produces. This is why all of us have had the experience of long and painful discussions, running through scenarios; worst cases, best cases etc. Pushing on as conditions worsen is a primary cause of death for sailors, pilots and hikers. The feeling that turning back will not be an option is a reason for people to never take to the sea, sky or hills in the first place. The only way to proceed is with the knowledge that any given step may be the wrong one, but that there is always another route to take.
The option to revert is the best way to minimise both the impact and shame of failure. Minimising the impact and shame of failure is the best way to facilitate change.
Back when I was just starting out on my journey into this space, a mentor of mine was rather fond of asking the rhetorical question, “when do you want to know that you have a problem?”. It’s a fantastic question to ask, and one that has always stuck with me. For my own part, I like to add the subsequent question, “how well positioned are you to do something about it?”. Some organisations are not aware of their problems. Some organisations are aware of them but have no means by which to do anything about them.
The ideal that we should be striving towards is to discover quickly and act rapidly. One might call that agility.