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 and whether they’d allow me to help them. They were also assessing cultural fit. But I was also assessing. Were they “ready” to try agile, were they serious about it, were they self-aware, and would I like to work with them.

It was a great meeting and it led to some interesting follow-up activity. But I remember a conversation distinctly to this day that I wanted to share with you.

Background

But 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 4 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 start-up division, so the IT group had only been in existence for approximately 3 years. They were static in size – so not growing in the foreseeable future.

They supported 100+ applications; many of them 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.

The Work

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?  Oh maybe 20-25

My reaction to this line of questions was dumbfounded shock. When I used my personal experience, I could see loading each team with 1 primary and 1 backup project, so that would equate to 8 parallel running projects. Perhaps round that up to ~12 if you wanted to stretch things a bit.

So wrapping that discovery up:

• I think the organizational capacity is no more than 12 projects
• They think there capacity is roughly twice that, ~25 projects
• They’re actually working on nearly twice that, ~45 projects
• They’ve got active stakeholder commitments for nearly twice that, ~80 projects
• And the project portfolio tracking system is “keeping track of” ~ 125 projects

And no, I’m not making this up. Back to their challenges, I’ll boil them down to the following:

1. We’re not meeting our project commitments, and
2. We have a quality problem

What would you say IS the problem?

Put on your “consulting hat” for a moment, and no, you can’t reply with “It depends”. What would you recommend this company do to turn the ship around and start delivering better quality software more reliably?

My advice surrounded the insanity of them trying to do too much with too little. And by doing too much, or working beyond the reasonable capacity of their teams, they were churning themselves. Or multi-tasking so much that it was reducing their already limited capacity and productivity.

Essentially, to them, it felt like they were working on a lot of things, working hard, even frenetically. And they were.

But the reality was, they weren’t getting things done. And when they did manage to deliver something, they were exhausted, which impacted the quality.

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, focusing on fewer, and then trying to get them done, they might get better results.

I say this in my agile classes all of the time. That:

• Multi-tasking is not an effective strategy, you actually lose time in task switching for knowledge work;
• That busyness or sheer effort is not necessarily correlated with results;
• That’s its always better to work on a small set (batch) of things (tasks, User Stories, Projects) and get them DONE;
• Finally that focus produces higher quality products.

It’s also 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. Independent of the size of those things, and in this case, they were quite large.

In their case, it gave the appearance that more was being done, but they weren’t delivering. Sooner or later, this promise, but don’t deliver strategy will become obvious to all and utterly fail.

But They’re Making Me Do It

The biggest pushback I heard from this group, and it wasn’t simply from the Director, was that they couldn’t “slow down” or “do less”. They blamed their senior leadership for the problem. That senior leaderships expectation of the organizations capacity was way beyond the reality of their capacity, but that they couldn’t say no. They couldn’t pushback or ask leadership to more thoughtfully prioritize their portfolio.

They bought into the insanity of their infinite capacity and were afraid to TELL TRUTH to their leadership team. Instead, they ignored the root problem, continued to churn, and to disappoint.

My return argument was that they were part of the problem. In fact, 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’

And Teams won’t say ‘No’ or “We’re FULL” and keep committing to more.

It’s insidious though because of the negative impact it has on already limited capacity. And it often creates a downward spiral until someone has the courage to tell the truth and to align the organizations capacity to project requests.

So while the senior leadership in the organization was a party in the madness, I put the root cause squarely on the leadership of the IT organization. Somehow they had to stop agreeing to more, more, more and immediately scale back on their “commitments”.

At this point, and I’m sort of joking, they thanked me for my time and virtually kicked me out of the door (we stopped exchanging email). My guess is that they’re still churning to this day.

Wrapping Up

I’ve recommended this before in other articles, but I think it’s relevant here. I want you to review a on the role of the Scrum Product Owner. It’s a 15-minute video and quite nicely done.

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 for my potential client and many other organizations. Heck, it’s relevant for all of us.

So as he says, you must practice it every day!

Stay agile my friends,

Bob.