Uprooting agile
September 14th, 2008 • Business, Internet, agile, software development
Agile methodologies are being bantered around again and are quite often discussed as if for the first time, with an energy that is exciting, but at times with a level of certainty and yet incompleteness in some people that just doesn’t seem to fit – I’ve recently sat through presentations and had discussions where people seem to be looking for some kind of fame or self-certified expert opinion without getting to the roots of this clearly historically evolved perspective – They are grasping at small aspects of what appears to be a much broader subject that requires careful review. Don’t get me wrong, i love the banter, but either i am just well far behind everyone else on this subject (which is most likely true), or they are just blagging.
So, my mission is to uproot the agile working methodology and get an understanding of:
- What are its parts?
- What are its predecessors and its history?
- What is its scope and who does it impact (it’s clearly a lot more than TDD, although some people don’t seem to think so)?
- Is it actually possible to “do” or “not do” agile, or is it valid to adopt only some of it’s parts (This sounds like an obvious one, but i’m fed up with hearing “we do agile” and “we don’t”!)
- How can we benefit from its many parts?
I’ll be posting more as I progress my uprooting.
I might have a stab at Agile’s predecessors and its history: I think its heritage goes back through “Lean Software Development” to “Lean Manufacturing” and back further to the “Toyota Production System” (TPS).
TPS in turn is often described as a “5th generation” innovation methodology. And lots of people are arguing that we are now in a 6th generation world in which the number of collaborators that can be involed in innovation is now exponentially larger (blah, blah).
One thing to notice about TPS, Lean and Agile (and Prince for that matter) – they all assume the ‘doer’ (coder/innovator) and the ’sponsor’ (client/user) are in essentially the same organisation and that the problem to be solved is effectively an internal one.