Here’s another real-life example of applying Agile values and principles in weird or hostile environments. You can adapt well-known Agile practices or even make up your own. The values and principles are what matter.

This client doesn’t currently follow any Agile practices, and my project will probably be over with in a few weeks, and the rest of my team is in India. It doesn’t seem practical to try to change the way they work in such a short time, and quite honestly they seem to be doing pretty well with ordinary project management.

So I simply implemented a little KanBan for myself and pondered the interface to my teammates on the other side of the world. Here’s what I came up with.

To:	Client Technical Director
From:	me

Last week you suggested getting some subset of the Quux Project into a testable form so we don’t save all the testing for the end of the project. I am totally with you on this. The earlier we spot defects the better.

If we had a tester right here, I’d say that person can just pull cards from my “QA” chart (column on the KanBan) and verify that those micro-features work, one at a time. But that only works when you have a really small feedback loop. It’s not so good when the tester’s in India. We need to work in bigger chunks.

Milestones

I figured a good milestone would be something like this story:

• I can log into Foo Bar and see the Quux menu option
• I get the prompt to choose a Quux type.
• When I choose a Quux type I will get the corresponding legal verbage.
• I can click “Continue” and get prompted for begin and end dates.
• If I enter no dates here I’ll get an error message.
• If I enter bogus dates here I’ll get an error message.
• If I enter real dates then the “Continue” button will get me to the configuration page.
• On the configuration page…
  • …I can enter or not enter explanation and/or comments.
  • …I can select a titration caliber.
  • …I can click the “kick me” checkbox on or off.
  • …I can drop a Quux by clicking on “Remove.”
• When I click on “Complete and Submit” my Quux will be queued for processing.
• And by the way this all works without JavaScript, so it’s good on mobile devices and security-paranoid environments.

Another good milestone would be to demonstrate the stuff above with JavaScript turned on, seeing the dynamic calendar, and so on.

Another good milestone would be something like this:

• I can log into Foo Bar and see the Quux Management menu option.
• I can see the Quux I just entered in the previous story.
• I can see the Validation Track that has been set up for me and that Quux type (as you and I discussed on Friday).
• Ditto the Verification Track.
• I can see the comment/explanation I entered with the original Quux.
• I can see the “kick me” checkoff I entered when requesting the Quux.

Likewise for admin, approval, and verification tasks.

How to make the testing work

I was thinking of sending Sarai (the tester) the first story, in “I can do such-and-so” form. I’d tell her that if someone there pulls current source out of TFS and builds it on the testing system, she should be able to follow the story step by step and simply check off for each item: YES, NO with explanation, or COULDN’T TEST. Then the next morning I can follow up and fix the NO and COULDN’T TEST items.

The board

I’ve already designated the first story as the “Diamond Story.” Every card that is required to implement the Diamond Story has a little diamond on it. I’ll move the Diamond cards through to QA as soon as possible, then let Sarai know to try following the Diamond Story.

Next one will the the Club Story, and so on.

It’s the Simplest Thing

The mistake a lot of people make when they try to “do Agile” is… well, they kind of work too hard at it. The idea is to cut down on things that don’t get the project done and build up things that do get the project done. Spending a disproportionate amount of time setting up the perfect Agile process is itself not Agile. And it doesn’t make sense.