1. March 29, 2022
11:00 am PDT; 2:00 pm EDT; 7:00 pm GMT
Unlocking Agile's Missed Potential !
VP Product Flow
Expert Insights. Personalized For You.
2. Brought to you by:
Started and run by an experienced and successful group of digital media entrepreneurs,
Aggregage is re-imagining and building out the next generation of business media in a way that
meets the needs and expectations of today’s business professionals and B2B marketers. Using
social media, machine intelligence/smart algorithms and big data, Aggregage’s ever-growing
portfolio of industry-sector focused verticals delivers the most engaging and relevant content to
each industry’s professionals.
Learn more at Aggregage.com
3. TO USE YOUR TELEPHONE:
You must select "Use Telephone" after joining
and call in using the numbers below.
United States: +1 (631) 992-3221
Access Code: 156-525-140
Audio PIN: Shown after joining the webinar
Click on the Questions panel to
interact with the presenters
TO USE YOUR COMPUTER'S AUDIO:
When the webinar begins, you will be connected to audio using your
computer's microphone and speakers (VoIP). A headset is recommended.
Expert Insights. Personalized For You.
7. Construx Software Leadership Summit
Agile in our organization:
1. Met expectations
2. No better than before
3. Worse than before
Only 14% met
9. You will learn:
• Why waterfall planning persists
• Investment-based Agile planning
• Deploying smaller increments
• Managing sales and operations expectations
• Increasing R&D ROI by over 25% without major Agile framework or
24. Tactical Investment examples
• Interactive dashboards to reduce customer operational costs by 10% to increase
annual revenue by 5% over the next three years
• EU competitive features to prevent market loss of 20% over three years
• Multi-tenant capability to reduce annual hosting costs by 15%
• Deployment simplification to reduce backlog Net Cost of Delay by $1M in the
next three years
27. “Our customers
• Poor quality
• Irrelevant features
• Impact to operations
You need to solve
these to become an
28. Agility Summary
• Waterfall release planning precludes the MMFS
• The Investment planning model quantifies Cost of Delay
• Higher value with lower effort gets higher priority
• Product management controls the roadmap
• “Yes, we could include that, but $2M of income will be shifted out of the next
• Don’t plan release trains – eliminate them!
• Increased income from cycle time reduction can be reinvested
39. The Mythical
• Product managers with no time
• Former business analysts with limited
access to customers and market
• Diverse product stakeholders requiring
• Product manager overlap
Either way, no time to
40. • Market research
• Market strategy
• Investment goals
• Functionality to achieve Investment goals
Product Manager Product Owner
Investments convey the business problem to solve
41. What your competitor made
“I want to relax outside”
“Build a device that customers rate
8 out of 10 or better in terms of relaxation"
42. Value Summary
• Distinct roles for product managers and product owners
• Stakeholder value analysis
• Value vs functionality
• Investments are engineering problems to solve
Gilb, Tom, Stakeholder Engineering, Leanpubcom/StakeholderEngineering, July 21, 2021
43. Available April 2022
• Investment model
• CoD and WSJF calculations
• Downloadable calculators
• Investment financial forecasting
• Technical debt Investments
• Stakeholder value analysis
• Agile roadmap planning
• Reducing waste
• Releasing faster
• Investment planning template
• Agile motivation
• Investment innovation
VP Product Flow Optimization, Construx
Webinar Coordinator, Residential Realty Today
Notas do Editor
Let’s start with the expectations of the business and what they believe they were promised with Agile.
And engineering had expectations.
Construx has an annual software leadership summit where I have moderated group discussions for many years. I heard the real state of Agile in many organizations. I used to call it group therapy because everyone thought others were doing Agile just like they read about in books.
I did an informal poll with 15 of my group session members, asking them to convey the extent to which Agile has met expectations in their organizations using this rating scale. I allowed for fractional answers. This chart shows the reality. Only 14% claimed that their Agile implementations met expectations. Something wrong is here. I am going to show you that expectations have not been met because real Agile is not really being done in most organizations.
This will be a major theme of this presentation. Waterfall release planning is incompatible with Agile. Planning releases with fixed schedule and content precludes the immediate feedback that is a foundation of Agile. There is no time for engineers to implement feedback when they are driven by a backlog full of committed features. I like to say that with waterfall we produced software that a customer would finally accept, often hiding behind pages and pages of requirements – you signed off on this! Agile has the potential to create software that delights customers, but only with effective feedback loops.
I’m not going to blame the business for retention of waterfall planning. My background as an engineering leader, VP of product management and CEO has given me a broad perspective on the problem. I empathize with both sides. The business retains waterfall planning in a vain attempt to achieve financial predictability.
This is ideal Agile. It includes product management that many of you have in your organizations. Product management combines business strategy and market research to set direction.
Market opportunities are broken down into epics and user stories so that Agile teams can add technical value with innovative solutions.
A business and technical savvy product owner is fully engaged with the team during development to ensure the team builds the right thing.
Feedback is welcomed and implemented during development.
This is the Agile I observed in 10 years of consulting.
Agile teams are relegated to implementors of a mishmash of features of questionable value.
And here is the project manager that’s still around trying meet a tight schedule with committed features. There is barely time to get demonstrate functionality working let alone incorporating feedback during development.
A preplanned large release is stuffed with features to provide a little bit for a variety of project stakeholders. And, as in this picture, deployment is slow. Customers are hesitant to accept releases because upgrades are disruptive and often contain little value for an individual customer.
You probably notice that the product owner is missing. They are in a different time zone and are available for questions by email.
This is the company addressed in this webinar.
People read all the Agile books that seem to make it simple. People come to the Construx summit to hear speakers boast about their Agile implementations. Most wonder what’s wrong with them. It turns out that companies that can easily implement Agile usually have certain characteristics.
I am going to define waterfall planning as continuing to plan large releases with fixed schedule and content, usually at the feature level.
This webinar is for the silent majority.
These are the examples you don’t see in Agile books or at Agile conferences. My assertion is that the majority of engineering departments work under one or more of these constraints.
I included diverse users. This is where the simplistic product owner model breaks down. Who is the one person who can represent the product for a company with international customers.
Weren’t Agile scaling frameworks supposed to meet the needs of larger organization? They simply put a waterfall wrapper around Agile development, still resulting in large releases stuffed with features.
The business liked scaling frameworks like SAFe because it allowed the business side to plan the same way they always did. Most engineers are still forced to meet feature commitments in large releases.
Let’s talk about the first business expectation of Agile – agility. The ability to deliver faster and turn on a dime.
Let’s look at how waterfall planning of large releases continues.
Investors have multiyear financial expectations. Companies retain a business plan to determine how they will achieve the expectations and assigns responsibility within the organization. First up is the sales department that has to commit to projected revenue. They make revenue commitments that will have major impact on their personal income in the form of commissions. They turn to product management and asks, “What will I have to sell and when?” That results in the engineering nightmare – the multiyear roadmap, often at the feature level.
The roadmap is a component of the company business plan and is not going away.
You’re probably thinking right now that Agile offered agility in the form of the Minimal Marketable Feature Set. However, it has been a cry in the wilderness. Why?
Let’s talk about sales organizations. Salespeople are like predators who get up every morning and need to hunt for their livelihoods. They demand things they can sell. And its usually something that they don’t have, yet. I have often told engineers that they think they see pressure from product management. They haven’t seen anything compared to product management blamed for missing sales targets because they can’t can’t deliver features.
Why does product management bend under the pressure of sales? Sales has most of the weight with the CEO. They just have to say that they can’t meet revenue commitments without this and that. What does product management do? They put as much pressure as they can on engineering to commit to more features within a release.
Nobody is at fault here. It’s just a case of misaligned organizational consequences.
Here’s the poor product manager with a stack of features requested by the North America business unit. They’re already struggling to fit these in. But wait, there’s more.
The product manager spreads the features around to make everyone equally unhappy, resulting in the bloated release, which takes a long time to build and deploy, causing more features to back up, resulting in larger releases…
Engineering is pushed into impossible schedules and take all the blame when they are missed.
Let’s assume we could define increments of software below the release level that can be prioritized on the basis of income generation and cycle time. Higher effort means lower priority. Now stakeholders are competing for engineering bandwidth. Those that can commit to the highest income with the lowest development effort, hence cycle time, rise to the top.
It turns out that Donald Reinertsen, in his landmark book, Product Development Flow, gave us a way to do this prioritization. Consider two projects, each generates income at different rates and has a different cycle time. Is it better to do the project that takes 4 months to develop and generates $10K per month first, or the one that takes 8 months and generates $15K per month?
His book showed that R&D ROI will be maximized when the projects are done WSJF order. In this case, the optimal order is P1 first.
Consider the importance of WSJF. Software can be objectively prioritized on the basis of income and cycle time rather than opinion and politics.
Why isn’t everyone using WSJF? The challenge has been that it was not possible to quantify income below the release level. We want the release to be broken down into smaller increments of business value. How can we determine the Cost of Delay?
We turned the problem on its head. Let’s define an “Investment” as the smallest increment that can produce financial value, hence each has a quantifiable Cost of Delay.
You might be wondering how product management gets sales or operations to commit to income projections. The references tell you how to do it. Basically, given a payback period and an annual sales profile, the required income can be calculated. Any product manager should deprioritize any Investment where sales is not willing to commit to a payback period.
We know that Investments generate income and have Cost of Delay. Prioritization by WSJF ensures that the Investment has the minimum features necessary to achieve the income to gain priority in the backlog. It’s not about feature favorability now. The question is, “Exactly how does that feature increase income. And, can we simplify the existing features to reduce cycle time?” The MMFS appears.
Portfolios can be broken down by P&L centers to distribute responsibility. For example, you might have different P&L centers for North America and Europe.
Investments must be planned to be deployed, because cycle time includes the time to deploy the Investment. Of course, there are times when Investments will have to be bundled into releases. We do the reverse of waterfall planning. We plan increments of value that can be deployed and then only assign them to releases when necessary. We’ll address that in an upcoming slide.
The Investment model causes you to look at your pricing model – pricing based on value instead of bulk release pricing.
Here are examples of Investments. There would be income forecasts for all of them.
Note the term “tactical” because a payback period within three years has been assumed. You can also insert strategic Investments in the backlog with no income. For example, rebrand the UI. But now you recognize that the total investment includes development costs and a quantifiable Net Cost of Delay impact for delaying tactical Investments below it in the backlog.
And I would always question whether strategic Investments should be tactical. What is the financial impact of not rebranding the UI?
This is an example of a set of Investments prioritized by traditional ROI and WSJF. The income increase in each year is just due to the order of development, assuming the same development resources. You can see that income is shifted forward in time, decreasing payback periods and reducing risk.
This is a common refrain. Are you really saying that your customers don’t want to receive value from your software sooner? Of course not. These are the main reasons behind customer reluctance that can be addressed. Cost of Delay calculations can show that investment to address these issues, including software refactoring, pay back quickly.
Planning should not begin with a bundled release assumption. Focus on planning deployable increments and bundle only when necessary. The references at the end will provide guidance, including quantification of the annual income lost by release bundling. There are strategies to release more frequently, even in regulated organizations.
Let’s look at how the Investment model facilitates business predictability, one of the biggest business complaints.
Let’s first ask ourselves why the business needs software predictability?
Of course, we have to acknowledge that the business never had predictability with waterfall development.
This is the refrain I heard from most engineering departments and Agile evangelists. This is a naïve view of business needs.
Of course, they didn’t have predictability with waterfall. This is Steve McConnell’s famous Cone of Uncertainty. It shows …
Accuracy was less than 50% even after requirements were developed. Now the business expected roadmap commitments in Agile where requirements are not done up front.
Consider what the business wants. They want financial predictability. Unfortunately, companies have tried to attain this by producing detailed roadmaps at the feature level.
The business wants financial predictability to support the business plan. But how can we do that in Agile? The Investment approach provides that answer. And we must accept that software estimates will vary as development proceeds.
This is the famous iron triangle that has been around forever and has always proven to be true. It says that you can only fix any two of the vertices and the other must vary. Of course, on a project the resources, or the rate at which resources can be added, are fixed. This means schedule and/or scope have to vary.
Some organizations say the meet all three. When I’ve heard that, it’s because they sacrificed quality. There are a few companies that can achieve all three, but it requires rigorous application of software engineering principles and excellent project management. They are in the 1% percentile.
We want to achieve schedule predictability for the business. That means we need to vary scope. Agile was based on fixed schedule and variable scope. We can time-box Investments and allow teams to vary content to meet the Investment goals.
Specific features schedules are not expected, unless it is a non-discretionary feature where resources will be subtracted from the resource pool.
Let’s use the analogy of landing a plane. The pilot is able to set the plane down within a few hundred feet of their target after a descent from 30,000 feet. How do they do that? It can only be accomplished with feedback from the altimeter and the airspeed indicator and small rapid adjustments.
A major value of Agile is that it provides feedback with much shorter cycles than in waterfall, if we use it.
We have an established financial and schedule target for Investments before development starts. We can time box the Investment based on top-down estimation techniques. We can use weekly feedback to adjust functionality or require a higher income justification to maintain its WSJF priority and financial and schedule targets.
Instead of trying to quash change as we did in waterfall, we adapt to the changes. For example, after a few more months of development, sales wants to add functionality. The first priority is to adjust scope and functionality to include new features to maintain the time box. That may mean dropping some lower value features or simplifying some features without significantly compromising income projections. If not, can additional income be associated with the new feaure to maintain WSJF and also account for the Net Cost of Delay of lower priority features? This becomes a collaborative effort to maintain targets. Either way, in contrast to waterfall, the financial impact of the change must be addressed in the week it is recognized, not at the end of a waterfall release.
The key is that we are not committing to specific features, but to the income and schedule. The business gets the predictability it wants.
The best approach is to create Investment teams, often led by a product manager, and include senior engineers and the product owner. This is the team that can “pilot” an Investment to achieve its financial and schedule targets.
The conclusion is simple. You can stay on target if the financial impacts of changes are addressed immediately. Or, the financial impact must be accepted. The Investment model quantifies financial impacts in terms of Net Cost of Delay.
The product manager doesn’t have to say no to sales. They can demonstrate in many cases that requested changes will actually reduce net income because of Cost of Delay. They will find that in many cases when features have to be added at the last minute to close a deal, the delay costs outweigh the value of the deal. It’s something product managers are aware of, but previously were unable to immediately demonstrates the loss.
Product managers are in control of the roadmap, and changes area allowed when current financial goals can be met or exceeded.
I’ve found that this is the most attractive aspect of the Investment approach for product managers.
We’ve got agility and predictability. How do we ensure that we are producing value. Value here means its something that someone is willing to pay for. It’s not an abstract concept.
We talked about the importance of a product owner who is both business and technical savvy and is engaged with an Agile team throughout development. The reality is that I haven’t seen this mythical character in the large companies I worked with.
This is what I observe.
This changes with the Investment model. The product manager works on what, and the product owner works on how They have separate and complementary roles.
This cartoon has been around since the waterfall days. It shows how far we could get off track with waterfall requirements and design practices. Agile was supposed to fix this by having a product owner and continuous feedback during development. If there actually was an engaged and knowledgeable product owner we could get to the tree swing the customer said they wanted.
However, here’s the problem. As your company was getting the tree swing, your competitor understood stakeholder value. They recognized that the customer didn’t know to ask for this innovative solution.
I see this often in Agile development. Teams are given user functional requests disguised as user stories, prohibiting the innovation potential of Agile.
Achieving the value can be put in the form of an Investment that can generate revenue.
Want to give credit to Tom Gilb, a well-known software industry contributor, for his influence on stakeholder value analysis