Unlocking Agile's Missed Potential
Denunciar
AggregageSeguir
29 de Mar de 2022•0 gostou•142 visualizações
Unlocking Agile's Missed Potential
29 de Mar de 2022•0 gostou•142 visualizações
Baixar para ler offline
Denunciar
Tecnologia
In this webinar you will learn how product management and engineering can collaborate with a NEW end-to-end Agile product development cycle model.
AggregageSeguir
Recomendados
Lean Portfolio Strategy Part 4: Picking the Right Tool for the JobCprime
Lean Development Practices for Enterprise AgileTechWell
From Project to Product: Let's Talk FundingCprime
Lean Portfolio Strategy Part 3: Epic Management - Take the ExitsCprime
English digital business 2.1.pptxJuanjo MARTINEZ PAGAN
Lean Portfolio Management DevOps Helsinki Contribyte
Mais conteúdo relacionado
Mais procurados
Portfolio prioritization with lean canvas and value game for PMI Buffalo NY C...Mike Caspar
Project portfolio management in an Lean Agile World – Rami KaramAgile Tour Beirut
The Foundations of Business Agilityshastie
Portfolio management lean canvasBrad Swanson
Lean Portfolio - A.Mckew (FINAL)Andrew Mckew
The Lean Agile PortfolioTechWell
Similar a Unlocking Agile's Missed Potential
Cynoteck - Salesforce Presentation - Consulting ServicesRosa Aguiar Catraio
DevOps for Enterprise Systems : Innovate like a StartupDevOps for Enterprise Systems
thinkLA AdU: Digital Production 101thinkLA
Big Data ExpertiseTO THE NEW | Technology
Why Value Stream is key to Digital Product Delivery Mani Maun
Guiding a Product Roadmap in a Chaotic WorldEric de Jager
Mais de Aggregage
Banking on Loyalty: Holistic Financial Advice for Unparalleled Business GrowthAggregage
Keep the Competitive Edge and Reduce ChurnAggregage
Mastering Supply Chain Sustainability: Where Does ESG Fit In?Aggregage
From Complexity to Clarity: Strategies for Effective Compliance and Security ...Aggregage
Is Training the Right Solution?Aggregage
How to Create Unique Customer Journeys to Optimize Business OutcomesAggregage
Último
Optimizing Your Supply Chain with Neo4jNeo4j
GDSC ZHCET Google Study Jams 23.pdfAbhishekSingh313342
Omada Pitch Decksjcobrien
Solving today’s Traffic Problems with Sustainable Ride Hailing SolutionOn Demand Clone
Lesson 1 - Algorithm and Flowcharting.pdfROWELL MARQUINA
RemeOs science and clinical data 20230926_PViv2 (4).pptxPetrusViitanen1
Unlocking Agile's Missed Potential
- 1. March 29, 2022 11:00 am PDT; 2:00 pm EDT; 7:00 pm GMT Unlocking Agile's Missed Potential ! Bob Webber VP Product Flow Optimization, Construx Rayvonne Carter Webinar Coordinator Residential Realty Today CTO Universe 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. --OR-- CTO Universe Expert Insights. Personalized For You.
- 4. Unlocking Agile's Missed Potential ! Bob Webber VP Product Flow Optimization, Construx CTO Universe Expert Insights. Personalized For You.
- 5. Agile Predictability Agility Value • Why did Agile miss business expectations? • How can we meet them? Business Expectations
- 6. Agile Reduced schedule pressure Build it right Engineering Expectations Technical value-add
- 7. Construx Software Leadership Summit Agile in our organization: 1. Met expectations 2. No better than before 3. Worse than before Only 14% met expectations
- 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 process changes
- 10. Vision Competitive analysis Strategy Market research Product Manager Ideal Agile Product backlog Epics and User Stories Development Daily Scrum Sprint backlog User feedback Engaged Product Owner
- 11. Development Daily Scrum Sprint backlog Feature backlog Agile Reality Schedule Pressure Release
- 12. The Agile you read about • Single team • Dedicated product owner • Domain familiarity • Talented engineers • New product Waterfall Planning
- 13. The rest of you • Waterfall planning • Product management • Project management • Legacy software • Multiple teams • Large releases • Feature pressure • Complicated deployments • Diverse users • Regulated industries
- 14. Agile scaling frameworks • Institutionalized large release planning • SAFe “Release Train Engineer” • Feature-driven
- 15. Agility
- 16. Why does waterfall planning persist? Business plan Multiyear sales and expense commitments What will I have to sell and when? Investor Expectations
- 17. MMFS! A cry in the wilderness
- 20. Achieving the MMFS • Prioritize software increments with higher income and shorter cycle times Priority = Rate of income generation Cycle time Effort Priority
- 21. WSJF = Cost of Delay Cycle Time Weighted Shortest Job First ? 1.9 2.5 > $10K/month 4 months P1 $15K/month 8 months P2
- 22. How do we calculate Cost of Delay? “Software Investment” The smallest increment of functionality that can increase revenue or reduce operational expenses Investments have CoD by definition
- 24. Tactical Investment examples New Sales • Interactive dashboards to reduce customer operational costs by 10% to increase annual revenue by 5% over the next three years Defense • EU competitive features to prevent market loss of 20% over three years Expense Reductions • Multi-tenant capability to reduce annual hosting costs by 15% Refactoring • Deployment simplification to reduce backlog Net Cost of Delay by $1M in the next three years
- 25. Example
- 26. SAFe “WSJF” Business value + Time criticality + Risk reduction Estimated size
- 27. “Our customers won’t accept releases more frequently” • Poor quality • Irrelevant features • Impact to operations • Validation You need to solve these to become an agile organization
- 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 three years” • Don’t plan release trains – eliminate them! • Increased income from cycle time reduction can be reinvested
- 29. Predictability
- 30. Predictability • Why does the business need predictability? • Why was predictability low with waterfall development? • How can we provide predictability in Agile?
- 31. “The business just needs to be more agile” Agile didn't address business predictability needs
- 32. We were never predictable The business cares about financial predictability not software estimation accuracy 0.67x 0.8x 1.0x 0.5x 0.25x 2x 4x 1.5x 1.25x Effort Agile schedule commitment? Definition Approval Require- ments Product Design Detailed Design Product Complete Steve McConnell, Code Complete, 1993
- 34. Rapid feedback and control Landing an aircraft
- 35. Development Cycle Reduce functionality or increase forecast Added functionality or reduced forecast Income Forecast Burndown “Landing a software Investment” $ Maintain WSJF
- 36. Investment “Product Teams” • Shared goals • Financial • Schedule • Collaboration • Innovation
- 37. Predictability Summary • Investment teams achieve predictability by managing WSJF • Investment teams share schedule and financial goals • “Product teams” • Collaboration • Innovation
- 38. Value
- 39. The Mythical Product Owner • Product managers with no time • Former business analysts with limited access to customers and market • Diverse product stakeholders requiring requirements elicitation • Product manager overlap Either way, no time to implement feedback!
- 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 Stakeholder value: “I want to relax outside” Investment: “Build a device that customers rate 8 out of 10 or better in terms of relaxation" Stakeholder Value
- 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
- 44. Q&A VP Product Flow Optimization, Construx Bob Webber /in/rcwebber/ Webinar Coordinator, Residential Realty Today Rayvonne Carter /in/rayvonnecarter/ CTOUniverse.com
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