In a recent post (Agile Adoption on the Rise? Problems Ahead), Pete Behrens notes that along with an increase in agile awareness comes an increase in the risk of what it means to be truly agile. Pete notes:
“This means that the rise in agile awareness and adoption will coincide with a rise in a veil of “agility” covering almost anything – including traditional software development methods.”
Most of us who coach agile teams have seen this paradigm at work, perhaps a daily Scrum or standup, and perhaps even decent agile project management practices at play. And yet, when you look under the management covers, sprints or iterations are more like mid-development milestones, lots of code in parallel, some features and a demo working in a branch, and yet the teams have not yet mastered the basic mantra of “working, tested code in a short timebox” and the system is nowhere near a “potentially shippable increment”. So long as the teams are working towards that goal, no blood no foul, but if the standup is used as an excuse for agility and the teams are resting solely on their agile project management laurels, and have not mastered the technical practices of shared code ownership, concurrent testing and continuous integration, then that’s a different matter entirely.
Moreover, at the enterprise level. the term “agile” has always engendered such confusion, because after all, what executive would say “no, we are not an agile enterprise?”