Are 100% of your developers fully allocated to a single agile team? Do you ever have dips in capacity where your best engineers are “allocated” to a special project, a waterfall team or are used as specialists across teams?This issue is common and presents an interesting challenge in terms of capacity planning. In a purely agile world, this is a straightforward exercise. You progressively breakdown and scope your backlog, define your capacity, rank your backlog, and see how far you can get.
But what if “special projects” or more traditional waterfall-style initiatives come up that require specific staffing models or specialized skill sets? If you have resource pools with reasonable buffers or people on the bench then you may be in decent shape. However, the more common scenario is that the people wanted for special projects already have a home on an agile team…and pulling them off on a temporary or part-time basis can seriously impact your velocity, your forecast and your roadmap introducing hidden delays, loss of productivity, and unwanted risks to committed projects.
Three Potential Solutions to Consider
#1: Visualize the impact.
Show clearly on a team, project, skill set and individual basis where over-allocations are happening that can put schedules at risk. Show the impact to project forecasts if the timeline were to be extended to allow for reasonable (but aggressive) workloads. The thought here is to convince the powers that be to avoid interruption because of the heavy cost involved with breaking the agile planning model.
#2: Baseline your organization by finding a home for everyone.
Try to fully dedicate each individual to an agile team. Establish your velocity and get into a pattern where you can reasonably predict what a team can produce in a given sprint. If there are “shared services” like UX design or Big Data engineers, allocate them to teams on a percentage basis or treat them as a separate resource pool available for allocation to projects / teams as needed. For traditional teams, establish a pool of “waterfall” resources and define their skill set so that they can be readily staffed to projects as needed. Do not blend the two capacity models on a single Epic unless absolutely necessary.
#3: Incorporate siphoning in your planning strategy.
As new special projects come up and resource needs are defined, provide a mechanism to request resources that need to be borrowed from agile teams and allocated to these projects. As these resources are pulled onto projects (either on a part time or full time basis), reduce their availability to contribute to the agile team and the corresponding impact on velocity. For example, requesting 1 week of someone’s time on a waterfall project would reduce their capacity by 50% for a given 2-week sprint and reduce the team’s planned velocity accordingly. Using historical data to hone in on / predict the most likely allocation is very important tactic to use here.
A picture speaks a thousand words. If you can setup automated reporting to visually show the impact of special / waterfall projects on your agile teams in terms of “red alerts” when people are over allocated or you have “extended timelines” for existing teams, you are much more able to manage expectations, avoid surprises, and make good decisions.
How do you address capacity planning in your organization when you have some form of bimodal development? Share your experience in the comments section below.