The ultimate goal of any Scrum Master or Agile Coach when working with teams is to bring them to a high level of maturity and self-organization. But what exactly does that vague term mean? How can we bring the team to this state? When should you not to let the team go? In my talk, I will try to answer these questions and share the lessons learned working with over ten cross-functional teams in three countries throughout the last five years.

1. Letting the team go:
How, When and Why?
Agile Tour Vilnius 2019
Denis Salnikov

2. About me
● Denis Salnikov, 28 y/o
● Scrum Master @ Finleap Connect
● Berlin, DE
● 6 years in Agile and IT
● @d.salnikov23

3. Why?

7. “The best architectures, requirements, and designs emerge from self-organizing
teams.”
Agile Manifesto
“Scrum Teams are self-organizing and cross-functional.
Self-organizing teams choose how best to accomplish their work, rather than
being directed by others outside the team.”
Scrum Guide

8. Employees motivation
Reasons

9. Improving results & outcomes
Reasons
Employees motivation

10. Eliminating Bus Factor
Reasons
Improving results & outcomes
Employees motivation

11. How?

12. Define “Where?” and “Why?”

13. Product Mission

14. Product Vision
Business Value canvas (left) & Value Proposition canvas (right)

15. Workshop on defining the product’s Mission & Vision

16. Create conditions (“the ship”)
Define “Where?” and “Why?”

17. Schneider Culture Model

18. Company Values workshop

19. Create conditions (“the ship”)
Define “Where?” and “Why?”
Catch a fair wind

21. Create conditions (“the ship”)
Define “Where?” and “Why?”
Catch a fair wind
(Re-) Form the team

22. Scrum Team Kick off
● Intro to the Product
● What makes us a team and motivates us? *
● Scrum rules and values
● Definition of Done
● Working agreements **
● Other agreements
* Management 3.0
** Can use Core Protocols

23. What makes us a team and motivates us?
Personal maps, Moving Motivators, Competency Matrix
(Management 3.0)

24. Scrum rules and values
Scrum Values Game

25. Definition of Done and Working Agreements

26. Create conditions (“the ship”)
Define “Where?” and “Why?”
Catch a fair wind
(Re-) Form the team
Apply and adapt practices

27. Adapting to the ship
● Engineering practices
○ Pair programming
○ Mob programming
○ TDD
○ Test automation
○ etc.
● Infrastructure
○ Continuous integration
○ Continuous deployment
● Flow optimization
○ From “push” to “pull”
○ WIP limits
○ Cycle time & Lead time

28. Catch a fair wind
Observe and assist
Create conditions (“the ship”)
Define “Where?” and “Why?”
(Re-) Form the team
Apply and adapt practices

30. When?

31. Risk factors
Artificial team

32. Team does not “own” the process
Risk factors
Artificial team

33. Team does not “own” the process
Risk factors
Artificial team
Unstable team composition

34. Team does not “own” the process
Risk factors
Artificial team
Unstable team composition
Low level of product
consciousness

35. Organization on the verge of
change
Team does not “own” the process
Risk factors
Artificial team
Unstable team composition
Low level of product
consciousness

36. Catch a fair wind
Observe and assist
Create conditions (“the ship”)
Define “Where?” and “Why?”
(Re-) Form the team
Apply and adapt practices

38. Good Scrum Master makes himself indispensable for the team
Great Scrum Master makes himself unnecessary but desired
Geoff Watts

39. Thank you!
@d.salnikov23