What is Agile?
I met with a potential client last week and found my self answering the question, “what, in a nutshell, does agile mean?”.
To date I’ve never had a canned answer to this and can come from various directions perhaps talking about the history and how it’s an umbrella term for a whole bunch of things or maybe talk about what it’s like working on an agile team. On this occasion I was quite pleased with the answer that fell out:
Agile is about delivering business value!
Businesses tend to exist in a state of constant change so if we want to deliver something valuable to them then we need to be willing and able to embrace that change and deliver quickly.
In order to deliver quickly and deal with change we have found that quality is a necessary. This is particularly true if we want to continue to deliver over a sustained period.
At the bottom of this stack, underpinning all the elements mentioned so far is the need to treat workers with respect and empower them to do the right thing. Without this you wont achieve the quality or speed that you need.
So:
Value <- Embrace Change <- Quality <- Respect & Empowerment.
Is there any more to it?
That is a very good insight. I’m sure you felt good listening to yourself at that moment in the customer meeting
Here’s some questions that popped into my head after reading this:
What do you mean by quality?
Do you mean to say that value is built on top of embracing the change and that embracing the change is built on top of quality or what do you mean by those arrows?
What do I mean by quality? I could answer that with an essay and still not be happy so I’ll be generic.
When I refer to quality I’m considering a wide range of traits, some of which the customer will recognise as important e.g. performance and defect as well as an aesthetic of the software its self e.g. design quality, conformance with good design practices such as encapsulation, loose coupling etc.
All of these aspects of quality affect out ability to modify software according to new business need. In particular a good test suite will support our ability to refactor which is necessary if we wish to embrace changing needs.
Hope that clarifies things, thanks for commenting.
Thank you for the clarification.
I think it is a curious thing that to be able to deliver something quickly one must consider quality.
Generally when I consider quality I seem to think that higher quality takes a longer time to achieve than lower quality. I guess this ties in with the belief that en masse production results in lower quality than something that is produced in single bits. This does not necessarily hold true of course but I feel that is usually the general belief in most fields.
I wonder to how many fields this “speedy production == lower quality” notion applies to. Software development seems not to be part of that because as Steve McConnell mentions in one of his books: concentrating on quality almost always reduces production time.
Somehow that is hard to believe in reality but easy to understand intellectually after studying it for a while.
I know exactly what you mean, I’ve had the same problem myself! Here’s my take on it:
http://www.agile-software-development.com/2008/01/definition-of-agile-software.html
Kelly Waters
All About Agile