1. Scaling Agile Organically
Presented by
Damon Poole
Agile Coach & Founder of Nexxle

2. @DamonPoole Highlights
Independent Agile Consulting
Founder at Nexxle
Chief Agilist
Enterprise Transformation
Built Agile Delivery team
800 Team Transformation
Acquired by
Founder, CEO, CTO
Past President

3. The Genesis of the Agile Manifesto
“Lightweight” Methodologies from the ’90s, represented during the creation of the Agile Manifesto
Scrum (1993)
XP (1996)
Crystal Methodologies (1998)
DSDM (1994)
FDD (1997)
Distilled Principles and Values
Agile Manifesto (2001)
17 authors at a gathering at Snowbird Ski Resort in Utah in 2001
“The principles and values in the Agile Manifesto were abstract and distilled from the signatories’ experiences and from 5 specific ‘lightweight’ methodologies that some of the signatories were working on at the time. Some of these predated the Agile Manifesto by 6 years.”

4. Scrum’s Connection to the Agile Manifesto
Continuous delivery of valuable software
Business people and developers must work together daily
Trust them to get the job done
The best architectures, requirements, and designs emerge from self-organizing teams.
Customer collaboration
Product Owner
Self-organizing team
Individuals and interactions
Responding to change
Backlog
Iteration
Scrum Master
Give them the environment and support they need
Simplicity--the art of maximizing the amount of work not done--is essential.
Iteration planning
Iteration Review
Standup
Working software is the primary measure of progress
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Progress tracking
Shippable increment every 1-4 weeks
Deliver working software frequently
Retrospective

5. Your Existing Traditional Ecosystem
Agile Transformation Capability and Capacity
Product Management / Business Units
Portfolio, Program & Project Management
Leadership & Management Behaviors
Policies & Procedures
QA / Testing
Software Development
User Experience
Process Infrastructure / Tools
Deployment / Operations

6. Throwing out the Baby with the Bathwater
“Scrum doesn’t have that”
Traditional ecosystem
Agile ecosystem
Project B
Project C
Project A1
Project A2
Project D
Project E
Agile Coach
Use of Scrum
Supportive manager (s)
Some training
Years of experience
Policy and procedure
Experienced project, program, and portfolio managers
Institutional support and “muscle memory”

7. Grow Towards an Agile Ecosystem
“Learning Agile, transforming an organization to Agile, these are things that one grows into. It doesn’t happen all at once. And like anything that grows, it is a slow, gradual process. We must be patient.”
ICP_ACC: 6.1.1
ICP_ACC: 6.2.1
ICP_ACC: 6.3.2
Image: public domain

8. Grow Agile Embedded Within Your Traditional Ecosystem
Project B
Traditional ecosystem
Project D
Project A1
Agile ecosystem
Project C
Project E
Project A2
Use whatever traditional mechanisms are in place to support your Agile efforts until such time as there is an Agile equivalent available. Example: continue to use traditional program management to coordinate multiple Agile teams.
Scrum on its own does not include multiple-team guidance. It is left as an exercise for the reader.
“Give them the environment and support they need, and trust them to get the job done.”
“Individuals and interactions over processes and tools”

9. Multi-Team Guidelines
Grow efforts from a single team to needed capacity
Truly releasable every iteration
Limit projects in progress
Reduce dependencies
Focus on removing and reducing complexity rather than accommodating it
Treat Agile expansion as any other project in your portfolio, but run it in an Agile manner

10. Accommodation Example – Dependencies
Iterations of work
TEAM A
Dependency
TEAM B
Iteration 1
Iteration 2
Iteration 3
Iterations not releasable
Coordination problems
May cause a delay

11. Splitting Stories to Simplify Dependencies

12. Coordinating the Work for a Story within the Same Iteration
Iterations of work
TEAM A
TEAM B
Iteration 1
Iteration 2
Iteration 3
Problems can now be resolved within the same iteration
“Working software is the primary measure of progress.”

13. Agile Techniques Related to Growth
Daily team coordination, aka “Scrum of Scrums”
Regular multi-team retrospectives
Co-planning
Regular multi-team reviews
Small stories (Rule of thumb: 2 stories / dev / week)
Escalation tree
Coordinated cadences
Refactoring
Automation

14. Synch Points for Interdependent Teams
Daily Leadership Escalation Meeting
Within a given value stream
BACKLOG
TEAM
Scrum, two week iterations
Daily SoS
BACKLOG
TEAM
Scrum, one week iterations
BACKLOG
TEAM
Continuous
VALUE STREAM MANAGERS
Kanban
PRODUCT
All-team review
All-team retro
PROGRAM

15. Iteration Based Portfolio and Program Management
Teams
Iterations
Planned Work
BACKLOG
TEAM
BACKLOG
TEAM
Funding and Priority Based Decision Making
BACKLOG
TEAM
BACKLOG
TEAM
BACKLOG
TEAM
BACKLOG
TEAM
“Responding to change over following a plan”

16. Cycle Time Customer Requests Product Updates
“There are many ways to measure ‘Agility.’ However, one of the most objective and non-localized methods is to measure the time from when a customer requests something to when they get something in response that they can use.”
ICP_ACC: 6.1.1
ICP_ACC: 6.2.1
ICP_ACC: 6.2.2
ICP_ACC: 6.3.3
ICP_ACC: 6.4.2
ICP_ACC: 6.5.1
Product Updates

17. A Cycle Time Based Measure of Agility
Traditional
A year or more
Near
Within a quarter
Basic
Within 4 weeks
Intermediate
Within 2 weeks
Advanced
Within 1 day
ICP_ACC: 6.1.1
ICP_ACC: 6.2.1
ICP_ACC: 6.2.2
ICP_ACC: 6.3.1
ICP_ACC: 6.3.2
ICP_ACC: 6.3.3
ICP_ACC: 6.4.2
ICP_ACC: 6.5.1
Here, cycle time refers to the time it takes for a user request to get from the user into production. It must be along an official path, which means it must be documented and not part of any expedited or exception based process. Also, if work must be part of a funded project, then either there is an official way to add an important new item and the full time for that process must be included or the full time it takes to get a project funded must be included.

18. Measuring Agility (Primary Measures)
Traditional
Near
Basic
Intermediate
Advanced
Cycle Time
Year or more
Quarter
4 weeks
2 weeks
1 day
Customer involvement
Infrequent
Feedback on completed work at least once every four weeks from real users of the solution or a reasonable proxy
Feedback on completed work at least once every two weeks from real users of the solution or a reasonable proxy
Feedback on completed work at least once per week from real users of the solution or a reasonable proxy
Continuous involvement of real users of the solution
Quality
No definition of done
Steps are being actively taken to move to the basic level
There is a definition of done. Steps are being taken to automate all testing and deployment activities.
The definition of done was agreed to by most parties responsible for getting work to done and it is generally followed.
The definition of done is agreed to by all parties and is strictly followed. All testing and deployment is automated
Morale
Not yet at the basic level and there is no move in that direction
People feel like their work is part of a shared goal.
People have some choice in what they work on, deciding how to do it, and estimating the amount of effort required
People are happy, supported, trusted, safe, and feel a sense of purpose, they feel it is one of the best places they have ever worked
“Just looking at any one of these four measures is misleading. For example, a fast turnaround of things customers don’t want with low quality and overworked employees is not sustainable. True success comes from moving all of these measures forward.”
ICP_ACC: 6.1.1
ICP_ACC: 6.2.1
ICP_ACC: 6.2.2
ICP_ACC: 6.3.1
ICP_ACC: 6.3.2
ICP_ACC: 6.3.3
ICP_ACC: 6.4.2
ICP_ACC: 6.4.3
ICP_ACC: 6.5.1

19. Start With a Single Team – Add-on as Needed
“The best architectures, requirements, and designs emerge from self-organizing teams.”
TEAM
Grow
Added
Weekly co-planning
Co-iteration review
Coordinated cadence
TEAM
Added
Value Stream Product Manager
Daily stand-up of stand-ups
Retro of retros
Start
TEAM
Iterations of work

20. Your Agile Capabilities and Capacity
Additions:
Appropriately staffed Scrum Master, Product Owner, manager, & coach mentorship and training program
x-Functional leadership team to handle multi-team impediments
Senior Tech Lead experienced in Agile coding and testing
Experienced Agile xFormation expert
Agilist UX expert
Devops expert
Additions:
Sr. Scrum Master or Agile Coach
Experienced Agile Product Manager
x-Functional Agile adoption team, run as an Agile team
Experienced Scrum Master
Experienced Product Owner
Everyone on team formally trained
All managers connected to team formally trained
“Air cover” for the team and managers to learn
“Give them the environment and support they need, and trust them to get the job done.”

21. Rinse, Repeat Is our current Agile ecosystem stable?
Increase capability, inspect, adapt
Add more people to Agile ecosystem if desired
Yes No
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”

22. Punkaj Jain
@JainPunkaj 22

23. Your trusted partner for Agile software product development.
Synerzip
Your trusted partner for Agile software product development.
Accelerate the delivery of your product roadmap
Address technology skill gaps
Save at least 50% with India software development
Augment your team with optional on-site professionals

24. Synerzip Clients

25. Connect with Synerzip @Synerzip linkedin.com/company/synerzip
facebook.com/Synerzip

26. Next Webinar Colin MacNaughton
Real-time with AI – The Convergence of Big Data and AI
Thursday, October 18, 2018 at Noon CT
Presented by
Colin MacNaughton
Head of Engineering, Neeve Research

27. TEXAS | SILICON VALLEY | NYC | INDIA