Recommended
More Related Content
What's hot
What's hot (20)
Similar to Learnings adopting Large Scale Scrum
Similar to Learnings adopting Large Scale Scrum (20)
Recently uploaded
Recently uploaded (20)
Learnings adopting Large Scale Scrum
- 1. LeSS an introduction through experiences
- 2. Roland Flemm Scrum Master LeSS Practitioner
- 3. 2017
- 5. Learning is painful We have learned to avoid pain Hence, we sabotage our own learning
- 7. $ SINGLE TEAM SCRUM
- 10. LeSS Huge
- 12. Less = Scrum, and: ● No Scrum team & Development Team, only Team ● TEAMS: E2E capable, self-managing, cross-functional, co-located, and long-lived. ● Self-organized Team is Self-managed Team ● Scrum Master is a full time role and handles 1-3 teams ● Additional events: overall or multi-team refinements, overall retrospective (BIG events) ● PO orders, does not clarify ● one PO per Product ● There is one sprint for one product ● Sprint planning in two separate sessions (planning 1 and 2) ● LeSS is Scrum applied to many teams working together on one product. ● LeSS is for Product mangement, not Project management. ● Systems Thinking is a core principle. ● Organisational descaling framework
- 16. magic
- 17. magic
- 19. Component teams
- 20. Feature teams
- 23. Learnings ● Copy paste Scaling ● Bad scaling is very harmful for companies ● Scrum and LeSS are designed for PERFECT ● Component teams and Feature teams dynamics ● To facilitate sessions with large groups of people ● The power of working with brownpapers and stickies ● Magic Estimation
- 25. The product customer loyaly: reduction, savings, presents
- 26. AND THIS LITTLE THINGY THERE IS OUR AGILE PROJECT1
- 27. THINGS ARE GOING JUST GREAT! WE ARE NOW DOING LARGE SCALED SCRUM!
- 28. Scrum & roles Responsibilities of the PM vs Scrum roles the PM PO
- 29. Changing teams
- 32. my great idea
- 34. BEFORE AFTER
- 35. Learnings ● Marketing has component teams too ● Project Managers are one-person scrum teams ● To make great teams, you need people full time ● People have a lot of unused potential (skill matrix) ● Get people to own an idea to make things work ● Splitting user stories ● Building components and deploying features is very inefficient ● Without Top management support, any adoption will fail ● I need to read books
- 38. SSR support for content widget CMDM Backenders create endpoint Portal Backenders create datasource Portal front end creates consumer CMDM front end connects the widget An example
- 45. Learnings ● Copying any kind of existing model to shape your org will not work ● Working with Remote teams is extremely difficult ● Don’t start with your first feature team in near-shore ● Product is everything ● How to break agile fatigue: soulsearching with Appriciative Inquiry ● How to prepare a FLIP ● Unalignment on need for change gives tsunami of change initiatives ● The importance of communities
- 48. activities
- 52. Learnings ● Verify everything with real data (like existing backlogs) ● Big companies have many people to talk to ● I Make mistakes and redo ● You need to have the answers right there and then (most of the time) ● C-level people think and talk and have assistants to do the work ● Making Feature team adoption maps is difficult ● It’s very difficult to keep thinking simple
- 54. LeSS Adoption Principles: Deep and narrow over broad and shallow - Top-down and bottom-up - Use volunteering Adoption Steps 1. Educate everyone 2. Define “product” 3. Define “done” 4. Have appropriately structured teams 5. Only the Product Owner provides work for the teams 6. Keep project managers away from the teams
- 55. To do it right, You need more from: Emergent by Cesario ramos
- 57. Learnings ● Verifying C-level buy-in is key ● You need a context to do your LeSS adoption in (see: Emergent) ● Go See to verify the need for change and create your context ● How to involve the key players: make them owner of the change ● LeSS and Scrum are designed for perfect; you need to start with a compromise and create a perfection goal ● I can use my Scrum Master learnings to do LeSS adoptions
Editor's Notes
- where i worked where i work what i do Scrum Less training: IMPOSSIBLE fairy tales scaling is not easy: it requires a deep CULTURAL change Scrum is industry standard
- LeSS is a small player contradictions mainly US and Gartner has other numbers So…. chances you will run into a LeSS implementation is not very big. but it is important to understand because they are very close to scrum as it was intended, with the DEEP CULTURAL CHANGE involved. and you will run into SOS shops!
- 2017 VersionOne 12th Annual State of Agile Report Challenges: deep cultural change no pain no gain
- The Learning Dilemma learning is out of you comfort zone that includes me… how do we sabotage our own learning: falling back into comfort zone patterns assuming we already know By not implementing scrum correctly in the first place and then scale that imperfect scrum structure follows culture and vice versa (larmans law)
- less is a descaling framework that optimises for speed flexibility and learning scrum was meant to create agility like startups is less going to solve this mess? not if your scrum sucks like Scrum LeSS requires a deep CULTURAL change (that’s why it is not so popular) it is deep and asks for a lot of PAIN
- differences between LeSS and Scrum less = scrum!
- LeSS is Scrum applied to many teams working together on one product LeSS wants the benefits of small scale development and apply it to large scale 1 po 1 backlog 1 increment coordination is team responsibility customer collaboration Less descales organizational complexity, dissolves unnecessary complex organizational solutions in simpler ways Less is difficult ot implement because it conflicts with how organisations are setup in general Less is not very prescriptive: eg RUP you dont have the knowledge to tailor your process down; hence small framework so you can start and build up by learning more with less build you method up, don’t tailor it down (when you start you are least knowledgeable) less demands to remove things from an org = difficult reduce complexity BUT…. The Po does not scale unlimited
- differences between LeSS and Scrum scrum = less! red is really different yellow is more explicit Now scale this!
- LeSS HUGE PO is the limitation for scaling up: max of properly handling work for 8 teams, then implement VA’s and APO’s example of VA : onboarding , using product, backoffice
- LeSS is scrum applied to many teams working together on one product more with less A less defined process leads to more learning. More roles lead to less responsible teams. More installed processes leads to less ownership in the teams and no continuous improvement. More artifacts leads to less customer-centric teams. Learn and evolve by doing experiments (shu-ha-ri) Complex product development doesn’t require complex solutions. Lean thinking: kaizen and respect for people 9and removing waste0 Overproduction of features, Waiting, delay, Handoff, Extra process, Partially done work, Task Switching, Defects, Under-realizing people’s potential, Knowledge scatter respect for people, manager-teachers Systems thinking is a set of thinking tools to help: See System dynamics See mental models See local optmizations. customer focus: A focus on feature teams that are aligned with creating end-to-end customer-centric features The LeSS Product Owner is a connector of customers/users and teams. Teams do the detailed refinement/analysis with customers/users. Since teams do most refinement of items, the Product Owner has more free time to focus outward on customers. Without transparency, it’s hard to steer or adapt. With it, adaptive control and improvement is possible. What is Perfection? (shared values, organisational vision, product vision)A perfection vision creates alignment. continuous improvement is based on several practices and ideas: Go See, kaizen, value and waste, perfection challenge, work toward flow, respect for people we don’t fix the scope of the product nor the processes of how to build it. Instead in short cycles we create a small shippable slice of the product, inspect what and how we create it, and adapt the product and the way we build it, Examples of queues: Products inventory waiting to be shipped, Code waiting to be integrated, Documents for design, analysis, requirements, Features waiting to be tested Queues are bad because: Introduce risk Increase time to market Reduce transparency Increase variability whole product focus In many large product development groups, getting everyone to focus on the whole product instead of their individual parts/tasks/specialization is one of the hardest parts of scaling Scrum. Parts of software that are not integrated into the whole product have no value yet. Teams who finished ‘their part’ are not done until it is integrated. scaling is not easy: it requires a deep CULTURAL change
- multiple team scrum not mutiple scrum teams sessions with a large group of people that is not efficient. it will never work!
- 10 less principles To produce rules by which frameworks are created With guides for your context And experiments to move towards perfection Less optimizes for: Fast time to market Flexibility learning scaling is not easy: it requires a deep CULTURAL change
- srum was not delivering what they expected
- one team scrum
- copy paste scaling But…. we need to integrate. Added complexity.
- you will find a lot of copy paste scaling async hence more defects, information scatter of a feature across teams and opaque measures of progress. The result was low productivity, high defect rates and unhappy customers. THEY DIDNOT TAKE THE PAIN OF THE REAL CHANGE
- functional specialism: on capability (billing, messaging, contract) or component (fe, be, db) advantages clear ownership for code and design clear responsibility as you will be delivering on 1 component deep specialisation downsides - imbalanced and asynchronous dependencies - focus on amount of output rather than value results in sequential life cycle and a long release cycle - integration hell low value work to keep teams busy
- What is feature team cross functional cross component each team can deliver an e2e feature by themselves (customer problems not tasks) long lived less coordination dependencies on code = synchronous dependencies canbe automated and dont cause delay With cross-functional teams, 1 team solves a customer problem. In LeSS we prefer specialization in the customer domain to increase collaboration with real users and remove hand-offs. often does not work: requirement hell multiple PO’s due to dysfunctional leSS work is not sliced into independent features domain knowledge considered too big and complex not all teams are feature teams not empowerec, no autonomy: org stuck in component/system owners
- learning is painful unfortunately we have learned to avoid pain to survive LArman’s law: organsiations are setup for status quo: culture follows structure and vice versa you are located in a remote place. that in itself is a position Large Scale scrum says to avoid.
- this bank tried agile, they need it and demand rises? we need to deliver more and faster!
- The promise: scrum and agile implement: deliver customer value fast flexible BUT We have scaled….. Nothing changed really.
- the PM welcomed me…. EDDY scope; a pm can negotioate scope decrease to meet deadline time: a pm can negotiate delivering later quality: a pm can reduce quality to meet goals cost: a pm manages cost of a project: # of people There is no difference when at scale roles are different, accountability is different
- coponent teams with chaning members doing all kinds of other work too company is optimising resource utilisation
- people in teams with specialism, provided by different vendors (cap, infosys, tcs) code base was split per vendor desired funcitonality -> split per team lots of work outside team: backlogs full easy fast solutions possible but no cooperation -> faster wow would mean vendors cooperating release trains, release coordinator, run meetings 3 months after done is go live: long feedback cycle
- did you ever need to loose weight? it will take a lot of effort, scarifice and change in your behaviour same goes for doing scrum: it is a deep cultural change no pain no gain
- hip cool place.
- another approach for copy paste scaling using the spotify model
- 4 teams one small bit of functionality if you are a portal backend team, you will need to align with 4 teams specification is key: you need good specs to have all these teams create something that works Asynchronous dependencies to keep teams busy we give them low value work this forces you in the direction of sequential work: waterfall different model:
- dopnt start introducing less in a near shore team
- po support if product is unclear, there is nothing
- adapt
- use cLD
- arguing about design is called refinement
- marketing 250 people silos working at C level! very complex to keep it simple
- before flip
- after flip: feature team adoption map
- mt in front fo their scrum board
- its very tempting to see the complexity
- small company i now read some books development department
- Less adoption…. that;s not enough
- Emergent: need for change announcement to everybody hire specialists (SM) awareness workshops LeSS trainings coach PO: create inital PbL do Refinements flip to feature teams
- first verify mandate!