In wrapping up this 12-post series about enterprise agile development, I feel compelled to touch upon a widespread practice in large firms. That is, developers assigned to work on more than one project at a time. They are typically told something like “…spend X% of your time on Project A, Y% on Project B and Z% on Project C”. They are rarely required to track actual hours except in the case of contractual work for paying clients.
Note that percentage of time allocated doesn’t map to project priority. For example, I might be told to spend only 10% of my time on Project A, yet the project could be mission-critical. It simply doesn’t need much of my expertise at this time.
Most developers would prefer to allocate a fixed time period each week for each project. So, I might devote Monday morning to Project A, the afternoon and all day Tuesday to Project B and the rest of the week to project C. This makes time management easy and provides a fixed frame of reference.
Unfortunately, fixed blocks of time almost never work. What if each project has a daily stand-up meeting and I’m expected to attend all three? (Let’s assume they don’t occur at the same time!) There’s also the major problem of interruptions. I can’t simply say, “Hey it’s Tuesday. I’m not working on your project today.”
The Multitasking Myth
Senior contributors are often expected to multitask but let’s face facts. Humans cannot truly multitask. Most of us are fairly good at switching contexts thus giving the appearance that we are working on more than one project at a time. In reality, each context switch eats up time as we mentally ‘file’ away the current project and open the ‘file’ for the next project. The switching process can take anywhere from a few minutes to half an hour depending on the complexity of the situations.
The practice of assigning multiple projects to developers is not going away anytime soon, particularly in the lean corporate environments of today. Here are a few ideas for dealing with it.
As a manager…
- Re-examine your list of projects. Cancel whatever you can or at the very least, put entire projects in the project backlog. Don’t fall into the trap of assigning someone to a project just to keep up appearances by attempting to show minimal progress.
- Eliminate unnecessary or redundant activities. Keep workflows simple for the developers and valuable to the company.
- To reduce interruptions, consider assigning a dedicated production support person/group to handle production problems. This assignment could be done in a round-robin fashion within the organization to balance the support workload.
As a developer…
- Try your best to allocate blocks of time to each project. The bigger the block, the more productive you’ll be.
- If you know what you’ll be working on over the next few days, try to batch similar activities across projects. The context switching will be easier.
- When interrupted, ask if the issue can wait until you have a chance to finish the current activity or at least bargain for time to get to a natural stopping point.
- Avoid having hours per week per project determine your activities. Always try to finish something before switching. Seek to balance out the hours per project over 2-4 weeks.
Finally, if there’s a crisis and you need to drop everything for several hours or a few days, communicate. Let your Project Managers, Scrum Masters, etc. know what’s happening. They’ll appreciate the notice and will be more likely to give you some leeway.