Keeping pace with an evolving understanding
Submitted by Antony Marcano on Fri, 26/02/2010 - 12:32.
agile
One of my ongoing rants was described to me as "awesome" (thanks Amy). I'm sitting here at the early moments of XTC and rather than procrastinate about writing this post, I decided to do it now! Despite doing that, it seems that it took me a month to get round to publishing it!
My rant is often a reaction to conversations that arise about what makes something "Agile". Often, in these conversations the other person places emphasis on "Agile" branded practices. One of the key dimensions of agile methods is a recognition that human beings don't know or understand things 'instantaneously'. We learn in an evolutionary way. This is no different whether we are evolving our understanding of somehting on paper (e.g. in UML diagrams and other such paper based modelling mediums) or whether we are representing this in a tangible, interactive, real implementation of what we think the customer wants. The key difference is that the customer can learn more about their own understanding of the problem they've asked us to solve by using something real, rather than just working on 'paper' (albeit virtual paper).
One advantage of agile methods, is that it arms us with the practices, techniques and thinking tools to evolve the product at roughly the same pace at which the shared understanding of what the customer wants evolves. Well, it's more like a leap-frogging experience - but each jump is a small distance from the last. The "traditional" alternative is that we would evolve our represenation of what we think the customer wants on paper first, and reach a point where we think we have a shared understanding of the whole problem then try to build the product. Of course, as soon as the customer gets their hands on the real product, they can get frustrated because what they now see is based on their understanding of the world months or even years ago. The world and their understanding of it has long since moved on.
The value of being able to evolve the product is that this process allows the customer to see whether what they thought they wanted was actually what they needed and for the team to rapidly react to the resulting feedback and reflect that in the next 'iteration' of the product. This is what iterative development is about - continual refinement of both our understanding of the problem, and the product, hand in hand.
Previous approaches that attempted to do this evolutionary learning on paper first, did so for a very good reason. It was because, using traditional development methods, software wasn't very "soft". In fact it was quite hard, brittle and expensive to change. Agile development methods (such as XP), now increasingly branded simply as the skills of a "software craftsman" make software "soft" again. Inexpensive and easy to change software, makes such evolutionary learning on paper as necessary as planning a road trip on a paper map when you have google maps and GPS.
My rant is often a reaction to conversations that arise about what makes something "Agile". Often, in these conversations the other person places emphasis on "Agile" branded practices. One of the key dimensions of agile methods is a recognition that human beings don't know or understand things 'instantaneously'. We learn in an evolutionary way. This is no different whether we are evolving our understanding of somehting on paper (e.g. in UML diagrams and other such paper based modelling mediums) or whether we are representing this in a tangible, interactive, real implementation of what we think the customer wants. The key difference is that the customer can learn more about their own understanding of the problem they've asked us to solve by using something real, rather than just working on 'paper' (albeit virtual paper).
One advantage of agile methods, is that it arms us with the practices, techniques and thinking tools to evolve the product at roughly the same pace at which the shared understanding of what the customer wants evolves. Well, it's more like a leap-frogging experience - but each jump is a small distance from the last. The "traditional" alternative is that we would evolve our represenation of what we think the customer wants on paper first, and reach a point where we think we have a shared understanding of the whole problem then try to build the product. Of course, as soon as the customer gets their hands on the real product, they can get frustrated because what they now see is based on their understanding of the world months or even years ago. The world and their understanding of it has long since moved on.
The value of being able to evolve the product is that this process allows the customer to see whether what they thought they wanted was actually what they needed and for the team to rapidly react to the resulting feedback and reflect that in the next 'iteration' of the product. This is what iterative development is about - continual refinement of both our understanding of the problem, and the product, hand in hand.
Previous approaches that attempted to do this evolutionary learning on paper first, did so for a very good reason. It was because, using traditional development methods, software wasn't very "soft". In fact it was quite hard, brittle and expensive to change. Agile development methods (such as XP), now increasingly branded simply as the skills of a "software craftsman" make software "soft" again. Inexpensive and easy to change software, makes such evolutionary learning on paper as necessary as planning a road trip on a paper map when you have google maps and GPS.