top of page

The Agile Resource Burn


I've had a couple companies ask me recently, is it ok to have staff in squads also doing their regular jobs outside of their agile work? Does this sound familiar to your organization?

At a particular point in planning an agile enterprise, the pain hits. Agile teams are usually defined by identifying the worthy 'persistent purpose': the mission of that squad to innovate with continuous improvement for the foreseeable future. Within the squad the roles are then hammered out that will give the maximum amount of self-management; equipping with the skills to repeatedly move from ideation to delivery.

And then the organization has to put names in those skill boxes, and bad things can happen.

It's possible, but unlikely that the org is going to 'staff fresh': have the budget, job market availability, and timeline to stock squads with some or all new hires. 'Adopting agile' means you're bringing agile ways of working into an existing resource structure. So the org will start looking at existing skills and, no surprise, those valuable people already have a lot on their plates. The temptation then is to cheat: "we'll leave them in their current roles, take some work off their schedule, and they can sit in this squad as well."

Why is having staff work in and out of agile, a bad plan?

  • You've made an investment, let it pay off. Training staff on agile ways is a significant investment of time and cost. The more the employee practices their agile skills, the better the return on that investment.

  • Don't be breaking up the band. It can take squads months of fulltime engagement together to reach a strong performance level. The effectiveness of the team in delivering on successful outcomes is directly connected to the constant involvement of the individuals, learning to depend on, and get the best out of, each other.

  • Overload is inevitable. In this dual mode, an employee is essentially working two distinct jobs; the performance leader doesn't see how much work is being done in the squad, and the squad has no mechanism to understand that employee's work outside. High performing employees will invariably over-commit on both sides, and this is the fast path to burnout.

  • It's hard to go back. Most people working in agile will tell you they never want to go back to a traditional hierarchical management model where they have a performance leader controlling the what and the how of their work. This shift back and forth can be demoralizing.

Then, how to manage resource commitment in agile?

  1. Be real at the time of squad design. You may have great aspirations for a squad purpose, but put that on pause until resourcing becomes available. Or, if the squad is seen as critical to the organization's progress, budgeting a resource addition could be rationalized.

  2. .5 FTE is possible. I've seen squad members function successfully working in two squads at once. In the squad design the resource skill may only be required part of the time. Utilizing a resource in two squads, maximizes their agile involvement, the workload can be self-managed, but doesn't spread that person too thin. Anything less than a half time participation, and that resource will spend too much time in multiple agile ceremonies.

  3. Consider secondment. You may find the needed skillset in other areas of the organization (or outside) that have availability at some point, that you could plan to integrate for a committed period of time. This will involve building agile skills and team integration, so secondment doesn't work well if the engagement is less than 3 or 4 months.

  4. Build out your Centres of Expertise. CoEs are a common and essential part of the agile enterprise, involving resource contribution from areas of the organization outside of the squads that aren't persistently required. Defining and preparing your CoEs can be extensive work, but gives the agile enterprise more scope of support in an organization (more, in a future post.)


In committing to becoming an agile enterprise, organizations have a baseline responsibility to ensure the design and function does not foster employee burn-out. With proper planning by agile sponsors, coaches and pod leads, staff can work in a fast-paced, continually improving environment without feeling like the 'new ways of working' are too much to manage.

Comments


bottom of page