|
I get a variety of reactions from both doers and managers when I tell them that the average individual contributor on a project team only completes three effort days of delivery-related work in a week. Usually the reaction is surprise. Surprise the number is so low. Surprise I'm willing to admit the number is so low. And surprise that this is a perfectly acceptable amount of work to complete each week.
There are a number of factors that contribute to this average individual delivery velocity of three effort days. Here are four of the most important factors:
First, the Mythical 40-Hour Work Week. Project managers love to draw up schedules fully utilizing "resources" by booking them for forty hours of work a week. Yet, even if people could spend their entire week on delivery-related work, they still wouldn't put forty hours a week in unless they work overtime. Why? Because of lunch and other breaks. Take even half an hour a day for lunch and two fifteen-minute smoke/coffee/bathroom/cell-phone breaks and you've reduced the work week to thirty-five hours, not forty. So, unless you require mandatory overtime from your employees, you have to forfeit half an effort day of work each week before you even consider any other factor.
Next, We Have to Define What We Mean by Work. Not just anything done during the business week constitutes meaningful work that contributes to the delivery of something that is valued by the customer. Everyone has a certain amount of "overhead" that they have to do in their job, such as completing timesheets, attending team and department meetings, or reviewing and responding to the ever-increasing onslaught of corporate emails. These overhead activities in no way contribute to customer-valued work. They just cut more available effort out of the week.
Additionally, There is Valuable Work That We Still Do Not Track. For any team that has a system in production, there's the possibility of support inquiries or activities. Even if each instance averages only five minutes it still takes time. Furthermore, any individual who has been with the team for a significant amount of time is likely to spend at least a portion of the day acting s a domain expert and assisting other team members in matters concerning the system or technology that they know very well. In fact, the more expert a person is on the team--and the more capable they are--the more likely they will be called upon to assist other members the team. While these and other activities are valuable, they do not contribute directly toward the specific individual's delivery velocity. Or, even if one might argue something does directly contribute to delivery, each individual instance is often simply too small to capture. Our goal in agile development is not to track every little bit of work people do--our goal is to deliver useful and useable functionality. Providing support and assisting team members are essential to the system being developed, but this is not work we can or should capture when planning and tracking delivery velocity.
Finally, Don't Underestimate the Cost of Switching between Tasks. When you cut a length of wood in two the total length of the resulting two pieces is shorter than the original uncut piece. No matter how thin the saw there is always a bit of matter that is lost in the process of cutting. Similarly, as we switch between tasks, some moment of time is lost as we set down one chunk of work and pick up another. If we attend meetings throughout the day, field questions from other members of the team, or get pulled into support activities, then there will be quite few moments lost to task switching. These moments can add up and can measurably reduce the amount of effort we can put toward our weekly delivery velocity.
So we only complete, on average, three effort days of work a week. That's fine and that's fair. What's most important is that we plan our projects and set our delivery commitments based on this reality--not on some over-optimistic assessment of what we believe the average individual can get done (like the Mythical 40-Hour Work Week). Basing our delivery velocity estimates on reality will help to ensure that we can meet our commitments. Doing otherwise will only ensure that the project ends up in a ditch.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Blogs 
