It seems that Agile has grown up. That was certainly the message I received when I attended the Valtech Agile Edge event recently. The people attending were primarily from large enterprises and the public sector. The type of attendee was not a surprise, given that target audience for the Agile Edge event is programme managers, CTOs, etc. The attendees seemed genuinely excited about the application of Agile within their organisation. It was there that it dawned on me just how far industry adoption of Agile has come in the last few years.
A Trip down memory lane
But where did Agile start? Nostalgia led me to recall my own introduction to the Agile movement back in its halcyon days. Many years ago I worked on a team that successfully adopted the eXtreme Programming (XP) methodology. It seemed a breakthrough that XP had addressed the delivery cycle (requirements, prioritisation, etc) AND improvements in development practise (Unit tests, Pair programming, refactoring, etc) with one fell swoop. In many companies, the adoption of XP was driven by developers trying to deal with delivering quality software with right features, on time. Often this grass-roots movement was successful and early adopting organisations saw the benefit of Agile methodologies. News of successes made it to senior management, and finally Agile had broad acceptance as an effective way to deliver software.
Times have changed. Nowadays, often it is top-level management driving Agile adoption. Success in promoting Agile as a process for managing projects, programmes and product portfolios is great news! However, it is my belief that we must be careful to remember that the successes of many grass-roots agile projects are not solely related to the Agile delivery cycle. My own productive experiences with XP were as much to do with new software development practises, as changes to the delivery cycle.
Back to the roots
In a quest to determine whether the founders of the Agile software movement had considered software-specific practises part of Agile, I referred back to the Agile Manifesto website. The 12 principles accompanying the agile manifesto were illuminating. One particular principle caught my eye:
“Continuous attention to technical excellence and good design enhances agility”
Technical excellence is not a direct product of SCRUM, Kanban or other delivery cycle management methodologies. When companies adopt Agile from the top-down, they must nurture a culture of technical excellence to complement its delivery cycle management. XP had this built in, but for those methodologies that do not, inspiration must be sought from elsewhere if we are to stay true to the Agile movement.
The Agile Hangover?
Some companies have discovered that Agile is not a magic bullet and projects can still deliver bad software. I have even heard that we are now suffering an Agile hangover (but we did party hard, right?). I believe that many of these failures are due to a lack of focus on technical excellence. I am sure that there are many who agree with this. Indeed members of the Software Craftsmanship movement propose their manifesto is the solution to an Agile hangover, even the natural successor. This theme of replacement was elaborated during a talk by Sandro Mancuso and Mashooq Badar on Software Craftsmanship at Agile Edge (thanks guys for a great talk!). I however, do not view Software Craftsmanship as a successor – I believe it is actually reinvigorating some of the founding principles of the Agile manifesto. Software Craftsmanship focuses on delivering technical excellence and better design, and bundles it under a coherent and sound-bite friendly name. Viewing the two as complimentary can deliver a powerful set of tools in the challenges of delivering software. Hopefully the top-down implementors of Agile will hear of the successes of Software Craftsmanship and actively champion this in the future as a complimentary tool to already accepted Agile methodologies.
Principles behind the Agile Manifesto: