Presented at ThreeBridge Solutions at Minneapolis SAFe Meetup on Aug 2nd, 2018. This talk walked through the challenges of a large scale, green-field, application development and how we solutioned efficient communication across the program in order to maximize software engineering efficient delivery of value.

1. Scaling Agility –
A Case Study
Presented by
Kevin Burns
August 2, 2018
@
ThreeBridge Solutions
SAFe Meetup
kburns@sagesw.com, @kevinbburns 1

2. History and Experience
2

3. 3

4. kburns@sagesw.com, @kevinbburns 4

5. kburns@sagesw.com, @kevinbburns 5
Introductions
Name
Role
Client
How many teams are you working with?
What do you want to learn tonight?
Do you have any questions you want answered tonight?

6. Agenda
• Opportunity
• Challenge
• Structure
• Planning
• Velocity
• Learn and adjust
6kburns@sagesw.com, @kevinbburns

7. Goals & Objectives
•Increase our understanding of…
•…how to scale agility
•…organizational challenges and solutions
•…coaching techniques and tools
•…coaching practices
7kburns@sagesw.com, @kevinbburns

8. Let’s do a live poll.
Start a new
text message.
To: 22333
Text message:
kevinburns785
Send

9. kburns@sagesw.com, @kevinbburns 9

10. kburns@sagesw.com, @kevinbburns 10

11. kburns@sagesw.com, @kevinbburns 11

12. kburns@sagesw.com, @kevinbburns 12

13. kburns@sagesw.com, @kevinbburns 13

14. Westrum Model: How orgs process info
Pathological Bureaucratic Generative
Power oriented Rule oriented Performance oriented
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure scapegoating Failure justice Failure inquiry
Novelty crushed Novelty problems Novelty implemented
kburns@sagesw.com, @kevinbburns 14

15. Coaching, Mentoring, Learning
How do we learn?
What helps us learn?
How psychologically safe is our environment?
15kburns@sagesw.com, @kevinbburns

16. Building an ideal work environment
16

17. Case Study Challenge
• Large green-field application development program
• New to agile
• Interdependencies across the teams to deliver a single product
• Integration dependencies required coordinated planning and
communication throughout the program
• Efficient collaboration across the teams was essential to successful delivery
kburns@sagesw.com, @kevinbburns 17

18. Case Study Context
kburns@sagesw.com, @kevinbburns 18
• Projects were taking longer than expected to deliver
• Budget forecasting wasn’t good
• Software quality suffered due to transient team members
• Pockets of agile practices existed but there was a strong desire for a program-
level structure for agile adoption
• Contention was happening at code implementation versus upstream in planning
• Solution was to create stable delivery teams that would fulfill program-level
strategic goals quarter-over-quarter

19. Case Study Team Structure
• The program had around 150 business and IT team members
• 10 Scrum and Kanban teams all working together to deliver a single
product.
• Average team size was 10
• Teams were cross-functional with representation from Business,
Architecture, Software Engineering, and Quality Assurance
Engineering
kburns@sagesw.com, @kevinbburns 19

20. Case Study Approach
• Defined repeatable and iterative structure for planning process
• Facilitate planning exercises relatively consistently across teams
• Iteratively learn, adjust, and improving the communication of cross-team planning, work sequencing, and
dependency management each sprint
• Conduct quarterly program-wide retros and planning events
• Scrum-of-Scrums was established to handle cross-team dependencies
• Lead architects worked a few sprints a head to reduce the challenges related to cross-team dependencies
• Code reviews were an important component of the quality assurance process
• Frequent (at least once day) code check-ins, builds, and test automation helped support a fast feedback loop
• We started with 1 week sprints to facilitate a quick learn and adjust cycles and then moved to 2 week sprints
• The 1-2 week learn and adjust cycles helped the teams achieve a predictable velocity for planning as well as a
focus on what was most important next in the queue
kburns@sagesw.com, @kevinbburns 20

21. Case Study Results
• Quarterly program plans provided clear milestone priorities and objectives across all teams
• Once teams realized the level of interdependency we had to build a single product, they become
much more plan-full and interested in fast learning feedback loops using CI/CD practices
• Planning became easier, quarter over quarter, as teams took ownership of their throughput
potential (velocity)
• We achieved a relatively stable, program-wide, throughput (or velocity) after two quarters
• Team performance increased as teams matured through forming, storming, norming and
performing phases of Satir model
kburns@sagesw.com, @kevinbburns 21

22. Team metrics used for planning, learning, and
adjusting
kburns@sagesw.com, @kevinbburns 22
Team Metrics
Reporting Master with cone o

23. ?
Kburns@sagesw.com
@kevinbburns
kburns@sagesw.com, @kevinbburns 23

24. Slides we didn’t get to but relevant to topic.
• We didn’t review the slides beyond this point but I’ve included them
just in case folks are interested in review them.
kburns@sagesw.com, @kevinbburns 24

25. Conway’s Law
Organizations which design systems are constrained to
produce designs which are copies of the organizations
communication structure.
— M. Conway (1967)
The law is based on the reasoning that in order for a software module to function,
multiple authors must communicate frequently with each other. Therefore,
the software interface structure of a system will reflect the social boundaries of the
organization(s) that produced it, across which communication is more difficult.

26. Matrix Org Efficiency Fallacy
BA Group
QA Group
Dev Group
TechnicalTalentDomains
SocialBoundaries
Interface
Interface
Proj 1 Proj 2 Proj 3
It’s more efficient to embed business and technical team members in a business and
technical domain for the long-haul as opposed to renting them for short-term projects
Ops Group
Interface

27. Conway’s Law
UI service area
Data service area
App service area
TechnicalTalentDomains
SocialBoundaries
Interface
Interface
Proj 1 Proj 2 Proj 3
Ops Group
Interface

28. PerformingForming Storming Norming
Let’s reduce the impact of ‘the change process’ by creating stable product (service) or domain teams, i.e.,
teams that stay together to deliver incremental service value within their application domain of expertise. 28

29. In In In In In In
Team A
Team B
Team C
Team D
Progs / Projs 1 Progs / Projs 2 Progs / Projs 3
Product (service) capability delivery teams are challenged with multiple competing support and project priorities
as they iteratively deliver and deploy software. This can cause inefficient context shifting and churn in solutioning
and delivery process. This can also lead to fragility and tech debt within the code-base. Consider more intentional
focus on prog/proj prioritization/ranking, decomposition, and optimal work sequencing across stable platform
service delivery teams. Consider Work-In-Progress agreement limits/targets to support efficient delivery.
Rn Rn Rn
Stories filling
iteration queues
Platform Service Area Release Planning

30. A
Team
PO SA
SQA SME
SPM
PO SA
SQA SME
SPM
B
Team
C
Team
D
Team
E
Team
F
Team
G
Team
H
Team
I
Team
J
Team
Platform 1 Platform 2 Platform 3 Platform 4 Platform 5
Project/Solution 1Project/Solution 2 Project/Solution 3
Solution Team members are challenged with multiple competing project priorities as they iteratively
deliver and deploy software. This can cause inefficient context shifting and churn in solutioning and
delivery process. This can also lead to fragility and tech debt within the code-base. Consider Work-In-
Progress agreement limits/targets to support efficient delivery.
Solution Team Solution Team
PO SA
SQA SME
SPM
PO SA
SQA SME
SPM
PO SA
SQA SME
SPM
Solution Team Solution Team Solution Team
Platform
Release
Planning

31. Multi-month
Monthly
2-weeks
Leadership
T-Shirt Sizing
X-S 1 Sprint
S <1 month
M 1-3 months
L 3-9 months
X-L >9 months
Team Planning-Poker
Fibonacci Sizing
(1,2,3,5,8,13,20,50,100)
Team task hours to
capacity (2,4,6)
Solution Decomposition
Sizing Pattern

32. Cost of Context Shifting
https://www.infoq.com/articles/multitasking-problems
https://blog.codinghorror.com/the-multi-tasking-myth/
Quality Software Management: Systems Thinking, Gerald Weinberg
342
46%
213
31%
134
18%
26
3%
11
0%

33. Context Shifting References
• “…it takes an average of 23 minutes to get back to the task.”
• “If your product owners don’t have the capacity to deal with requests … it will cost
you a developer, per team, every year.”

34. How is work assigned & managed?
Traditional Project Model
• PM assigns
• PM Command and Control
• Telephone problem for work
handoff
• Get stuff done
• Wait inefficiency
• Work queuing inefficient
• Context shifting waste
• Late bug fixing cost
• Lack of user understanding
• Tech Debt and Entropy
New Product Model
• Team coordinates, self-organizing
• PM Servant Leadership
• Collaboration on value, definition
of done, and quality
• Get most valuable stuff done
• Wait time reduced
• Optimization of work queue
• Reduced context shifting
• Early bug fixing savings
• Optimize user understanding
• Refactor and Elegancy
How much PM and Mgr capacity would be freed-up if teams were self-organizing?

35. Control Number of Active Projects
1
2
3
4
1
2
3
4
Cost of Delay Savings Late Start Advantages
Time to Deliver
Time to Deliver Time to Deliver
Don Reinertsen’s 2GLPD

36. User
UX, BA, QA, SME
Business
Valuable
Design Usable
Software Engineering
AD, DD, DA
Business Customer
PO, SM, BL
Technically
Feasible
Do you have the right balance to deliver Quality, Value, & Innovation?
Quality
Innovation
Value

37. Do you have the right balance?