Scaling Scrum Without Crushing Its Soul - Patricia Kong - Agile NZ 2017
•Download as PPTX, PDF•
3 likes•354 views
At the core of Scrum is the empowered self-organised team. However, when organisations scale, if they are not careful, they can disempower teams and destroy self-organisation. When they do, they don't get what they are looking for and the teams end up feeling defeated and unmotivated. About Patricia Kong: Patricia Kong is co-author of The Nexus Framework for Scaling Scrum published by Pearson. She is also a public speaker and mentor. Patricia is the Product Owner of the Scrum.org enterprise solutions program which includes the Nexus Framework, Evidence-based Management, Scrum Studio and Scrum Development Kit. She also created and launched the Scrum.org Partners in Principle Program. Patricia is a people advocate fascinated by organisational behaviour and misbehaviours. She emerged through the financial services industry and has led product development, product management and marketing for several early-stage companies in the US and Europe. At Forrester Research, Patricia worked with their largest clients focusing on business development and delivery engagements. Patricia lived in France and now lives in her hometown of Boston. She is fluent in four languages.
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (20)
Similar to Scaling Scrum Without Crushing Its Soul - Patricia Kong - Agile NZ 2017
Similar to Scaling Scrum Without Crushing Its Soul - Patricia Kong - Agile NZ 2017 (20)
More from AgileNZ Conference
More from AgileNZ Conference (11)
Recently uploaded
Recently uploaded (20)
Scaling Scrum Without Crushing Its Soul - Patricia Kong - Agile NZ 2017
- 1. © 1993-2016 Scrum.org, All Rights Reserved by Scrum.org – Improving the Profession of Software Delivery Scaling Scrum Without Killing Its Soul Patricia Kong | @pmoonk88 Product Owner Enterprise Solutions
- 2. © 1993-2016 Scrum.org, All Rights Reserved Or Don’t Adopt Agile Using A Waterfall Approach 2
- 3. © 1993-2016 Scrum.org, All Rights Reserved For the past decade, organizations have been rushing to Agile and Scrum
- 4. © 1993-2016 Scrum.org, All Rights Reserved4 Scrum●pede Inspired by ©TomaszWłodarek.
- 5. © 1993-2016 Scrum.org, All Rights Reserved5 “We’re going agile!”
- 6. © 1993-2016 Scrum.org, All Rights Reserved Irony: Adopting Agile Using A Waterfall Approach 6
- 7. © 1993-2016 Scrum.org, All Rights Reserved •… and they often want to plan their “Agile transformation” •... with a kind of precision »X number of people to be trained »Y number of teams, each with coaches, Product Owners and Scrum Masters »All marching toward the goal of “adopting Agile” »With regular milestones at which they will measure progress »Where success = “we are on plan” 7 Traditional organizations love plans What could possibly go wrong?
- 8. © 1993-2016 Scrum.org, All Rights Reserved Little has changed.
- 9. © 1993-2016 Scrum.org, All Rights Reserved9
- 10. © 1993-2016 Scrum.org, All Rights Reserved Optimizing good practices effectively? Dealing with DevelopmentTeam Dysfunction, Forrester Research 2017
- 11. © 1993-2016 Scrum.org, All Rights Reserved Reducing manual processes? Dealing with DevelopmentTeam Dysfunction, Forrester Research 2017
- 12. © 1993-2016 Scrum.org, All Rights Reserved Closing the gap? Dealing with DevelopmentTeam Dysfunction, Forrester Research 2017
- 13. © 1993-2016 Scrum.org, All Rights Reserved13 “The thing is Bob, it’s not that I’m lazy. I just don’t care.”
- 14. © 1993-2016 Scrum.org, All Rights Reserved What is scaling agile really trying to achieve? 14 Customer needs change Frequent adaptation is essential The Firm Customer The Firm Customer This radical shift in focus is leading to vast economic, social and political change
- 15. © 1993-2016 Scrum.org, All Rights Reserved How can we scale?
- 16. © 1993-2016 Scrum.org, All Rights Reserved What’s at the center of Scrum?
- 17. © 1993-2016 Scrum.org, All Rights Reserved17 #shitspray
- 18. © 1993-2016 Scrum.org, All Rights Reserved • Scrum Framework • ScrumTheory and Principles • Cross-functional, self-organizing dev. • Analysis • Emergent Architecture • Programming • Test First Development • Standards • Testing • ALM Professional Scrum Master • Scrum Framework • ScrumTheory and Principles • Cross-functional, self-organizing teams • Coaching and Facilitation • Scrum at Large • Nexus Framework • Application of Nexus • Scaling Fundamentals 18 Establish a solid professional basis Scaled Professional Scrum Professional Scrum Developer
- 19. © 1993-2016 Scrum.org, All Rights Reserved19 Scale that solid professional basis Team 1 Team 2 Team 1 Team 4 Team 3 Team 1 Team 2
- 20. © 1993-2016 Scrum.org, All Rights Reserved The Nexus™ Framework
- 21. © 1993-2016 Scrum.org, All Rights Reserved The Nexus™ Framework
- 22. © 1993-2016 Scrum.org, All Rights Reserved • Identify and resolve or minimize dependencies: » Ongoing & persistent » In all dimensions » Prior to work occurring 22 Essence of Scaling • Reactive to ensure that undetected dependencies aren’t corrupting outcomes: » Frequent integration » Acceptance testing » Continual build and delivery » Minimize technical debt ANTICIPATION* REIFICATION** * The act of preparing for something. A prior action that takes into account or forestalls a later action. ** The process or result of reifying. Making something real, bringing something into being, or making something concrete.
- 23. © 1993-2016 Scrum.org, All Rights Reserved Nexus | noun ˈnek-səs : a relationship or connection between people or things : the exoskeleton of scaled Scrum – Ken Schwaber 23 Nexus™
- 24. © 1993-2016 Scrum.org, All Rights Reserved24 #exoskeleton
- 25. © 1993-2016 Scrum.org, All Rights Reserved A customers Start scaling incrementally from the outside in customers customers
- 26. © 1993-2016 Scrum.org, All Rights Reserved26 What does successful scaling look like?
- 27. © 1993-2016 Scrum.org, All Rights Reserved27 ThankYou! scrum·on/skrʌmˈ ɔn/ 1. Explore the art of the possible. Patricia Kong | patricia.kong@scrum.org | @pmoonk88
Editor's Notes
- Title inspired by Edwin Dando. At the core of Scrum is the empowered self-organized team. However, when organizations scale, if they are not careful, they can disempower teams and destroy self-organization. When they do, they don't get what they are looking for, and the teams end up feeling defeated and unmotivated. When organizations impose order and consistency from the top down, they lose the benefits of Scrum. What organizations need is to scale the benefits of Scrum to multiple teams working together to deliver an integrated product, but without destroying transparency and the courage, respect, commitment, focus, and openness that Scrum encourages. In this talk, we will explore the common dysfunctions of scaling and how to overcome them. In the process, we describe the Nexus Framework for scaling Scrum. Nexus extends Scrum by focusing on removing cross-team dependencies, freeing teams to do their best work. Nexus builds on Scrum in a minimal way, helping organizations scale Scrum without destroying the essence of Scrum.
- Followed by a rush toward scaling Scrum. It starts simply…
- An executive becomes convinced that Agile is a good thing... why not do it everywhere? A decree is annouced: “Everyone will be Agile by the end of the year...” The irony is - the rush to scrumpede leads to waterfall!
- Ironic that we’re using waterfall to adopt agile
- We’re not seeing a difference and things are still working the same.
- Often the narrative we hear is that we need to scale because we need to go faster or because we have a lot of people… and we revert to what we know.... And so when we scale we need to look at a few questions and what we are scaling....
- We have these plans and processes… Help us from scaling too early, too fast, and unrestrained? Pushing change on teams before they have mastered engineering practices? Consider what must be done to integrate the work?
- Scaling has a cost.
- vision, ability for people that empathize with your customers. If we’re scaling that that’s how we kill the soul of scrum.
- When we impose -- We hinder the intention of Scrum, of agility. That’s how you kill the soul of Scrum. What were we really scaling?
- Obtaining customer feedback & being able to rapidly act on it is the key to succeeding in a customer-empowered world. - Frankly, this is now the status quo – so we are in a better place to do this – to scale value. But when we are focused only with the process and planning of becoming agile... Because we need to go faster? Because we have a lot of people? Why else? The purpose of “scaling” is to get more DONE in a given timeframe and to deliver MORE VALUE.
- Pockets working, expand.
- What can we scale? If we really want to scale Scrum. People and more relevant the team (a Self-organizing, Cross Functional Team) is at the center of Scrum – the soul of Scrum.. The team should have good practices. Don’t scale shit.
- And that is something we don’t want to scale
- Scrum Teams are self-organizing and cross-functional; which is very different from traditional development groups. Scaling Fundamentals - Scaling Scrum effectively requires a firm understanding of the Scrum Framework and how it is founded on empirical theory. This includes an understanding of the Scrum principles and values, and a focus on technical excellence. Establish a solid basis of professional scrum
- Scaling will always be painful, but a solid basis will make it less so. Happier people, more creative, ownership. Scale the empirical and self organizing team. Story about CapOne who grew the teams. Story about NH who had all the teams and reshuffled. Scale that goodness. Core focus will be on removing dependencies and figuring how to integrate work together every Sprint. Get good at what you’re good at and then do what makes sense in your context. Also get good at what you’re not good at. Technical practices
- Multiple teams working together requires coordination. Just get started. So if you know Scrum, and you’re working on one thing this helps you reinvest that knowledge and experience. TIME Common sense – dependencies and integration issues Nexus, like Scrum is a simple framework that that promotes bottom-up thinking and empiricism. Nexus augments Scrum minimally to effectively allow Scrum to scale by lifting transparency and fixating on integration by working from a single Product Backlog to deliver at least one “Done” Integrated Increment every Sprint. “Multiple” means, typically, three to nine Scrum teams. Why not two? Because two teams can generally coordinate between themselves without additional structure. Why nine? Just as Scrum recommends limiting teams to no more than nine members to improve cohesion and reduce complexity, Nexus recommends the same for the number of teams. Nexus Framework and our education on it through Scaled Professional Scrum focuses on 2 things dependencies and integration. Also a formalization of things that people who are doing Scrum well recognize. The Nexus’ foundation is Scrum
- Every additional role, event and artifact was the minimal that we felt was needed to increase transparency. Just as in Scrum, however, everything depends on circumstances. Ken asking me if anyone has said that this doesn’t seem new?
- We have teams with high performing teams How can the teams work together? Dependencies will be the killer. Teams lifting transparency. And they can do it using Scrum. Nexus is …..
- Look for a straightforward approach that builds on their current knowledge and skills Default to what they know but did they keep it easy and straightforward? The Events, Roles and Artifacts that define a Nexus exist to facilitate connections and communications that allow multiple Scrum Teams to create an integrated increment. It’s not about the structure, it’s about the connections (i.e. collaboration and conversation) Nexus integrating people and teams. Update Nexus Guide and book
- Exoskeleton reference: The “exosuit” that Tom Cruise wore in the Edge of Tomorrow movie (http://bit.ly/1gjwSjI).
- Getting to the status quo now means being able to leverage a modern digital business and the ability to pursue opportunities to deliver value. Getting to a place where you can say I know what value is for my customer -- 2 circles slide -- This is not your end state. Because it isn’t about structure it’s about connections. Scaling fractal of self organization. don’t scale too early-optimize 2. balance the cost and benefits of scaling vs value produced 3. Your scaling initiative is unique. No one can tell you what your org will look like. Because of your structure, culture, goals, challenges, current practices and infrastructure, existing software, domains of competence... People, leadership.
- Courage - courage saying no, doing the right thing Committed to quality – to the effort – to each other – to the goal – to show up? Focus – getting done, what’s simplest Respect for people and their background and opinions and experience? Open – to feedback, possibilities and change? Are these alive? Build trust and inspect and adapt. Exercise – scale this ”Never stop believing that fighting for what’s right is worth it.” -- As a community, this is our purpose.