Are you agile – the Nokia test

I’ve been helping lots of clients start new agile initiatives recently.  This has led to me seeing up close and personal some consistent startup issues with new teams.  In particular, most teams that are new to agile tend to still think they need to have incredibly detailed requirements, they just may not need them all up front.  I’ve hard QA people say they absolutely will not test software without having the detailed requirements to refer to while testing.  I’ve heard developers say they can’t give estimates or even relative sizes of stories without knowing all of the details.  Quite frankly these things make me cringe.  They make me cringe even more when I realize some of these people have been in classes where it is made very clear these attitudes need to be changed!

This is where the Nokia test comes in.  I think I’m going to start using it in my courses for teams that are new to agile because it makes some things very clear.  It consists of two parts.  The first part is to determine if you are actually doing iterative development.  It has 3 tests:

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The iteration must start before specification is complete

Wow, that’s some pretty stringent stuff!  I love it!  The first item is a no brainer for most teams.  Almost every team I’m currently dealing with is using 2 week iterations.  The 2nd item is a lot harder to do.  Without automated testing it becomes nearly impossible almost immediately.  I would extend it to say that all previously written software also needs to be tested at the end of each iteration.  This would make it clear tests need to be automated to handle iteration by iteration regression testing.  But the 3rd item is the absolute worst for most teams!  It means our user stories really are “invitations to a conversation” as many trainers (including me) teach.  We don’t even want to know everything ahead of time, because that is how we got to where we are – WE CANNOT KNOW EVERYTHING UP FRONT OR WATERFALL WOULD WORK!!!

The 2nd part of the Nokia test is testing for use of Scrum.  It is close enough to what I teach that I’ll give it and then reword some of them to be more specific to my teaching of agile:

• You know who the Product Owner is (I prefer the term Product Champion)
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team (relative sizes created through team consensus – probably using Planning Poker)
• The team generates burndown charts and knows their velocity (I prefer burnup charts, and it is impossible to know velocity for a few iterations)
• There are no project managers (or anyone else) disrupting the work of the team

Only agile teams that are functioning at a reasonable level will pass all of the tests in part 1 and part 2.  If your team passes these tests you are unlikely to be doing mini-waterfall, “wAgile” or any sort of cowboy agile.  I would add one more test to all of this:

• The products created are accepted by the market

We can talk about business value all we want, but if we aren’t getting that part right, then why bother?

Any other tests you think should be added?  Let me know if you have suggestions.  I think creating a document to give to new agile teams would really help.  These are certainly a good start, but I’m sure there are other things that would be very useful.