Alternatives to scaling your agile process: valuing outcomes over output
Download as PPTX, PDF•2 likes•649 views
This document discusses alternatives to simply scaling up agile processes. It argues that organizations should focus on continuously improving outcomes rather than just increasing output or volume. Some key points made include: - Agile is about mindset and values, not processes, and scaling up risks losing those. Organizations should fix weaknesses before scaling. - True scaling happens incrementally based on measuring business impacts, not just adopting more processes. Teams should regularly inspect and adapt. - There are many ways to improve value, quality and productivity within existing teams, like improving technical practices and skills, before considering larger scale changes. - Scaling is primarily a "people problem" - organizations should focus on building networks between self-organ
![What sort of weaknesses?
On the whole, [our survey results are] not exactly a
reassuring picture for those who depend on the software they build.
Develop Landscape - Forrester Research 2013](https://image.slidesharecdn.com/agilenz2014presentationv1-140911172957-phpapp02/85/Alternatives-to-scaling-your-agile-process-valuing-outcomes-over-output-14-320.jpg)
Alternatives to scaling your agile process: valuing outcomes over output
- 1. Alternatives to scaling your agile process: valuing outcomes over output Edwin Dando Assurity Your pic
- 3. There is a management revolution underway “Tomorrow’s business imperatives lie outside the performance envelope of today’s bureaucracy-infused management practices… Equipping organizations to tackle the future would require a management revolution no less momentous than the one that spawned modern industry.” Gary Hamel - the landmark HBR article Moon Shots For Management,
- 4. What is changing? To focusing on customer value To exploiting variability for competitive advantage To providing a vision to a self-organised, cross-functional team and getting out of the way. To measuring results on outcomes To regular delivery of customer value via economies of flow To focus on building wonderful workplaces and strong employee engagement To a strategy that is about deep customer engagement, rapid manoeuvrability, fast feedback and regular pivots From focusing on maximizing shareholder $ From avoiding variability From telling employees what to do From controlling performance through rules, roles, plans and reports From efficiency through economies of scale From focus on lowering costs through offshoring From a “coping with competition” strategy through regulation and monopoly behaviour
- 5. Agile has made a major contribution to this
- 6. Large scale and agile – a clash of cultures? • Agile is a mind-set and set of values, not a process • Agility is earned, not installed • For a long time many people have worked hard to help shift thinking, adopt new values and change… Yet… • Agile is now mainstream • Markets forcing businesses to become more responsive • Insatiable demand to “be agile” – especially from large companies, often who have come to the game late And so, • Market responded with “buy and install” agile @ scale • Approach viewed as disrespectful to core values
- 7. The scaling dilemma • The desire ‘to scale’ is a reflection of the demand to develop more software, faster (rather than better outcomes with same/less effort). • Existing internal structures make it difficult to increase capacity • So we add new structures to manage this and increase our efforts. • But investment to achieve more goes mostly to the additional structures, and is often much higher than the gains expected. • We enter a vicious cycle. Gunther Verheyen - Maximizing Scrum, http://blog.scrum.org/maximizing-scrum/
- 8. In an organisation near you… • An organization starts adopting Scrum • Soon they ask ‘how do we scale?’ • Very few stop and investigate this desire prior to exploring scaling. • What do we hope to obtain from scaling? • How does this fit with our strategy? • What are the risks? • How will we know scaling is helping us? • How will we measure this?
- 9. Humans love simple assumptions The logic of induction teaches us that • If n is true (it works for one) • and n+1 is true (it works for the next) • then n must always be true….. Right? So lets test this hypothesis: 1 + 2 + 3 + … + n = ½n(n+1) 1 + 2 + 3 = ½ x 3 x 4 = 6 1 + 2 + 3 + 4 = ½ x 4 x 5 = 10 1 + 2 + 3 + 4 + 5 + 6 + …. + 7823 = ½ x 7823 x 7824 = 30603576
- 10. And we carry that logic into business contexts • Agile works for one team and gives us great benefits • and it works for two teams and gives us more great benefits • Therefore it must work for many teams and make us world beaters, right?
- 11. Add to this the fact that knowledge work is highly creative • Good Agile managers create environments where people can flourish and grow. • Much like the role of the gardener… Get your hands dirty and create an environment where people can flourish. FHeeelpd And our raenmd garden owvaet ethr itnhgesm grows th raetg and sutloaprl y rewards them succeeding us
- 12. But does the same thinking apply on a large scale? Value is very, very different from volume Outcomes are very different to output
- 13. Shoe-horning agile • Over time, many organizations have grown very complicated with interdependent internal structures. • The implementation of Scrum is expected to fit into these existing structures. • Within these structures, ‘scaling’ is synonymous to increasing volume and quantity, to larger numbers. • The expectation is that Scrum must be expanded with additional processes, roles, phases, etc. • At which point we have missed the point • The entire point of Scrum is to highlight your weaknesses – so you can fix them Gunther Verheyen - Maximizing Scrum, http://blog.scrum.org/maximizing-scrum/
- 14. What sort of weaknesses? On the whole, [our survey results are] not exactly a reassuring picture for those who depend on the software they build. Develop Landscape - Forrester Research 2013
- 15. Some clear areas for attention • Basics of Agile – we’ve only adopted the basics “Organizations claim that they’ve ‘gone Agile,’ but when one probes on specific Agile practices, the reality is that they’ve only adopted a few basic ones and stalled out in the scaling process.“ • Quality software development “Only 12% of the developers we surveyed spend more than an hour a day writing test cases. Developers spend more time on email than writing tests” Develop Landscape - Forrester Research 2013
- 16. Why would you want to scale this? Fix these first
- 17. Some clear areas for attention • Small Teams “Developers who work in small, collocated teams understand the applications they build fare better. Most development teams are not collocated. Our takeaway: Organizations are trading understanding and efficiency for an efficient cost structure”. “We see the inverse relationship between development team size and the level of project understanding/transparency. Our recommendation? Lose the industrial metaphor forever and think more along the lines of a talent management from or a Broadway production.”
- 18. Focus on getting more out of what you already have Why would you want to scale this? Fix these first.
- 19. Why would you want to scale this? Used with permission – Scrum.org
- 20. No evidence “What is the business impact of agile? The reality is, we have no idea. We have no real evidence. If we start measuring by evidentiary outcomes, then we will have firm grounding when we assess its value to the organization, and the value of our investments and initiatives.” Ken Schwaber, Scrum co-creator Maybe we would want to fix this before we scale?
- 21. Scaling, finally So, lets assume we get good at developing software and get to the point of “scaling up”, how do we scale? 1. Start with reality – there is no recipe, only patterns 2. Start small and iterate. a) Try some of the known scaling patterns b) Inspect how it has worked in your context. Hint – you should find a way to measure the business impact. c) Adapt as required. d) Repeat
- 22. Incremental scaling with evidence Single team starts doing Scrum They identify things that need improvement and capture these in an organisational improvement backlog Review Retrospective OAG makes next round of decisions on evidence: Are customers happier? Is quality improving? Are we innovating faster? Is staff morale better? Are we more agile? Organisational Agility Group selects items and implements transparently Evidence based planning Measure business impact Organisational learning Organisational Improvement backlog How can we improve quality? Should we start another team? Are we working well together? Do we have interdependency problems? What does the evidence tell us? How’s our culture? Teams inspect and adapt collectively, using evidence Change Increment Is revenue improving? May decide to add another team… Change Owner What is true for us? Meets regularly to track progress and re-plan Are we getting to done every iteration?
- 23. Evidence • Over 85% of senior international executives* say organisational agility is critical to success. • Yet few can demonstrate tangible business benefits to their boards • This is a tragedy, given the investment involved in agile. Even more important, how do we • know the risk and disruption involved in this agile transformation is working? • continually tweak the approach to our organisation’s unique needs? Unfortunately, most organisations don't. They measure output, not outcomes. And then they want to scale... *Organisational agility: How business can survive and thrive in turbulent times The Economist Intelligence Unit
- 24. Evidence of business outcomes (not agile outputs)
- 25. Focus on evidence based business decision making • How has the ability to release fortnightly helped? • Are our staff happier doing agile? • Are we seeing value from our technical debt repayment? • Has our investment in test automation improved quality and customer satisfaction? • Maybe, if we are getting these right, then we should consider scaling
- 26. There are many ways to “scale” before you “scale Scrum” • Quality software development – a good developer can be 20 times more productive than an average one. Grow them. – pair programming - instant feedback loops, higher quality. – continuous delivery – regular delivery of value and regular product learning cycles • Technical debt – prevents agility and is extremely expensive. Slow down, write good code, write less code - only on features customers value. – only 29% developers time spent working on value. 53% spent on complexity/technical debt*. Your teams want to fix this. Given them the opportunity and double/triple productivity. *Source: Forrester, October 2010 “2011 IT Budget Planning Guide For CIOs”)
- 27. There are many ways to “scale” before you “scale Scrum” • Value – ~ 65% of features aren’t valued by customers. Use validated learning to find out what they don’t value and stop delivering it. – Deliver products that make a market impact, not just ship more features… Impact Mapping • Team – Developers are intrinsically motivated & creative*. Create environments in which they can flourish. – #1 reason for software project failure is a lack of shared understanding. Specification by Example helps resolve this. – Agile isn’t just about Scrum Masters and Product Owners. Testers, developers and analysts need training too. *Source: Forrester, October 2010 “2011 IT Budget Planning Guide For CIOs”)
- 28. There are many ways to “scale” before you “scale Scrum” *Source: Forrester, October 2010 “2011 IT Budget Planning Guide For CIOs”) • Evidence – Measure and track the business impact of agile. – Make evidence based decisions. – If the evidence shows something isn't working, change it. • Test automation • Product Ownership • Team behaviours & collaboration • … In other words, walk before you run
- 29. Scaling is a people problem, not a process problem .
- 30. Thinking about the people – networks versus hierarchies • Hierarchies can be an effective way to organise, but they don’t tend to be an effective way to communicate • Typically, coordination responsibility likes with individuals • But when people are busy, they pass their problems to the coordinator to pass to someone who can fix it. • Why? Because people are busy getting their features to done. It’s human nature. We push problems up a hierarchy for someone else to remove if that’s how it’s supposed to be. Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs http://bit.ly/1l7EcjZ
- 31. Networks • Don’t have to have everyone interconnected with everyone else – just some connected individuals. • Don’t need the Scrum Masters to do it. • E.g. Bob and Alice have a question, they ask each other. If that doesn’t resolve it they ask someone else who might know (not necessarily a manager). • The question doesn’t go up the hierarchy. It goes across the network. Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs http://bit.ly/1l7EcjZ
- 32. Communities of Practice help build networks and coordinate work • Testers talking to other testers • Developers talking to other developers • Ability to solve common problems and coordinate common activities • Ability to inspect and adapt our common work and approach Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs http://bit.ly/1l7EcjZ
- 33. Benefits of a network model • Communication flows quickly through networks. Puts the inherent rumour mill to work for you. • Networks are connected by humans who are more prone to connecting/communicating • A network engages people in a way that hierarchy does not • A network decreases the transaction cost of just about everything. • No waiting on meetings to address problems, issues, or risks. People on teams solve problems when they have the problem. • No need for a “master” or a “chief” to intervene. Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs http://bit.ly/1l7EcjZ
- 34. In summary • Use Scrum to highlight your weaknesses • Systematically fix them • Then consider scaling, if it makes sense • If so, start small and iterate • Measure the business impact of each change
- 35. If the definition of insanity is “doing the same thing and expecting different results”, then what is the definition of insanity at scale?
- 36. Thanks for listening… Edwin Dando Assurity @edwindando agileforeveryone.com [email protected] linkedin.com/in/edwindando/