less - moving beyond single team scrum

© leanpitch Technologies Private Limited

Naveen Kumar Singh [email protected] +91-9810547500 @naveenhome naveen75home

Large-Scale Scrum (LeSS)

Moving beyond single team Scrum

© leanpitch Technologies Private Limited 2

What problem you are trying to solve?

43 people

Multiple project team

Different Skills

Different goal

Complex coordination

Legacy code Many managers

But One Product


Customer-centric and whole product focus


What is Product?

Single code base ?

Server-side or back-end ?

Library/Common platform/Service (Not sold directly) ?

A project to develop a few features ?


Exercise – Identify a product


Current product team structure


What is LeSS (Large-Scale Scrum)


What is LeSS (Large-Scale Scrum)

Large-Scale Scrum is Scrum and it is not new or improved scrum as stated by Craig Larman and Bas Vodde.

LeSS is also not a framework to apply at team level instead it is scrum scaled on all the levels.

Large-scale Scrum, like regular Scrum, is a framework for development in which the details need to be filled in by the teams and evolved iteration by iteration, team by team. It reflects the lean thinking pillar of continuous improvement. It is a collection of suggestions for inspecting and adapting the product and process when there are many teams—at least two teams and up to groups of 500 or 1000 people.

Read here - http://less.works/less/principles/large_scale_scrum_is_scrum.html

http://less.works/less/principles/lean_thinking.html

http://less.works/less/principles/continuous-improvement-towards-perfection.html

http://less.works/less/principles/large_scale_scrum_is_scrum.html

http://less.works/less/principles/large_scale_scrum_is_scrum.html


What is LeSS Principles?



Large-Scale Scrum is Scrum – LeSS doesn’t introduce any new role till 8 teams. LeSS is a simple framework that exposes organization problems just like Scrum. Beyond 8 team only role that get introduced is APO (Area Product Owner).

Empirical Process Control – Inspection and Adaption of the product, processes, organizational design, and practices to craft a situational appropriate organization based on Scrum, rather than following a detailed formula.

Transparency – Based on tangible “done” items, short cycles, working together, common definitions, and driving out fear at workplace.

More with LeSS – 1. in empirical process control: more learning with less defined processes. 2. In lean thinking: more value with less waste and overhead. 3. In scaling: less roles, artifacts and special groups.

Whole-product focus – One product backlog, one product owner, one product increment, one sprint regardless of number of team.



Customer-Centric – Identify values and waste in the eye of paying customer. Reduce the cycle time from their prospective. Increase feedback loops with the real customer.

Continuous Improvement towards Perfection – Do I need to tell you? This is all about Scrum I believe.

System Thinking – See, understand, and optimize the whole system and use causal-loop modelling to explore system dynamics. Avoid local optimization.

Lean Thinking – Create an organizational system whose foundation is managers-as teachers who apply and teach system thinking and lean thinking, manage to improve, and who practice go see at gemba. Add the two pillars of respect for people and continuous improvement. All towards to the goal of perfection.

Queuing Theory – One product backlog, one product owner, one product increment, one sprint regardless of number of team.


Causal-loop modelling


Causal-loop modelling - Exercise

5 minutes discussion on what you wanted to improve in a product that you have identified earlier.

10 minutes to draw causal-loop modelling showing Positive feedback, Negative feedback, Balancing feedback, Reinforcing feedback and delay loops.


Lean Thinking


Lean Thinking - Exercise

Identify waste in your software product development process that you will prefer to eliminate – 10 mins


Common Waste - Software Development

Waiting

Delay

Handoff

Partial done work

Task switching

Defects

Under-realize people's potential

Knowledge Scatter

Wishful thinking

Many more…..


LeSS Rules - Structure

• Structure the organization using real teams as the basic organizational building block.

• Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.

• The majority of the teams are customer-focused feature teams.

• ScrumMasters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A ScrumMaster does not focus on just one team but on the overall organizational system.

• A ScrumMaster is a dedicated full-time role.

• One ScrumMaster can serve 1-3 teams.


LeSS Rules - Structure

• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus is the value-delivering capability of the product development system rather than the specific scope of a product.

• Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance”.

• For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.

• For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where experimentation and improvement is the norm.

More details


LeSS Rules - Product

• There is one Product Owner and one Product Backlog for the complete shippable product.

• The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders.

• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.

• One shared Definition of Done for the whole product.


LeSS Rules - Product

• Each team can have their own expanded Definition of Done.

• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might increase. Broader definitions are preferred.

• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).


LeSS Rules - Sprint

• There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product.

• Sprint Planning consists of two parts: Sprint Planning Part One is common for all teams while Sprint Planning Part Two is usually done separately for each team.

• Sprint Planning Part One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on the next Sprint.The Teams identify opportunities to work together and final questions are clarified.

• Each Team has their own Sprint Backlog.


LeSS Rules - Sprint

• Sprint Planning Part Two is for Teams to decide how they will do the selected items.This usually involves design and the creation of their Sprint Backlogs. The Team forecasts how many items they believe they can complete during the next Sprint.

• Guidance: For some Teams, do it in a shared space to enhance coordination.

• Each Team has their own Daily Scrum.

• Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination

• Guidance: Coordination via Open Space, joining other teams’ Daily Scrum, Scrum of Scrums, multi-team workshops, or “simply” working in the same space, talking to each other, and using visual management.


LeSS Rules - Sprint

• Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future. Do multi-team PBR to increase shared understanding and exploiting coordination opportunities when having closely related items or a need for broader input/learning

• Guidance: Hold an overall PBR with representatives before each team PBR to explore which teams might work on which items, and to increase learning and alignment.

• There is one product Sprint Review; it is common for all teams. Ensure that enough stakeholders join to contribute the information needed for effective inspection and adaptation.

• Guidance: Use decentralized “diverge-merge” techniques for better feedback and less boring meetings.


LeSS Rules - Sprint

• Each Team has their own Sprint Retrospective.

• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, ScrumMasters, Team Representatives, and managers (if there are any).


Large-Scale Scrum (LeSS) - Structure


Team

Self-managing

Cross-functional

Multi-skilled workers

Long-lived teams

Dedicated Teams


Challenges with Component Team

Organization is practicing Scrum for last 3 years

Cost of Production was very high

Single codebase but multiple integration points

Lots of dependencies between team

Many managers/leads to deal with dependencies

Many product managers for same product from different region

Difficult to prioritize PBIs

Cycle time was 6 weeks

Small fake products

Separate testing team


Feature Team


Technical Excellence


Technical Excellence

Why emergent Design is still a dream?

Why team avoid refactoring?

How do you review code? Still reading?

Is TDD takes more time?

Code is poor because ownership still with individual?

Collective code ownership improves code quality?

When to start writing Acceptance-test driven development?

Continuous Integration is not about just configuring tools but more about practice?

How to branch your code and when to branch out?


Emergent Design

Big Design Up Front (BDUF) Emergent DesignThink before your code Assume change is cheapSupport IT governance Handles ambiguityRequires abstract thinking Requires details thinking

This is good but how to start?


Feature Team

Component team can help in improving technical practices?

Local optimization is good?

Feature team can take away specialization?

Feature team can lead to poor quality of code?


Exercise

What team type is more suitable for better code? Component or Feature team?

Discuss for 10 minutes and write your suggestions and let’s understand what others are thinking.


Management


Role of Manager

• The role of middle management is to see the whole and build the capability of the organization to build great products.

• He should help team and ScrumMaster with removing obstacles and making improvements.

• He should teach the team how to improve and solve problems.

• He should Go See to understand what is really going on in the place of work and see how he can best help the team improve their work.

• The role of senior management is perhaps changed less as they are still involved with strategic decisions related to the company and its products.

• That said, also senior management’s role is teaching people—his subordinates—how to teach people.

http://less.works/less/principles/systems_thinking.html

http://less.works/less/management/improvement_service.html

http://less.works/less/management/teaching_problem_solving.html

http://less.works/less/management/go_see.html


Self-Management – Types of teams


Structure after LeSS Adoption

Maximizing Value


Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

Individuals and Interactions Processes and Toolsover

Working Product Comprehensive Documentationover

Customer Collaboration Contract Negotiationover

Responding to Change Following a Planover

That is, while there is value in the items on the right, we value the items on the left more


Agile PrinciplesI. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

II. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage

III. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

IV. Business people and developers must work together daily throughout the project.

V. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

VI. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

VII. Working software is the primary measure of progress.

VIII. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

IX. Continuous attention to technical excellence and good design enhances agility.

X. Simplicity--the art of maximizing the amount of work not done--is essential.

XI. The best architectures, requirements, and designs emerge from self-organizing teams.

XII. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

39


Building leaner pitches for your efficiency games

Contact Us: www.leanpitch.com | [email protected] | #309, 4th B Cross, HRBR Layout, III Block Bangalore-560043 | +91-80-41614192

Agile Transformation

ServicesAgile Coaching

& TrainingCollaboration Tool

Development Services

We also offer

Test Driven Development Methods Behavior Driven Development Methods Agile Project Management Using JIRA +

GreenHopper Collaboration Tools for Agile Teams Software Configuration Management for Agile

Teams using Perforce

Certified ScrumMaster

Certified Scrum Product Owner

Certified Scrum Developer

Need a Coach, Call

us

less - moving beyond single team scrum

Education