Scaling Agile with TFS The Architecture Forum Colin

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

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

Scrum on a Slide © conchango 2006 www. conchango. com

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

UAT Test Deploy Design Analyse Vertical Increments Build-Test Inside a Sprint © conchango 2006 www. conchango. com

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. 2. 3. Ø Large or many teams Geographically dispersed Agile adoption at an organisational level Often all of the above! © conchango 2006 www. conchango. com

Agile Fundamental Principles • Scale means that it is even more important to understand the Agile fundamental principles and apply them • • • Challenges to peer communication Easy to fall into the command 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. Individuals & interactions Working Software Customer Collaboration Responding to Change over Processes & Tools Comprehensive Documentation Contract Negotiation Following a Plan © conchango 2006 www. conchango. com

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 2006 www. conchango. com

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 Scrum of Scrums Teams © conchango 2006 www. conchango. com

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 2006 www. conchango. com

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

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

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

Align Iterations Across Teams Enables Joint Planning Enables Joint Delivery Smaller Iterations In Phase © conchango 2006 www. conchango. com

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, Place. Ware 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 2006 www. conchango. com

Single Customer - Multiple Teams 1 st Step Scale Model • 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 © conchango 2006 www. conchango. com

Multiple Customers Each Customer Needs Their Own Product Backlog • 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? © conchango 2006 www. conchango. com

Multiple Customers - Collaborating Teams Real World – Teams are interdependent • 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 Shared Code © conchango 2006 www. conchango. com

Multiple Customers - Collaborating Teams Stream Backlogs – Logical Groupings of Requirements or Features • 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 Scale number of Streams • Streams are logical groupings of requirements which can be split by • Business Service • E. g. CRM • Architectural Service • E. g. Web Platform Scale number of Teams © conchango 2006 www. conchango. com

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 2006 www. conchango. com

Putting It All Together - An Example Programme Product Ownership © conchango 2006 www. conchango. com

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 2006 www. conchango. com

Scaled Infrastructure Support © conchango 2006 www. conchango. com

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 © conchango 2006 www. conchango. com