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

@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

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

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

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

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”

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

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”

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

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

Splitting Stories to Simplify Dependencies

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

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

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

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”

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

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.

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

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

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

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”

Punkaj Jain punkaj@synerzip.com @JainPunkaj 510.509.8447 22

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

Synerzip Clients

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

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

TEXAS | SILICON VALLEY | NYC | INDIA