This document discusses how, when, and why to let a team go in an agile project management context. It outlines several factors to consider, including whether the team "owns" the process, the level of product awareness, and team stability. It also provides guidance on building conditions for the team to succeed initially by establishing culture, values, and vision, then supporting the team in adopting practices like Scrum, continuous improvement, and self-organization over time. Regular diagnostics of the product, process, and company are recommended to evaluate when it may be time to restructure a team.

1. Letting the team go:
How, When and Why?
Lviv Project & Product Management Day 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. Improved results & outcomes
Employees motivation
Reasons

10. Scaling up
Employees motivation
Improved results & outcomes
Reasons

11. Eliminating Bus FactorEmployees motivation
Improved results & outcomes
Scaling up
Reasons

12. Business agility
Employees motivation
Improved results & outcomes
Scaling up
Eliminating Bus Factor
Reasons

14. How?

15. Building/repairing the ship

16. Company culture

17. Schneider Culture Model

18. Company Values workshop

19. Product’s
Mission & Vision

20. Mission

21. Business Value (Lean) & Value Proposition canvases

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

23. ● Company culture and values
● Product’s mission and vision
● Product metrics
Building/repairing the ship

24. ● Company culture and values
● Product’s mission and vision
● Product metrics
● Scrum basics *
* We don’t do Scrum just for the sake of doing
Scrum. Our goal is to create and develop a
successful Product applying short feedback
loops from the market and users.
Building/repairing the ship

25. Fair wind

27. “The essence of Scrum is a small team of people.”
Scrum Guide

28. (Re-) Forming the team

29. ● 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
Team kick-off

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

31. Scrum rules and values
Scrum Values Game

32. Definition of Done & Working agreements

33. Adapting to the ship

34. Pair/Mob programming, TDD, etc.

35. Infrastructure and test automation

36. Flow optimization

37. Adapting to the ship
● Engineering practices
○ Pair programming
○ Mob programming
○ TDD
○ Test automation
● Infrastructure
○ Continuous integration
○ Continuous deployment
● Flow optimization
○ WIP limits
○ Cycle time

38. Support from spirit of the sea

40. ● Teaching Scrum rules and basics
● Providing suitable tools and
practices
● Servant leadership
● Facilitation
● Asking stupid questions
● Highlighting problem areas
● Conflict resolution
● Removing impediments
● Coaching and mentoring
Support from spirit of the sea

41. When?

42. Team does not “own” the process
Risk factors

43. Artificial teamTeam does not “own” the process
Risk factors

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

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

46. Tuckman’s Model

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

48. Team diagnostics
● Product
○ Product metrics
○ Feedback from stakeholders and
users
○ Financial results
○ T2M & A2I

49. Team diagnostics
● Product
○ Product metrics
○ Feedback from stakeholders and
users
○ Financial results
○ T2M & A2I
● Process
○ Stability
○ Kaizen (Continuous improvement)
○ Engineering practices & technical
excellence
○ Self-diagnostics

50. Spotify Squad Health Check

51. Company diagnostics
● Employees happiness
○ eNPS
○ Turnover
○ Gallup Q12
● Financial results
● OKRs

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

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

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

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

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

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

59. Recommended literature
“Scrum - A Pocket
Guide” by Gunther
Verheyen
“Scrum Mastery”
by Geoff Watts
“Management 3.0”
by Jurgen Appelo
“Coaching Agile Teams”
by Lyssa Adkins

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

61. Thank you!
@d.salnikov23