Agile@Scale presentation for PMI Łódź chapeter on 26 June 2013

1© Rule Financial 2013

PMI meeting - Lodz

Agile@Scale

Prepared by: Philippe GuenetSubmitted on: 26/06/2013Version: 1.0


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


Before we start, let’s discuss a real story...


The story that started the idea of Agile@Scale


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


... 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


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


Inevitably Agile has gained some bad reputation...

Agile is too often an excuse for lax discipline


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


Waterfall vs Agile – Different success factors

What the Business want

What the Business needs

What IT understands

Waterfa

ll

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

http://www.google.co.uk/url?sa=i&source=images&cd=&cad=rja&docid=Jr19rnoCxYPlkM&tbnid=D2s68eL4sO1mjM:&ved=0CAgQjRwwAA&url=http://air.guns.20megsfree.com/contact.html&ei=QBDGUbzDBsWM7QbDsoDQBQ&psig=AFQjCNFeWbNF6u0-T1cdaUF3q9mN-XYzvg&ust=1372021184184399



http://www.google.co.uk/url?sa=i&source=images&cd=&cad=rja&docid=JJXbAD263p0dsM&tbnid=UGmHFC7Xolta8M:&ved=&url=http://www.shutterstock.com/similar-116757373/stock-vector-cartoon-start-sign.html&ei=OxHGUbGoJsuw7Aal7YCABg&psig=AFQjCNF8pjhooCA8NLG_EjNAHIbF16zhqQ&ust=1372021435702003


A possible answer – Project Rulebook

Project: rulebook™ - Defined

Project: rulebook™ - Exploratory

assembled into

assembled into


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.


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.

AnyDue 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


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 iterationsMultiple dependencies – not independence

Hard deadlines – not endless iterationsGet it right, high impact when getting it wrong

Coordinate multiple geographies – no co-location Business / DevelopersVarious seniority levels & resource distribution challenges self-organising

teams


Scaled Agile framework addressing Enterprise Agile transformation


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


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

Refa

ctori

ng

, R

ep

riori

tisa

tion

, R

ep

lan

nin

g

loop

s


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)

Refa

ctori

ng

, R

ep

riori

tisa

tion

, R

ep

lan

nin

g

loop

s

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

SCRUMNot reinventing the wheel – not in scope of A@S

Analysis Sprint• Role of the BA• Definition of analysis sprint processes• Story format


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


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


http://www.google.co.uk/url?sa=i&source=images&cd=&cad=rja&docid=NPLogp7DEMxTfM&tbnid=YYfg_RPwQBzTlM:&ved=0CAUQjRw&url=http://en.hdyo.org/jhd/questions&ei=MGzHUZndMOOr0gXln4HwCw&psig=AFQjCNHVvKaJXG5nZYlMNEoNHsaLbYkkWA&ust=1372110241619434

Date post:	18-Oct-2014
Category:	Technology
View:	445 times
Download:	0 times