Charles Lambdin recently published a piece on Medium titled “Dear Agile, I’m Tired of Pretending”. In the post Charles talks about his frustrations with the state of Agile evolution practice. Some notable lines include:
- “Agile is dead.” People keep saying that. But then they say, “We’re just kidding.” They tell you they meant the way you do Agile is dead. And stupid. But “real” Agile isn’t dead. It’s just that everyone does Agile wrong. So I guess real Agile is, you know, Agile in theory. Even I have done this. And you know what? I’m sick of doing it.
- Here’s a quiz for you. How does the first line of the Agile Manifesto begin? No peaking. Don’t know? That’s fine. It doesn’t matter. It says, “We are uncovering better ways of developing software….” Stop. Notice it says, “developing software.” It does not say, “leaning out your org,” “paying down transformation debt,” “cutting it out with this command-and-control crap,” “focusing on outcomes and getting better at discovery work,” “fixing your medieval budgeting system,” or any of the other far more value-adding things people have tried to glom onto it. But the thing is, when people say that Agile pertains to the whole org, it’s revisionist history. It’s dishonest.
I spent the first 15 years of my career in the Enterprise Application Development tools business. I was an adherent of James Martin’s Information Engineering. In the 1980s and 90s Information Engineering was the “thing” in application development and was supplanted by Object Oriented Analysis and Design. To a large extent, Information Engineering is the antithesis of today’s Agile methods. Information Engineering focused on using structured graphical models like entity relationship diagrams, data flow diagrams, state transition models, etc. to capture business requirements and systems design artifacts. These models were used by Computer Aided Software Engineering (CASE) tools to generate applications.
A core tenet of Information Engineering is that text based business requirements and system design artifacts are inherently flawed – they are difficult to validate, subject to mis-interpretation, and generally inefficient. Entity relationship models allowed the capture of business semantics and data requirements. These could be directly translated in logical database designs. Adherence to data normalization rules could be checked automatically.
A central proof point of Information Engineering revolved around the cost to correct defects. Software Engineering studies had shown that it cost $1 to correct an error in business requirements. It cost $8 to correct the same error once an application had been coded. Information Engineering represented a faster, better, and cheaper way to do enterprise scale application development.
Agile Manifesto
In 2001 the Agile Manifesto was published. Agile represented a new way of doing software development. The Manifesto stated:
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
My Experience with Agile
In 2010 I joined a systems management software firm as a product owner. I worked on two product lines. The first was a SaaS secure messaging application. It was developed from scratch in an Agile manner with weekly deliveries of working code and continuous deployment. The second was a tradition licensed software product developed in a Waterfall Scrum approach – 6 to 8 two or three week sprints, with the final sprint focusing on final QA and Integration certification. The product was an independent job scheduling agent that ran natively on everything from Z series mainframes, UNIX boxes, Windows, and even iSeries. As a mission critical piece of infrastructure software QA and certifications were critical. Customers only deployed new versions once a year after extensive in-house testing.
I quickly came to appreciate some of the advantages of Agile – frequent deliveries of working software was a great thing and it reduced a lot of risk. The downside in comparison to Information Engineering is that user stories and backlog items rarely specified requirements in adequate detail. Under Agile we could deliver software quicker and respond to changes quicker – but we were doing it at a code level versus a graphical model. The $1 vs $8 economics were still true – we were just able to respond to defects and incomplete requirements faster than we had in the past.
How Agile Needs to Evolve
As Charles Lambdin points out:
So let’s get on board with continuous learning, and let’s stop pretending Agile was some sort of cure all. This needs to be said: Agile is and always has been a local optimization providing little gain to the system. All Agile did was put software development teams unfairly under a microscope. This does nothing to increase organizational agility. NOTHING. Interestingly, Agile was an attempt to, in the words of Ken Schwaber (see his “unSAFe at any speed”), “undo the damage that Waterfall had done,” and yet Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice.
Agile actually tends to mask the core problem, which is a systemic, bidirectional lack of vertical trust. The Agile trainers leave, having made things worse, with the managers speaking Pig Latin and the dev teams now speaking Esperanto.
Well guess who’ll win? Two camps with two radically different perspectives, but with one camp receiving performance reviews from the other? If the teams are like the blind people feeling the elephant and disagreeing on what it is, then leadership is like blind elephants stepping on people and agreeing they’re all flat. The way out is to recognize that the system is the team. Quit with the local optimizations already, and realize trust is the №1 issue. Stop unfairly putting dev under a microscope and letting everyone else hide in a black box. (Why aren’t we just as concerned with how strategy teams operate? Or how legacy architects are constraints in the system?)
I agree with Charles that Agile is not dead, but in a state of evolution. I wish there was a magic bullet for software development that solved all of its’ ails. Instead his advice to continuously learn and evolve makes the mo