What do I mean when I say “we’re going Nimble”?
Posted on February 11th, 2010 by Paul McArdle – 8 CommentsI was speaking with someone today, who stated that they had inferred I would have a tattoo on my butt reading “Agile Rocks” (or something like that).
I do apologise for any misconception caused by posts such as this one.
I also apologise for the images inadvertently conjured up by the first sentence.
A. What do I mean?
I wholeheartedly support the four key principles of the Agile Manifesto, which I have copied verbatim (but added emphasis) below:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
(a) Individuals and interactions over processes and tools
(b) Working software over comprehensive documentation
(c) Customer collaboration over contract negotiation
(d) Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
B. What don’t I mean?
What it does not mean, to me, is that we must be slavish in following, to the letter, any (or all) of the methodologies that have evolved in and around the Agile banner (which now read like an alphabet soup).
Rather, we need to be pragmatic, in selecting what works for US in delivering real value to OUR clients.
I certainly don’t think that I am the only one advocating pragmatism. What we heard from Cogent last week was aligned with this approach.
It reminds me of (in my previous life as a Mechanical Engineer) consultants bandying around an abstracted version of the Deming philosophy (or BPR, or whatever other fad-of-the-month) to wreak havoc on poor unsuspecting businesses.
It certainly has never been my intention to contribute to the growing jaundice about the misappropriation of “Agile”.
Ultimately, (surprisingly uncommon) common sense needs to prevail in all circumstances.
Hence - to avoid any further confusion we will henceforward label our method of software development (tongue-in-cheek, guys) “our Agile Nimble Software Development Methodology”.
C. How do we work out “What works for us”?
First, we focus on the client, and ask them “how can we make you happier?”.
Then, we continue improving, each and every month, by pursuing a combination of three factors:
1) By continuing down the path of “trying a lot of things and keeping what works”
2) By continually striving to upskill ourselves (through books, webinars, consultants, face-to-face, meet-ups, whatevers) such that our selection of which “lot of things” to try becomes smarter as we learn from our mistakes;
3) By leap-frogging the process somewhat by hiring in a few key people (such as our GM 3D WCW) who have already made the mistakes that we want to avoid (and learnt from them).
D. It’s much more than the software
This is the most important point.
My focus is delivering real value to the customer – and to me ICT is just a conduit through which to deliver this value.
Hence, our need to “Go Nimble!” extends much beyond just our core software development process, and encompasses every aspect of the business.
What are the key principles of this approach:
1) Start with a focus on the customer
2) Always strive to deliver real value
3) Never stop improving.
[...] To enable the company to do this, the company must remain agile (or nimble!) [...]
PS - I like this description of 6 Reasons Agile Value is Different.
For ease of reference, Federico’s reasons are:
1) There is a focus on delivering what the customer needs (shock, horror!)
2) Creativity and innovation is increased (in my mind, it happens because all programmers are brought out of their comfort zones - hence triggering all of the “Five Discovery Skills of Innovation” - but particularly the networking aspect, including with customers & end-users
3) Processes are focused on delivering value (to which I would also add documentation, as a means of achieving shared understanding, not a Pulitzer)
4) Value is delivered early (and also surprises, as the hard bits are done up-front - not left till the end, or swept under the carpet).
5) Value is delivered sustainably
6) Value is the objective - as I keep repeating internally:
Value to the customer = Benefits - Cost (i.e. Price + Indirect)
Value to us, the supplier = Revenue - Our Cost
For both stakeholders, both pieces in the equation need to be taken into account.
I particularly like the reference to Jim’s suggested change to the traditional iron triangle, which always - to me - seemed a trite, defeatist cop-out, as it is assumed a uniform level of skill amongst all development teams. At least Jim’s triangle is an improvement - though it only goes part-way to addressing this shortcoming.
[...] 5)
[...] 5)
[...] is one of the core reasons why we’re in the process of “going Agile” – much as I dislike this [...]
[...] a bit like our transition to Agile.
[...] my mind, this is the primary driver of our pragmatic adoption of the Agile principles – which to me means (in simple terms): real value to the customer, and [...]
[...] in the team is aligned with where we are headed; ii.