Everyone loves to claim they have an Agile (capital-A) process. We have two week sprints! We do daily stand ups! We play planning poker! We have burn-down charts! Working agreements! Story cards! A scrum-of-scrums! But do these trappings really make you (small-a) agile? In our opinion, they don’t. True agility comes from your software and your architecture, not your project management process.
Let’s go back for a minute to the founding principles of Agile software development.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Does that sound like a typical “Agile” shop to you? If you obsess over your burn-down charts and your project management software, are you really valuing individuals over tools? If your trunk isn’t always releasable, and you only release once every few months, do you really have working software? Forcing a team to sign a working agreement and commit to user stories sounds an awful lot like a contract negotiation. Writing out an entire project’s worth of “user stories” in advance and then methodically moving them all to the “done” column by the end of the project feels a lot like creating a plan and following it.
Do you see what we’ve done? We’ve taken pretty decent principles and turned them completely on their heads. We’ve made capital-A-Agile look a lot like Waterfall.
Let’s strip away the trappings and get back to basics. The fundamental insight of the “agile revolution” is that change is going to happen and should be embraced. The business will never know exactly what it wants in advance and its needs will change regularly, even after the “project” is complete. We’ve spent over a decade focusing on how “embracing change” should modify the process by which we develop software, but we haven’t spent nearly enough time focusing on what “embracing change” means for the software itself.
As much as we’re skeptical of buzzwords, we view the popularity of the “DevOps” movement as an opportunity to refocus on the original promise of the “Agile” movement. We need to focus on building software that can easily adapt to evolving business needs. That will be a main focus of DevOps on Windows, and we will explore what truly agile software looks like in future articles.
In the meantime, try not to fall off the agile waterfall.