During difficult economic times like these, people tend to whine less about common complaints that now seem trite. Mostly, I’m relieved not to hear how much e-mail is in Ingrid’s Inbox, how Brian broke the build again, and how Suresh’s service schedule slipped successive sprints.
However, it’s during difficult days that we should patch plaguing problems. When are you going to be more motivated to mend malignant maladies? Surely, no additional alliteration is advisable.
A surprising number of common issues can be solved using two simple techniques—single-piece flow and checklists. There’s a ton of behavioral and process theory behind why these simple methods are effective. The point is that they are effective and you and your team are less effective without them.
All too easy
Take Ingrid’s Inbox. Like most Inboxes, Ingrid’s is overflowing. She spends tons of time on it, yet it only gets bigger. She constantly loses track of mail, discovers mail, and revisits mail. It’s hopeless.
Ingrid would have her mail under control if she followed single-piece flow. Single-piece flow tells her to handle one piece (one message) at a time till it’s done. By “done” I mean she’ll never look at that message again (except to answer a related message).
Here’s how it works. Each time after Ingrid reads an e-mail message she does one of four actions:
1. She deletes the message (my favorite).
2. She files it away in a folder.
3. She forwards the message to someone else and then deletes or files it.
4. She answers the message and then deletes or files it.
That’s it. She never opens a message and then leaves it in her Inbox. By the end of each day, every day, her Inbox is empty. She never misses a mail message, loses a message, or revisits a message.
Single-piece flow is efficient because it removes overhead and rework. There’s overhead every time you context switch to look at a new message, and there’s rework when you re-read a message. In single-piece flow, overhead is minimized and rework is eradicated.
Deja vu – all over again
Brian keeps breaking the build. You can punish Brian till he’s afraid of checking in code regularly, but doing so only causes other problems.
A better solution is to give Brian a checklist. Checklists are wildly misunderstood, improperly developed, and underutilized. Regrettably, well-meaning compulsive people list everything possible Brian should check before he submits code to the build. That’s not only a waste of time, it’s also ineffective.
Brian’s checklist should list only common causes of build breaks (less than one page’s worth). It should be in Brian’s sight when he submits code. The goal is to be quick, easy, and effective.
Too long or complex and Brian won’t follow it. Too short and it’s not effective. Luckily, most mistakes are common mistakes. Thus, all the team needs to do is collect a list of the common or critical causes for build breaks and turn that into a checklist. The same is true for design review lists, code review lists, and all checklists.
Remember to update your checklists as your failure patterns change or they will become stale. Checklists prevent common errors and promote good habits. Any structured manual process you follow should have a simple checklist—unless you like being Brian the build breaker.
Slip sliding away
Suresh’s software squad slipped their schedule on successive sprints. Bad news for a service—or any project. Is it time to work weekends? No. Is it time to slap the squad silly? No. Is it time for single-piece flow and checklists? Yes.
Suresh’s squad is made up the usual way—a few PMs including a service engineer, a bunch of developers, and a similar-sized bunch of testers. The PMs write specs, the developers code them, and the testers test them. The squad is using Scrum-like Sprints with a nicely prioritized backlog of features.
Unfortunately, the PMs are creating specs faster than can be implemented. They waste time and effort on specs that change or are cut before they see daylight. The developers and testers jump from feature to feature as they get blocked. Nothing is in sync. Nothing gets finished. The schedule slips incessantly. In retrospectives, all Suresh’s squad talks about is unblocking people.
Even though Suresh’s squad is using Scrum-like Sprints, they aren’t using single-piece flow. They aren’t splitting into cross-discipline teams, with each team working on one feature at a time till it’s done. They don’t even have a checklist that defines done. It’s doomed.
Once they create feature teams that spec, code, and test one feature at a time (sometimes called, feature crews) and a checklist that defines done, there’s a chance for progress. The single-piece flow removes blocking issues because everyone is working on the same problem. Instead of jumping ahead, the checklist keeps the team honest, motivating them to work together, finish, and stay focused. Now the team doesn’t waste time context switching and can tell how long it really takes to complete a feature, leading to confident scheduling and higher quality finished products and services.
Our two weapons are
So there you have it—single-piece flow and checklists. Two enormously useful, remarkably simple, and yet woefully underutilized techniques for managing workload and building quality software.
Single-piece flow and checklists can be applied to individuals, small teams, and large divisions. They aren’t controversial when used pragmatically, and have years of documented case history supporting their effectiveness.
Sure, you could create a whole grassroots movement around single-piece flow and checklists, but that seems a bit overblown for such simple ideas. Maybe you should just use them wisely. Enjoy the time you get back and the improvement in your results. The best things in life are often the most basic and simple.