Culture Clash: Agile Cadence vs. Business Cadence
•Download as PPTX, PDF•
0 likes•1,590 views
By now, many software Product Managers have encountered Agile development teams and adjusted their daily and weekly schedules to accommodate working with the team or with a Product Owner. But what about annual planning and budgeting? Roadmapping? Business cases? These are areas that touch the business as well as the development teams. Has your organization made the transition to more agile methods for these critical product management processes? If not, you're not gaining the full benefits of Agile software development methods.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Culture Clash: Agile Cadence vs. Business Cadence
Similar to Culture Clash: Agile Cadence vs. Business Cadence (20)
Recently uploaded
Recently uploaded (20)
Culture Clash: Agile Cadence vs. Business Cadence
- 1. PMC March 2015 Culture Clash! Agile Cadence vs. Business Cadence
- 2. © 2014 Pivotal Product Management, LLC Tonight’s Key Take-Aways 2 • How jet fighter tactics apply to your business • How to start shifting attitudes and practices toward business agility • How to synchronize business and development cadence for competitive advantage
- 3. © 2014 Pivotal Product Management, LLC Good News: Agile Development Works! 3
- 4. © 2014 Pivotal Product Management, LLC Bad News: The rest of the organization isn’t so agile. 4 How do you move toward business agility in a world of annual planning?
- 5. © 2014 Pivotal Product Management, LLC Change the Plan vs. Plan for Change 5 Take shots at the annual target vs. execute OODA loops
- 6. © 2014 Pivotal Product Management, LLC OODA Loops? 6 Observe Orient Decide Act Learn more: “Certain to Win” by Chet Richards
- 7. © 2014 Pivotal Product Management, LLC What situations drive the need for agility? 7 Kind of challenge Problem Definition Solution Planning Method Results Technical (Familiar) Understood Proven Conventional Delivering results that are close to what was planned. Adaptive (New) Requires learning Requires learning Adaptive Gaining evidence on which to base subsequent actions and decisions.
- 8. © 2014 Pivotal Product Management, LLC Plan for Change 8 • Annual strategy review with quarterly planning, 5-quarters forward • Use KPIs with percentage improvements instead of fixed goals • Determine best use of discretionary budget
- 9. MANAGING YOUR BACKLOGS © 2014 Pivotal Product Management, LLC 9
- 10. © 2014 Pivotal Product Management, LLC Screen Ideas 10 Product Backlog
- 11. © 2014 Pivotal Product Management, LLC Backlog Prioritization: Weighted Shortest Job First 11 WSJF = User Value + Time Value + RR|OE* Value Job Size * RR|OE: Risk Reduction/Opportunity Enablement
- 12. © 2014 Pivotal Product Management, LLC WSJF Cost of Delay Components 12 • They prefer ‘this’ over ‘that’ • Revenue impact for the business • Penalty potential on the business USER VALUE: Relative value in the eyes of the customer • Is there a fixed deadline (i.e. compliance) • Will customers wait? or move to another solution? • What is the effect on customer satisfaction? TIME VALUE: How user value decays over time • Reduce the risk of this or future delivery • Is there value in the information we will receive? • Enable new business opportunities? RR|OE: What else does this do for our business?
- 13. © 2014 Pivotal Product Management, LLC Backlog with WSJF Scoring 13 Product Backlog WSJF Scoring User Value Time Value RR|OE* Job Size Score Story ID Story Backlog Priority Sprint Release Acceptance Criteria 5 2 8 2 7.5 14 As a <user> I want to <do something> so I can <get benefit>. 1 3 v2.1 5 8 2 5 3 17 As a <user> I want to <do something> so I can <get benefit>. 2 3 v2.1 1 1 1 1 1 22 As a <user> I want to <do something> so I can <get benefit>. 3 3 v2.1 Scale for each parameter: 1, 2, 3, 5, 8, 13, 21 Done one column at a time, start by picking the smallest item and giving it a “1” (There must be at least one “1” in each column!) Job Size is re-estimated for remaining work each time you re-prioritize (ignore sunk costs!) Score=(User Value + Time Value + RR|OE Value)/Job Size Highest number is the highest priority. RR|OE: Risk Reduction/Opportunity Enablement
- 14. © 2014 Pivotal Product Management, LLC MVPs 14
- 15. © 2014 Pivotal Product Management, LLC Approach Business Cases Iteratively: Lean Canvas 15 Hypothesize and test each box
- 16. © 2014 Pivotal Product Management, LLC Kill Aggressively; Ignore Sunk Costs 16 Problem Problem definition Customers & Markets Value Proposition Solution/Prototype Solution definition Unique advantage Channel BusinessValue Key metrics Revenue streams Cost structure ProductionMVP Launch Drive adoption Monitor Customer Satisfaction Operate Enhance Refine metrics Manage life cycle Incremental Funding and Go/No Go Decision Points
- 17. Submit to product council Idea Assign PM Approve Submit business case Opty Analysis Assign dev team Approve Measure Product Planning Cycle Time To verification Design, Build Test To Operations Validation Gain valueLaunch Value Waste Value Waste Efficiency = Total Value/ (Total Value+Total Waste) 17© Pivotal Product Management, LLC
- 18. MANAGING STAKEHOLDER COMMITMENTS © 2014 Pivotal Product Management, LLC 18
- 19. © 2014 Pivotal Product Management, LLC Manage Stakeholder Commitments 19 THIS NOT THIS
- 20. © 2014 Pivotal Product Management, LLC Manage Stakeholder Commitments 20 Q1 Q2 Q3 Q4 Q5 Events, Rhythms Business Objectives/ Themes KeyFeaturesKey Resources, Deliverables & Dependencies COMMITTED LIKELY FORECAST
- 21. © 2014 Pivotal Product Management, LLC In Summary… 21 • Start building flexibility in “adaptive challenge” areas • Use OODA loops annually, quarterly, and as needed • Approach business cases incrementally • Don’t let the lists get too long • Spend wisely Your Questions?
- 22. © 2014 Pivotal Product Management, LLC Want to learn more? 22 • Beyond Budgeting (Hope, Fraser) • Certain To Win (Richards) • Agile Software Requirements (Leffingwell) • Agile Product Management classes – see me!
- 23. © 2014 Pivotal Product Management, LLC Thank You! Lindam@pivotalpm.com Linda Merrick, CPM, ACPM, CSPO, SPC 25+ years experience in software product management AIPMM “Excellence in Product Management Education” award winner Instructor and advisor UW Software Product Management Certificate Program Pivotal Product Management: skills assessment, training, consulting and coaching for greater product success. 23
Editor's Notes
- Thanks for that lovely introduction! Good evening and thanks for joining me tonight. Tonight we want to talk about extending agility beyond your development teams. Some businesses “grew up” as agile organizations. But for some, having Agile development teams represents a major cultural departure!
- So I think that there is now consensus that – at least for some situations – Agile works and works well to deliver faster, and deliver competitive advantage. T: But of course, there’s a ‘bad news’ slide to go along with this…
- In many organizations, that’s proving to be a little frustrating. How many of you are using some flavor of Agile development? Of those, how many have experienced some disruption or change in how the business operates because of your Agile adoption? Good disruption? Bad? Both? Transition: Just as in your Agile development transformation, you need an attitude shift to make it successful.
- Today, nearly every organization goes through some sort of annual planning process. The bigger the organization, the longer it takes to plan. In some organizations, it takes 9-15 months! We’re not talking just about budgets – although the 2 go hand in hand. We make the big plan, and its obsolete how soon? [wait for answers] That plan locks us in – we make specific commitments to shareholders, customers, and stakeholders, and our bosses and MBOs based on the annual plan. Then things change and we have to re-plan, and adjust everyone’s expectations. What if we recognize that things are going to change and shape our processes to leverage that? In Agile, we “plan to re-plan”. In business, we should adopt the same attitude. One way to think about this is OODA loops. T: What’s an OODA loop?
- You observe the environment around you – a strategic analysis, if you will. You orient yourself in that environment – what do your observations mean? Where should you face next? What resources do you have? You decide to do something to achieve a specific result. You shape a hypothesis. You act to test that hypothesis, Then you observe the changes in the environment and repeat the loop. OODA loops are the way John Boyd articulated the success principles of “maneuver warfare” – used by fighter pilots in the Korean and Vietnam wars, and by the Germans in WW2. Chet Richards adapted his principles to business in a book called “Certain to Win”. We all do one big OODA loop in Annual Planning. What if we did it more frequently? Aha – this is the key to winning in war as well as business. The faster you can execute OODA loops, the more advantage you have. This is the only way to survive in fast-changing environments. This is the essence of Agility! T: But let’s stop and think for a moment. This could be a big change for your business if you implement it wholesale. Let’s think for a moment about the situations that it might be most important to apply this type of agility.
- The problems that we try to solve can be viewed as one of two types: Technical – or Familiar, And Adaptive – or New. When we’re faced with a new challenge, we don’t fully understand the problem yet, and so we don’t instantly identify the solution. We can’t use traditional planning methods; we have to use learning cycles. Competitive markets demand flexibility. If you’re a younger organization in a fast changing market, perhaps few of your problems will be in the “familiar” category – what’s being called “keep the lights on”. But for more established organizations, a big portion of the plan is devoted to keeping the existing business running. Any challenge that you place in the “New” category needs an adaptive process (like Agile) to help it plan and execute. Like OODA loops. Both types of challenges can benefit from some level of adaptive planning, but new challenges demand it. (Getty example) Transition: So by looking at our current planning efforts this way, we can see where we need more flexibility. How do we execute on this? Reference: Ronald Heifetz, HBR and other works on org change.
- To implement that flexibility, we put more frequent emphasis on Observe and Orient activities. We do an annual scan, but we also do quarterly scans and use that information in planning for the next few quarters. We shape experiments and execute them. Repeating the OODA loop more frequently AND having the ability to ACT on the results via our spiffy new Agile development teams? NOW we can move ahead of the competition! T: One of the biggest obstacles to adopting this new way of operating is the big backlog of “stuff we already had planned”. Let’s look at how to deal with the “baggage”
- We need to review the stuff already in the enhancement lists and remove as many items as we can. The first screen is “is it still on strategy?”. This applies both inside your organization and externally. Even those things that you committed to customers may no longer be on THEIR strategy, so it’s always good to review! The next screen is financial. If this is big effort, it should probably go through a light-weight business case process. We’ll look at that in a moment. But smaller items should go directly to the product backlogs so they can be prioritized by product leaders. T: let’s look at an effective technique for prioritizing the items in the lists – any list, really.
- The key to growing our businesses is delivering as much value-producing software as quickly as possible. There’s a technique that takes both of those factors into account: Weighted shortest job first. WSJF is a relative ranking method that takes into account the user or business value, time constraints, risk, and opportunity cost. WSJF refers to the top line of the equation as “cost of delay”, although there are other ‘cost of delay’ methods that are more quantitative, like COD3. So the idea is to find the items in your backlogs that deliver the highest value with in the shortest time – which generally also means the lowest cost. Transition: Let’s look at each of the top values in WSJF a little closer.
- [Review 3 sections] Transition: now let’s see how the ranking process works.
- If you’re familiar with planning poker, then doing WSJF estimating will be really easy for you. [go over the bullets and point to examples in the spreadsheet] The idea is that you will re-prioritize the backlog that you own on your main cadence: - PO (with your input) will re-prioritize release backlog between sprints PM will re-prioritize product backlog between releases Note that when you re-prioritize partially-done items in the backlog, you RE-ESTIMATE the remaining work, ignoring all sunk costs and value already received. This allows us to say “stop” to projects that should stop, either because the case for continuing isn’t as good (with most of the value already delivered) or because they’re not doing as well as we thought. These projects/features will simply not make the cut. Transition: The final too to help shorten the lists is to determine the minimum viable product.
- Whatever you’re thinking you MUST have for release, reality is probably smaller. Part of the beauty of seeing working software every few weeks is actually experiencing what is “good enough” and knowing you can come back later – based on REAL user feedback – and quickly get more! Transition: And “minimum viable” applies not only to products, but also to business cases.
- One of the time-honored traditions of annual planning is to prepare business cases for each major new initiative. We spend weeks on each, carefully constructing a tower of assumptions that “prove” our concept is best. Some of them get approved and incorporated into the next annual plan. Lean Canvas or Business Canvas take a more adaptive approach. Rather than build a plan up-front, we build the plan iteratively and test our assumptions in the real world as we go. There are lots of formats for business cases out there, Here’s a recent model that I find very impactful for helping people think through the elements of an initiative. Lean Canvas is derived from the Business Canvas, which is also a great model. But for applications or initiatives, I prefer Lean Canvas. You print this in poster size and post it in a visible place. Have you ever had anyone question how long it takes to pull together business case? This makes the work visible. You write down your hypotheses and check them off once you have research to support them. You can start a Lean Canvas any time during the year, and in fact you should. Why wait? Progress is evaluated at least quarterly. Funding comes from that smaller “discretionary” slice of the budget. Transition: Here’s how the approval process works.
- Lean canvas takes you through the first 3 boxes. [go over the contents of the first 3 boxes] The triangles indicate review and funding points. At each review/funding point, the decision makers can continue funding to move forward, continue limited funding to find a pivot point, or discontinue funding and close the initiative. We recommend portfolio review monthly in dynamic situations. Transition: The final step in adopting these new processes is to apply continuous improvement to the process. To do that, you need to measure how well it’s going.
- Value Stream Analysis helps us spot opportunities for improvement and quantify that improvement. Here’s a typical process for new products or major enhancements in most software organizations. To do a value stream analysis, simply map out your activities and decision points. Then, determine the typical time each of those steps takes. You’ll look at two different types of time: time that actually adds value to the process, and time that doesn’t add value (waste). What do you think the primary type of waste is? (wait time). Note that by just reducing the wait time between steps, you’ll improve your efficiency rate. This is the wisdom behind small batches. Transition: So, as with every change in an organization, there are expectations to manage.
- And here’s the most effective method I’ve seen for working with business stakeholders.
- This, again is an attitude shift. We move people from the ‘kid in a candy store’ mentality, where they ask for everything, to what I call a “spend wisely” mode of operating. The truth is, as product managers, we don’t get to totally own the prioritization of our backlogs. Sales has a say, architects have a say, Tech Support and Marketing and BizDev have input for you too. Part of this attitude shift is to help stakeholders understand that there will be another “bus”, or planning opportunity, shortly. At that point they can see what’s been done – both from a development side and a business/market side - and change their minds about priority if they want. It’s your job to remind them of the value of the current trajectory, but if they want to change, they can! One reason that we WANT business agility is so we’re not locked in to a plan that no longer makes sense! This applies to Development, too. How often have you heard “we’re tired of being jerked around”? If everyone agrees that there may be bigger priority shifts at the quarterly boundary, then the shifts are not unexpected. I’ve witnessed this change first-hand. When stakeholders can see the progress in the form of working software, and when they can see their feedback incorporated, the ‘wishful thinking’ and gold-plating just evaporates. The game-playing stops when reality is so satisfying. T: That said, they still want to know when things are going to be “done”.
- So you’ll still need to prepare roadmaps, for the same 5 quarters as you’re looking forward in your planning cycle. Your release plan should contain committed features and stretch goals. Once your stakeholders experience the value of being agile, they will understand the value of being able to modify the forecast according to the current Observations and Orientation. T: So let’s wrap up.
- If you’d like to learn more about the topics in this talk…
- Here are some resources for you. And one last item:
- © 2014 Pivotal Product Management, LLC www.pivotalpm.com Do not reproduce.
- Note that three of the boxes change Transition: If you’d like to learn more …
- Transition: Here’s how I recommend teams approach getting the answers into the boxes.
- The numbers indicate my approach to working the issues. 1, 2, and 3 – problem and position - first. Then 4, 5, and 6. Last, we fill in the metrics, revenue, and costs – 7, 8, and 9. Transition: And between each group of boxes, the teams present their results and ask for funding the next phase.