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.
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
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
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.
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
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
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”