What Problems Are Executives Trying To Solve With Agile?
Like I mentioned in my last post, the problem we think most execs are trying to solve with agile (are we building the right product), isn’t the problem they are actually trying to solve with agile. Walking into a room of senior vice presidents talking about empowering teams, enabling them to inspect and adapt, and figuring out requirements as they go doesn’t always resonate.
In fact… in my experience… it doesn’t often resonate.
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. Sure… execs want to take more feedback from customers, build the right products, engage their people, and continuously improve; but that’s not where they are bleeding.
If I could summarize the three most important challenges execs face…at least the execs that call us… they are predictability, quality, and early return on investment. The interesting thing about these answers is that, many of the things we are trying to sell with agile directly compete with the goals of the executive team… especially when it comes to predictable outcomes. Quite often, we are selling the wrong stuff.
In my next post we are going to talk about the language we use in agile and how to begin to untangle some of the preconceptions and myths people are carrying around about how to deploy these methods. There is no right or wrong here… just getting explicit about what problems you are trying to solve and making sure we are choosing the right practices to help us get there.
Read the previous post, Are We Solving The Right Problem?
Read the next post, Is Your Business Model A Good Fit For Agile?
Comments (13)
Roger L. Cauvin
Great post. Enlightened product managers embrace (and even drive) agile methods to address requirements risks and uncertainties in the business model for their products. Unfortunately, confusion surrounding which problems agile methods address have led some product managers mistakenly to dismiss agile methods as purely for development.
Chip
Key word: Communication. Lack of it, and ignoring things that are inconvenient cause bad product to go to market, or messes that take as much time to clean-up as they took to create, and increased support time / costs. It’s an attitude problem first and foremost. Everyone understands the need to get things to market, but, if you push crap to market, push too hard, don’t allot time for burn-down, etc…. don’t listen and don’t pay attention…
What I’m seeing / hearing here is one of the many reservations I’ve started to take with “Agile” — Even with “agile” properly implemented, you can push crap if you don’t know how to use it. And, to “use it” — management is looking at a process / tool, rather than individuals and interactions. You can’t ignore individual interactions and communication and implement a process or tool to try and abridge this. And that’s what I’m hearing. And it all sounds bad.
Thanks Roger for the comment. As this series of posts unfold… I’m going to explore how you deal with requirements risk when you are more focused on predictability and dates vs. a more discovery focused requirements approach.
Chip… thanks for the comment. I think my next post will help explain my position a little further.
Roger L. Cauvin
Mike, I’m looking forward to the rest of the series.
Paul
Very insightful stuff, Mike. Resonates absolutely with my experiences as a Product Manager in the media sector in London. However, not sure i can be as balanced as you in my assessment of the situation. Isn’t this the last gasp of the dinosaurs before extinction? If Execs don’t listen to their Product and Engineering teams then aren’t they simply in denial about the realities of the digital landscape? Native digital players are Lean-Agile from the ground up so fundamentally embrace uncertainty, iterative development, experimentation and customer focus as a matter of course – time will prove that they are better suited to the digital marketplace and the digital consumer.
Looking forward to hearing more.
Agree Paul… I think some of these companies are going to die. That said, giving them a solution that won’t solve their problem won’t fix it. It can’t change over night. As I explore these ideas, we are going to develop a language for how to lay a foundation where execs can be the kind of companies they want to be… and probably should be. Just like you can’t go from a legacy architecture to services orientation overnight… there is a process to agile transformation that involves intermediate states. That is what I want to explore… for now, just laying the conceptual foundation ;-)
Jackson
Executives are simply trying to cover their butts. They and their teams make promises that can’t be kept, and engineering goes crazy trying to meet deadlines for constant moving targets. The engineering teams say “hey you can’t do this stuff and expect deadlines to be met”. And everyone hears about how “Agile” can solve all of this. Agile can’t solve any of this if the feature creeping inserts itself immensely into the small sprints…which over time, become the same long sprints everyone was used to with waterfall. People like using the word agile, and saying many syllables like “continuous integration”, but in most cases, Agile is a top-down mentality, and if the executives aren’t truly on board, then Agile is just a marketing term folks use to try and look good. Executives (and the customers) can’t really see the beauty, up front, of agile. It’s too plain. They like the word, but they don’t like what it really means. Small sprints means small sprints. Low numbers of features at a time means exactly that. But how can execs and even engineering managers brag (and look good) about small sprints and small feature sets ? They can’t…or at least they think they can’t. They need to showcase how awesome all their exec and managerial skills are, by showing huge numbers of features and functionality. And since they are the execs, and they want huge features sets all at once, then that is what they get. Which isn’t agile. It’s the same old style where incompetence can hide and thrive through lack of accountability.
Jackson… execs are trying to run their businesses profitably… period. In my experience, folks want to do the right thing. Teams are poor at making and meeting commitments. Execs have no good data so ask for irrational things. It’s fundamentally a problem of capacity and demand and bringing those two sides of the equation into balance. The problem isn’t solved by pointing fingers but by fixing the system of delivery both sides are operating within.
Glen B Alleman
Great post.
As the Director of Program Governance for a SaaS provider to the public health insurance domain we face three core issues:
– Increase quality of releases to reduce the Break/Fix cycle and free up resources to produce new products and improvements.
– Predictable releases with predictable quality. Late breaking code, late arrival of “urgent” requirements” creates churn, reducing quality, decrease staff effectiveness, and increases cost
– Visibility to staff utilization, prioritization, and measures of effectiveness of their work to provide visibility to the Estimate to Complete
Our coding method team based and flexible enough for now. But our needs a steards of “public” funding are:
– Estimates to Complete of the “sprints” we’ve laid out in TFS
– Requirements management. Customer not always well equipped to developed requirements, but due date – federal mandates – fixed.
– Resource planning
– “road block” removal between development, Ops, QA, IV&V, security, Help Desk, Training, with visible dependencies being removed by Project Management processes.
The term agile means many things, but adaptive development practices certainly help at the code level within the governance model of federal guideline for public funds
But standard PM practices come first. Cost, schedule, requirements, resource management must be the foundation of flexible development.
Hopefully you be speaking of that next – agile in the presence of program governance.