The challenges of resource management in our Agile team
Over the last year, as we’ve been formally trying to work in a more agile way, one of the biggest challenges I’ve faced as a project manager is resource management. In other words,
- How do we know how much time each team member has to work on projects?
- When we’re planning the next sprint, how do we track how much work has been assigned to a team member, so that they have neither too little nor too much work.
Agile planning in theory
In theory, Agile planning should be pretty straight forward.
Imagine we have a team of five developers, each with 6 hours available for work each day. That gives us 30 hours per day, and assuming 9 days of project work (with one full day set aside for retrospective and planning) then within each two weeks sprint we should be able to dedicate 270 hours to development work.
During the planning session then, with the business having prioritised the work to be done next, it’s up to the development team to estimate the size of tasks and stack these up in a backlog. We know that we should aim for around 270 hours of work (or perhaps a little less, maybe 265 hours, to create some slack — breathing room to make provision for some tasks running on a bit longer than anticipated).
Moving through the sprint, developers pull work to themselves and gradually over the fortnight all 265 hours of work is completed.
Within a few sprints the team begins to establish a velocity—the average amount of work that can be comfortably completed. This really helps to plan further ahead as the team becomes both more predictable and reliable.
Challenges
That, at least, is the theory. In reality, here in St Andrews, we have a few challenges.
Not a cross-functional team
One of the challenges we face in the digital communications team, however, is that Agile assumes cross-functional teams. As Ilan Goldstein puts it in Scrum Shortcuts without Cutting Corners (Addison-Wesley, 2014)
“A successful, self-organising Scrum team has no place for divisive, clannish structures that create functional silos within teams. Silos are often former either on functional groups (such as a programmers versus testers) or on hierarchical grounds (such as technical leads versus non-leads).” p. 26
We very much have functional silos: our team comprises mostly content editors and developers, and there is very little overlap in either direction. Our web editors write well, have some HTML skills, but little or no CSS or JavaScript knowledge; and conversely, the developers are comfortable writing code but, in the words of one developer the other day, “I cannot words”.
Not just one project
Another challenge is the amount of business as usual work that we manage.
Agile assumes that the team will be available to work on only one project at a time and that the project will be their primary focus. Across our team as a whole, though, about 60 to 70% of our time is spent doing business as usual tasks: admin, team communications, support, mentoring, meetings, and consultancy—offering our input on projects managed by other teams. Some of us also have portfolio responsibilities (how we transition projects from an initial idea, through approval, to beginning to work on them).
That leaves relatively little time, around 40% of their working week, to dedicate to project work. Which means that we really need to be as efficient as we can when planning, so that we may deliver projects at as close to our maximum velocity as possible.
Universe of work
One tool that our friendly, neighbourhood business analyst introduced us to is the Universe of work. It’s a bit like a time budget sheet.
On our universe of work spreadsheet I’ve grouped all tasks and activities under the following categories:
- Business as usual (BAU)
- Support
- Personal development
- Team communication
- Admin, including emails
- Internal team mentoring/coaching
- Meetings (BAU)
- Consultancy (BAU)
- Portfolio
- Portfolio board meeting
- Portfolio board admin
- Pre-project work
- Project mechanics
- Daily stand-up meeting (scrum)
- Sprint planning
- Retrospective
- Project management
This has been key to us getting a handle on how we spend our time, and what time we have available for project work. As my Agile project management trainer kept telling us, “If you don’t measure it, you can’t control it”.
For example, this week it reveals we have 187 hours available across the team, but once business as usual and portfolio activities have been accounted for we have only 76 hours available for working on projects.
Work in progress
My current challenge — this has been a blog post full of challenges, hasn’t it! — is how to more efficiently use this universe of work document to help us while planning sprints.
During the last planning session on Friday afternoon we each kept a tally of tasks estimates (in hours) that we’d committed to during the sprint. While that may have been good to enable team members to begin to own their own universe of work, it made it difficult to see at a glance how balanced work allocations were for the team.
This week I’m going to redesign our universe of work document, based on our experiences and feedback from Friday, to allow it to provide this information. I’m also toying with the idea of categorising it into content work and development work to see if that will help, given that that is the reality within our team. I will report back with our findings.
Going into this, though, I am reassured by the words of the trainer I had on a recent P3O (portfolio, programme and project office) course: resource management is really hard!
An interesting approach! Why did you decide to use the "Universe of Work" spreadsheet instead of tools such as Pivotal Tracker or Trello?
Hi Chris! I just wanted to reply quickly as Gareth is on annual leave at the moment. The short version is that we use Trello to break our work into tasks and assign them to members of the team, and also use the universe of work spreadsheet as a way to understand for any given sprint how much time we have for different kinds of tasks (content, design, dev, testing etc). I am sure that Gareth will explain in more detail, but it basically means we predict how quickly we can finish a project when it requires different skillsets, and the team all have different capacities.
Hi Chris, what she said! (I actually did reply a few days ago but somehow the browser crashed and I lost it.) The idea behind the Universe of Work, as Carley alluded to, allows us to think in terms of time budgets for the different responsibilities we have as team members. Many Agile teams will simply be working on a single project, therefore their entire time budget (for us that’s 125 hours each per sprint) is used up on the project. For us, however, we’re juggling business as usual (support, personal development, communications, mentoring, University meetings, consultancy), portfolio activities, plus a maximum of two concurrent projects. We felt it was important to get an idea of what time budget we had for each area. I would love it if we had a fixed budget for each project per sprint. That would make predictions much easier. We may get to that point, but for now the Universe of Work spreadsheet helps us at least know how much time we’ve got, and what the rest is being spent on.
Your approach is not agile. The team has to work 100% on the sprint. Nothing else. If this is not possible then your company does not allow Agile.
Thank you for your comment Duck. I'm not entirely sure why you think that, to be honest. Certainly a lot of recommendations about Agile/Scrum/XP, and a lot of teams do only work on one project 100% of their time, but there is nothing in the Agile manifesto nor the DSDM Atern principles that dictates that the team has to work 100% on the sprint. Much of what Agile recommends is that there are things to do (the backlog), during a certain amount of development time (the sprint) worked out from the team's record of what they've done in the past (velocity). There is no reason that the backlog cannot be made up from requirements from multiple products, or that the team has to work their entire work-week on one project. Sure it affects the velocity for that project, but if it becomes stable and predictable then they can demonstrate control and deliver on time.
Hi Gareth, A very interesting post - thank you. I find a number of aspects of it particularly interesting: (a) You acknowledge that agile in the real world requires compromise. This is refreshing as many exponents of agile see it through a narrow lens. (b) How there is still a need for resource planning in an agile environment. In particular to help you manage cross project allocations of people. I assume you also use the spreadsheet to form some longer range forecasts for your projects / future staffing? It would be interesting to understand how this works. (c) Spreadsheets are typically the first tool that people work with when implementing a resource planning solution and the appeal is easy to see. However from experience it does not take long for them to become problematic. Reasons can include time spent to update, static models (i.e. no ability to model things like "what if hire 5 people", "what if we defer certain projects", "what if we start up new projects" and the effect on the resources and problematic reporting. I have shared some of this below. http://www.linkedin.com/feed/update/urn:li:activity:6293791284570267648
Hi Ian, thanks for your comments. You asked a couple of things: b) why there is still a need for resource planning in an agile environment, and c) why spreadsheets? b) Resource planning We've been following the DSDM Agile project management framework which fixes resources and time, but allows for flexibility in features. All good, so far: we gather and analyse requirements, we prioritise and estimate them, and then stack them up in a rough timebox plan to give us some reassurance that in an ideal world we could deliver at least all the musts, shoulds and coulds. The problem is: our team members rather enjoy a life outside work, and so some weeks we have had a full complement of ten team members for a ten day sprint, and other weeks we've had five, or any variation of days off (last sprint one team member was off about every second day). With such a localised and wild variation in resource size from sprint to sprint we can't simply estimate based on an average of the last _n_ sprints, although I have now begun recording that to see how we perform over a longer period, say a couple of release cycles. The other reason is related to our need for compromise. While we try to split business as usual and project work 30/70, there are times when due to the nature of what we do and the heartbeat of the academic year that we have to adjust that to, say 50/50. So, being able to respond to these periods is very essential for us. So, when we put together our initial timebox plan in the Foundations phase we try to account for these periods in the academic year. These then get built into the plan, and we set a fixed project length at this point. Then during exploration, engineering and deployment if any further adjustments need to be made we start dropping features (shoulds and coulds). This is partly why I don't understand why people argue that unless we are working 100% on a project then we cannot possibly be using agile. That's a bit like saying if you work two part-time jobs—say, as a postman from 06:00 to 11:00, and as a barman from 16:00 to 22:00—then because you don't work 100% on your first job you can't possibly call yourself a postman. The important thing is being consistent in your timeboxing, which is why we commit to working 70% of our time on project work. c) Spreadsheets I started using spreadsheets because I knew them and had immediate access to them. As with many things, we just wanted to get up and running quickly. We didn't want to have to go through a requirements gathering exercise (and begging for funding) to figure out if we needed Asana, or Hub Planner, or 10,000 feet, or whatever else might suit our needs. Instead, we had some immediate questions that we wanted answering and so fired up a quick spreadsheet and threw some numbers at it. I've just spent the last couple of weeks updating our spreadsheet given what we've learned on the last few projects, and some new questions that I wanted answering. Among those questions, though, are not the ones you posed: "what if [we] hire 5 people", "what if we defer certain projects", "what if we start up new projects". In our situation, we are systematically working through a programme of closely related projects. We know that we're going to be working on the prospective students' website next, along with study abroad information, then we'll turn our hand to news and events. What I do want to improve, though, is our forecasting, based on team availabilty. I expect there will be a blog post about that in due course. Thanks for your feedback, Ian.
Thank you Gareth, you raise familiar questions and it is interesting to learn how you are approaching a resolution for each. I face a similar situation managing my development team with varying skill levels and a large amount of BAU requests coming in so I'm interested to learn how you are calculating and forecasting their capacity across your portfolio of work now. Are you still using Universe of work or have you found another useful tool or plugin for jira?
Hi Sarah We are still using our universe of work but we have simplified it greatly since this post from November 2015. When we first created it we listed all of our regular commitments (from support calls to meetings with other departments, that may only be attended by one member of the team) but this grew to be too complex to manage, so we reduced it to the basics: * daily stand-up meetings * slack * support calls (including 'Fix-it Friday') * sprint planning * personal development time * end of sprint retrospective This creates the basis for our weekly rhythm. And into this we plug everything else. We also have a commitment from the business that we will split our time 30% to BAU and 70% to project and programme work. So on the first Monday of our new sprint, we spend much of the day in planning. We stack up enough work (in Trello, we don't use Jira in this team) for that sprint, based on priorities that have been determined prior to the meeting by our strategic steering group. In terms of forecasting, that's something I'm now turning to again after neglecting it for a while. Obviously, the further ahead you look the more uncertain things appear. People need to take annual leave, or go off sick unexpectedly. We had an algorithm for this, to build this uncertainty into our long-range planning. I should dig it out again and reevaluate it given our experience. At the end of the day, though. I'm trying to keep things as simple as possible. And having the commitment to limit BAU work to only 30% of our full capacity, has been instrumental in creating a more predictable environment in which to work. I'd obviously be keen to learn about any resource planning tools that others are finding useful.
Hi Gareth, Interesting Post. I would encourage you to start looking at metrics such as throughput, cost of delay, lead time and cycle time, to help you with better forecasting and also making sure you are improving as a team. One of the challenge of working with diverse items in the backlog is that the learning curve and the context switching need to be taken care of.
Hi, Fascinating article! and still relevant 7years on! Do you have a template to share on the universe of work?