A Retrospective on Returning to the Spirit of the Agile Manifesto (Using the words of the Founders, Elvis Costello, and the Tao)
By: Allan Gross
“It’s a devastated wasteland. The life has been sucked out of it. It’s a few religious rituals carried out by people who don’t understand the purpose that those rituals were intended to serve in the first place.” — Kent Beck, creator of Extreme Programming
If you’ll excuse a brief diversion down the rabbit hole, I can tell you that I started to write a straightforward essay on the state of Agile Software Development, supplemented by some quotes from the writers of the Agile Manifesto themselves. Along the way, I flipped on some music, did a bit of Internet searching, and before I knew it, I headed off in a different direction.
On Elvis Costello’s Punch the Clock, there is a song called Shipbuilding. In many of Mr. Costello’s songs he hides literal meanings and allows for varied interpretations with vague but interesting imagery. Shipbuilding offers a more direct, pointed allegory spawned from the buildup to the war in the Falklands. I’ve read that Costello was particularly proud of the haunting line, “Diving for dear life when we could be diving for pearls.”
The line seems relevant as we consider the choices we make, in what, why, and how, we do any job. We can build ships for war or we can build them for more peaceful or pleasurable pursuits, like diving for pearls. The boy depicted in the song learns… “that people get killed in the result of this shipbuilding”. This also reminds me of verse forty-six of the Tao te Ching as translated by Stephen Mitchell. He modernizes this ancient wisdom as: “When a country is in harmony with the Tao, the factories make trucks and tractors. When a country goes counter to the Tao, warheads are stockpiled outside the cities.”
What does all this have to do with Agile Software Development?
I remember well when I picked up my first edition of Kent Beck’s seminal Extreme Programming Explained back in 1999. I was blown away. It really spoke to me, as it did to many software developers. It was not just a set of techniques to develop software, but it created a feeling that software developers were not hired assembly-line workers generating code. There were human values and principles involved. And fostering these values would also help in building quality code! Great stuff!
“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.”
While the four main bullet points are not numbered, I find it significant that the first one references the value in people. This was a relatively new and important idea at the time when being applied to software development. And the Manifesto’s list structure has a familiar Taoist nature, with the comparisons replete with a sense of duality. You can value the items on the left AND the values on the right, even when they seem at odds. It is surprising how often I encounter developers who have been taught Agile Software Development but really don’t grasp this spirit. As Ron Jeffries said, “And worst of all, agile methods themselves have not been agile. Now there is an irony for you.”
Today, depending on your organization, you may get a feeling that for the most part Agile is trapped in time and space. There are exceptions, but it is fairly static, as pointed out by Jon Kern, who lamented, “Scrum, scrum, scrum, scrum. Part of me is happy that there are legions out there turning the sod under, trying to sow the agile seeds via Scrum. Another part of me thinks it is like Corn-to-Ethanol. A waste of energy for the dumbfounded among us, spurred on by lots of lobbying.”
Andrew Hunt described it this way, “The word ’agile’ has become sloganized, meaningless at best, jingoist at worst. We have large swaths of people doing ‘flaccid agile,’ a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots — as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim.” Given this religious fervor, it won’t be easy. The genie rarely goes back into the bottle without a fight, and customers feel like they are getting a great deal of work from the team with this forced structure. There is pressure to continually standardize or reduce the length of sprints, like that is chiseled in a stone tablet or cast in deathless bronze. James Grenning explained, “Generally, I am critical of what most Agile adoptions have become, Agile in name only (AINO). AINO adoptions leave developers feeling like they are being micromanaged and pressured to do poor work.”
Do we see a trend here in where the failings come from?
So, while it is useful to examine the shortcomings of the Agile technical evolution, it is more important to see what the true goals of the Agile Manifesto were, where they went wrong, and what we can do about it. Many of the creators have tried to do this. As Ward Cunningham (creator of the Wiki) said, “Agile is the accepted methodology, and people are ready to find the next variation of it, to master its intricacies and respond to the computing opportunities that are out in front of us and however we need to organize to do that.”
It is also interesting to see all the directions the creators have gone and some of their creations. They have, for the most part, attempted to live the vision, to continue to adapt, to create, to try new things, and make software development interesting and empowering for software developers and the engineers and team members that work together to solve problems. Andrew Hunt has his GROWs method, others have gone on this to expand Agile in more business-oriented areas (business agility), or simply helping corporations adopt Agile practices effectively.
So, all this to say, what if “spinning in place” isn’t just about Agile development losing its way in terms of software development methodology. What if the metaphor runs deeper? Maybe this is more about losing the spirit of humanity that was initially instilled in the movement. Is this all about business practices? Are we back to just shipbuilding again? Have we lost the spirit of diving for pearls? Of finding beauty and perhaps self-improvement? Where is the joy in what we do and what we accomplish through the spirit of a team that communicates well, shares knowledge, and a passion for learning their trade, while taking pride in supporting their product? Does this need to be spelled out in a new Manifesto?
Kent Beck noted fairly recently that the most important skill he was learning was “compassion”.
Interesting. Leave it to Kent to get me spun up again.
That is the type of spinning I can appreciate.