When the Manifesto for Agile Software Development was written in 2001, it was the beginning of a significant change in the way software is constructed and delivered. The uptake of this new model was slower when it was first introduced, but its immediate influence meant the days of waterfall planning were numbered.
Today, nearly 20 years later, “agile” now no longer refers to simply a way that software is developed. It has become a mindset all on its own. Generally speaking, to be “agile” is to apply a value-driven and customer-centric approach to nearly any business problem. This approach is successfully used among business units globally on a daily basis.
Agile is not without it’s critics. A simple web search of, for example, “Alternatives to agile methodology” will provide more than enough results to keep any skeptics well-engaged. Healthy debate is encouraged, and it has helped make agile better.
More recently, one of the 17 writers of the Agile Manifesto, Ron Jeffries, 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 agile has been adapted to suit the needs of your company?
For more information on our we can help you successfully execute your agile projects, call us today on +65 6818 5771.