Welcome to agile reflections.
I’ve worked in the software business for more years than I care to remember , and have ‘agile’ experience going back to when the original ‘Extreme programming’ concepts were being propagated in 2001. Some of us might remember the ‘XP days’ staged in London where this brave new world was being communicated to wide eyed corporate software folk.
Roll forward to 2016 and we are now in a different world, and much wiser for it. The hype bubble around agile adoption has largely come and gone, and organizations are now more more realistic about agile benefits and costs. That sentiment is captured well in an article from which the diagram below is taken
I remain an agile advocate but like anything else agile has to be viewed as a tool/methodology that has a sweet spot both in terms of an environment (culture, tech pre-requisites, process, roles etc) and project landscape (problem type, requirements state, time frames, quality regime). For example, would I recommend agile methods for building the software for a nuclear power station? Probably not. Hence my tag line of ‘agile pragmatist’.
The purpose of the agile reflections is to hold a light to agile methods, tools and techniques to show how the reality of project life aligns with the huge body of agile related ‘propaganda’ that is available on the web. Propaganda might be a loaded term, but we have to remember that there is a whole consulting industry out there selling the benefits of agile methods. Over my career I’ve had the pleasure of working directly or indirectly alongside a number of high profile agile experts/gurus. Not every organization has been so lucky.
Agile itself now stands at something of a cross roads – scaling agile to work for larger organizations is a Rubicon yet to be crossed ‘Disciplined Agile Delivery‘ and the ‘Scaled Agile Framework‘ have much to prove. In the months ahead I hope to cover that and many other aspects. Let the reflective journey begin.