When the Manifesto for Agile Software Development was written in 2001, it represented a seismic shift in the way software is constructed and delivered. Adoption may have been more incremental than swift in the early days, but its immediate influence meant the days of waterfall planning were numbered.
Today, nearly 20 years later, “agile” is not only the preferred way to develop software, it has become a mindset all on its own. Colloquially, to be “agile” is to apply a value-driven and customer-centric approach to nearly any business problem. Teams across the globe use agile every day and extol its value.
That’s not to say, however, that agile is without critics. A quick Google search of, say, “Alternatives to agile methodology” will yield enough results to keep any skeptic well-engaged. Constructive debate is healthy, and it has clearly made agile better.
What really grasped people’s attention recently was one of the 17 writers of the Agile Manifesto, Ron Jeffries, who wrote a piece on his personal blog warning against agile misapplication:
“When ‘Agile’ ideas are applied poorly,” he wrote, “they often lead to more interference with developers, less time to do the work, higher pressure, and demands to ‘go faster’. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing ‘Agile’ poorly will result, more often than not, in far more defects and much slower progress than could be attained.” This also causes good developers to abandon agile organisations, he wrote, resulting in a “less effective enterprise” than before agile.
Jeffries also called upon his readers to go back to the foundations of the Agile Manifesto, as it is widely known, and not any one interpretation of it. He offers three strict principles:
- Produce “running, tested, working, integrated” software every 1-2 weeks with capacity for daily updates
- Software should be clean with a bias against complexity, such as by refactoring as you go
- Discuss your work to product leadership and management in its increments, such as “…what’s ready to go, and in terms of what they’d like you to do next.”
What’s most interesting about these debates is the depth of knowledge of modern agile from which they spring. There is also a strong thread that agile remains a living and breathing concept.
We should consider this a collective call to restore the concept of self-organisation and self-determination within agile maturity, which, due to its very age, will have taken on more process and more structure. It’s fascinating to ponder how the return to agile roots might look today. “If I were starting a company, I’d let the teams choose any process they wish,” Jeffries writes. “However, there would be constraints, not on how they choose to work, but what I need to see. I’d make it clear that every two weeks at most, I would like to review their running tested product slice.” Does that sound more familiar than controversial? That’s clearly open to individual interpretation.
Perhaps that’s what the founders wanted all along, a set of guiding principles that could stand the test of time and vary widely in their application: Simplicity, technical excellence, teamwork, building things of value. Debate aside, these are things we can all get behind – and revisit as many times as needed.
Tell us, how has agile been adapted to suit the needs of your company?
For more information on how we can help you successfully execute your agile projects, call us today on 1300 70 13 14.