Post-Agilism: The Next Wave
Agile software development has existed in some form for almost ten years and while it's awareness and benefits are gaining greater market acceptance it's also becoming clear that Agile itself does not provide any better answers that the ideas that had proceeded it. In fact, the time has come to start thinking of Post-Agilism and the next wave of ideas and approaches that will prepare and support software development into the future.
I presented a topic to the Houston Rational Users Group the other night on Scaling Agile. As I prepared for the presentation and afterwards discussed with several colleagues our experience with agile and software development it became clear that a new movement in software development is starting to form.
For the last 20 years my career has involved software development (in fact if I include all of the software development I completed on my Apple II e/c in High School you could say I have close to 25 years of software development experience!). The last 8 years has been focused on iterative development techniques and what is now widely described as Agile. I came to my understanding of software development and IT in general steeped in a tradition of large process frameworks from the PMI/SEI and RUP. I leanred and applied the Zachman Framework in my early Enterprise Architecture efforts and eagerly absorbed the V-Model as a mechanism to manage projects and their complexities. As a project manager, these tools and techniques were invaluable in understanding how to manage the myriad of complex parts that comprise a large project. My early experiences in project management involved introducing time-boxed, iterations and techniques like Domain Modeling and System Sequence Diagrams.
In 2001 I had an opportunity to apply XP to a project and became familiar with terms like YAGNI - Ya Ain't Gonna Need It, Design Patterns, Unit Testing and paired programming. Later I leveraged story cards to manage tasks and established Information Radiators to provide visibility, I saw the benefits of Test Driven Development and Continuous Integration. I read about Scrum and leveraged Daily Stand-ups, introduced burn-down charts and began to leverage retrospectives with my projects. About three years ago I started introducing Executable Requirements (Fit/Fitnesse) into projects and Feature Driven development, All of these techniques were valuable and over the years I've been able to refine most of them through practical experience.
However, I applied all of these techniques within the context of a larger project management framework. Classic PMP components like budget management, communication, and resourcing needed to come from somewhere, Deployments required coordination with other projects and release windows. Government standards like HIPPA or SOX had to be addressed while also ensuring that integration testing was coordinated with other systems and sometimes other organizations. I learned early on that not receiving early involvement from Enterprise Architecture teams and Network Operations could delay a project more than not getting well defined requirements. The Unified Process helped me manage risk across project phases and structure work across disciplines with roles and responsibilities. The agile techniques I mentioned above seamlessly integrated into these broader models and the results were tangible.
This is the new face of Agile as I see it, an agile that embraces the value system of the Agile community but within the context and realities of getting something done in large enterprise organizations. In the least few years though, I've come across a number of agile experts (or agilistas) who have 8 to 10 years of experience in agile techniques but little awareness (even at the broadest levels) of discplines outside of Design and Implementation. I'm frequently surprised at the level of dogma that surrounds their interpretation of Agile and the lack of tolerance for anything outside of the realm of Design and Implementation. Most have little appreciation for different roles on a project let alone artifacts or awareness of different stakeholder needs. Increasingly agile is becoming a marketing term and it's being leveraged to justify poor work habits and an exclusively developer centric perspective on building software.
I'm not alone in these observations and I've noticed others starting to write aobut Post-Agilism like Jonathan Kohl and Jason Gorman. Philippe Krutchen recently wrote a very interesting piece called Voyage in the Agile Memeplex which discusses agile as a culture and the effects this has on software development and effective communication.
It's time to once again start looking at software development as an engineering discipline, one that requires a balanced perspective which leverages the experience of the past with the new ideas of the future. Post-Agilism is already underway and it's time for the industry to begin adopting these ideas.