My wife and I are planning to move. We aren’t sure where we want to move to, or indeed how much we have to spend. Naturally, though, we want to get the highest possible selling price for our current house in order that we have as many options as possible. So we called in a “house doctor” to help.

After she (the house doctor, not the wife) had recovered from the initial shock of seeing how we have customized a fairly standard 4-bedroom house into a 6-bedroom eclectic disaster, she produced a report containing a list of cosmetic improvements we should make in order to attract prospective buyers. The list is long, with jobs for myself, my wife, and our local handyman. We needed to make the project manageable in a way that would allow us all to contribute as and when we have the time. So I found an old whiteboard in the garage and made this:

As you can see, I drew a very rough plan of the house, including sections for upstairs, downstairs, the attic, and the outside. We then wrote a small sticky note for every improvement suggested by the house doctor (blue) and some that we had always wanted to do ourselves (yellow).

When we finish a task, we simply remove the ticket. For example, you can see that we have already finished all of the tasks needed in the Office (priorities, right?).

And why am I telling you all this? Because this is what I recommend teams do for their software projects. When you pick up the next feature, draw an architecture diagram and populate it with sticky notes. The resulting board is a “map” showing the feature and the tasks that need to be done in order to deliver that feature (thanks to Tooky for that analogy).

• The diagram you draw for Feature A might differ from the one you draw for Feature B because you might be touching different parts of your estate. That’s cool. The diagram needs to be the one that’s most appropriate for the work you’re about to do.
• The visual representation of your architecture allows more people to be engaged in discovering the tasks that need to be done to deliver the feature.
• And it allows everyone, often including non-programmers, to see and understand the scope and impact of what is to be done.
• Sometimes doing a task will spawn others: things we didn’t consider when we did the original feature break-down; things we’ve learned by making changes or completing spike tasks; things we or the Product Owner couldn’t envisage sooner. That’s fine — we simply add and remove sticky notes as we think of them (and look for opportunities to slice off a separate feature that we can push back onto the ideas heap). The whole thing is quite dynamic, and yet very well controlled at the same time.
• If possible I like to include testing in the scope of the stickies, possibly adding a few explicit testing task stickies where necessary.
• As you finish each task (whatever “finish” means for your team), either remove the task’s sticky note or mark it with a big green tick. For our house doctor board, we’ve decided that removing the stickies is best. But for software teams, I generally recommend adding big green ticks to completed tasks. This allows anyone to see how much progress you have made through the current feature, and which areas still need more work.
• Sometimes the distribution of ticked and un-ticked stickies will suggest opportunities for splitting the feature and releasing a subset earlier than planned.
• Hold stand-up meetings around the diagram as often as you need, and certainly whenever anything significant changes (some of the teams I coach have been known to hold informal stand-ups 4-5 times each day). The architecture diagram helps facilitate and focus these discussions and makes it much easier for everyone to contribute.
• Note that all of the above works best when the team has a single feature in flight. A WIP limit of one, single piece flow.
• This approach works well when combined with the 5-day challenge.

As usual with the recommendations I write in this blog, this idea is probably not a new one. But it is highly effective, and I recommend you try it.

Update:

I gave a lightning talk on this topic at the Lean Agile Manchester meetup this week. There is a video (below), although unfortunately, you can’t actually see what’s on the slides. So I uploaded the slides here.