Having spent the second half of my software engineering career doing ‘agile’ development, I think I’ve spent more time trying to convince people what agile is not than explaining to the uninitiated what it is. Since the so-called manifesto was published in 2001, the whole thing’s been so abused, monetized and co-opted that, for all intents and purposes, it seems to have lost any tangible meaning. By 2014, I had basically decided I would simply use the word ‘lean’, since the culture around agile was so polluted with nonsense…
What made this thing so popular in the first place? I remember reading about it and feeling like it was a bit revolutionary… I was excited by it. Excited because, in many ways, it was a repudiation of decades of stodgy and bureaucratic software practices that I always despised. My blog is called ‘On the Contrary’, after all, so I naturally found this upending of the table appealing.
If I peel back the layers and get at the hot molten core of agile, though, what is it really? What was its intent?
When launching a new business or a new initiative, I see lots of teams make the mistake of obsessing over what process they are going to use to manage the software production efforts.
They start, typically, with some ‘textbook’ example of SCRUM©… this quickly leads to obsessive debate over what ticketing tools to use… which then devolves into silly discussions over what ‘states’ the ticketing process should have (‘waiting for tests’, ‘testing in progress’, ‘testing failed’, etc)… Add in some arguments about what roles would be on the team and the delicate parsing of the responsibilities that do, and do not, belong to each… it doesn’t take long before I’m wondering: ‘When did we stop being software engineers and become process engineers?’
The problem is that we’ve forgotten the FIRST principle of the agile software movement:
Individuals and interactions over processes and tools
Oh yeah… forgot about that.
Serious problems require a serious tool… Meetings should center on concisely written reports on paper, not fragmented bulleted talking points projected up on the wall.
If every software meeting that you attend is being driven by a PowerPoint deck, don’t kid yourself: you’ve got yourself a serious problem. This is a sign of an acute infection of bureaucracy.
Let’s face it, most software decisions… whether it be design, prioritization, process, budget… are conversations that need to be had at a detailed level. PowerPoint presentations, almost by design, forces your meeting participants to gloss right over those details. It implies tacit agreement with high level, and mostly generic points and statements that often bear little to no significance to the problems being discussed.
Let me illustrate by identifying some glaring symptoms of the PowerPoint infection:
When a pack of Software Engineers met in Utah in early 2001 to discuss a new way of building software, the summit did not produce a brand new SDLC, but rather a simple set of guidelines for software teams to follow in order to achieve better results with less friction. This ‘Agile Manifesto’ was as much a guiding force for future software development as it was an indictment of the processes that continue to plague the industry. As simple as the guidelines are, they can be profound when applied properly:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I find it informative to invert the guidelines and ask ourselves what it looks like to build software badly. If you want to build it the wrong way, you’ll define the process and choose tools first, write a whole bunch of documentation and requirements before you write any code, negotiate a detailed client contract but ignore those clients while you’re writing the code, and stick firmly to your plan regardless of what happens along the way. As horrible as that sounds, I’m afraid it also sounds pretty familiar to anyone who’s been in the industry for a while.
William Edwards Deming was sent to Japan in the early 1950’s and propagated his ideas about quality control and production process throughout Japanese industry.
There’s a wealth of wisdom in Deming’s work, albeit much of it industrially focused, but I’m particularly fond of his “Seven Deadly Diseases” of management (with my comments):
- Lack of constancy of purpose
- It’s clear that having some core concepts about what you are trying to do is helpful… simple, effective statements about what’s important to your company, what your company does, and perhaps what your department’s role is in helping to fulfill the company’s purpose.
- Emphasis on short-term profits
- Encourages what Bob Lutz describes as what-can-we-get-away-with thinking.
- Evaluation by performance, merit rating, or annual review of performance
- These systems reward results rather than process-improvement, which can be counter-productive, and thereby encourage workers to maintain the status quo rather than innovate… their goal is to ‘get it done’ rather than to improve how they do so.
- Mobility of management
- Too much ‘reorganization’ interrupts and breaks process improvement initiatives. Probably happens so much because of #3.
- Running a company on visible figures alone
- You cannot measure everything, but must nonetheless do things you think need to be done. Too many times are we told not to do something if you can’t show me it will be valuable.
- Excessive medical costs
- A very interesting observation made over 60 years ago
- Excessive costs of warranty, fueled by lawyers who work for contingency fees
- Maybe not so relevant to the software industry.
It’s also worth mentioning a few other items from “A Lesser Category of Obstacles”:
- Neglecting long-range planning.
- I’m a little torn on this. In software, too much long-term planning can be a waste of time, but you certainly can’t neglect it entirely.
- Relying on technology to solve problems
- I see this all the time. Figure out your problems first please… I beg you… before you start buying software you think will solve it for you… it won’t.
- Seeking examples to follow rather than developing solutions
- Excuses, such as “our problems are different”.
- Placing blame on workforces who are only responsible for 15% of mistakes where the system designed by management is responsible for 85% of the unintended consequences.
- Relying on quality inspection rather than improving product quality.
- Relying on software testing rather than changing how we build the software in the first place.
I’m often drawn back to these little pearls of wisdom and I continue to be amazed at the prevalence of many of them throughout the industry. Keep them in mind while you are trying to steer your own efforts.