August 24th, 2010

The One With The Fifty Percent Resources


The Wizard Sleeves were a team of 7 people – Alistair, Dave, Gordon, Margaret, Nicola, Olivier, and Peter; pulled together from various project teams within the department to tackle a project that had been hanging around for about a year. At Sprint Planning Tony, the ScrumMaster (and also one of the management team in the department), brought along a “resource planner” to show how much time each of the team members had available to spend on this project.















Every member of the team had other projects that they were working on at the same time as working on the Wizard Sleeves team. Indeed this was not the primary project for over half the team and only Olivier could say that this was his priority one project.

Sprint Planning was tough for the team because although they had the “resource planner”, it didn’t indicate when each person was available – was Dave available for the first third of the Sprint? The last third? 33% of every day? The first third of every week? How was that going to synchronise with the other team members’ availability?

They ended up committing to a lot less than they would have liked to because of the uncertainty, which did not please Tony, but at least they were on their way. However, the Sprint itself didn’t seem to go very smoothly. The team never seemed to really be together and there were always impediments being raised to Tony. The Sprint Burndown started off badly and got progressively worse as the Sprint progressed leading to a failed Sprint goal and a cancelled project.


Sprint Planning was tough for the team because it was very difficult for them to commit to any amount of work when they didn’t feel comfortable about who would be available and when. There were often days when only 2 or 3 people in the team would be at the Daily Scrum and hardly ever was there a time when everyone was there. Whenever someone in the team encountered an impediment – and it was often the fact that they needed someone else on the team – there was always something else they could be getting on with. The problem was that this was always another project! If we were able to co-ordinate our available time so as to be most effective this problem would be mitigated (it would likely never go away though) and so a good first move would be to ask the team this question: “how would you ideally organise your availability in this Sprint to maximise your ability to deliver?” A shorter sprint will make this an easier question to answer by the way.

In order for these people to become part of this new team, they had to cut their availability on their current project(s) that, although sanctioned by management, didn’t mean the load was lighter for them. Productivity on the other projects inevitably dropped but this wasn’t even matched by an increase in productivity on the new project – the organisation as a whole was losing out. Demands on their time were still high and what happened in practice was that they were stretching themselves past their capacity, increasing their stress levels in the process.

Mary & Tom Poppendieck talk about the inefficiencies of task switching in their book “Implementing Lean Software Development” and I love the diagram they use to explain it. It is so simple, true and powerful. It says that if you attempt to take on three tasks concurrently it will effectively take you longer than if you did them sequentially. This is primarily down to the inefficiencies of multi-tasking. Mike Cohn also talks about this in his book “Succeeding with Agile” and refers to a study in 1992 by Clark & Wheelwright that says the total time spent “on task” decreases after 2 (it pays to have a back up task in case you get blocked on task 1)

Even if we put aside the assumption that multi-tasking causes inefficiencies that actually decrease your overall productivity (even though I strongly believe it and almost everyone I speak to strongly believes it), taking on concurrent projects is still a bad thing. Let’s assume that I am perfectly able to split myself across 3 one-month projects (33% each with no waste or drop in overall productivity). Instead of finishing project A in the first month then finishing project B in the second month and finally finishing project C in month 3, I am delaying completion of ALL of these projects until month 3. This reduces my organisational return on investment by delaying the release of my most important project for 2 months. Even project C is no worse off by sequencing the projects.

Everyone working on one project only is a laudable, if somewhat impossible, aim and sometimes it will actually make sense for people to be shared across projects as it would be a complete waste of their time to be entirely focussed on one project as their skills just won’t be needed for the whole Sprint. Mitch Lacey, a CST and Scrum Alliance board member, called these people internal consultants at Microsoft and they were not considered part of the core team. This is an example of a simple rule that teams can employ to increase their effectiveness. Other examples are: “Everyone on the team must be at least 60% allocated to the team” or “No more than 4 people can be on 2 projects”. 

I am a firm believer that most organisations are fooling themselves by the amount of projects that they have on the go at any one time and they would all actually increase their productivity – and the happiness of their people – if they actually cut a number of their projects. I would much rather wait until the ROI of one project falls low enough to allow us to focus on a new one and staff it properly than be working on multiple projects. My personal opinion is that ScrumMasters should strive very hard for this as it directly affects both team productivity and organisational ROI. 


I believe that teams can cope with a couple of non-dedicated people on the team, even though it is not ideal and, as Mike Cohn says, organisations should “minimise the number of people required to be on two teams and avoid having anyone on three”. If nothing else, having people who are 49% or less allocated to a project sends the message that there is something else more important somewhere else and, by definition, x% of your time is being spent on something less important.

In my experience, any organisation that refers to its people as “resources” and believes they are fungible, is going to really struggle with Scrum. While Scrum doesn’t mandate that nobody should work on more than one team or project, its values of focus and commitment and its dependence upon teamwork pretty much call it out. I would find it hard to describe the situation above as a team.

I always encourage ScrumMasters to push the problem of multi-tasking at a project level back up the management chain rather than making team members cope with it as it is a structural problem affecting the organisational performance. 


Scrum / scrum master / ScrumMaster Stories


Dedicated Teams / Multi-task / Resource / Sprint Planning / Team / The One With

0 comments | view comments | add comment


RSS Feed Subscribe to RSS