Sunday, July 19, 2009

A Couple of More Agile Flashcards

a couple of weeks ago Jeff langr and Tim Ottinger asked the public at large to contribute a couple more ideas for agile flashcards onto their site Agile in a Flash.

I decided to quickly create a couple which you can find at their site, but I've listed them again here just for reference purposes.

Of course, I probably need to spend a little bit more time on them to polish and clean up the quality of the grammar.

domain driven design(by Eric Evans)
-Agile documentation (by Scott ambler)
-agile modeling (by Scott ambler)
-product oriented development lifecycle
-enterprise stakeholders

Here are some other ones I hope readers also find useful...
Behavior Driven Development:
1) use story driven scenarios to specify the acceptance criteria for an iteration

Given [some State]
And [some more state]...
When [an activity completes]
And [another activity completes]...
Then [an assertion is true]
And [another assertion is true]...

2) wire these acceptance criteria into an automated acceptance testing framework (like fitness)

3) have your developers write code for the iteration into the acceptance criteria pass

-make sure to use the ubiquitous language when defining your stories/tests
-focus your requirements and quality testing efforts on designing these executable requirements at the beginning of an iteration
the Kano model of customer satisfaction
-when creating a backlog for your customers, categorized items into:
-reverse (don't implement these :-))

Do this by developing a questionnaire that asks different stakeholders how they would feel if a specific feature was present or not present
1. I expect it to be this way
2. I like it that way
3. I am neutral
4. I can live with it this way
5. I dislike it this way

both negative and positive answers can be cross-referenced to determine the category of the feature

See for a example...

Value Stream Mapping:
the best way to determine how much agile can help an IT delivery organization is to perform a value Stream mapping analysis.

Measure the ratio of work to wait time/waste for both the current and suggested future development process

Do this for
-larger features
-typical bug fixing
-emergency fixes

(Picture here)

Web 2.0 Based Documentation:
make sure all documentation, including technical specifications, standards, decisions, etc. are all placed on a web-based collaboration platform.

This collaboration platform must
-allow all participants to modify content
-be available to both internal staff, contractors, and outsourcing
-promote an open, collaborative approach to running projects

Excellent examples are wiki, blogs and user forums...