Recently many of my discussions on process optimizations come to a point where we focus on hand-offs. When I say about hand-offs I think about every situation when a work item, feature, user story, requirement, or however you call those gizmos you build, is handed from one person to another. Think a business analyst handing requirements to a developer or a developer handing updated version of an app to a quality engineer, etc.
Now, hand-offs are bad because I say so. You have to believe me because I am a Jedi.
OK, being serious, I can show you why it is so. Every hand-off which is incorporated in your process is a place where work can pile up, and it usually does. Lots of tasks waiting to be picked up by another team member – doesn’t it sound familiar? Basically, one of things we are trying to do whenever we’re implementing Kanban is to limit work in progress, and one of very first effects of it is limiting a number of tasks waiting in these hand-off stages.
There is more however. Another reason why hand-offs aren’t cool at all is it means making knowledge chain longer. It means adding another link between client/user and people who actually build the thing. You are virtually asking for more of unspoken assumptions and interpretations while making it even more difficult to sort things out whenever they’re vague. You will go through all these people to get the answer for your question. Or, more likely, you will just make one more assumption which is likely to be wrong.
Then, we have responsibility. It’s funny to look at these huge corporations adding new roles and teams to their development process. Somehow they believe that each team which is more downstream will verify what a team which is more upstream has just done. At the same time they’re dissolving responsibility for building good software, and building good software is I guess what is what they aim for. I don’t say that mentality like “I have a whole team of quality engineers so they will catch any bugs I make” is something they consciously incorporate to their process but that’s exactly what they typically get. They should really look at those small companies that are built purely from software developers. Somewhat magically they can deliver high-quality software. How come? How is it even possible without a crowd of business analysts, quality engineers, release managers and whatnot? I have a hint: they all feel damn responsible for quality as they hand their product off only once – right to their client.
I am well aware that, most of the time, we can’t get rid of all hand-offs from our development process. I don’t even say that we have to avoid them by any means.
I just say that we should be aware of everything that comes along with them and…
- Limit a number of hand-offs to lowest reasonable level. Think about any shortcuts in your process that you can make without quality loss. Think about simplifying the process.
- Avoid adding new hand-offs whenever possible. Sometimes we want, or need, or have to add another link to our chain. Sometimes we want to have a messenger between clients and users and development team. But please, don’t add more messengers that it is absolutely necessary. As a rule of thumb: the closer development is to the client/user the better.
- Measure and control hand-off stages you already have. Learn how big piles of idle tasks there are. Limit work which is waiting for someone. Organize your process in a way which supports quick consumption of work items which hit one of hand-off stages.
- Make hand-offs more informal. The more informal hand-off is the more smoothly it will usually go. People sitting in one room, cross-functional teams, little formalisms all help to keep hand-offs informal.
In terms of improving team’s productivity it is really a low hanging fruit and the one that may teams don’t even think of.
If you don’t think it is a problem in your case, perform a little experiment. Measure how much time your work items live within the process and then split it into two numbers: how much time someone is actively working on them and how much time they are waiting for someone to take care of them. Simplifying things a bit, the latter number is the price you pay for all your hand-offs. And yes, I pretty much expect that, statistically speaking idle time is way bigger than active time.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
3 comments… add one
is it really possible to Limit a number of hand-offs to lowest reasonable level without quality loss.? how?
It is. The key term here is “lowest reasonable.” I don’t say it means zero or one or three or whatever. It depends on your context. However, there are practices which can help you to limit a number of hand-offs pretty reasonably.
Cross-functional teams come as the most obvious case. If all the project roles, or at least most of them, are grouped under one hood it is way easier to eliminate formal hand-offs without any quality loss whatsoever. Instead of focusing on proper hand-off to the other team, which often results in increased work-in-progress, people try to get things done as a group.
This one is tricky, but I find it that often less formal process, as a whole, helps to introduce more responsibility among people. I mean that we get rid of this mentality that someone would check whether I did my job well and I take care of the quality by myself. It results in less failure demand, meaning that we spend less time fixing things, which in many organizations can improve productivity vastly.
Visualization also helps. It is sort of counter-intuitive but just making hand-offs visible, making queued work items visible results in improved people behaviors, e.g. they focus on items which are “furthest to the right side of the board” which basically means they’re closer to completion.
Limiting work-in-progress is another great tool here, although it works a bit differently. Instead of limiting a number of hand-off stages it helps to limit number of work items waiting in these stages.
I know organizations that are adding more and more formal stages to their process. Surprisingly enough they don’t get better results. Feedback loops are longer, there are more places where you can misunderstand something or assume the wrong thing etc. Eventually, they need even more complex process to add a number of verification stages so they can fix issues they just introduced to the system. Not that clever if you ask me.
Pawel, I’ve built an app (over 2 years) that solves precisely this sort of problem :-) – please take a look at https://tallyfy.com
Happy to chat in detail if this interests you.