The process of software development for reasonably small team (less that 9 people) is pretty straitforward. Usually it is based on Scrum or Kanban with some variations and simplifications. For huge team with more then 30 people it is not that obvious. For sure teams have interdependencies both in coding and requirements management that can really slow down development. For people and teams it looks like constant interruptions caused by other teams and management. The problem is that “classic” Agile doesn’t help. In this session we will consider methods of scaling Agile in huge teams.

1. Scaling Agile
Askhat Urazbaev
Agile Coach
ScrumTrek

2. Askhat Urazbaev
• ScrumTrek
• Agile Coach
• CEO
• In the past
• Programmer, manager, process
architect

3. Structure Practices Culture

4. STRUCTURE

5. Front End
Back End
Testers
Architect
OPS
6 ppl
8 ppl
4 ppl
Boss

6. Front End
Back End
Testers
Architect
OPS
6 ppl
8 ppl
4 ppl
BossToo long!

7. Why so long?
Product
Queue here Queue here

8. Product
Input > output
No life here

9. Feature team
• Mutual help
• Early integration
• Fast defect fixing
• No beurocracy
• Минимум
бюрократии
Size: 7±2

10. Boss
Feature Team 1 Feature Team 2 Feature Team 3
Architect
Poor
quality!
I cannot control
everything

11. Boss
Feature Team 1 Feature Team 2 Feature Team 3
Architect

12. Virtual Team
• Members of different teams
• Meet around problem
– Architecture, infrastructure, testing …
• Typically
– PO sync
– SM/TL sync

13. Spotify
http://agilerussia.ru/practices/spotifyscaling/

14. Flow
Design
Web
Core Lib
Backend
Video Encoding
iOS AndroidWinPhone
Testing

15. Same feature, different teams

16. Feature Team Stack
Android
iOS
C++
Obj C
Video
Java
JavaScript
HTML/CSS
Ruby/Pyth
on

17. Feature Team would be…
• Too large
• Hard to help each other
• Hard to deliver in a
sprint

18. Where’s
bottleneck?
Design
Web
Core Lib
Backend
Video Encoding
iOS AndroidWinPhone
Testing
Bottleneck

19. Bottleneck
Capacity
problem
Rework
problem

20. Fixing bottleneck
~throughput

21. Fixing bottleneck

22. Theory of constraint
• Identify the constraint
• Exploit the constraint
• Subordinate & synchronize to the
constraint
• Elevate the performance of the constraint

23. Identify
Type I
• Fast response
• Hardwork &
Overtimes
• No time for quality
Type II
• Waiting for result
• Long queue of
requests from
other teams

24. Exploit
• Transfer all possible
work to other teams
• Get rid of
unnecessary
meetings
• Get help for
administrative work

25. Subordinate
• Decrease plans to constraint

26. Team board

27. Elevate
• Hire and educate

28. Rework

30. “Integration” team
• Cross-component
team
• Where rework is
maximum
• SWAT-team
Size: 7±2

31. Backlog structure
Integration features
~ 30% of backlog
Team 1
Team 2
Team 3

32. Managing delivery team
structure
• Split into value streams
• Find bottleneck
• Cross-system and cross-component team
where rework is maximum
• Focus on the next constraint

33. PRACTICES FOR MANAGING
DEPENDENCIES

34. Backlog dependency
Team А Team B

35. Client and service teams
Product
Value
User story, CR, Bug, Feature
(but not task)
ServiceClient

36. Impact Mapping/Feature
Injection

37. Impact Mapping/Feature
Injection

38. http://www.slideshare.net/sgreene/dependency-management-in-a-large-agile-environment-presentation

39. Pairing story: Get From/Give To
• Client: GetFrom
• Service: GiveTo
• Use acceptance
criteria
• Don’t use inside of
team
• Sync by dates and
sprintshttp://blog.ciber.com/2013/planning-and-managing-dependencies-and-risks-in-agile/
As a Systems Engineer,
I want to get a
performance report
from Vendors A,B, and
C, so that I can
determine if their
software’s UI response
time will meet our .5
second threshold.

40. PI Planning

44. You are Agile Coach.
Team B have commited new
feature and broke team А’s
functionality
You can visit one retro. Which
team retro would you visit first?
A. Team A
B. Team B
C. Joint retro of А & B

45. “Self-defense”
It is team
responsibility to
cover its own
code with tests

46. CULTURE

47. In the middle of the
sprint people from
another teams bring in
new urgent tasks. You
could help but it will
broke your own
commitment.
What would you do?
A. Help immediately
B. Move task to the
next sprint

48. service
client

50. сервис
клиент

51. Managing urgent work in scrum
• Don’t care. It just lows
down your velocity
• Allocate a budget
• Have a person on duty

52. Policy
• Request is #1 priority
• Request is get fixed by
members of both
teams in 1 sprint
• Request is considered
as done if it is
integrated, tested, all
bugs are fixed and
closed

53. 4 “keystone habits” (by Ahmed
Sidky)
1. Communicating and
collaborating
2. Deliver in evolutionary slices
3. Integrate as early as
possible
4. Gather feedback from
multiple levels as early as
possible “Decentralized Control”

54. Askhat
Urazbaev
askhat@scrumtrek.r
u
askhat.urazbaev
@zibsun
askhatu