Suzanne Nottage (CA Technologies Ltd)
•
1 like•446 views
How Agile Improves Decision Making and Innovation
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Suzanne Nottage (CA Technologies Ltd)
Similar to Suzanne Nottage (CA Technologies Ltd) (20)
More from AgileNZ Conference
More from AgileNZ Conference (20)
Recently uploaded
Recently uploaded (20)
Suzanne Nottage (CA Technologies Ltd)
- 1. Decisions-in-progress and 20,000 reasons why you should care Suzanne Nottage 30 November 2016
- 2. 2 © 2015 CA. ALL RIGHTS RESERVED. Why are we here? Hands up
- 3. 3 © 2015 CA. ALL RIGHTS RESERVED. Agenda Source:http://www.themotherco.com/wp-content/uploads/2012/05/Frustration_2.0-881x499.jpg “What’s the problem?” “How does Agile / Scrum / Lean help us make better decisions?” “How do we get our teams to make better decisions?”
- 4. 4 © 2015 CA. ALL RIGHTS RESERVED. “Organisations are decision-making factories” Source: http://cdn.wonderfulengineering.com/wp-content/uploads/2013/11/factory-wallpaper-2-798x350.jpg
- 5. 5 © 2015 CA. ALL RIGHTS RESERVED. We often decide by “thin slicing”, which is good but bad Source: likes, dislikes unconscious biases stereotyping prejudices
- 6. 6 © 2015 CA. ALL RIGHTS RESERVED. Our decision-making process is sometimes “corrupted” Source: http://www.vectorfreebie.com/wp-content/uploads/2016/01/Heart-Sketch.png http://4.bp.blogspot.com/-GXOy6NJ7Pmk/TwoN39V7yfI/AAAAAAAAEGI/HtWJh3STDPQ/s1600/operahousesketchbydavidjack.jpg Hamilton Lower Hutt Palmerston N Tauranga Christchurch London Wellington Dunedin Hobart Auckland
- 7. 7 © 2015 CA. ALL RIGHTS RESERVED. The first step is admitting you have a problem Source:
- 8. 8 © 2015 CA. ALL RIGHTS RESERVED. Decisions-in-progress (DIP) are like work-in-progress (WIP) Source: http://www.domusweb.it/content/dam/domusweb/en/news/2015/06/08/carsten_holler_decision/domus-01-holler-decision.jpg
- 9. 9 © 2015 CA. ALL RIGHTS RESERVED. Low DIP means high flow (throughput) Source: https://static-secure.guim.co.uk/sys-images/Guardian/Pix/pictures/2009/11/2/1257167787984/1960-A-car-turns-off-the--016.jpg
- 10. 10 © 2015 CA. ALL RIGHTS RESERVED. Source: http://s3.scoopwhoop.com/anj/No_cars/618340655.jpg High DIP leads to low flow of decisions (throughput)
- 11. 11 © 2015 CA. ALL RIGHTS RESERVED. High DIP leads to bottlenecks and compounding delays Source: https://campustocareer.files.wordpress.com/2011/04/flight-delayed.jpg
- 12. 12 © 2015 CA. ALL RIGHTS RESERVED. Unplanned work & decisions kill flow & eat up capacity Source: http://www.tragic-christian.org/.a/6a00d83455629c69e2017ee3bf0b88970d-pi
- 13. 13 © 2015 CA. ALL RIGHTS RESERVED. Unplanned work increases decisions & reduces thru’put Source: 32 21 4 18 0% 20% 40% 60% 80% 100% Sprint 1 Sprint 2 Sprint 3 Planned cards delivered Unplanned cards delivered
- 14. 14 © 2015 CA. ALL RIGHTS RESERVED. Smaller batches make decisions more frequently Source: http://www.businesstraveller.com/files/News-images/Qantas/Qantas-A380-780.jpg, http://www.moneymorning.com.au/wp- content/uploads/2014/06/qantas-plane-flight.jpg
- 15. 15 © 2015 CA. ALL RIGHTS RESERVED. Steady flow of decisions improves stability & predictability Source:https://media.apnarm.net.au/img/media/images/2015/04/19/SCN_20-04- 2015_EGN_04_SCN190415TRAFFIC02%20fade_fct1024x768x420.0_ct620x465.jpg
- 16. 16 © 2015 CA. ALL RIGHTS RESERVED. Are your decisions flowing or stop:start? Source: 0 50 100 150 200 250 300 350 400 4/14/15 4/21/15 4/28/15 5/5/15 5/12/15 5/19/15 5/26/15 6/2/15 6/9/15 6/16/15 6/23/15 6/30/15 7/7/15 All Trains - Features CFD – Release 3 Done In Progress To Do 0 500 1000 1500 2000 2500 3000 3500 4/7/15 4/14/15 4/21/15 4/28/15 5/5/15 5/12/15 5/19/15 5/26/15 6/2/15 6/9/15 6/16/15 6/23/15 6/30/15 All Trains - Story Count CFD – Release 3 Done Ready To Validate In Progress To Do Blocked
- 17. 18 © 2015 CA. ALL RIGHTS RESERVED. “As sober irrational as a judge?” Source: http://www.economist.com/node/18557594
- 18. 19 © 2015 CA. ALL RIGHTS RESERVED. Takeaway action Source: Action: Map a (simple) process & identify the cycle time for decisions Why? Delays represent a significant ‘waste’ in many processes Metric: Lead time (from idea to customer)
- 19. 20 © 2015 CA. ALL RIGHTS RESERVED. Problem: “We have too many decisions to make” Source: https://upload.wikimedia.org/wikipedia/commons/1/10/Florida_Gopher_Tortoise.jpg
- 20. 21 © 2015 CA. ALL RIGHTS RESERVED. “Established & well-known decision-making framework” Source:
- 21. 22 © 2015 CA. ALL RIGHTS RESERVED. SECAR: Simplify, Eliminate, Combine, Automate, Relocate Source: http://www.portalsoin.com.br/wp-content/uploads/2010/11/secar_premium_02.jpg
- 22. 23 © 2015 CA. ALL RIGHTS RESERVED. Simplify: Kanban boards: WIP limits & lane definitions Source: Picture courtesy of client
- 23. 24 © 2015 CA. ALL RIGHTS RESERVED. Standardise: consistent user story format Source: http://www.romanpichler.com/wp-content/uploads/2013/03/ConstraintStory.jpg
- 24. 25 © 2015 CA. ALL RIGHTS RESERVED. Simplify: standardise decisions, where possible Source:
- 25. 26 © 2015 CA. ALL RIGHTS RESERVED. Eliminate: 3 types of decisions (and work) Source: http://influitive.com/wp-content/uploads/three-pie-chart.jpg necessary non-value add value add non value-add runners repeaters rarities
- 26. 27 © 2015 CA. ALL RIGHTS RESERVED. Roughly right vs. analysis paralysis Source: http://img.timeinc.net/time/magazine/archive/covers/1965/1101651231_400.jpg
- 27. 28 © 2015 CA. ALL RIGHTS RESERVED. Short decision-making lead time reduces Cost of Delay Source: http://i2.wp.com/blackswanfarming.com/wp-content/uploads/2014/03/short-horizon-reduced-peak-urgency-curve.png
- 28. 29 © 2015 CA. ALL RIGHTS RESERVED. Type 1 vs. Type 2 thinking (and decisions) Source: http://footage.framepool.com/shotimg/152416915-dimple-upward-inspiration-concept-undershirt.jpg optimism bias anchoring effect loss aversion sunk cost
- 29. 30 © 2015 CA. ALL RIGHTS RESERVED. Prioritise epics/features relatively: value, urgency, size Source:http://www.agileadvice.com/wp-content/uploads/2013/07/The-Bucket-System-600x176.png
- 30. 31 © 2015 CA. ALL RIGHTS RESERVED. Prioritise using an economic framework Source: Use Weighted Shortest Job First (WSJF) Relatively compare features: cost of delay ÷ job size Prioritise delivery based on highest WSJF (common sense check) User/Business Value + Urgency + RR/OE* Value Job Size WSJF = *RR/OE = Risk reduction / opportunity enablement
- 31. 32 © 2015 CA. ALL RIGHTS RESERVED. Automate (+ a common sense check) Source: Minimise time spent deciding “no brainers” Each column must have at least one “1”. You may use numbers more than once. Use the standard story point values: 1, 2, 3, 5, 8, 13, 20. Feature User / Business Value Urgency RR/OE Value Cost of Delay Job Size WSJF Implement 24/7 processing 13 8 8 29 3 9.6 Accept payments in USD 1 1 2 4 1 4 Self-service by providers 3 1 2 6 2 3 Single sign-on 1 1 1 3 2 1.5 Payment via PayPal 8 3 13 22 2 11 + + = =÷
- 32. 33 © 2015 CA. ALL RIGHTS RESERVED. Combine: Big Room Planning – the secret sauce Source: www.rallydev.com 20,000 decisions ~500 people 2 days
- 33. 34 © 2015 CA. ALL RIGHTS RESERVED. An Agile platform for portfolio-level decision making Source:
- 34. 35 © 2015 CA. ALL RIGHTS RESERVED. Automate: “I’m trying to pare down decisions” - Obama Source: http://media.nbcchicago.com/images/1200*900/obama+suit-640.jpg https://cdn1.vox-cdn.com/thumbor/4mFlTD8G3WLITcvNILqIjxvLGTo=/0x40:2038x1399/1280x854/cdn0.vox- “I don’t want to make decisions about what I’m eating or wearing. Because I have too many other decisions to make.”
- 35. 36 © 2015 CA. ALL RIGHTS RESERVED. Relocate: Centralised vs. de-centralised Source: https://upload.wikimedia.org/wikipedia/commons/a/a4/Parliament_House,_Canberra,_Pano_jjron_25.9.2008-edit1.jpg economies of scale infrequent not time critical need local input frequent time critical
- 36. 37 © 2015 CA. ALL RIGHTS RESERVED. Why? Free up non value-adding time for innovation Source: Provided courtesy of friend
- 37. 38 © 2015 CA. ALL RIGHTS RESERVED. Avoid context switching: let the teams focus on their work Source: http://images.veer.com/stock-photos/do-not-multitask-sticky-note-10566717.jpg
- 38. 39 © 2015 CA. ALL RIGHTS RESERVED. Activity: context switching is costly and error prone Source: Workstream 1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Workstream 2: Place beginning with the following letters: (e.g. Alaska, balcony) A, b, c, d, e, f, g, h, I, j Workstream 3: Clap 1x, clap 2x, clap 3x, clap 4x, clap 5x, clap 6x, clap 7x, clap 8x, clap 9x, clap 10x.
- 39. 40 © 2015 CA. ALL RIGHTS RESERVED. Further ‘reading’ – decision-making dysfunction Source:https://upload.wikimedia.org/wikipedia/en/f/fe/Eye_in_the_Sky_2015_film_poster.jpg
- 40. 41 © 2015 CA. ALL RIGHTS RESERVED. Create a high-performing team Source:
- 41. 42 © 2015 CA. ALL RIGHTS RESERVED. Takeaway action Source: Action: Use SECAR on decision-making activities Why? Reduce cost of delay, prioritise objectively, bias towards smaller / higher value work Metric: Capacity of system to deliver (story points per Release)
- 42. 43 © 2015 CA. ALL RIGHTS RESERVED. Problem “How can our teams make better decisions?” Source: http://www.valeofglamorgan.gov.uk/Images/Unsorted/library-2/diversegroup.jpg
- 43. 44 © 2015 CA. ALL RIGHTS RESERVED. Create cognitively diverse teams Source:
- 44. 45 © 2015 CA. ALL RIGHTS RESERVED. “[Cognitively] diverse teams make better decisions” Source: https://jerue.org/wp-content/uploads/2016/01/Rey-In-Star-Wars.jpg “A person’s value depends on her ability to improve the collective decision.” – Juliet Bourke
- 45. 46 © 2015 CA. ALL RIGHTS RESERVED. What makes teams ‘smart’? Source: http://cdn.newsapi.com.au/image/v1/ff160db409c27975a834e88f6e4e64d2?width=650 communication equal participation emotion-reading
- 46. 47 © 2015 CA. ALL RIGHTS RESERVED. Innovation behaviours Source: http://jilltoyoshiba.com/wp-content/uploads/2013/04/wGreenSlide.jpg everyone is heard safe to propose new ideas decision-making authority share credit give actionable feedback implement team’s feedback
- 47. 48 © 2015 CA. ALL RIGHTS RESERVED. 6 lenses of problem solving & diverse teams Source: http://cdn.meaningfullife.org/wp-content/uploads/2014/10/looking-through-a-lens.jpg evidence options outcomes risk people process
- 48. 49 © 2015 CA. ALL RIGHTS RESERVED. Takeaway action Source: Action: Build long-lived, cross-functional teams around ability and cognitive diversity Why? Improved decision-making, productivity and innovation Metric: Team size, lead time, WIP
- 49. 50 © 2015 CA. ALL RIGHTS RESERVED. Thank you & questions Source: http://heartsconverse.com/wp-content/uploads/2012/04/Black-woman-thinking.jpg
- 50. 51 © 2015 CA. ALL RIGHTS RESERVED. ROTI – return on time invested (this session) Source: http://blogs.adobe.com/agile/files/2013/12/hands-counting.jpg https://s-media-cache-ak0.pinimg.com/736x/4e/5c/f7/4e5cf7d4ccb9c59b6620a9c71944d51e.jpg https://dq9ucdqjq6nrk.cloudfront.net/wp-content/uploads/2014/02/01_sad_emoticon-300x269.jpg https://s-media-cache-ak0.pinimg.com/736x/e9/9b/54/e99b541789969921ebd0110309a35f63.jpg
- 51. Senior Principal Transformation Consultant Suzanne.nottage@ca.com Suzanne Nottage Suzanne.Nottage Suzanne Nottage
Editor's Notes
- Today we will quantify and address the problem with decisions, decisions-in-progress (DIP) and decision-making. And how Agile principles and practices lead to more effective decision-making, meaning more productive teams, better business outcomes and more innovation.
- Let’s get to know each other. Why are we here? Explorer – sailing into new waters, want to pick up everything you can and return with treasure to use in your home organisation Shopper – walk down the aisles and put ‘some’ things in your trolley Vacationer – happy to have a day off work, and it’s fully catered! Prisoner – don’t want to be here: boss sent me or I have other things I need to be doing.
- As humans we have flaws around the way we make decisions. And, in the workplace we often have too many decisions. Agile and Lean have many principles and practices that facilitate effective decision making, leading to more productive teams and more time for innovation. And, we can build our teams around cognitive diversity to improve decision-making and improve innovation.
- There are around 2 million people employed in New Zealand. How many decisions are 2 million people making daily? 10? More? That’s at least 20 million new decisions floating around workplaces every day or ~4.5 billion per year. How many of us have had training in decision-making? Like communication and conflict management, etc. it’s often one of those things we just do, learn on the job. When decision-making goes well, companies are more productive and more innovated. If we’re not making decisions well, we’re less likely to be productive and innovative. Makes sense? The problem is, as humans, there’s some problems with how we make decisions, particularly in traditional project delivery environments.
- This is like “first impressions” or “gut feel” or “sixth sense” or “intuition”. Sometimes we don’t even know how we made the decision – it’s a “locked door.” Thin slicing is sometimes really useful – e.g. in an emergency and in fast sport situations. But it has its limitations…we are often swayed by our likes/dislikes, by stereotypes, by prejudices and by unconscious bias.
- Confirmation bias – we search for, favour or recall things that match our preconceptions Prejudice – Lower Hutt 1327mm, Wellington 1215mm, Auckland 1211mm, Tauranga 1177mm, Hamilton 1108mm, Palmerston North 920mm, Dunedin 726mm, Christchurch 618mm, London 594mm. http://www.geonames.org/NZ/largest-cities-in-new-zealand.html https://www.currentresults.com/Weather/Australia/Cities/precipitation-annual-average.php Planning fallacy / optimism bias: Sydney Harbour Bridge expected to be completed in 1963, costing $7m. Scaled down version opened in 1973 costing $102m. (D Kahneman) In the UK, more women than men have died from heart attacks since 1984. http://ukhealthcare.uky.edu/Women-and-heart-attacks/
- When we are making decisions, let’s first admit that we have these biases, and even knowing that we have these biases doesn’t stop us from having biases. And, our problem is that we can’t really see decisions – they’re invisible. And, it’s hard to work on invisible problems. So, what if we found a way to visualise our problem? What if we treated decisions-in-progress like work-in-progress?
- DIP is like WIP. DIP is invisible in many organisations but too much DIP is an expensive problem to have. So, let’s visualise it with some metaphors.
- Who drove to work on a road like this today? It’s great if we have one decision flowing through the system. However, when we have a handful – or dozens – of decisions, and our people split across multiple projects, and these projects are different shapes, sizes and lengths, well, it doesn’t work so well. And our organisations focus on maximising items in progress (be it DIP or WIP), rather than optimising. What happens when we maximise the number of cars on the road?
- Let’s visualise a real world example. Who drove to work on a road like this? It’s “busy.” Here we have many different types and sizes of work. We have overlapping workflows. We don’t have signals or agreed ways of working We have very large and very small work packages: pedestrians, cyclists, tricycles, tuk tuks, cars, vans and a bus. Oh, and who is going to get through more quickly, the motorcycles or the bus? Right, small packages flow more quickly than large packages. Now, when you’re about to drive on the roads and you hear it’s “busy” you know that translates into longer journey times, more unpredictability / variation in your journey time or route, more chance of accidents – and one delay or bottleneck can have a knock on effect on the whole system. And, that’s because the system is operating at maximum capacity, not optimum capacity. When I go to companies, most people tell me they are “busy” and see it as a good thing. Busy means productive, busy means I’m adding value. But, does it? Are you busy *doing* or busy *finishing*? If you’re “busy”, I’ll ask a couple of questions to find out more. Do you have lots of DIP? When are you due to finish the next thing you’re working on? Because lots of DIP is going to slow your throughput (your flow of work) – like, *really* slow it down. And that will cause delays.
- In a traditional SDLC we split people across multiple projects, we don’t have a view of the capacity of the system, we push rather than pull work through the system. This causes bottlenecks and delays. And one delay can have a knock on effect across the whole system. Just like flying – if there’s fog in the morning, sometimes the system can’t catch up over the rest of the day because we are operating at maximum capacity, not optimum capacity. It also promotes a “hero culture” – we can become reliant on single individuals to go “above and beyond” to “save” the situation. In theory that sounds good but it’s not sustainable in the long run. So, enough about the problems, what about solutions?
- Unplanned work comes in many forms and is often invisible or an attack by stealth on the capacity of the system. For example, “urgent” work, scope creep, initiatives (that aren’t tracked via standard governance nor run via the SDLC), defects and some BAU work. We need to firstly visualise it and secondly have standard ways to deal with it.
- This is what unplanned work can look like. This team was attacked on two fronts. Externally, they were required to “drop tools” and fix defects (1/2 a day to ½ a week) mid-sprint. Secondly, they were all secretly taking on unplanned work from colleagues in other teams. This means that up to 50% of their capacity (some sprints) was spent on unplanned work. No wonder the planned work was not flowing across their board! The team had an amnesty and started visualising *all* work, but identified unplanned work with pink cards (they hated pink!). Sure enough, they could see the size of the problem and then start addressing the problem. Also, the unplanned work tended to be less well understood and twice as large as the planned work – a double whammy for flow. The unplanned work led to lots of DIP – should we take the work into this sprint, it’s not well understood so what does the customer really need, what planned work to we ‘bump’ out of this sprint, etc. Then they identified standard ways for handling the unplanned work requests. For example, was the unplanned work *really* urgent or could it wait a few days (till the next sprint)? If it is really urgent, what is the smallest thing that we can do *now* for the customer? The team also had a problem with its backlog. On the back of a moveable whiteboard they had 100-150 index cards of work from customers – some was several months old. They used the “sunlight method” to decide how to prioritize it. When the writing on the cards had faded to no longer make it readable they de-prioritized that work. They didn’t throw the card away – they put it in a drawer “just in case” they had time to deliver it one day. Given the team was in the UK, it took a long time for cards to fade!
- Here is our final ‘problem’ and also our first solution. Often we have big batches of decisions in IT – change used to be more expensive and harder than it is today! (Not that I’m saying it’s cheap and easy now!) For example, a single requirements gathering phase at the start of a project. Larger batches of decisions mean longer feedback cycles, longer lead time, introduce delays as a ‘waste’ and more variation. More variation means we are more likely to deliver late (and later than a small batch). For example, at a previous company, small projects that were late tended to be 1-2 months late. Large projects that were late tended to be 5-12 months late. Smaller batches reduce variation and deliver more frequently to customers. For example, we *could* use an Airbus A380 to fly a few times per day between SYD – MEL but our customers would prefer more frequent flights (even if there is a price trade off). And, if one small plane is delayed it affects fewer passengers than a big plane being delayed.
- If we start following Agile / Lean practices, if we have smaller batches, if we focus on finishing, if we pull and don’t push… we get stability and predictability.
- This is a tale of two cities, so to speak. This is a CFD, a cumulative flow diagram, showing work flowing through the system. If you haven’t seen one before, the key word is flow. The teams on the left used Agile principles and practices to reduce batch sizes of decisions and standardise decisions, and they minimised their DIP and optimised their flow. The teams on the right didn’t visualise their work or decisions, didn’t limit their DIP and took in more work and decisions during this period in the illusion that being « busy » was the same as being productive. It’s not, and the value they delivered to customers suffered. Same company, same time period, very different results.
- Dan Ariely – no matter how much experience we have, we make irrational decisions in high emotion situations, this includes hunger, tiredness or frustration. How many of us make decisions under emotional stress? Yeah, like every day! How about a real world example?
- A paper in the Proceedings of the National Academy of Sciences describes how Shai Danziger of Ben-Gurion University of the Negev and his colleagues followed eight Israeli judges for ten months as they ruled on over 1,000 applications made by prisoners to parole boards. The plaintiffs were asking either to be allowed out on parole or to have the conditions of their incarceration changed. The team found that, at the start of the day, the judges granted around two-thirds of the applications before them. As the hours passed, that number fell sharply (see chart), eventually reaching zero. But clemency returned after each of two daily breaks, during which the judges retired for food. The approval rate shot back up to near its original value, before falling again as the day wore on. That is consistent with a second theory, familiar from other studies, that decision making is mentally taxing and that, if forced to keep deciding things, people get tired and start looking for easy answers. In this case, the easy answer is to maintain the status quo by denying the prisoner's request. Two further findings buttress the idea that it is the psychological load of decision making which matters. First, the average unfavourable decision (unfavourable to the prisoner, that is) took less time to arrive at (5.2 minutes) than the average favourable one (7.4 minutes). Second, it also took more time to explain. Written verdicts in favourable rulings averaged 90 words, compared with just 47 for unfavourable ones. - The Economist
- So, whether you are doing Agile or Waterfall or something in between, here are some things you can start doing now to improve the health and performance of your system.
- Too much WIP or DIP overloads our system, which slows things down and encourages people to go ‘around’ the system. But it can also break the system. This may be less visible in a services workplace than in construction but it’s just as expensive. When our system breaks it means people leave, it means stakeholders “go external” to get things done quicker, it means people get things done “under the radar” – antipatterns that make our system and our organisation weaker. Every company I go into says they have too much work, their pipeline is big, everything is high priority and they start too much work. We need an objective, simple, relative way to make decisions that is economically-driven and biased towards reducing cost of delay – i.e. let’s be biased towards high value / low effort work over low value / high effort work.
- We’re focusing on the top two levels here. Some companies use HIPPO, JFDI, “under the radar”, “it’s not really a project”, “that’s the way we’ve always done it”, etc. to make decisions about work. We need a better way, a way aligned to Lean and Agile principles, to identify the right things to work on and encourage decisions to flow through the system.
- SECAR (which spells RACES backwards) is a Lean acronym and a useful reference point when making improvements. So, with decisions and decision-making, can we simplify (or standardise), eliminate, combine, automate, relocate (re-arrange) – roughly in that order? Let’s look at how Scrum/Agile and Lean have already done that…
- Let’s simplify how we see work by visualising it in a simple and consistent way. This team didn’t know how many projects it had or how many things it was working on, until they bought stickies and made a Kanban board. This team didn’t have a decision-making framework other than saying “yes” to new work that came along. They’ve conservatively estimated a productivity increase of 20% through using Kanban visual management and Scrum ceremonies to improve work flow and simplify / standardise decisions around what and how things are worked on. They decided to actively limit their WIP, have lane definitions and finish 2 things before starting one new thing. Now they focus their expensive cognitive activity (Type 2 decisions) around the ”significant few rather than the trivial many” (as W Edwards Deming says).
- 95% of teams I see have a consistent way of writing user stories, which is great because it simplifies the conversations and decisions around what is required to deliver the story.
- This rolls up to Program level. This Program Manager (another Suzanne) is addressing an ART with the Program Level DOD (which the teams created). Again, it standardises what’s required at story, feature and feature set level, making decisions simpler (or eliminating them).
- Try to eliminate NVA. Try to do ‘just enough’ NNVA This frees up effort for VA. Runners, repeaters, rarities. Decisions that are Runners (things that happen frequently and are small scale) should just flow thru the system – decentralise to the teams. Rarities are where the effort should focus – the outliers that need discussion and Type 2 decision-making. Repeaters fall in between, with a preference for decentralising, where possible.
- Better to be roughly right rather than precisely wrong, JM Keynes If the big picture is clear enough to decide, then decide from this without a magnifying glass, M Gladwell Blink
- Don Reinhersten – Cost of Delay (if there’s one thing to measure!). Try to reduce CoD because your C’s get the product quicker, your features are degrading while they’re not released and your competitors are getting more business from your C’s. “Principles of Product Development Flow”
- So, we have some irrational biases that impede our decision making. Which is a problem when we have lots of decisions to make about important stuff, like projects and portfolios. Optimism bias – “we were over budget this time but next time we’ll get it right!” Loss aversion – people are more focused on avoiding a loss rather than achieving a gain (or going after an opportunity). Reflected by the number of companies I work with who are openly risk averse. Sunk cost – ignoring that we’ve spent $1m already and although the Business Case doesn’t stack up, we won’t kill the project because we have spent so much to get this far. Anchoring – overly focusing on one piece of info to make a decision. So, let’s come up with an objective and simple way of making decisions about what to work on.
- If you don’t understand this slide, see me afterwards. In short, it’s relative estimating, i.e. an 8-point story will take “about” 8x longer to do than a 1-point story. It’s a quick and “relatively accurate” (pun unintended) to size lots of work (the team doing the work should do the estimating). We can also use story points to prioritise work based on its relative value, urgency and size. In short, an economic framework for making decisions with a bias to reducing the Cost of Delay and focusing on high value / low effort work.
- Credit is due to Don Reinertsen and Dean Leffingwell for the development of an economic framework that recognises CoD when prioritising work. Here we have a few key variables that will give us a relative cost of delay for our upcoming work and we will prioritise it based on how long it takes. In short, high CoD and low effort work is prioritised earlier. And, we do a common sense check. You can use this with upcoming features (or projects if you use Waterfall). Let’s see an example.
- You may have a one-page feature value statement for each of these features, so stakeholders understand what each feature involves. We start by looking at the list and saying, which of these features has the *lowest* user/business value, and assigning a “1” to that feature. Then we *relatively estimate* user/business values for the remaining features. We need at least one “1” per column. We repeat for each column, calculate the CoD and divide by the job size (job size is the single variable that will most influence the result). Then we sense check. Features with a high WSJF will be prioritised ahead of features with a low WSJF.
- I know what you’re thinking: this is the most casual wedding reception I’ve ever seen! This is what we call BRP – or the secret sauce of scaled Agile. At BRP we bring together everyone working on the product we’re developing – co-located for 2 whole days. All the Scrum teams and all the significant stakeholders from IT, the Business or other teams we are relying on. We start off with a senior Business stakeholder articulating the “why” – the vision for the next Program Increment. They’re also on hand to clarify any questions or take on board any suggestions from the teams. We run about one BRP per week somewhere in the world. How big are they? Well, last year we had 500 people, 7 ARTs, doing their third BRP for their flagship product – a new insurance offering as part of the Obamacare legislation. Is this expensive? Well, I estimated that the teams made over 20,000 decisions in those two days. How long would it take your teams to make that many decisions? So, that works out at less than the price of a cup of coffee per decision. These companies invest and re-invest in these events for one reason: they work. But don’t try this at home alone. Do your first few BRPs with a scaled Agile expert who has done it before. The output of the 2 days is 12 weeks of prioritised and sized features, with 2 sprints broken down to story level, dependencies identified, and a program board as a rolled up view of the next 12 weeks. And, a “fist of 5” from everyone involved – how confident are we that we will deliver this work? And, that work can be shown in the CA-AC platform as follows…
- We can visualise the output of a prioritization session like this in a tool like CA-AC. Here we have a roadmap of prioritized features for delivery over the next 2-3 quarters. We know the capacity of our system (in story points) based on past delivery by our teams. Rally delivered predictably and stably with its own teams – 40 out of 44 planned features in Q1 2015.
- Obama only wears suits that are dark blue or grey. Why? Why waste cognitive effort on these tasks when this effort is expensive? Whose wardrobe is this? Mark Zuckenberg’s (Facebook CEO)
- Let’s decentralise our decisions where we can. There is a small overhead but the benefits outweigh the overhead – faster decisions, empowered teams and people more likely to represent the customer. Scrum does this well at team level. Scaled Agile frameworks also follow these principles.
- If you free 4h week by having a more effective decision-making process, that’s 6 weeks per person per year that you can use for innovation. Or, a whole extra FTE in a Scrum team! It’s essentially creating an innovation budget of 10% for free. So, if your teams cost $10m per year to run, that’s $1m towards innovation. That’s a healthy amount that can make a real difference.
- And once we’ve motivated our people, united behind our vision, planned our next 12 weeks of work, what should we do? Let the teams get on with delivering their work and get out of their way! The final ‘proper’ slide in this deck covers context switching: the cost of picking up and putting down decisions-in-progress. Most of us are knowledge workers and there is a high cost associated with context switching. Different studies have slightly different results, but it’s easily arguable that there is a cost of 20% for switching between just 2 items. So, we have a short activity to demonstrate how even simple activities have a context switching cost.
- Play this game with the person standing next to you. There are 2 rounds. Use a timer to see how long it takes to “deliver” all 3 workstreams (i.e. say/do all the words/actions with you and your partner) Round 1: (easy, sequential, no context switching) You and your partner alternate saying the numbers in Workstream 1, then Workstream 2, then Workstream 3. E.g. you say 1, your partner says 2, you say 3, your partner says 4, etc…. You say Alpha, your partner says Bravo, etc… You clap 1x, your partner claps 2x, etc. (How long did that take? How many “defects”? How easy was it?) Identify quickest / slowest team and calculate variation in time between slowest/fastest. Round 2: (hard, context switching) You and your partner alternate across all 3 workstreams. E.g. you say 1, your partner says Alpha, you clap 1x, your partner says 2, you say Bravo, your partner claps 2x. (How long did that take? How many “defects”? How easy was it?) Identify quickest / slowest team and calculate variation in time between slowest/fastest.
- If you don’t like reading and do like sport, this is a great book that details how a committed coach with a vision took a mediocre cycling nation to become champions. Super organised and get rid of uncertainty – e.g. Team Sky has people set up the riders’ hotel rooms every night (they take their own pillow) as they stay in a different hotel every night of the tour, and this saves the riders time and means they have less to think about – can focus on just riding and recovering. Took GB 99 years to win the Tour de France and now they have won 3 of the past 4 (Froome crashed in the one they didn’t win). Also, Wiggins holds one-hour cycling world record and Marc Cavendish has been sprinting world champion (check facts).
- Go back to your workplace and use WSJF on your current program / portfolio of work. Start sizing your work so you know the capacity of your system.
- We can’t deliver all the work in our pipeline with our current headcount, but we don’t have budget to hire more people. We’ve already identified some things we can do to help our people: limit WIP, focus on finishing, work in long-lived and cross-functional teams. But there is more we can do to help our people deliver optimum results.
- Juliet Bourke is a Deloitte consultant who wanted to quantify the benefits of diversity in teams. So, she took 2y to research a book that demonstrated, amongst other things, that “we listen harder and talk more and have fewer assumptions in teams with gender and cultural differences.” Cognitive diversity doesn’t just mean ethnicity and gender, it also relates well to Scrum’s principle of cross-functional teams. So, what should we think of when we’re building teams?
- Ability still trumps diversity, but they are not mutually exclusive. We need to think of the performance of the team, and the team (rather than the individual) as the core unit in the organisation. So, bearing that in mind, a person’s value depends on her ability to improve the collective decision. In terms of problem solving, experiments have shown that diverse teams have a 30% lower “error rate” when solving problems. Not only did diverse teams have a lower error rate, they also came up with more innovative solutions. The kind where you say “I never would have thought of that myself!”
- Flowdock - Christine Hudson Schneider Electric: 60-90 Q’s per hour, 75% answered in real itme Diverse teams make fewer assumptions and ask more questions
- There are better ways to solve problems and make decisions than unstructured brainstorming. For example, cross-functional teams tend to look at problems in multiple ways. At team-level in Scrum, the team members tend to each use 1-2 of the following lenses, which is great, as all are covered. However, at higher levels in the organisation we get often less cognitively diverse teams…and research shows that only two of these lenses tend to be commonly exhibited: outcomes and options. So, what can we do: