© conchango Scaling Agile with TFS The Architecture Forum Colin Bird December 2006

© conchango Wasted Effort Features and Functions Used in a Typical System Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Always 7% Often 13% Sometimes 16% Rarely 19% Never 45% Rarely or Never Used: 64% Often or Always Used: 20%

© conchango Scrum on a Slide

© conchango Production Quality Code Every 4 Weeks Business can choose to release early when they see sufficient business value

© conchango Inside a Sprint Analyse Design Build-Test Deploy UAT Test Vertical Increments

© conchango What do we mean by Scale? Typical individual Agile team is 5-10 people Above this number the team doesn’t function efficiently Common interpretations of Scale 1.Large or many teams 2.Geographically dispersed 3.Agile adoption at an organisational level  Often all of the above!

© conchango Agile Fundamental Principles Scale means that it is even more important to understand the Agile fundamental principles and apply them Challenges to peer to peer communication Easy to fall into the command and control trap Don’t just apply an Agile Scale pattern that worked for someone else While there is value in the items on the right, we value the items on the left more. over Individuals & interactions Working Software Customer Collaboration Responding to Change Processes & Tools Comprehensive Documentation Contract Negotiation Following a Plan

© conchango Organisational Adoption When an organisation transitions from a few independent teams to corporate adoption of Agile as the project delivery standard Massive step change Poor communication of corporate vision for Agile Lack of training Imposition of standard corporate programme standards Departmental Structure Logistical limitations Cultural Impedance Leads to:  Lack of Actual agility at either project or organisational level

© conchango Scrum of Scrums Classic model for scaling Scrum projects Coordination across teams through the Scrum meetings Aggregated view of requirements Programme view of impediments Prone to Command & Control mentality Implied Hierarchy

© conchango Start with a beachhead team Early evangelists Opinion leaders Cannot start effectively if focus is spread too thin Give them the early infrastructural tasks Keep this team together until they’re succeeding Should be fully cross-functional Programmers, testers, DBAs, etc…

© conchango Start Small Time Initial Team Start with a “Beachhead” team and then build from there Add New Team members

© conchango Inter-team Communication Communities of common disciplines E.g. DBAs Informal team to team collaboration E.g. Resolve integration issue How do Multiple Teams work together?

© conchango Stagger Daily Stand-up Meetings Any team members can attend any other team stand-up meetings

© conchango Align Iterations Across Teams Enables Joint Planning Enables Joint Delivery Smaller Iterations In Phase

© conchango Distributed Teams Collocation is ideal Anything else is less than ideal! If the teams have to be distributed – minimise the communications gap Instant Messenger VOIP enables low cost voice communication - Skype Web Conferencing for team presentations – Wired Red, PlaceWare Good quality phone conference facilities Programme level wiki Face to Face meetings/working – swap team members Maintain daily “Stand-up” meetings Ensure the teams have an integrated development infrastructure Team Foundation Server and Visual Studio Team System Ensure regular integration of all teams output TFS Build & Deployment

© conchango Single Customer - Multiple Teams Single Customer Single set of prioritised requirements Joint Sprint Planning Separate Sprint Backlogs Dynamic team split from iteration to iteration Works well for a small number of teams Runs into issues above 3 teams Sprint Planning Common code base and check-in/out Code contention 1 st Step Scale Model

© conchango Multiple Customers Requirements independently prioritised If the Teams Are Independent Separate Product Backlogs Separate Sprint Planning Separate Sprint Backlogs But what if some requirements are shared? Each Customer Needs Their Own Product Backlog

© conchango Multiple Customers - Collaborating Teams We are looking for efficiency through code reuse If there is a small overlap of functionality and only a few teams  Teams can manage commonality through inter-team communication and collaboration Real World – Teams are interdependent Shared Code

© conchango Multiple Customers - Collaborating Teams If there is a large overlap of functionality Teams can manage commonality through a Stream Backlog to aggregate customer requirements And Through inter-team communication and collaboration Streams are logical groupings of requirements which can be split by Business Service E.g. CRM Architectural Service E.g. Web Platform Stream Backlogs – Logical Groupings of Requirements or Features Scale number of Streams Scale number of Teams

© conchango Customer and Technology Backlogs Customer facing teams can generate their own requirements for common “Platform” features Teams 1 & 2 are “Customers” for Team 3 Team 3 has a Product Owner who prioritises the Technical backlog Team 3 consults with Teams 1 & 2 while building their platform features Team 3 Sprint Review to show output Teams 1 & 2 can feedback Teams 1 & 2 integrate platform features into their own delivery in subsequent iterations Team 3 may work to a smaller iteration length, but still in phase with Teams 1 & 2 Team 3 may “Borrow” team members from Teams 1 & 2 – agreed in Sprint Planning

© conchango Putting It All Together - An Example Programme Product Ownership

© conchango Multi-team Engineering Practices Common coding standards & practices Common Source Control Plan source structure Automation of Build Deployment Testing Environments to support Independent Team Development Independent System Testing Regular Integration Testing UAT Load & Performance Testing Staging Production

© conchango Scaled Infrastructure Support

© conchango Scaling Summary Keep to Agile Principles Build up rather than “Big Bang” Prepare for scale but don’t be prescriptive Communicate widely Provide the infrastructure, tools and logistical support Mitigate corporate Programme reporting requirements Let the teams evolve their own inter-team communication and working practices But ensure common engineering practices and supportive infrastructure Be prepared for mistakes and unforeseen issues But ensure the lesson are learned and applied