Platforms and Agility Do they work (together)?

Presentation to BCS West Yorkshire Branch

Bradford, Thursday 19th May 2016

Who am I?

In the past, I’ve…

Worked for 15 years in IT in the telecommunications, energy and local

government sectors

Taught software project management at University of Brighton

PhD on software effort estimation in conjunction with Ericsson

Wrote BCS ISEB/Certification syllabuses for Project Management

Chief moderator for above

BCS representative on British Standards project management standards

committee

Event coordinator: BCS Project management specialist group (PROMS-G)

Platforms and agility:

Where we are today

Despite efforts of the Government Digital Service etc., government IT

projects are still of concern e.g. Universal Credits, Rural Payments

2011 The Institute for Government published a report on UK government

project delivery System Error: Fixing the faults in government IT which

recommended:

Use of agile delivery

Development/consolidation of common IT platforms for delivering IT services

Basic ideas adopted by the then new Con-Lib coalition government

Question: what problems and issues arise from implementing these ideas?

Agenda

What makes IT projects different?

What we mean by ‘Platform’ and ‘Agile’

Two contrasting project case studies as illustrations

Seagull and Koala - Scrum

ABC – parallel incremental

Is it just a case of project size? PRINCE2 Agile and scalability

Some discussion points

Back to basics 1: software

Agile methods were developed primarily for software development –

arguably?

Special characteristics of software (following Fred Brooks)

Complexity

Invisibility

Changeability – software functions tend to replace hardware as a result

Conformance – need to conform to external requirements

Plus

Ease of replication – once created, mass production/distribution is easy

Back to basics 2: projects

More to projects/programmes than just software delivery

Programmes are often primarily about business change i.e. transition

management

Pre-transition: software/system building – project management

Transition: installing system into an organization – change management

Post-transition: value through operation – benefits management

Each type of management has a stake in the preceding phases.

Platform strategy 1

The platform consists of the software/hardware infrastructure in place to

enable applications (which do useful things for users)

The idea of platform strategy based on Ross, Weill & Robertson Enterprise

Architecture as Strategy Harvard Business School Press

Key dimensions:

Standardisation – using the same processes

Integration – sharing the same data

The basic advantage is having common services:

(i) removing duplicated effort

(ii) economies of scales e.g. negotiating bulk discounts

Platform strategies 2:

operating models

Diversification FEW common processes / LITTLE common data Example: local authority departments: e.g. road maintenance and social services may have little in common. Focus on common generic organizational tools e.g. office tools (word processing, spreadsheets …), desktop, payroll, purchase orders etc.

Coordination FEW common processes/ MUCH common data Example: Dept of Work & Pensions may supply a range of different services to the same customer base Focus on shared databases

Platform strategies : operating models

Replication MANY common processes / LITTLE common data

Example: Local authority functions across the country e.g.

council tax

Focus on same system replicated with different data sets

Unification

MANY common processes/ common data

Example: Fire & Rescue Service as envisaged by

(now abandoned) FiReControl project.

Focus on single national integrated system

Note: Some advice implied about selection criteria for the choice of the

approach

Agile development

Original movement away from pure waterfall (sequentially phased)

projects

Increments – division of functionality into modules, each of which can implemented individually

Iterations – repeated versions of same function with subject to trials/changes from user representatives

Agile focus on removing obstacles to fast communication between

developers and user representatives e.g.

Test data first development

Pair programming

Continuous integration etc., etc.

Scrum

Other Agile methods available! Scrum is the approach given most attention by PRINCE2 Agile™

A metaphor based on rugby scrums – team joining together in one effort

Not an acronym – so not ‘SCRUM’!

Scrum was originally a product design approach – not specific to software development

Developed originally by Ken Schwaber and Jeff Sutherland

Identifies three key roles:

Product owner

Scrum master

Development team

Case study: Seagull software

Based in a south coast town in the UK

Provides a service to travel businesses generating standard email shots to

their customers e.g. E-tickets

Uses data extracted from the standard PNR (passenger record) created by

systems such as Amadeus or Sabre

So,

Seagull had international clientele

Competitive because of existing software/IT assets and expertise

Two platform elements: access to external PNR, in-house bulk emailing capability

Seagull espoused the use of Scrum

The client: Koala Travel

A travel related business based in eastern Australia

Objectives of project

To use statutory email confirmation of an online transaction as an opportunity for cross-selling new or enhanced services

To outsource the work of generating the confirmatory emails

To ensure that the email (which would appear to customer as coming directly from Koala) had the correct corporate image/style

Koala had never used Scrum before

Scrum roles

Product owner – from Koala

Owned the requirements

Approved products

Scrum master – from Seagull

Guided the process

Chaired key meetings

A different role to being a project manager

Development team

Seen as largely self-managing – based at Seagull

Scrum planning meeting 1

Group meeting to identify requirements - recorded in a product backlog.

The initial version of product log established during pre-contract discussions

Work out the tasks needed to implement product backlog in a sprint

backlog

Identify tasks/products for first sprint, i.e. Increment

Estimate effort for each task and allocate tasks to developers

Sprint Planning meeting 2: Sprint

backlog

Two passes

Identification of tasks needed

Estimation of effort and allocation of developers

Seagull developers came to the fore here

Discussion tended to be technical but Scrum Master stressed importance of

Koala understanding how estimates were arrived at

At end Scrum Master promised to distribute updated Product and Sprint

Backlogs

Product Owner ‘don’t give me a Gantt chart’!

Sprint execution

Usually Sprint meetings – daily 15 minute ‘stand-up’ meeting of the

development team

In this case, telephone conferences with clients every other day

Each developer reported:

Progress since last meeting

Planned activities for next meeting

Any inhibitions of further progress

Sprint terminates with a sprint review meeting – presentation of products to

product owner

Followed by planning meeting for the next sprint

Communications

Initial contract negotiation done by Seagull managers going to Australia –

importance of physical contact to establish trust.

Seagull had a physical Australian presence but in a different city to Koala

Because of the need for a contract, basic requirements had been

established up-front although this is against the spirit of Scrum

Telephone conferences were scheduled at the beginning of the UK day

and end of the Eastern. Australian day – used for planning meetings and

stand-up progress meetings on Tuesdays and Thursdays

Also heavy use of email for document transfer.

What this showed

Distributed Scrum can work – where there is motivation

Telephone conferences can be effective

Use of tabular list approach rather than diagrams make more sense in

voice only conferences

Seagull needed a lot of detailed information from Koala in order to set up

mailing facility. Intensive interactive approach with customer effective

here – but not classic Scrum

Which shore is ‘off’?

Case study 2 : ‘ABC’

‘ABC’ is a multinational consulting, technology services, and out-sourcing

company

Fortune Globe 500 company

300,000 employees

Clients in 20 cities and 50+ countries

The project(s)

Large integrated software system within enterprise architecture environment

Client – UK public sector organisation

Time and materials contract

Software development in India

ABC project actors

ABC development site

(India)

Test

manager

Build

manager

Test

manager

Build

manager

Project

manager

(development)

Project

manager

(client-facing)

Project

manager

(development)

Design

manager

Client site

(UK)

ABC development site

(UK)

Performance

report

Performance

report

Performance

report

Functional

specification

Software

Functional

knowledge

Code defect

Design defect

Performance

report

Performance

report

Performance

report

Performance

report

Performance

report

Key

People

Product

Consumer layer

Sof

twar

e de

velo

pmen

t (D

esig

n, B

uild

, and

Tes

t)

Process middleware layer

Service middleware layer

Legacy layer

Com

pone

nt c

atal

ogue

too

l

Sys

tem

dev

elop

men

t (o

pera

tion

, sec

urit

y, a

nd g

over

nanc

e)

Consumer

system 1

Consumer

system 2

Consumer

system n

Legacy

system 1

Legacy

system 2

Legacy

system n

Aut

hent

icat

ion

tool

1

23

. . .

4

5

Service components

Process components

6

78

Legacy components

9

Consumer components

. . .

‘parallel incremental’ delivery

design build test

Increment 1

Increment 2 Increment 1

Increment 3 Increment 2 Increment 1

Increment 3 Increment 2

Increment 3

Time

Time delay and quality deficits

The largest project delays were at the testing phase

Phases (e.g. design/build/test)

all started on scheduled time whether previous phases were completed

Risk of rework when finalised products of previous phase became available

Testing: when this identified faults, software developers could be working

on the next increment – resources clashes

The complex integrated architecture meant that there were interventions

from a wide range of specialist stakeholders – see next slide

Specialist stakeholders

Build manager (UK)

Build manager (India)

Client

Consumer/user

Cross project delivery managers

Design manager

Enterprise service bus manager

3rd party/peer suppliers

Project manager (customer-facing)

Project manager (development UK)

Project manager (development India)

Solution architecture manager

Technical architecture manager

Technical environment manager

Test data manager

Test manager (UK)

Test manager (India)

Tester

How does PRINCE2 AgileTM fit in here?

PRINCE2 ®

Owned by AXELOSTM , a joint venture between Capita (51%) and the

Cabinet Office (49%)

AXELOSTM expected to pay government £500 million over 10 years

PRINCE ® a project management framework focussed on project

governance

Claims to be applicable to any project delivery mode, including agile, but

seen by many as a traditional, waterfall based approach

PRINCE2 AgileTM 2015

An extension to PRINCE2 looking ‘at interactions between PRINCE2 and

agile, and how they can be adapted to accommodate each other’

PRINCE2 Agile

350 page manual costing £100 – somewhat cheaper via Amazon

Certification available: but only to paid-up current PRINCE2 practitioners

General approach

All of current PRINCE2 remains intact, especially:

the two top levels of Project Direction and Project Management

PRINCE2 roles e.g. Project Board, Project Manager, Team Managers

Focus on Stages – which can be equated with Releases

PRINCE2 management model synchronised with Agile delivery at either Stage or Work Product level

PRINCE2 has always been designed to accommodate external work at Product Delivery/Work Package level managed using non-PRINCE2 approaches

Does not explicitly deal with coordinating parallel agile groups

Agile and project management – a

matter for debate

‘Agile can be successfully scaled across very large and complex

organisations without project governance frameworks such as PRINCE2.’

Agile and PRINCE2® And how they integrate Peter Measey BCS

Accreditations Whitepaper

‘…Scrum and Kanban are not project management frameworks…a project

manager role is not defined….On their own they cannot be used to

manage a project’ page 21 PRINCE2 Agile AXELOS

‘…[Scrum] does not contain any engineering or delivery practices so it

could be said to “manage” product delivery as opposed to “do” product

delivery” page 174 PRINCE2 Agile AXELOS

Some final thoughts: design vs build

In IT/software system development, two different modes:

Product design

One-off

Customer-client oriented

Iterative learning

Product build

Continuous development

Code oriented

Structured

Design vs Build

Agile software development merges the two: the code is the design

document

Projects often divided into two stages: product design (with prototyping),

and product build cf DSDM

In the case of ABC, a continuous production line process with no PRINCE2-

type stages but rigorous quality checking and control – like Kanban – might

be more appropriate

Designers Builders Testers Buffer Buffer

Final thoughts

The starting point should be asking:

What are the problems with your processes?

How damaging are they?

What can you do about those problems?

How much would they cost to fix in terms of time and money?

Need for empirical evidence – rather than just opinions (and spin) – about

effectiveness of approaches

The ideal would be the IT equivalent of NICE (The National Institute for

Clinical Excellence)

Could BCS The Chartered Institute for IT have a role here?