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.
The problem is that Agile is slowly being disfigured from practical best practices on project management to a cult!
PS: This post reminds me of a post we have published a very long time ago: Are we agile yet? (see: http://www.pmhut.com/are-we-agile-yet-are-we-agile-yet )
Thanks for sharing your article! We hope you’ll stay tuned and participate in the discussion as we explore this topic further.
If you strip it all away and get back to the basics, how do you manage the project?
I’m eagerly awaiting new articles explaining what true agile software looks like.
Jason, lots of the “agile” project management concepts make sense and can be valuable if used in the proper context. We just think that ultimately, true agility comes more from having agile software than from having capital-A-Agile management practices. Stay tuned Friday for our thoughts on what makes software agile.