We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byCedric Norsworthy
Modified about 1 year ago
© 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
© conchango Scaling Agile Teams Architect Insight Conference Colin Bird & James Dawson March 2007.
© conchango Agile Architecture Microsoft Architect Insight Conference Howard van Rooijen
Colin Bird Founder A Perspective on Agile Development.
Agile development By Sam Chamberlain. First a bit of history..
Introduction to Agile. Objectives High level overview o Agile o Scrum Take Home Message o Gain enough of an understanding of Agile and Scrum to see how.
Agile Methodology. -Dhanashree Kumkar -Plus91 Technologies.
Dr. Tom WayCSC Software Processes CSC 4700 Software Engineering.
Im an Agile Test Manager: Do I really exist? A discussion and debate David Evans & Ivan Ericsson SQS Group Limited Test Management Forum London, 24th October.
An Overview of Agile L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n.
Software Development Models: Waterfall and Spiral Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 21, 2012.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Scuola Politecnica Dipartimento DITEN Università degli Studi di Genova An Introduction to Scrum and XP Prof. Riccardo Berta.
COPYRIGHT © 2012 ALCATEL-LUCENT. ALL RIGHTS RESERVED. 1 Agile documentation development methodology Giby Panicker and Judith Benjamin 1-Dec-2012.
Tuesday, June 8 th, Agile Development-Successful Delivery & Implementing Across the Enterprise.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
BEFORE AGILE METHODS Other Engineering fields development models were used, ie: Waterfall Method: Intensive planning and refactoring before coding is actually.
Chapter 3 Agile Software Development (2/2) Yonsei University 2 nd Semester, 2013 Sanghyun Park.
Agile Methodologies: Comparative Study and Future Direction 林佳蓁 資工 4B.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Chapter 3 – Agile Software Development Pepper modification of Sommerville presentation & Colm O’hEocha – AgileInnovation Ltd presentation 1Chapter 3 Agile.
Stephen Chief Strategy Officer Telerik
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Does it work with Data Warehouses?. “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.
© conchango Scrum for Team System.
Chapter 2 Software processes. Topics covered Software process models Process activities Coping with change.
CMPS 116 Software Design Project. Introduction Instructor: Dr. Huahai Yang IBM Research – Almaden Former SUNY Albany Programming.
Agile Software Development Matt Rice November 27, 2006.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Agile Assessment Gadi Lifshitz, Ayelet Kroskin, Barak Yagour, Yael Dubinsky.
Chapter 3 Agile software development 1 Chapter 3 – Agile Software Development.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Agile Architecture Prabhu Venkatesan for COMP-684.
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
Agile Software Development Chapter 3 – Lecture 1 Adrián Susinos.
Pragmatic Testing in Agile Projects Dr Stuart Reid Testing Solutions Group Test Management Summit, London 28 th January, 2009.
Keith McMillan Principal, Adept Technologies Copyright (C) 2008, Adept Technologies llc.
Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why? The Agile Manifesto: Individuals and interactions over.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
Agile Project Management with Scrum. Resource links
Agile Software Development Robert Moore Senior Developer Curtin University.
Dr. Rob Hasker. What if every project used Scrum? Why might Scrum not be perfect for every project? Hard to get the big picture Early choices may have.
Intro to Scrum. What is Scrum? An answer to traditional “fixed cost / strict requirements” contracts which had very high rates of failure Recognizes the.
Agile Development Implementation Considerations. Agile software development is a methodology based on iterative and incremental development, where requirements.
Successful Software Practice How to successfully work as a team to create software Chris Mendes, Chief Technology Officer Sirca Limited March 2012.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Presentation from: See Also: scrumreferencecard.com/ScrumReferenceCard.pdf.
Ni.com Introduction to Agile and Scrum Speaker/Author: Paul Packebush Section Manager, Corporate Metrology Author:Logan Kunitz Staff Calibration Engineer.
© 2017 SlidePlayer.com Inc. All rights reserved.