1. The document describes a story of a project that struggled to implement Agile at scale, spinning its wheels through multiple iterations and failing to deliver requirements on time. This highlighted the challenges of using Agile for complex, distributed projects. 2. It then contrasts the IT and business perspectives on Agile, noting that while IT loves Agile's iterative approach, businesses need more accountability and traceability which Agile does not always provide. 3. The presentation proposes a new Agile@Scale framework that addresses delivery, process, and people to connect predictive planning to agile execution for large projects through a staged delivery funnel.

1. 1© Rule Financial 2013
PMI meeting - Lodz
Agile@Scale
Prepared by: Philippe Guenet
Submitted on: 26/06/2013
Version: 1.0

2. 2© Rule Financial 2013
Introduction
 Name : Philippe Guenet
 Company : Rule Financial
Rule Financial is a professional services company based in UK, US, Canada, Poland & Spain
Rule Financial specialises in the Wholesale Investment Banking sector
 Role : Delivery Lead
Overall responsibility for all the work we do for a Tier 1 Investment Bank
20 projects on-shore & across shores – 220 people
Governance responsibility to improve our delivery

3. 3© Rule Financial 2013
Before we start, let’s
discuss a real story...

4. 4© Rule Financial 2013
The story that started the
idea of Agile@Scale

5. 5© Rule Financial 2013
The story of a project that did not get it right
The project started with strong support from the stakeholders to run Agile
 Stakeholders had limited
influence
 Agile experience was
limited
 Architecture and high-level
were done in-flight
 Project was complex with
fixed deadlines
 The project “spun its
wheels”
 Fundamentals could not be
closed
 First Pilot was a success
 First Live delivery failed

6. 6© Rule Financial 2013
... And still did not get it right...
 Established details of
requirements backlog
 Addressed end-to-end
architecture painfully
 Refocused scope with new
timeline
 And “spun its wheels”
again
 Delivered to Live
successfully
 But...
 Requirement throttling
 Waterfall became Kanban
 Team <50% utilised and
poor morale
The project then decided to go back to a Waterfall approach

7. 7© Rule Financial 2013
Lessons learnt from this experience
 Running complex, time critical, distributed projects using
Agile is difficult
 Agile requires experience and discipline to get it right
 Driving the right architecture & end-to-end requirements in-
flight is a key challenge
 Waterfall is not a safe-heaven
 Teams prefer Agile, Business actually needs Agile too

8. 8© Rule Financial 2013
Inevitably Agile has gained some bad reputation...
Agile is too often an excuse for lax discipline

9. 9© Rule Financial 2013
IT loves Agile, Business is divided
Technology
 Iterative development breaks
down complexity
 Developers gain confidence
through lifecycle
 Business interaction improves
understanding
 Change is acceptable
 Autonomy & self-organisation
is surely a good thing
 Low pressure
Business
 Stakeholders fund IT projects
for an outcome at a date
 Complexity needs traceability
and accountability
 Agile gives a feeling of
disorganisation challenging
trust
 Agile requires continuous
involvement
 Yet, Business needs to adapt
to continuous change

10. 10© Rule Financial 2013
Waterfall vs Agile – Different success factors
What the
Business want
What the
Business needs
What IT
understands
Agile
Waterfall success is all about
converging those 3 targets with much
anticipation
Agile success is all about making
this journey as straight as
possible

11. 11© Rule Financial 2013
A possible answer – Project Rulebook
Project: rulebook™ - Defined
Project: rulebook™ - Exploratory

12. 12© Rule Financial 2013
A possible answer – Project Rulebook
Defined
Exploratory
This lifecycle involves considerable up-front work to
understand the detail of the customer’s requirements and their
stability. allowing high-quality estimation and fixed-price / fixed
scope contractual relationships.
A rigorous iterative lifecycle suitable for large and fixed-
priced projects.
A lightweight iterative lifecycle suitable for
smaller, experimental projects (usually T&M). This lifecycle involves close collaboration with the customer to
evolve the requirements and project scope across the lifecycle
whilst early versions of the system are evolved. It requires
regular access to and involvement of customer experts.

13. 13© Rule Financial 2013
But what if we need to do this all in-flight?
Risk
Waterfall Agile
Risk pushed to the right, making projects more likely to fail or
not meet timelines
High risk items delivered early
Works for all project sizes - S, M, LTeam Size
Location
Project type
Business
involvement
Change
Quality Gates
Requirements
& Design
Agile works best with small teams
Co-located or distributed are used to working in a waterfall fashion
Agile thrives in co-located settings. With increasing cost challenges
off and near shore capabilities are quite often used.
Any
Due to its nature agile works best with smaller and / or greenfield
projects. Using agile in existing projects can be difficult
Design done upfront which does not allow for changes throughout
project without high cost / time impacts. However, sets expectations
well and helps to paint the big picture.
On-going for flexibility, however at times end goal not always clearly defined
or communicated. Can lead to wrong design decisions that are hard to fix. Big
picture missing at times
Business is generally engaged during requirements gathering at
the beginning & during UAT at the end (at which point it is
often too late to change anything)
Agile brings all functions together in cross-functional teams throughout
the lifetime of a project
Difficult and costly to accommodate for change after design
Scope can be re-prioritised throughout the project up to close to
launch
Strict gates process that can stop projects from progressing. No
parallelisation is built into the method
Less formal, often no gates which can result in issues when working
with bigger teams
Agile@ScalePredictive
outcome
Agility of
execution

14. 14© Rule Financial 2013
Objectives of Agile@Scale
Agile @ Scale aims to provide a framework for delivering
successful Agile Projects & Programmes in the challenging
conditions inherent to large scale Businesses
Scale challenges the Agile manifesto
Complex systems – difficult to deliver working software in short iterations
Multiple dependencies – not independence
Hard deadlines – not endless iterations
Get it right, high impact when getting it wrong
Coordinate multiple geographies – no co-location Business / Developers
Various seniority levels & resource distribution challenges self-organising teams

15. 15© Rule Financial 2013
Scaled Agile framework addressing Enterprise Agile
transformation

16. 16© Rule Financial 2013
Scale Agile Framework
 Though theoretically right, Scaled Agile framework requires
the entire enterprise to move to Agile
 This is a big leap of faith for the Business
 It is likely to take substantial time to return success
 Each painful experience will require to keep the faith going to
carry on forward and achieve an Agile enterprise
 Our approach aims for a simpler and more pragmatic method

17. 17© Rule Financial 2013
Rule Financial approach to Agile @ Scale
DELIVERY
• Entry / Exit criteria between stages in the flow
• Maturity matrix
• Dynamic replanning Loops
PROCESS
• Strict adherence to entry / exit criteria during funnel
stages
• Strict estimation, planning & replanning loops
• Standard Scrum principles made into a process
PEOPLE
• Redefine the skills / roles of BA and Architect
• Train, Champion & Coach Agile in the organisation
• Educate stakeholders & other projects to adopt Agile
• Move progressively Business to Agile
Refactoring,Reprioritisation,Replanningloops

18. 18© Rule Financial 2013
Agile@Scale Delivery funnel
1. Programme Planning
• Continuous planning (Epic
level)
• Capacity management
• Dependency management
2. Release planning
• Story creation (from Epics)
• Maturity matrix
• Prioritisation
• Dependency alignment
3. Analysis Sprint
• Work from prioritised
backlog (from maturity
matrix)
• Story specifications
progressed to development
readiness criteria
4. Agile Development
Sprint
• Development done in Agile
fashion (SCRUM)
Refactoring,Reprioritisation,Replanningloops
Core of the framework
• Process flow
• How to go from predictive
planning to agile execution
• Dependency Mgt
• Capacity planning
• Role of the BA vs Arch
•Replanning loops
• Maturity matrix
• Suitability for Agile (context /
environment / culture / approach
/ etc)
Framework Scope
SCRUM
Not reinventing the wheel – not in
scope of A@S
Analysis Sprint
• Role of the BA
• Definition of analysis sprint
processes
• Story format

19. 19© Rule Financial 2013
Agile@Scale – Work in Progress
 Estimation framework
 Definition of the Entry / Exit criteria of each process step
 Skills redefining BA and Architect roles
 Techniques to break down complexity into building blocks
 Maturity Matrix
 Refactoring / Replanning loops

20. 20© Rule Financial 2013
In summary
 Practical example of Agile struggling at scale
 IT perspective vs Business perspective
 Agile vs Waterfall
 The need for a new way: Agile@Scale
 Other frameworks require a massive transformation for successful adoption
 Our approach covers Delivery / Process / People
 ... With a funnel shaped process that connects Predictive Planning to Agile
execution

21. 21© Rule Financial 2013