-
0
0
I am often asked how to manage teams with partially allocated personnel. This is no small task and there is no always right answer. Simply put, each organization must figure out the best way to manage their own resources and personnel. While Agile best practices may strongly encourage dedicated resources within a team, and Scaled Agile is deliberate in its practice of dedicated teams of teams or Agile Release Trains (ARTs), many enterprises are challenged during their transformation to determine the best solution to the problem of maintaining current operations while transforming into a more Agile product and value focused environment.
So what are we to do? Simply marching into an executives office and telling them “This just isn’t going to work if you don’t do it right!”, likely won’t work. Oftentimes, even articulating a very reasonable and rational argument as to the why and how to do it right isn’t effective. They, like so many others, believe there to be too much risk if it’s changed.
Instead, we must let the principles guide us, whether they be from the Agile Manifesto or the Scaled Agile Framework (SAFe). We often must try to persuade the leadership over time if they aren’t able to, or refuse to see, the reality of the challenges they are creating. We will need to take the approach of allowing them to discover the challenges and set-backs of their decisions over time – and there are plenty of metrics to support this approach (though a topic for another day).
So where do we start? Do we simply say that each person on this team of 10 (for simplicity) who is partially allocated to our team is a Shared Service (resource)? When the allocation is below 25% this may be the best manner to handle things, but there are still many questions we must ask. Things are never this simple. Let’s look at some of the questions I often ask when I’m faced with coaching teams or ARTs with partially allocated resources:
Each of these questions present their own challenges and set of solutions and we will look at that next.
How many people are on the team and what are their allocations?
An agile team is typically made up of 5-11 personnel, of broad backgrounds and experiences, that can analyze, develop, evaluate, and deploy value. Keeping to this definition, it is important to understand the size of the team, and understand that communication becomes more challenging as we add individuals. So one problem some may fail to realize is that just because our people are partially allocated does not mean they are less of an individual. Often I hear the argument that 2 X 50% allocated personnel equal 1 person (in terms of man-hours). While this is certainly not the case in any instance, it is especially not the case when it comes to communication. We can’t simply tell one of the two people what is needed and expect them both to understand – it must be communicated to both/all, consuming more man-hours (either by bringing them both together or by communicating it several times). This effect is exponentially greater when your allocations of personnel are lower, say 10-25% and you have more personnel making up each “1 person”.
Another challenge this helps address is the question of shared services – being those who are shared across the entire program or solution. In the instance that many of the personnel are identified as low allocations (<50%) we should make an argument to move them from the Agile Development team and onto a Shared Services team. This would allow them to focus on one set of ceremonies, if any, and not consume all of their allocation just trying to collaborate and communicate.
What are the skillsets within the team? Are we cross-functional? Do we have I shaped or T-shaped skills?
We need to understand the skillsets across the team. Too often teams are thrown together based on rudimentary understanding of what is needed. Too little though goes into the teams and teams of teams. While we can certainly head this off with strong and successfully facilitated {ART} workshops, many enterprises are challenged by time and fail to spend it adequately on this topic. Once we understand the skillsets within the team, we can then determine if there are those who could or should be allocated more greatly, while dismissing others who may not need to be involved all that much. We certainly want to maintain any and all forms of cross-functionality individually and as teams, but I often have found that partially allocated personnel find themselves with little to do, or no time to do it. Ensuring the appropriate people with the appropriate amount of time (to avoid constant task switching) are on our team and ART, will enable us to deliver on our commitments more regularly, making us what every enterprise wants, predictable.
For those who are partially allocated to a team, where does the rest of their allocation lie? Inside or outside of the program?
When team members are partially allocated we must also understand where the rest of their time is dedicated. This isn’t for tracking purposes but rather to truly understand the contributions they will be able to provide. Certainly it makes sense to keep all resources working on a solution solely on that solution, again to avoid task switching, but also to ensure we are delivering the highest value solution at the time. When we have personnel working across multiple solutions, who are supposed to be part of an Agile Team, they are being pulled in too many directions and both solutions will be delayed. One person can make all the difference, just imagine having multiple partially allocated personnel and the delays that may cause.
Secondly, lets consider the possibility that the personnel’s remaining allocation is outside the solution being developed altogether. Outside, working on legacy systems, HR functions, SME functions, or holdover waterfall projects. How does this impact their work? If they are contributing to our team in only a small capacity, yet 20% of their time can either be consumed by collaborative ceremonies or “catching them up” then how much are they really able to contribute? Solution: Make them work 60 hours a week? 80 hours? Likely not. Look to dedicate any personnel working on the solution, to just that. Look to allocate enough of their time to the team to ensure they have time to contribute and not just get caught up.
Is the time allocation provided dedicated to productive efforts or will it include team ceremonies (which is extremely important but can add 20% overhead)?
As mentioned above, we need to be sure to allocate enough of a persons time to make it make sense for all parties. Consider what happens when we have a 25% allocated resource. Someone with only 25% of their time allocated to an Agile team could spend:
So as you can see, there is no good answer when it comes to low allocations. Based on my experience, they always fall into one of the four buckets above. This is simply not effective.
How are we tracking the availability of these resources?
We must understand when these resources are available. Too often, I have found that not only are these personnel partially allocated but they also have a fluctuating allocation, meaning they may be 10% allocated one iteration and 50% the next. In an Agile environment this is a recipe for unpredictability. While possible, this makes the Scrum Masters job that much harder as they attempt to track individuals availability across spreadsheets that likely mean little. The Scrum Master may look to calculate individual capacity only to realize that when its needed, its not supported. Stories and Features may lag iterations or even program increments because personal allocations are not steady. Granted, very few individual capacities are constant (as people take time off), but partial and fluctuating allocation complicates this even more. Velocity (the average effort a team can deliver over a given period) goes out the window for iterations and becomes far more complicated and less predictable incrementally.
What is the true availability of each of these people? Are they working 1 hour a day or dedicating a day or two per iteration to the efforts?
Another challenge that is presented by partially allocated resources is understanding when the work will actually get done. Consider this: If a team member is allocated at 50% (less makes this worse) when exactly will they be putting in that effort?
When you consider the possibility of someone who is 25% allocated, this could mean they work only 2 hours a day on this solution. In doing so, what is still a 1 (effort) point story could take them a week to accomplish. A 2 point story could take them the entire iteration. What happens if we plan it and there are dependent stories or features on this work? Delay. More time spent planning. Higher overhead. What happens if what they expect their plan to be (specific days) gets altered or delayed in some way? Our commitments are missed. Downstream impacts are incurred. Stakeholders and customers are unhappy.
While we can certainly do our best to overcome this challenge, things happen. Sure we will remain agile, but with less dedication comes greater challenges. Businesses want to lower risks correct? So mitigate this. Ensure specific days will be dedicated to the work and those days cannot be changed. In doing so, we can plan more accurately, spend less time understanding an individuals capacity, and apply some kind of cadence to a challenging situation.
Are there specialized skills that these personnel share on work outside of the program?
Lastly, there is always the opportunity to reallocate resources. I have worked with an organization with serious challenges in regards to partially allocated personnel. One of the solutions we investigated in order to overcome their challenges was to review the skillsets across all of the partially allocated personnel. What we found was that in some cases there were multiple personnel who were allocated both internally and externally to our program who possessed the same skills. In identifying them we were able to allocate more of their time to either internal or external efforts, completely removing them from the other.
For example, John and Susan shared the same skillsets and were both allocated 50% to our program and 50% to ongoing legacy efforts. After some discussion and thorough analysis, we were able to shift Susan to 100% allocation on our ART while John moved 100% of his efforts to the legacy system.
By doing a thorough analysis of the skillsets within your team, and looking at the skillsets and allocation of those same individuals efforts outside the team, you can find ways to build a more dedicated team.
When faced with the challenges highlighted above, it is always the smart investment to head this off early. Consider the questions above and how you and your team may overcome the challenge of partial allocations. Understand the problem to be solved, brainstorm potential solutions based on your organizations unique situation, and resolve to implement changes that improve your team’s and ARTs value delivery.
