Update: there are two papers in this series: “What Does Agile Smell Like?” and “Agile QA Automation.”
As mentioned a little while back, I have 3 short notes on Agile I’ve been working on. The first, “What Does Agile Smell Like?” goes over a list of several “gut checks” you can do to get a sense for how Agile an organization is.
9 Smells
For those who don’t want to download the PDF, here are the sniff tests, without the rest of explanation:
- An Agile organization develops iteratively, verifying that the
software is going in the right direction at the end of each
iteration. - An Agile organization has very flat and open communications
paths. - An Agile organization arranges it’s work to be done in
prioritized queues, allowing the ordering and content to
change over time as required by the business needs. - An Agile organization values putting off a decision for as long
as possible, but, still makes many decisions. - Agile developers tend to check in smaller, but still operational,
batches of code rather than larger, feature complete batches. - An Agile organization runs a large amount of tests on a daily, if not hourly basis.
- An Agile organization builds and tests it’s software at least
daily, fixing broken builds rapidly. - An Agile organization values frequent communication over
comprehensive documentation. - An Agile organization operates on trust, respect, and
delegation instead of command and control.
I guess 10 would have been a rounder number, but I wasn’t counting at the time.
Further Revisions
As you know, dear readers, we like to practice open analysis, so if you see something missing, or bogus, just tell me or leave a comment, and we’ll probably put it in the next revision of the note.
Get It!
The note is available for here.
Technorati Tags: intuition, pdf, peopleware, projectmanagement, smells, testing
The point is to make decisions only once you have all the required input rather than making decisions just to make them. And, of course, building a process that enables that.
In fact, as this great interview with Chris Matts about "Real Options" outlines, there's actually incredible "business value" in being able to put off a decision instead of having to lock yourself into making one.
Hopefully that's explained adequately in the PDF. If not, I'll have to update it.
How'd the nods for for 5-9?
hrm…. I was nodding until I got to 4.
An Agile organization values putting off a decision for as long as possible, but, still makes many decisions.
Not saying your wrong, but that doesn’t smell like an agile org. to me… can you explain what about this behaviour has the scent of agile?
(disclaimer: I haven’t read the PDF!)
You touch on it in #3, but I think it would be worth breaking out a separate "smell":
10. An agile organization interacts with customers and revisits requirements on an ongoing basis.
A fundamental part of agile development is avoiding BUFR.
It’s important to note that deferring a decision isn’t the same as shirking it – Agile recognises the value of making the decision (and I think we need to recognise that we will NEVER have all the data), but also the value in keeping as many options open as possible for as long as practicable.
yeah, I was still nodding from 5-9.
I understand what you mean by no. 4 now, but still not loving the wording.
my experience of companies leaving decisions as long as possible is certainly not an agile one… for me it's more about having the right information to make the decision or being proactive rather than reactive about decision making…
nice list tho' 🙂
ya on #4, seems to me it’s a slippery slope to “paralysis by analysis”. Maybe I’m missing the point to thought. I kinda like the concept of a bias towards action, make decisions with the information available knowing that mistakes will be made, and code will have to be re-factored later. Am I way off base?
I think #4 could use some re-wording them. I’ll have to go re-listen to the above and re-read the relevent stuff in Implementing Lean Software Development to see how they do the rhetoric to get the point right.
The idea is supposed to be that having more than one option is more valuable than having just one option (or no options). So, you want structure things to allow for that. But, yes, the wording might be too counter-intutive ;>
nope. cote i think you got it right, its just that the point is counterintuitive. the fact is requirements will change- which is why you want just in time decision-making. you don't make a bunch of decisions and expect them to be set in stone. compare and contrast Longhorn aswas and the .NET framework 3.0 – same code, different choice of when to make the decisions. so decisions are made about the units of work, but not the entire design, and how it will all fit together – that way there *is* a bias to action, but also a bias to delivering something users want and need, rather than something you and they hoped they did 18 months ago…
decisions are implementation decisions, and as such should be put off until something is implemented.
requirements change over time. so should code. if you decide everything up front you might as well lay concrete on a set of formal requirements in a 50 page Word document.
oh yes – try reading the doc. i bet you’ll be able to help us nail the language so the point works, even for a useability expert
further thoughts on design decisions and finalisation…
http://copia.ogbuji.net/blog/2006-12-11/What_s_goo
In addition to reading over the relevant sections of Mary and Tom Poppenendieck’s book, I would recommend checking out an earlier, related article available on their website about Lean Development: http://www.poppendieck.com/lean.htm
Specifically, take a look at Lean Rule #4: Pull from Demand (Decide as Late as Possible) – sorry, no anchor link.
My favorite line from the section is the last one: “the ability to make decisions as late as possible provides a competitive advantage.”
Indeed, that’s the line — or a variant of it — that I’m referencing looking for. Explaining it is what takes some effort, thought it seems to make intuitive sense to me. I think it’s best to find an analogy: maybe selling stock or other investments. That is, doing something at the right time rather than doing it too early just for the sake of “getting it done”…?
Love the concept of 'smells' for principles…
I wrote a similar post on my blog "all about agile" and picked out different principles that I think really characterise an agile project over another. And I did get to 10 🙂
For my "10 Key Principles of Agile Software Development", see here…
http://kw-agiledevelopment.blogspot.com/2007/02/1…
Kelly Waters
http://www.allaboutagile.com