The document discusses various scaled agile project management frameworks like LeSS, SAFe, DAD, and DSDM. It summarizes findings from a white paper on adopting these approaches which found that the mindset is more important than the specific method. Organizations need to determine what fits their purpose and rely on experienced teams to decide on the appropriate blend of techniques. Training, multi-skilling teams, and ensuring strategic alignment are also important for successful adoption of agile project management.

1. THE PRACTICALITIES OF ADOPTING
SCALED AGILE METHODOLOGIES
Susan Clarke
28th September 2017

2. CONTENTS
1. Introduction
2. Overview of agile project management frameworks
 LeSS
 DAD
 SAFe
 Agile Project Framework (DSDM)
 DevOps
3. Play a game
4. APM white paper findings
5. Summary
6. Some useful links
7. Questions

3. INTRODUCTION
 Agile development terms are often used in the context of
Agile project management, but development is only a
part of the project life cycle.
 Agile development frameworks include
 Scrum
 Agile Extreme programming
 Kanban
 Lean software development
 However, agile development and project delivery do
have some common themes
 Iterative
 Flexibility and adaptability
 Customer input and focus

4. APM WHITE PAPER FINDINGS
 APM white paper to be published soon on adoption of scaled
Agile project management in the North West uncovered the
following practical experience:
 the adoption of “Agile project management” is still confused with “Agile
development” approaches.
 The overall view was that the number of organisations who can use
scaled agile is necessarily limited, as it incurs significant overheads; don’t
do it and incur the release and cadence overheads, if all you need is lean
or agile.
 A blend of DSDM, some Safe and some Scrum were used. The
consensus view is that DSDM is great at lightweight business cases that
can evolve, Safe is better on the coordination and Scum of scrums is a
natural interim stage.
 The view was that the mindset is more important than the
method, as most techniques are adaptable and transferrable.
 Work out what is fit for your purpose and rely on the experience of the
project team to decide on the appropriate blend.
 Do concentrate on building a flexible enterprise culture and positive
individual behaviours to become “agile”.

5. AGILE DEVELOPMENT - SCRUM
Scrum artefacts:
• The Product Backlog
• The Sprint Backlog
• The Sprint Burndown Chart
• The Product Increment

6. LESS OVERVIEW
Large Scale Scrum is widely adopted in the US:
 Provides a large-scale Scrum framework, with the aim of directing teams to consider the whole product, rather
than components.
 Advocates up to eight teams (of eight people each), with LeSS Huge for when a few thousand people are
required on one product.
Key principles, similar to those in Scrum development, are:
 Coordination: Just Talk, Communicate in Code, Travelers, Open Space, and Communities.
 LeSS has many complete, cross-functional teams (with no single-specialist teams), but one common Sprint.
 So, all cross-functional teams share a common sprint, to deliver a common shippable product, every sprint.
 Overall Product Backlog Refinement meeting: this includes the one Product Owner and people from all teams, to
decide which teams are likely to implement which items, before holding individual team, more detailed PBR’s.
 There is a single Product Backlog.
 One Definition of Done for all teams.
Sprint Review: For inspecting the product increment and new items, run like a “science: a large room with multiple
areas, each staffed by team members, where the items developed by teams are shown and discussed.
Overall Retrospective: This is a new meeting not found in one-team Scrum, and its purpose is to explore improving
the overall system, rather than focusing on one Team.
The project management responsibilities are shared between Product Owner and Teams.

7. DAD OVERVIEW
A goals-driven approach to delivery:
• One process does not fit all: “DAD is a hybrid approach which extends
Scrum with proven strategies from Agile Modelling (AM), Extreme
Programming (XP), Unified Process (UP), Kanban
• Ability to adapt other techniques includes adapting the team roles as
scope increases.

8. SAFE OVERVIEW

9. AGILE PROJECT FRAMEWORK
(FORMERLY DSDM)
Core practices:
 Time boxing For each portion a number of requirements are selected
 MoSCoW
 Iterative development.
 Workshop
 Modelling
Project roles:
Business Sponsor The “Project Champion”. This role has an ultimate power to make decisions.
Business Visionary The one who has the responsibility to initialize the project by ensuring that essential requirements are found
early on. Visionary has the most accurate perception of the business objectives of the system and the project.
Business Advisor Can be any user that represents an important viewpoint and brings the daily knowledge of the project.
Business Ambassador Key representative and decision make for the business, embedded in the solution development team.
Project Manager Can be anyone from user community or IT staff who manages the project in general.
Technical Coordinator Responsible in designing the system architecture and control the technical quality in the project.
Technical Advisor Supports the team with relevant specialist input and perspectives.
Team Leader Leads his team and ensures that the team works effectively as a whole.
Solution Developer Interpret the system requirements and model it including developing the deliverable codes and build the
prototypes.
Solution Tester Checks the correctness by performing some tests, raising defects where necessary.
Workshop facilitator Responsible to gather and record the requirements, agreements, and decisions made in every workshop, for
managing progress, preparation and communication.
DSDM Coach Key to helping tram members with the approach set within their corporate context

10. THE “DEVOPS” CONCEPT
 A key principle underpinning all of these approaches is that of “continuous release,
continuous delivery” or “release on demand”.
 That is, the ability to support frequent, incremental changes as they come out of the
development stage, so that they can be used immediately and so realise benefits.
 DevOps promotes a set of processes and methods for thinking about collaboration
and working between technical departments doing development, quality and
operations.
 Typically, this collaboration involves embedding IT operations specialists within software
development teams, thus forming a cross-functional IT team (Feitelson & Beck, 2013).
 The aim is to improve processes and automate a much as possible, to immediately
implement pre-approve changes and make approvals happen on demand.
 Typically, operations functions run cyclical (weekly) change approval sessions, which time
constrains development teams in delivering business benefit.
 However, this concept doesn’t just have to apply to software development moving
into the production environment, but can equally relate to any function outside of
any type of development team.

11. PLAY THE GAME
As sponsor, my Goal is to maximize ball throughput
 Rules:
 I will appoint each team one project manager and one product owner
 The project team must be more than 5 and less than 10 people
 The project team will deliver:
 The ball to be caught and thrown by everyone on the team to count
as one point (must not be touched by two people at the same time)
 Each full circuit increases the score to the next full point, each
person increases the score by a hundredth of a point e.g. 2.05=2
times round + 5 people
 If you drop the ball, it must be returned to the start point (score
reverts to last full point)
 To reduce chaos, ball must bounce at last once before going to next
person
10/17/2017
11
AgilePM

12. APM WHITE PAPER FINDINGS
 Strategic alignment: alignment between programme and organisational goals.
 getting the necessary product management hierarchy; how to find the right personal attributes,
e.g. stakeholder management, interpersonal and communication skills, and product
knowledge/control.
 Reporting needs careful consideration, explanation and practice.
 Automated tooling and Kanban boards can be used to simplify tracking and reporting, but
consumer expectations need to be set to be in line with the tool capabilities, rather than
adding a measuring “overhead”.
o Logistics: there is a setup effort and potential cost, to ensure everyone
has access to the facilities required for successful team working across
time zones and geographies.
 Co-location of a full team remained the ideal for all participants. Sprint planning is possible to
do using collaboration tools for remote workers.
 Invest in regular full team workshops, face to face, and budgeting for the necessary travel to
make that happen.
 Plan the environment. Full team planning sessions need a lot of space! Remote teams or
team members need good online and communication collaboration tools.

13. APM WHITE PAPER FINDINGS
People
 Multi-skilling/fully functional teams: There are two levels of teams – moving from
single skills e.g. development, quality assurance, to a grouping of individuals. Then
have some specialists and add people who can cover a range of skills, with an
interim step where people understand enough to help.
 Programme resource management functions need to understand that workload for
skills fluctuates, even within iterations, so a project or programme manager can’t just
say how many BA’s, how many PMs, etc., will be needed.
 It’s important to think more about the work and the people interactions and the
team’s familiarity together, than simply pull together individual job specifications.
Training
 Team members should be trained in the approach, cadence, tools and practise as
part of the first kick off and planning session, regardless of approach adopted.
 In particular, reflecting the importance of an overall design or solution intent, the
“Architecture” roles needed specific coaching on discovery, cross-team coordination
and downtime coordination.
Consider the level of risk, and build risk stories or capacity

14. SUMMARY
 Agile means different things to different people – check
language and therefore expectations are aligned
 Unless an organisation is completely agile, project
managers are still necessary to :
 Align the project or programme goals (and backlogs) to
strategy
 Design the governance, reporting and manage stakeholders
 Identify and mitigate risks
 Optimise team structure, design, resourcing
 Take issues away from the delivery teams and smooth work
across boundaries
 Embed lessons learnt/process improvements
 Culture and coach

15. A PM CAN ADD VALUE BY……
• Culture
– Customer need to really understand their requirements
• Clear Vision
– Focus on the why, not the how
• Get better at estimating
• Encourage constant feedback
• Real, not over, commitments : keep promises
 Go iterative for everyone, not just the delivery team
 Think about who is in the team and who supports outside it, with
empowerment of people
 Selecting the customer is key
 empowered, knowledgeable, decisive and a good communicator
 Clear benefits (outcomes) identified up front - Sell outcomes, not outputs
 Change clearly prioritised/understood
10/17/2017
15
AgilePM

16. USEFUL LINKS
 VersionOne, (2016) Agile Project Management,
report
 https://www.slideshare.net/gasproni/scaling-
agile-done-right-agile-manchester-2017
 www.dsdm.org/dig...papers/Agile-project-
management-white-paper
 Agile Manifesto
 SAFe ”Big Picture”