Upstream Agile Project Checklist (updated)
updated: added sven’s point from the comments
Explaining agile to customers is hard, sometimes more, sometimes less so. In order to improve communication and make it clear what to expect and what not to I came up with the following checklist of what agile projects are about:
You DO get a working, maintainable, production ready, 100% quality piece of software in a fixed amount of time.
You do get a first working, maintainable, production ready, 100% quality version of that software after a very short time (usually 1-2 weeks).
You DO get to launch your software in time.
We DO pair program all the time to ensure that quality and it doesn’t slow us down.
We DO write automated tests to ensure that quality and it doesn’t slow us down.
You DON’T necessarily get all the features you wanted after an iteration.
That’s why it’s important that you DO prioritize what’s most important for you.
We DO estimate how long each feature will take us to implement. But it’s only an estimate.
We DON’T accept a functional specification you bring in as a basis for our work.
We DON’T believe this would work. We DON’T believe it is possible to completely specify a software upfront with tolerable effort.
We DO use your functional spec as a basis for a discussion where we’ll write down stories for each feature together with you. Those form the basis of our work.
We DO embrace changing requirements by working in short iterations.
We DO deliver successful software projects when working like this.
__________________
Signature Customer
Anything I forgot? The comments are open.
June 4th, 2009 at 07:09
Hi
I totally agree with your list, except one point: “We DON’T accept a functional specification you bring in as a basis for our work.”
What else than a functional list of requirements and specification you take as basis of your work? But I guess its just to clarify the wording. For me a functional specification is not a list of specified functions a system should provide, it’s more a definition of business needs, a list of non-system-specific requirements I need to be solved.
When you see it as a list of inputs, buttons etc. you’re right.
Fritzek
June 4th, 2009 at 07:42
we base our work on user stories we write together with the customer. with that functional spec I mean a waterfall like document that has “everything you need”(tm) in it.
June 4th, 2009 at 09:16
I agree that point could be improved. Maybe like this:
We DON’T accept a functional specification you bring in as a basis for our work. *)
…
*) We DO accept your functional spec as a basis for the discussing of user stories that we’ll write together with you.
June 4th, 2009 at 11:59
We DO drink buckets of Club-Mate to ensure your project will be done on time.
June 4th, 2009 at 12:51
That’s a secret, shhhh!
June 4th, 2009 at 14:50
I suggest one more
And YES, we would like to have Steven Bristol to assist us in eliminating alcoholic beverages in town.
June 4th, 2009 at 15:46
Does that mean that an agile team that has inherited legacy code to work on (by Feathers’ definition: having no tests) is no longer agile by virtue of the inability to produce 100% quality every two weeks? Is this so even if they follow all the other practices to a T?
This is the only objection I can raise, given the specification amendment suggested above. Legacy code frustrates the release of assured quality on short timeframes. IMHO getting from heavy tail-end QA to quick, quality releases is the biggest challenge in transitioning and may take many months or even years depending on the size and scope of the legacy programs.
Getting the code under test is hard, and Michael’s book “Working Effectively With Legacy Code” helps quite a bit, but without everything under test it is quite difficult to avoid cringing at the phrase “100% quality”.
June 5th, 2009 at 09:48
@frizek just what sven says
@sven agreed, i’ll add that to the list
@steven right, now you’ve spoiled our success secret
@tim i guess we have been fortunate enough not having to deal with too large amounts of “legacy code” (isn’t all code legacy code from the moment after it’s written?) so my experience with that is limited – in cases where we have to rely on such legacy code we can still be confident that it works by covering that in our integration tests. i don’t think this is much different from using external libraries.