In traditional resource allocation, we assign programmers or “resources” to a project based on need or availability. However, issues arise when we start working on multiple projects and suddenly our programmers are now working on multiple projects and teams. Traditional resource allocation is a sure way to overwhelm individuals.
In Agile, we form teams much differently. Agile teams work together to tackle the work that is prioritized the highest, according to stakeholders.
Learn more about forming successful Agile teams and how to prioritize projects effectively with this video from David Hawks.
Want to know more about forming strong Agile teams? Check out our whitepaper: Build High Performing Teams Through Trust and Alignment.
Video Transcription (has been slightly edited for brevity and clarity):
Traditional Resource Allocation
Hi, I’m David Hawks from Agile Velocity. Today I’d like to talk to you about Agile Resource Allocation, or people. Let’s compare how we’ve traditionally done it versus how we want to do it now. What we’ve traditionally done, is we’ve got project 1 and who do we need for that? I’ve got Alex, I need Alex for this, I’ll assign part of it to Alex. I also have Janet, I need to assign some work to Janet and we also have Camryn. All of project 1, we say, Alex, Janet, and Camryn need to get this done. Then comes project 2. Who do we need for project 2? We need Alex and Carter and Will. And then we get project #3, another project comes in and who do we need on that? We need Alex, a little bit of Camryn and we also need some help from Carter. Does anybody see a problem with this situation? We have a little bit of a problem with Alex. Alex is feeling overloaded—maybe important, maybe asking for a raise, or dusting off her resume and looking for her next gig. All of these are not good situations.
What do we do? We go to management and we say,”What are the priorities of these projects?” And they are all high priority, they all need to get done and have been committed by certain dates. So Alex has been given all these things—Projects 1,2 and 3 have to get done. She has three things on her plate. How does Alex decide to prioritize her work?
There are three main ways developers prioritize their work if left to their own devices:
- Work on the coolest feature—whichever is most interesting or will help their resume
- Work on the easiest one and get it off of their plate. What can I do to get this thing done and knock it out?
- Whoever is screaming the loudest—which project manager they like the most, whoever buys them beer or cookies, the one who yells at them or trying to get them to work on this. This person yells at me, so I’m going to do theirs’ first.
These are not great prioritization techniques. These are actually really bad prioritization techniques and we don’t want to do those. But that’s what we’ve left our developers up to. Because you leaders are not making priority decisions, you’ve left prioritization up to the person furthest removed from understanding the business priority. And they’re going to prioritize your company based on coolest, easiest and whoever is screaming the loudest. That’s a terrible way to prioritize work.
Agile Teams Resource Allocation
What do we do in Agile? We want to form a team of people. Let’s form a cross-functional team that has all of the people that we need. We’ll call it our scrum team, kanban team or agile team. We’re going to take all these people and put them on a team together. Then we’ll build a funnel of work in front of this team. We need to prioritize this work. We won’t just assign all this work out to these developers over here, we’ll tell business stakeholders to prioritize. The problem is we can’t prioritize project 1 against project 2 against project 3 because they are so large. Project 1 might take 6 months to get all of it done and we need to make some progress on project 2.
We break down project 1 into little pieces. Then take Project 2 and break it down, then prioritize those pieces amongst the other parts of project 1. Then we’ll take project 3, and prioritize that against the other projects pieces. Now, we’ve given our team a backlog that’s ordered by our product owner and scrum. We have to make some hard choices as a business. We’ve got to decide which of these things are going to go before the other things. And instead of assigning the people to the work, we’re now going to assign the work to a team of people and then the team will work together to figure out how they’re going to divide and conquer. “Alex is overburdened, so Will needs to go and figure out how to help Alex.” Because now it’s a team goal and we’re trying to get a shared ownership of the goal together. Instead of assigning the people, we’re now pulling work into our Sprint and the team is swarming to get things done together.