17spm_L16
Scaling Up Agile Processes
SPM 2017 © Ron Poet Lecture 16 1
Multiple Team Projects
� Agile approaches mainly describe how to run a single team on a
project lasting a few months and with uncertain requirements.
� What about larger projects with multiple teams and longer timescales?
� Most larger agile processes are based on Scrum.
o Large Scale Scrum
SPM 2017 © Ron Poet Lecture 16 2
o Large Scale Scrum
o Scaled Professional Scrum
o Scaled Agile Framework
Larger Projects
� One obvious approach is to take a pure agile process that works and try
and scale it up.
�Scrum is the usual starting point.
� Other approaches provide a list of principles, which can be helpful.
� The main issues are:
�Managing multiple teams working on the same project.
�Continuing support after product delivery.
�Managing multiple projects. The organisation would like a
pipeline of potential work: a backlog of projects.
3SPM 2017 © Ron Poet Lecture 16
Large Scale Scrum
� Sprint planning is now split into two parts.
o All teams choose the stories they will work on in the next sprint.
o Each team breaks their stories into tasks in the usual way.
� Daily meetings are in two parts.
o Each team has the usual stand up meeting.
o Each team sends one representative to a Scrum of Scrums often
called a Town Hall Meeting to coordinate activities.
� The sprint review includes everyone.
o Each team has its own retrospective.
� A chief product owner works with several area product owners.
o There will be a pre-sprint product owners meeting.
4SPM 2017 © Ron Poet Lecture 16
Scaled Professional Scrum
� The Nexus is the point of contact for several (up to 9) teams.
� There is a single product owner and a single product backlog.
� There is an overall coordinating team called the Integration Team.
o It coordinates the individual development teams.o
o It operates and uses scrum in the same way as a development team,
but focusses on coordinating teams rather than producing code.
� There is a Nexus planning meeting at the start of each sprint.
o Focuses on dependencies between the work of individual teams.
� There is a Nexus Daily Scrum.
o Equivalent to a Scrum of Scrums.
5SPM 2017 © Ron Poet Lecture 16
Scaled Agile Framework (SAFe)
(More Scrum)
� It maintains a portfolio of future work.
o A backlog of projects.
� This is summarized in the Big Picture, a diagram of this project
backlog.
� The strategic portfolio section contains a number of value streams.
o Product lines.
� The program section contains a number of ‘epics’ which can lead to
new programs and be added to the program backlog.
o Each will have a release train.
� The development teams section lists all the teams and their iteration
and release plans.
6SPM 2017 © Ron Poet Lecture 16
SAFe: Additional Roles
� Product Manager.
o Responsible for the program backlog.
� Release Train Engineer
o In charge of one program and manages the Scrum Masters.
o Supported by a team.o Supported by a team.
� Portfolio Management Team
o Looks after the financing.
� The actual development teams use Scrum / XP
SPM 2017 © Ron Poet Lecture 16 7
Feature Driven Development
SPM 2017 © Ron Poet Lecture 16 8
Origins
� Object oriented languages such as C++, Smalltalk and Objective C
became popular in the mid to late 80s.
� They introduced an entirely new programming paradigm.
� There was a mismatch between existing software design
methodologies and OO programming.methodologies and OO programming.
� A number of people worked on bridging techniques that modified
existing techniques to add OO features.
o Database design techniques such as Entity-Relationship diagrams
we called object oriented design approaches.
o Edward Yourdon was prominent in this area.
� This evolved into object oriented analysis and the Coad/Yourdon
methodology.
o Introduced by Peter Coad.
SPM 2017 © Ron Poet Lecture 16 9
Origins (2)
� In 1997 Peter Coad and Jef De Luca were brought in to rescue a failing
project by a Singapore bank.
o It had run for 2 years without results.
o They completed it in 15 months with a team of 50.
� It is a mixture of traditional and agile approaches.� It is a mixture of traditional and agile approaches.
o Not efficient enough for small teams of less than 10.
o Scales up well for larger projects.
SPM 2017 © Ron Poet Lecture 16 10
Features
� A Feature is a unit of client valued functionality.
� It is the equivalent to a use case or user story.
� There is a special notation for naming features:
o Action … Result … Object.
o E.g. Calculate (action) the total amount (result) of a sale (object).o E.g. Calculate (action) the total amount (result) of a sale (object).
� They must be small enough to be designed, built and tested within 2
weeks.
o Larger features should be broken down into smaller ones.
SPM 2017 © Ron Poet Lecture 16 11
Feature Hierarchy
� Related features are grouped into Feature Sets.
� There is a special naming convention:
o Action-ing … Object
o E.g. Making (action) a sale (object)
� Related feature sets are grouped into Subject Areas.
o Object … Management
o E.g. Sales (object) Management.
SPM 2017 © Ron Poet Lecture 16 12
Processes
� Create the Object Model.
o This is essentially object oriented analysis.
o The specification documents are analysed and objects and classes
of objects are identified.
o The relationships between these objects and classes is discovered.o The relationships between these objects and classes is discovered.
o A UML class diagram is produced.
� Build a Feature List.
o A top down approach is used to identify subject areas, then feature
sets and finally features.
� Plan the Releases
o The feature sets are assigned to different programming teams and
the release plan is developed.
SPM 2017 © Ron Poet Lecture 16 13
Processes (2)
� Each team selects a group of features that can be developed in 2
weeks.
� This forms a Work Package.
� The features are designed
o Sequence diagramso Sequence diagrams
o User Interfaces
o Methods
o Class Interfaces
� Class Owners build and test their classes.
� At the end of 2 weeks, all the work packages are integrated into the
Main Build.
� The next work package is then developed.
SPM 2017 © Ron Poet Lecture 16 14
Roles
� Project Manager with traditional responsibilities.
� Chief Architect: responsible for overall design of the system.
o Responsible for conceptual integrity, a single vision for the whole
system.
� Development Manager: responsible for day to day management of the � Development Manager: responsible for day to day management of the
project.
� Chief Programmer: Really a team leader.
� Class Owner: A developer. Each class is owned by 1 person.
� Domain Expert: responsible for user requirements and representing the
business.
SPM 2017 © Ron Poet Lecture 16 15
Deliverables
� Object Model
o Class diagram
o Sequence diagrams
� Feature List
� Development Plan� Development Plan
o Schedule for subject areas
o Schedule for feature sets and the responsible chief programmer
o Class owner list.
� Feature Work Package: one for each team per each iteration.
� Completed Features: ready for release.
� Parking Lot Report: status of each feature set.
� Burn-Up chart: an earned effort chart.
SPM 2017 © Ron Poet Lecture 16 16
Key Aspects
� Object Modelling
o UML diagrams for classes, sequence diagrams etc.
o An object modelling tool should be used because it is easier to
track changes.
o Must be kept up to date.o Must be kept up to date.
� Class ownership
o Each class has one owner who is responsible for making all
changes to that class.
o This simplifies problem resolution.
o Opposite of egoless programming (XP).
SPM 2017 © Ron Poet Lecture 16 17
Key Aspects (2)
� Feature set teams
o All members work on a related part of the system
o Encourages ownership.
o Makes multi-team projects possible
o The temptation to keep shifting members from team to team should o The temptation to keep shifting members from team to team should
be resisted. (so not XP)
� Tracking Features
o Features are the main deliverables and are tracked through their
lifetime.
� Code Inspections (code walkthroughs)
o A good way of finding bugs and transferring knowledge.
SPM 2017 © Ron Poet Lecture 16 18
Key Aspects (3)
� Regular Builds
o Can be run once per day.
o Main integration of new features at the end of each 2 week
iteration.
o A time to fix integration errors when they are small.o A time to fix integration errors when they are small.
o Always a working version for demonstrations.
o Need automatic regression tests.
SPM 2017 © Ron Poet Lecture 16 19
Issues
� FDD will work with multiple teams but:
� It is focussed on the code, the class structure, rather than other
considerations.
o Scrum and XP also focus on developing code early on, but they
SPM 2017 © Ron Poet Lecture 16 20
o Scrum and XP also focus on developing code early on, but they
don’t have an initial design to work from.
� It is important to get the class structure nearly right at the start of the
project.
� This limits it to projects where the basic requirements are fairly well
known at the start of the project.
� In general it is better to focus on the “what” rather than the “how” at
the start of a project.