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!