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.
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.
Once we progressed a bit in our assessment, I asked a series of questions around the project work they were doing:
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:
And no, I’m not making this up. Back to their challenges, I’’ll boil them down to the following:
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.
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:
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.
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.
I’ve recommended this before in other articles, but I think it’s relevant here. I want you to review a video by Henrik Kniberg 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.
This article was originally published on rgalen.com and was reposted here with permission from Bob Galen.
About the Author:
Bob Galen – Agile Consultant, Coach & Trainer at RGCG, LLC – Bob Galen is an Agile Methodologist, Practitioner & Coach based in Cary, NC. In this role he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is a Principal Agile Evangelist at Velocity Partners, a leading agile nearshore development partner. He is also President and Agile Trainer & Coach at RGCG. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing and team leadership. He is a Certified Scrum Coach (CSC), Certified Scrum Product Owner (CSPO), and an active member of the Agile & Scrum Alliances. He’s published two agile related books: Scrum Product Ownership, in 2009 – 2’nd Edition in 2013 and Agile Reflections in 2012. He’s also a prolific writer & blogger and podcaster. Bob may be reached directly at – firstname.lastname@example.org or email@example.com
Come see Bob at STPCon, he will be busy! Bob is leading a workshop on March 31st entitled: Keys for Transitioning from Traditional to Agile Testing – Lessons from the Trenches. Bob is also one of our Keynote Speakers this Spring – The 3 Pillars Approach to Agile Testing Strategy. Join us in San Diego!