Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.
So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:
Well then… if empowering teams, inspecting and adapting, and handling emerging requirements isn’t the problem execs are trying to solve… what exactly *is* the problem they are trying to solve. Rather than guess, I’ve gotten in the habit of asking them. Most senior leadership teams will say something like this…
- We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.
- We are putting poor quality products into market, we think agile can help.
- We need more transparency into what is going on.
- We need more visibility into the progress we are really making on the product
- We need to get products into market faster.
- We don’t communicate very well, I hear agile can help us fix that.
- It costs too much to deliver software, we want to use agile as a way to lower the cost to product the product.
- We have way too much to do and not enough resources to get all the work done.
- Support work is constantly interrupting new product development
Much less frequently, we’ll hear answers like the following…
- We are trying to better understand our market and are putting out the wrong products.
- We deliver on time, on cost, and on budget but the product wasn’t successful in market.
- We are looking for better ways of incorporating customer feedback in real time.
- We are looking for ways to continuously improve our processes
- We want to help people be more empowered to make decisions.
It’s not that this second group of answers aren’t important… it’s not that they never come up… it’s just that when they do, they are often secondary concerns. They are derivatives of first order concerns.
I’m actually not surprised that Mike is hearing the first list. Of course that’s what the majority of leaders are looking for. And I’m empathetic that they are searching for solutions to these challenges. When I was leading technology teams, from the late 1980’s thru 2012, I personally experienced all of them in a variety of forms. And frankly, it drove me crazy at times.
But what disappoints me a bit is the impression that they’re looking at “Agile” as a “Silver Bullet” that will address what are complex, organizational and systemic problems. These are problems that no mere framework or methodology will have a chance of resolving on its own. It’s this desire, and I may be overreaching a bit here, for a quick fix that disappoints me.
Why?
Because there are no Silver Bullets or quick fixes to hard problems. And any “fix” will require the engagement of this same leadership because most likely, they are a “part of the problem”.
To be honest, I get just as disappointed when leaders look at bringing in a tool or a consulting team as a panacea that will solve their problems as well. Sure tools can help and outside expertise is often valuable, but again, the leadership team needs to be “in the game” with the transformation and not just by paying the bills or initiating the idea.
Looking a Bit Deeper
Let’s take a few of Mike’s points that he’s hearing and drill into them a bit further…
We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.
Absolutely. I agree. But, how are those “commitments” being made. Are your teams making them as you align them with your roadmaps and customer needs? Or are they simply being told what needs to be done by when by “management”? You simply can’t force commitment and a simply having a job or receiving a paycheck doesn’t necessarily guarantee it either.
Instead, you want to enable a culture and environment where you support commitment and you support the process for your teams to get there. And part of commitment is acknowledging that things will change and there are no 100% guarantees. You have to be willing to trade things (scope) off as progress and discoveries are made. Remember, these are typically complex systems we are developing, which are notoriously hard to plan and predict exactly.
We are putting poor quality products into market, we think agile can help.
Why are you doing that? What do you mean by poor quality? In my experience, executives are often a factor here as they relentlessly drive the organization towards “more”, the message the team receives is that SPEED & DATES trump QUALITY. Agile will try to help with this, by reemphasizing quality deliverables at a team level. But delivering quality is typically hard work.
As a leader, you’ll need to “step down” and adjust your emphasis to be on quality over speed or dates. This may take a bit of time for your teams to realize the shift in your goals. But you’ll be surprised that when you successfully make this shift, with your teams, that you’ll get better quality and relatively increased speed as well.
We have way too much to do and not enough resources to get all the work done.
So if I get this right, a process model or type of SDLC will fix this how? This is the ultimate in Silver Bullet thinking. And beyond that, as a leader, you can actually do something here to help. You can either hire more people and/or prioritize the work so that the most important things actually align with your capacity. But clicking your heels together and hoping to “work smarter” or “get more done with less”, is never a viable strategy.
Agile, if implemented properly, it will force you to acknowledge the team capacity and ask them for the highest priority work that will fill their capacity. And yes, hold them accountable to deliver to their commitments to done software.
Support work is constantly interrupting new product development.
In many ways, support work is a side effect of our own doing. Clearly software isn’t perfect and has issues or drives usage questions. So support is indeed required. But my experience is that much of the support burden these executives are complaining about is driven because they established a culture where speed to market trumped doing things right and holding the line on product quality. Imagine that?
So when you don’t honor quality and release poor quality code, you get hit with high degrees of support and rework which derail your next release. And we all have heard of those repair cost models that discuss finding bugs by review vs. having your customers find them. It’s a pay me now or pay me later scenario. And most teams really want to deliver high quality code. It’s normally the business pressure and overall culture that forces premature releases.
What problems are executives trying to solve with agile?
All right, I may have rambled a bit too much, so back to the point.
I remember when I took my Certified Scrum Master certification with Ken Schwaber he said something along the following lines towards the end of the course:
People get frustrated with an introduction of Scrum thinking that it’s creating all of their problems. Scrum, or any of the agile methods, doesn’t create anything. But what it does do is show you your problems— often every day.
- As a leader, it will expose to you organizational issues and other more systemic challenges.
- As a team member, it will expose the impediments and realities of how well you’re delivering your software.
- As a project manager, it will expose the faultiness of your planning and estimates, etc.
Then it’s up to you to do something about it. Reflect, examine root cause, and make a change. If you do you’ll improve. If you don’t, Scrum will bring it to your attention again tomorrow. It can be very frustrating—particularly if you’re looking for others to fix things for you.
So instead of creating problems, agility creates an environment where the problems are exposed and almost demand resolution. But not simply “team problems”. It will expose challenges that all levels of the organization need to face and resolve—including the leaders who have been giving Mike this feedback.
Wrapping up
Certainly I’m not dumping all of the responsibility on the leadership folks referenced in Mike’s post. I just want some of it to reside there. I’d much prefer that leaders truly move from Silver Bullet thinking to truly partnering with their teams. I’d also like them to take some personal responsibility to learn about the methods and the mindset of agility and to engage with it and their teams.
Additionally, I’d ask them to look at the problems that they identified as more holistic and systemic in nature and equally as much their problems as their teams. And finally, wouldn’t it be great if they rolled up their sleeves, with their teams, and got to work on improving things. And yes of course, as Servant Leaders and not Command-and-Control leaders.
Now is that too much to ask?
Stay agile my friends,
Bob.