We’ve all heard of the KISS principle. It stands for: keep it simple, stupid.
Well I want to apply it to software development leadership. Particularly those leaders that are in an agile context.
I’ve been hearing a tremendous amount of pushback and whining amongst leaders in agile contexts of late. What you say. How can this be?
Here’s a sampling of the running types of dialogue (complaints, whining, pushback, etc.) that I’m referring to:
- We’ve already committed to customers a release date for a new, highly profitable product by June 1. However, the agile teams keep saying it will take till January. I thought agile would allow us to get more…faster. It’s sounds like every other time when the teams couldn’t seem to meet our demands. Where’s the creativity? Where’s the can-do attitude? Where’s the commitment to hard work? Where’s the agility?
- The teams keep complaining about interruptions slowing them down. However, our clients need to be supported AND we need to deliver on our project commitments. I know that these are two conflicting areas that could easily take 100% of our capacity. But the harsh reality is that we have to figure out a way to do both at the same time. And I have full confidence in our team’s ability to do that. Now, if they would only stop complaining and get the job done.
- I just don’t understand how many of our small customer requests take so long to get completed. That and our bug backlog seems to be growing as well. These are all incredibly small changes. I remember when I was developing the original application I managed to keep up with the demands. Of course, we only had 10 customers then and we have 100k now, but come on, it takes only a few minutes to make each change…right? And they need to be able to keep up with this maintenance while still meeting our newly forecasted project commitments.
- The leadership team met for several days to determine our next year forecast for system enhancements and new opportunities. We tried to be as conservative as we could be, but the market is moving incredibly fast. And we need to match that speed. So, we’ve come up with a plan that we feel is perfectly feasible for our development organization to execute. We’ll hand it to them at the end of the year and ask them to commit to it. Oh, and of course, we’ve already announced it to our board, stockholders and clients.
- We work in a regulated environment. Our applications have to support the annual regulatory changes by very specific dates. Often our teams push back on these commitments because they have “too much to do”. The counter-pressure is that they are non-negotiable dates, so the teams need to figure out how to meet them. No matter if they are 2x, 3x, or 4x our capacity. It really doesn’t matter. We’ve just got to do it. And agile is the way it will happen.
If I were to categorize all of the above, it really boils down to leaderships lack of understanding (or denial of reality) and poor understanding of their organizational capacity. It’s as simple as that. In other words, they need to stop:
- Managing not to the hopeful capacity;
- or the imagined capacity;
- or the wishful capacity;
- or what they “think or perceive” it is;
- nor to what they could do when it was only themselves and two programmers.
And start managing to their actual capacity. That is, what their teams say it is.
But many leaders view a primary aspect of their role as distrusting the capacity estimates coming from their organizations. Because they’re bloated, uninformed, and padded. And it’s their job to put downward pressure on the teams so that they get more juice from the orange.
In other words, they’re squeezers. Squeezing, and squeezing, and squeezing…
And I guess I could buy into this approach…if it really worked. But I’ve never actually seen it work. Not in the end, when the team delivers. The resulting software inevitably suffers from quality and scope challenges. And it’s often delivered late anyway.
There is another approach. One that feels incredibly uncomfortable, but one that is congruent, honest, and real.
It’s Simple Really
Leadership in an agile context is incredibly simple. Here are some generative rules:
- Don’t make client commitments (scope, time) until asking and discovering with your teams how long it will take.
- Trust their answers and don’t put undue pressure on them to compress estimates. If you don’t like an estimate, de-scope your request.
- Make your business decisions and forecasts on the actual capacity of your team (what they tell you it is, what they prove it to be) and not on what you’d like it to be.
- In order to go faster, agile can help by:
- Delivering higher initial quality so as to avoid rework;
- Encouraging business stakeholders to provide early and often feedback;
- Realize that you play a role in agile transformation by making trade-off decision based on your real-world capacity.
So, stay incredibly disciplined in your capacity management and support of agile principles and you’ll probably achieve “faster” delivery.
That’s it. It’s like you were planning on doing a painting project in your house. And you haven’t painted for 20 years. And you have shaky hands. And you are easily diverted. You could plan it for a single day. But that would be too optimistic and not take into account the reality of your capabilities and capacity.
In other words, you could fool yourself into believing you’ll finish the project in a day. And then be disappointed when you fall short.
Or
You can plan it for reality. Considering everything, admit it will take you 5 days to do it and that you will have to drop several other commitments in the process. Then decide if you want to do it or not.
Not at the imagined/optimistic 1-day cost, but at the real world & realistic 5-day cost. Oh and, how would you feel if you absolutely know it’s a 5-day effort, but your spouse came in and demanded it be done in 1-day. Motivated and energized…huh?
Wrapping Up
I also believe there’s another factor lurking below the surface here.
I think many leaders lack the courage to have hard conversations with their own organizational leaders. It’s far easier to be a “yes man” or an “overly optimistic person” than it is to have a challenging conversation surrounding the trade-offs that need to be made to fit demands into the organizations existing capacity.
Ongoing denial and/or deferring these conversations till the very end seems to be the preferred approach.
But it’s simple really. I want all leaders to start being honest with themselves and bite off what they can chew. No more and no less.
Now is that so complex?
Stay agile my friends,
Bob.
Here’s a related topic that Josh and I discussed on our Meta-cast recently: http://www.meta-cast.com/2017/05/episode-115-responsible-leadership.html
And here’s a related blog post link: http://rgalen.com/agile-training-news/2015/1/2/agile-is-focused-on-capacity-equalization