Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.
They were assessing whether I knew what I was talking about, if they would allow me to help, and if it was a cultural fit. However, I too was gauging whether they were ready to try agile, their seriousness, their self-awareness, and if I would want to work with them. It was a great meeting, and it led to some interesting follow-up activity, but I remember a distinct part of the conversation that I wanted to share with you:
First, we need to set a bit of context. This was an IT group within a division of a very large manufacturing organization. There were about 25 folks on the team organized into four groups that aligned with the applications or functions they were supporting. There was a director and each group had a manager/technical lead.
This was a startup division, so the IT group had only been in existence for approximately three years. They were static in size –not growing in the foreseeable future.
They supported 100+ applications. Many of these applications were driven by corporate apps that this organization was leveraging, so there was a legacy component to their work. They were also building new set of applications for a new product line being developed.
When I asked the director why he was thinking of engaging Agile practices, he said:
Bob, we’re really struggling to keep up with external demand. There is a perception that “it takes forever for us to update or release anything”. We also have a fairly significant quality problem and our rework is high. I’m also having an incredibly tough time planning our work, as things change or come up all of the time.
I’m hoping “Agile” will help with or solve most of these challenges.
Once we progressed a bit in our assessment, I asked a series of questions around the project work they were doing:
- How many projects are in your “portfolio” right now? ~125
- How many of them are you committed to progressing based on stakeholder requests? ~80
- How many are you actually working on right now? ~45
- What do you (and your teams) think their capacity is – I.e. parallel projects that 25 folks can make reasonable progress on? ~ Maybe 20-25
I was shocked at their responses! When I used my personal experience, I could see loading each team with one primary and one backup project, which would equate to a total of eight parallel running projects. Perhaps round that up to around12, if you wanted to stretch things a bit.
Or if you wanted to be really crazy, double it to 25 projects in play at any one time. But they were running a nearly two to three times that number and the thrashing it was creating across the team was obvious.
What would you say IS the problem?
Let’s put on our “consulting hat” for a moment. What would you recommend this company do to turn the ship around and start delivering more reliable and better-quality software?
They were trying to do too much with too little, which caused them to burn out quickly.
They felt as if they were working frantically on a lot of things and they were. However, nothing was getting done. When they did manage to deliver something, they were exhausted, and the quality of their work was far below customer and stakeholder expectations.
Multi-tasking IS The Enemy AND Agile is a Capacity Equalization Play
I tried to walk them though the idea that they had too many things in play. That by significantly reducing the number of parallel projects, and focusing on fewer, they might get better results.
I say this in my agile classes all of the time:
- Multi-tasking is not an effective strategy. You actually lose time in task switching for knowledge work.
- Busyness (or sheer effort) is not necessarily correlated with results.
- It is always better to work on a small set (batch) of things (tasks, User Stories, Projects) and get them done as soon as possible.
- Focus also produces higher quality products.
It’s important to align your work and your commitments to your reasonable capacity. Clearly in this case, having three committed projects per person was probably not a good idea no matter the size of the projects. In their case, it gave the appearance that more was being done, but they weren’t delivering. Sooner or later, this will become obvious to all and will likely lead to failure.
But They’re Making Me Do It
The biggest pushback I heard from this group was that they couldn’t slow down or do less. They blamed their senior leadership for the problem. The expectation of the organization’s capacity was way beyond the reality, but they couldn’t say no. They couldn’t pushback or ask leadership to thoughtfully prioritize their portfolio.
They bought into the insanity of their infinite capacity and were afraid to tell the truth to their leadership team. Instead, they ignored the root problem and continued to churn and disappoint.
My return argument was that they were part of the problem. Because they were allowing everyone to expect increased capacity, they were inspiring the increased expectations. I also explained that their leadership team was probably very aware of their not having the perceived capacity. (I.e. in slipped dates, slipped scope, and poor product quality.)
It’s a game of sorts that many traditional software and IT organizations play:
Leaders keep asking for more until you say ‘No’
Teams won’t say ‘No’ or “We’re full” and keep committing to more.
It’s insidious because of the negative impact it has on already limited capacity. It often creates a downward spiral until someone has the courage to tell the truth and to align the organizations capacity to project requests.
While the senior leadership in the organization was a part of the problem, I put the root cause squarely on the leadership of the IT organization. They had to stop agreeing to more work and immediately scale back on their “commitments”.
At this point, they thanked me for my time and virtually kicked me out of the door. My guess is that they’re still churning to this day.
I’ve recommended this before, but I think it’s relevant here. I want you to view a video by Henrik Kniberg on the role of the Scrum Product Owner.
About 5-7 minutes into the video, Henrik makes the point of the most important word for the Product Owner. I want you to watch the video and catch that moment. I think it is not only relevant for the Product Owner, but many other organizations. In short, it’s relevant for all of us.
As he says, you must practice it every day!
Bob Galen is an Agile expert and works to serve Vaco’s Raleigh market, delivering expert