List of Agile practices

I read an interesting list of agile practices at Naresh Jain's blog: Explosion of Agile Practices.  I think there is a lot of overlap in his list, but it made me re-visit what I think the core list of lean and agile practices should be.  My list is below in no particular order.  Each item can be expanded - for example, Technical Excellence implies TDD, simple design, following SOLID principles, etc.

1. Daily Stand-ups
2. Visual Project Management
3. Customer Accessibility
4. Technical Excellence
5. Frequent Delivery
6. Frequent Retrospectives
7. Continuous Improvement
8. Continuous Integration
9. Co-located teams
10. Iteration Planning
11. Team Estimating
12. Acceptance Tests (and automation of those tests)
13. User Stories
14. Self Organized Teams
16. Iteration Demos

Update 8/15/2010:
- And one more... Deliver Value!

Agile scope completion techniques

One of the questions I've received in the past about agile techniques is how to ensure you've captured enough detail about your requirements in order to proceed without missing major scope elements.

Whether you are using story cards, features or other techniques to capture your requirements, you need to answer this question: "How do I know when I've done enough requirements gathering?" In waterfall this is ‘easy’ – gather all the detail and sign-off (ok – I’m simplifying). In agile, we depend on features or stories, but many are concerned that major scope elements will be left out which will either cause many items to grow exponentially in size or that feature X is really feature X, Y and Z. For example, when the registration screen has 50 fields instead of the 10-15 that we might have assumed, but didn’t write down. It is hard to understand how this can be done in 1 or 2 days using feature or story cards that contain only one line of description, a few lines of acceptance and a few assumptions.

Three things for you to consider to help you solve this dilemna:

1. In waterfall techniques, although we hold some comfort in our massive requirements documents, we know from experience that even then things will change and things will be missed.

2. My teams estimate using planning poker with the full team including the client and we have found this has helped to uncover hidden or unknown scope. We discuss each item together before estimating and talk about the number of screens, inputs, outputs, services etc involved. This discussion itself often uncovers additional scope, but so does the estimating that follows each discussion. For example, when most of us say ‘2’ and one person says ‘8’, the person who said ‘8’ enlightens the team on the complex caching required to meet the performance requirements listed as an Acceptance test. This is especially important if your client is the one with the highest estimate. Don't ignore it.

3. Lastly, I attended a virtual class on agile estimating that suggested another technique. For every feature or story, categorize the requirements certainty as high, medium and low. Keep challenging your client until the requirements certainty on each story is 'low'.

I'd be interested in other techniques you may be using to keep the initial requirements gathering phase light weight, yet complete. I think as an industry we are getting better at embracing the changes that are inevitable on all projects, but our clients still require us to have a good understanding of the known scope and the resulting estimate before starting the project.

Planning Poker and Buckets of Hockey Pucks

The teams I've been working with over the past while have been using planning poker for project estimating. Despite initial and fleeting skepticism by a few when we bring out the cards, as a whole our teams and our sponsors are finding value in this approach. I was reminded today that we should look at poker points as buckets of sand. That is, when deciding between a 5 and an 8, if something is a 6, you can probably still put it into a size 5 bucket if you think of the points as sand that can be heaped at the top of the bucket. Also, a 7 would overflow a size 5 bucket but would fit easily into a size 8.

In light of Canada's 7-3 victory over Russia in Olympic quarter finals, I've decided to change the metaphor to buckets of hockey pucks instead of sand. Go Canada!

P.S. I'll be presenting on Planning Poker in Regina in June at http://www.prairiedevcon.com/

FitNesse gets the gold!

I've been using FitNesse for just over 3 weeks and I am pleased with the value it is adding to our project even though I'm only using the basic features at this time. As a former developer I'm finding it fun to use because I have to write a little bit of code in order to create an interface between FitNesse and each service that I'm testing. Most of our testing on the project was going well and we were avoiding major errors - until last Thursday...

A change in the code from a newly completed work item resulted in 81 of our 191 tests failing. Imagine how long it would take to re-run all 191 tests manually to find out that 81 had failed. Imagine how long it would take to re-test all 191 tests manually to make sure they were fixed. As you can see from the image below, it took us 39 minutes to find, fix and re-test all 191 tests. Thanks FitNesse.

** Update 6/28:  This project had the highest quality metric that I've ever been a part of in terms of defects / month / developer.  FitNesse was a big part of that success.

Fitnesse with C#

I've decided to try out Fitnesse on my current project so I attempted to find a complete tutorial on fitnesse with C# today. The best tutorial I found is contained in the following 2 links:

1. Installing FitNesse
2. Writing your first Hello World test

This is a great tutorial. Although in the end I figured everything out, there are a few steps that were implied in the tutorial that I missed on the initial pass. Here are those steps:

a. Leave the command line open. You need to execute this command line everytime you want to use Fitnesse. If you close the command line, Fitnesse will not work.
b. When downloading the FitSharp binaries from github, place the contents of the zip file in a "dotnet2" folder that you create as a subfolder in the folder that you downloaded/installed the .jar file to.

After adding those 2 steps, everything worked great. Thanks to Gojko for all the work you put into the tutorial at the links above. I found the Fitnesse User Guide to be lacking.