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.
Eric Aside
Sure, there are exceptions to the read-it-once rule, but they account for less than 5 percent of the mail I get in a day. Even those e-mail messages get filed in a special folder for more intensive attention. I also use Inbox rules to pre-filter mail from discussion groups.
If you’re wondering how to get started and don’t want to just delete all the mail in your Inbox, follow these steps:
1. Take mail you are actively working on right now and move it into a special folder.
2. Create folders for your remaining mail that correspond to your obligations and interests.
3. Search your Inbox for mail that fits each folder and move that mail into the folder.
4. Go through your special folder and clear out 90% of it using single-piece flow.
Now you are on your way.
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.
Eric Aside
You may have battles deciding what goes in a checklist. You shouldn’t. Remember, you list what the data says are the common or critical failure points, not everything that ever happened.
For example, I added a checklist to my e-mail signature several months ago, which I check and then delete before I send every mail. It lists the two mistakes I’ve made for years, but haven’t made since:
· Check the Cc and Bcc lines for undesired aliases
· Ensure the subject line is accurate
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.
Eric Aside
Many people wonder what to do with feature crew PMs once they finish specing, or developers once they hit code complete. For PMs there are two solutions—be part of multiple feature crews or be prepared to work with their dev and test peers on problem solving and development. For developers, the right solution is to work with the test team on tools, automation, unit tests, and component tests.
There’s another clever solution, Scrumban, written up by a former Microsoft employee, Corey Ladas.
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.
PingBack from http://www.anith.com/?p=25224
You wrote "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".
There’s a simple name for that process. It’s called "scrum".
Scrum has gotten a bad name because lots of people claim to be doing "scrum" but only have clue one about what it means.
For the build breaks, once you have a checklist, figure out what you can automate rather than making people follow it each time.
“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
Helpful post.
It is such an annoying waste of time when one has to deal with emails with an empty subject-line or an excessively vague subject-line… wish everyone reminded themselves to write a decent subject-line.
Another good ’email essentials checklist’ item: ensure desired attachments are attached.
Deleting mail after forwarding makes a lot of sense now with Outlook conversation view: you can see your previous sent mail if someone responds, so you don't need to keep the original in your Inbox.
I will prefer not deleting email that has attachment