(I originally posted this on my MSDN blog.)
My current work environment is pretty typical of a lot of tools teams, IT shops, and similar groups; we have lots of relatively small projects to build and maintain. In fact, we have far more projects than we have people in each discipline (Dev, Test, PM). This obviously means that we don’t have the luxury of assigning individuals to one and only one project for long periods of time; we have to slice up our time and devote attention to multiple projects in turn. Given that’s the reality of our situation, though, there are still different ways we can go about doing that, some healthier than others. We can multi-task at either an individual level or at a team level.
Individuals
Multi-tasking at an individual level means that Joe is splitting his time between the Widget project and the Froberg project, while Sally is splitting her time between the Froberg project and the Walleye project. Every individual has a different portfolio of projects that they’re responsible for. The benefit of this strategy is that it gives us maximum flexibility to allocate scarce engineers in a way that seems to cover all the holes on paper. There are several very expensive costs, however:
- People rapidly shift from project to project which means that no one develops a deep and strategic understanding of any one project.
- Because people are always coming and going on a given project, it’s hard to develop a sense of team identity or to develop productive working relationships with colleagues.
- Individuals are often left to make their own choices from day to day about which project is most in need of their attention at the moment. There’s no strategic thinking about priorities or about how to spend the overall time budget of the group.
When we multi-task at an individual level, we often end up building plans for our projects that assume 100% allocation when that’s not really the case. For instance, say that we have work happening on the Widget project and the Froberg project at the same time. From a group planning and budgeting perspective, it might look like we have one team devoted 100% to Widget and another team devoted 100% to Froberg and that the work should be able to proceed in parallel. But in reality that’s not the case because Joe is double-booked for both projects. That puts him in an awkward position because now he has to decide on a day-to-day basis which is more urgent: Widget or Froberg. That decision isn’t being made by the project owners and it’s not being made strategically; it’s being made individually and tactically. Despite people’s best intentions, that kind of system usually devolves into a last-in-first out work queue, i.e. we work on whatever was most recently brought to our attention.
Teams
On the other hand, we could multi-task at a team level. In other words, we could build a stable, consistent Dev/Test/PM team that has explicit responsibility for both the Widget and Froberg projects, while another stable team has responsibility for Walleye and something else. We still have multiple projects that need to be worked on, and we still need to make priority decisions between them, but now the trade-offs are visible in the budgeting, planning, and strategic thinking realms. Say the team is working on a new Widget feature. Oops, we have an urgent Froberg bug that needs to be fixed! What’s the cost of handling that? Well, the cost is that we postpone the Widget project while the whole team shifts its attention to Froberg. Is it worth it? Maybe, maybe not, but now we can have a proper discussion about it. It’s very clear and obvious. You can’t just sneak it in under the radar.
The costs were there in the individual model, too – if Joe is working on Froberg today then by definition he’s not helping Widget make progress – but the costs were hidden. The individual model seems like it’s easier to work with in the short term because it avoids the hard priority choices but those choices still need to be made and it’s best if they’re made explicitly rather than on an ad hoc basis.
Agile Means Teams
Of course there are multiple agile project management methodologies that emphasize the team as the unit of work. Scrum prescribes a team, a backlog, and a sprint full of work that is locked. If something urgent comes up, it gets prioritized into the product backlog for the next sprint and everything else necessarily shifts down in the stack. The benefit and the cost are clear to everyone.
Kanban describes a similar system but emphasizes continuous single-piece workflow which is probably a better fit than Scrum if you’re juggling lots of small, unpredictable jobs across multiple projects. If something new comes up, slot it into the backlog and everything else gets bumped down. The team continually pulls from the top of the list and you can forecast a pretty accurate time to delivery for any point in the backlog.
Even groups who like agile methods and are trying to practice them sometimes have a hard time breaking the habit of treating the individual as the unit of work. Every time they slip back into that old habit everything gets much more unpredictable and velocity falls dramatically. It’s inevitable. The way to make agile methods work is to keep the team together as a cohesive unit and feed them the work you want the most. Don’t steal individuals for side projects. Multi-task at the team level, not the individual level.
(Whew, I wrote that whole post without once using the word “resource”. It was harder than it sounds! 🙂 )
SaintGimp 