Evolving the kanban board

My wife and I are planning to move house. 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 customised 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:

full2

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?).

up1

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.

 

 

carnival of the agilists, 9-nov-07

Welcome to the latest edition of the Carnival of the Agilists, the blogroll that skims the cream from the top of the agile blogsphere. This week’s theme is: a bumper bag of liquorice allsorts

Brian Marick has posted the transcript of his OOPSLA talk in several parts. Part 3 discusses Pasteur’s attempts to educate the French about the causes of anthrax, and relates that to a fun idea for energizing daily stand-up meetings: “another example of using a weirdo theory from sociologists to give myself ideas.” Meanwhile Mark Levison has revived his team’s iteration boundaries by introducing good agendas: “By breaking things down into smaller more focused chunks the new agenda (and prompting questions) has made our retrospectives more valuable”. Dale Emery also chips in on the subject of efficiency, with a great discussion of the causes of multitasking: “If I split my time among all six tasks, I get to tell all six people every day that I’m making progress on their important tasks. And I get to be sincere about that”. (I have no idea why this post appeared in my RSS reader this week, as it was written over two years ago. Still, it fits here and its still very relevant today; think of it as this Carnival’s “Two Years Ago This Week” entry…)

Both Mark Levison and Dave Rooney discuss the downsides of working remotely from the team. And while Mark (and his commenters) provides a list of tools and techniques to help improve communications, Dave’s top tip is: “Remind your significant other that hay and shavings from the rabbit’s cage shouldn’t be washed down the drain in the laundry room.”. Now why didn’t that practice make it into the white book?

Rebecca Wirfs-Brock reports on the findings of a workshop that discussed Challenges When Communicating Designs: “I started by making the connection between telling others about designs and storytelling. Effective designers need to tell good stories. And the tone and means by which we communicate design ideas should vary depending on the reasons we have for telling a particular story, and our audience’s background and expectations”. Now I think about it, the great developers I’ve worked with are all great story-tellers too; Rebecca’s discussion suggests that’s no coincidence.

Michael Feathers’ latest addition to the Beautiful Code blog is a post entitled Elegant Byte Counting, which centres on the use of the SpecialCase pattern to solve a tricky little code duplication problem: “This is a particularly elegant way of handling things. Rather than having separate code to traverse writable things for size and write, all of the work can be done with the same piece of code, the write method. There’s less duplication and less possibility of error in maintenance.” There are nowhere near enough of these great little design vignettes around, in my opinion.

After the summer-long debates about certification of various sorts, Willem van den Ende has discovered that you’ll make more money if you are not certified. He quotes Mark Gallaher thus: “A new report from industry research firm Foote Partners LLC finds that the average pay for noncertified IT skills topped that for certified professionals […]”. Less is more, it seems.

And finally…

The calls-for-participation have been published for both Agile 2008 and Scotland on Rails. Give them a look and submit a few sessions — I know I will!

To suggest items for a future carnival – especially from a blog we haven’t featured before – email us at agilists.carnival@gmail.com. As ever, this and all previous editions of the Carnival are catalogued at the Agile Alliance website. Look out for the next edition of the Carnival around the end of November, hosted by Pete Behrens.

reporting during the daily stand-up

airmen In On Scrum and the curse of the three questions Lasse Koskela throws doubt on one of the central pillars of Scrum – the three questions that everyone on the team must answer during the daily stand-up meeting.

“I think the way we talk about “answering three questions” contributes to the difficulty of getting people away from reporting progress to the Scrum Master (who almost unanimously is the same guy who used to be the project manager before adopting Scrum). […] Apparently words like “answer” and “question” tend to be associated with ideas closer to being interrogated rather than communicating information.”

This is a really good point, and hits the nail right on the head. Whenever I visit a team I always ask to attend their daily stand-up meeting. And time after time I see the team members treating the session as time to report progress to their boss. In some cases the team members even look at that person as they speak.

That’s not what the meeting is for. The daily stand-up is the team’s primary opportunity to self-organise. The outcome should be that the team has collectively agreed what to work on today, and what impediments they need their ScrumMaster to remove along the way.

So I like Lasse’s rewording of the “three questions”, but I prefer to go further. As I said in an earlier post, focus on the task board. Each team member’s report should be directed through the board: “Yesterday Chet and I completed this [points at a card in the Completed column] and this [points at another]. Annie and I started this [points at a card in the In Progress column], and we’ll continue with that today.”

Note the use of language here: “worked on” is vague to the point of redundancy. Note also the physicality: point, move cards around, update the burndown chart. Around eighty percent of all human communication is non-verbal; we should capitalise on that fact to make daily stand-up meetings more effective.

accessible = approachable = £££

In Accessible = Approachable = $$$ Scott Ginsberg (the guy who wears a name-tag 24 hours a day, 7 days a week) discusses the benefits of making sure you and your business are easily accessible. I know I’m no great shakes in the ‘approachable’ department, but last week I also discovered the truth in Scott’s words: three separate people in twenty-four hours independently told me they struggled to find my email address starting from pages in this blog. I hope I’ve fixed that now, but it does underline the point. So a big thank-you to those people who took the time and trouble to work out how to contact me, and then to give me feedback on their struggles. I wonder how many other people have just shrugged and left…

bouncers In the main, Scott writes about approachability – which is also vital to the success of an agile software development team. For example, anyone who wants to get a view of the team’s progress towards the next release needs to know in advance when they hold their daily stand-up meetings. And because feedback is the fuel of the agile process, it’s essential that development teams ensure that their team persona is also approachable. For example, it’s no good going into an iteration review with arms folded, and rejecting stakeholder comments with responses along the lines of “no, you’re wrong.” Because people will soon get the message and stop attending. At which point the team’s product begins to lose its way; morale, time to market and profitability will surely follow.

We software geeks have a lot to learn from Scott…

fix the time of your stand-ups

I work with a team who operate a flexible workday. Some team members habitually arrive in the office at 7:30am, while others usually get in around 9:45. When the team was first formed, they tried to carry over a practice from their previous teams, in which the daily stand-up meetings were held at a fixed time of 9:30 or 9:45. The new group quickly found that this didn’t quite work for them, as the arrival times of the later folks tended to be somewhat unpredictable.

The team discussed the situation at their next weekly retrospective. The suggestion to abandon flexi-time was soundly rejected by both early and late comers. So the team adopted a compromise: the daily stand-up would occur as soon as the last team member arrived.

After a few weeks a different problem became apparent, and one day a manager pointed it out: “I want to come to your stand-ups, but I can’t schedule them because I never know when they’ll happen.” Non-members of the team now couldn’t predict when the stand-up would occur, so they stopped coming. Communication with other groups in the organisation had reduced, without anyone really noticing. And the team itself now seemed just a little more aloof. The change had been imperceptible, but nonetheless a small barrier had erected itself around the team.

At this week’s retrospective, the team decided to fix the stand-up time at 10am (and all agreed to be in work by then).

One of the pillars of open communication is predictability.

focus on individuals at the daily scrum

The Scrum process recommends that everyone in the daily stand-up meeting should answer three questions: “what did you do since we last met?”, “what will you do until we next meet?” and “what might prevent you doing that?” While it isn’t necessary to go through the ceremony of actually asking those questions, it is very important to get individual answers to them – particularly the last.

This week I attended a couple of daily scrums in which the third question was asked only once, at the end: “do any of you foresee any problems today?” There was a bit of a mutter, along the lines of “nothing different from yesterday,” but mostly people looked at their shoes and kept silent. So the team recorded no impediments, and the meeting broke up. As it turned out, on those particlar days no-one was impeded sufficiently that they failed to deliver. (But everyone in the team did recognise that they could have delivered much more, if only the age-old “habitual” impediments had been removed!)

My point here, though, is one of focus. I suspect that we would have discovered more by asking the third question to each team member individually. We’re going to start doing that, and writing down each answer on a card. Those cards will be put on a board, and will be the ScrumMaster’s to-do list for the day. And as each impediment is addressed, for some of them we’ll set up kaizen teams to eliminate them completely. I’ll let you know how it goes…