Going Agile

Working With Agi le:

emerging from the Waterfal l

a view from the front l ine

Andrew Ball

Andrew Ball Consulting LtdInformed analysis for your organisation

A few words about agile

Let’s start with a user story

Once upon a time….

No – that’s not how they start

As <a business user> I want to <achieve a

goal or capability> in order to <meet a

business objective>

Are you sitting comfortably? Then I’ll begin

Here is a user story for today

As a presenter, I want to alert you (the

reader) to the pitfalls that you may encounter

in moving to Agile, in order that you can

learn from my experience and avoid the

same mistakes.

We can probably improve this a bit…

Now let’s try this one

As a reader, I want to learn from your

(presenter) experience of working with Agile

in order to draw lessons and decide whether

and how to apply them at my workplace.

Why might this be a better user story?

Agile lessons - perspective

• Write your user stories from the

customer perspective

You get a much better understanding of the customer

requirement if you actively involve them in the

development and creation of user stories

The Agile elevator pitch

Well you all know

the saying…

…but how is this

related to Agile?

The Agile elevator pitch

“In Waterfall or plan-driven methodologies, we expect the customer to

know and fix all their requirements up front (and sometimes they do and

it’s the right approach to take).

We then design and build against a long list of assumptions (many of

which turn out to be flawed), we impose strict change control and force a

customer to pay more to change things they could not possibly have

known when they fixed the scope.

In short, on plan-driven projects, we sometimes make a very large turd

and burn a lot of time and money polishing it!”

Agile aspires to both challenge

and change this paradigm

A very fertile

breeding ground!

is like an agar plate…

to a bacteria

The return of the fundamentalist

Agile…

to a fundamentalist…

Be it methods or standards, fundamentalists will happily

lie down in the road to defend their principled views.

Fundamentalists don’t breed enthusiasm, motivation, or

ignite a kindred spirit; in my experience they just cause

damage and piss people off.

Don’t tolerate fundamentalism. Agile is not always the

right answer - deal with it!

Agile lessons - fundamentalists

• Be wary of fundamentalists,

purists and other Agile nerds

• Understand the Agile principles

and try to stick by them

• Remember, God loves a

pragmatist

Agile is a set of principles – the key to success is making it work and a

shared understanding and buy in to how you operate within those principles.

In the early stages – when you’re on a learning curve - being told ‘you’re

doing it wrong’ is not especially helpful unless it comes with constructive and

practical advice on how to improve.

The problem with requirements

I conducted a

straw poll and

these are some

words developers

use to describe

(waterfall)

requirements:

These were

amongst the more

polite adjectives!

The problem with requirements

If you really want to know how good

your requirements are - ask a

developer what they think?

Just don’t be surprised if the answer is

not exactly flattering to your ego or

your profession if you’re a BA by trade!

They typically say things like this for three reasons:

• The extent to which they have to expand them (incomplete)

• The extent to which they subsequently change (too many assumptions)

• The context and perspective from which they are written (imprecise)

On the other hand

Project Managers like

nothing more than a

hard-boiled, nailed-down

set of requirements

Is there a better way to

cover your position?

More of him later

INVESTable requirements

ndependent

egotiable

aluable

stimatable

ized Appropriately

estable

I

N

V

E

S

T

Write user stories from a customer perspective

Use the INVEST mnemonic to check

Independent means not dependent on lots

of other stories or things

Negotiable – not locked into a solution or

technology

Valuable – delivering business value or

knowledge value

Estimatable – relatively comparable for

sizing purposes

Sized Appropriately means small – typically

deliverable in around two or three days

Testable – make sure you know what done

will look like

It’s about this big…

This takes some getting your head round

Story points are an abstract measure of

relative size

Not an actual measure based on a known unit

Imagine this exchange:

Q: How long will that report take Mike?

A: About five

How do you interpret that answer without a

qualifying unit of measure (of time)

Welcome to story pointing!

It’s all about relativity

3 Story Points

42 minutes 35 minutes

Mike Cohn tells a good story about two runners trying to estimate

the effort to run 10k. One is a 35 minute runner the other around

42 minutes. Using time, they will never agree about how long it

takes and the effort required to run a 10k.

However they can both agree that if a 10k has 3 story points, a 5k

might be 1 story point and a half marathon might be 8. The relative

effort is the same for both athletes. This principle is important as it

allows people who work at different speeds to estimate the same

tasks and come up with broadly similar answers.

Agile lessons - estimating

• Resist the temptation to relate

story points to actual

measurable units

• They are relative comparators

• They allow people who work at

different speeds to agree on the

scale of a task

Story

A product backlog is not infiniteP

rod

uct

Backlo

g

Story

Story

Story

Story

Story

Acti

ve S

pri

nt

Story

Story

Story

Pipeline of candidate user stories/ features

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

Sto

ry

The Product

Owner is the key

to controlling the

scope of the

project and

prioritising what

is important

Story

Agile lessons – product backlog

• The most important word in the

vocabulary of a Product Owner is

“NO”

• Make sure your Product Owner

understands how the process for

refining the backlog works

• See link for a very good video

explaining the Product Owner role

https://www.youtube.com/watch?v=502ILHjX9EE

Sprinting for success

Sprints are iterative cycles of development

Focus on the customer priorities

Ideally between two and four weeks

Locks the scope for the duration of the sprint

Use consistent durations

Agile lessons – sprints

• Immature teams do not handle very

short sprints well

• Trim your sprint boundaries to reflect

sprint duration

• Keep your sprints consistent in length

• Try to avoid sprint buffers

Teams adopting Agile can find two-week Sprints really challenging: no

sooner have they started; they are reaching a Sprint boundary.

Sprint boundaries take them longer to execute due to inexperience and

they find the whole experience demotivating, overwhelming and

thoroughly frustrating.

Bear this in mind when moving to Agile.

Roles - whatever happened to…

The Business Analyst?

In a SCRUM team, there is no BA role

BAs often turn up in a Product Owner role

Should the PO be customer or supplier role?

a discussion for another day…

Proxy Product Owner is another option

See next lesson…

The BA role in Agile is very different to the Waterfall version. The freedom

to innovate and to do and think differently presented by Agile can be an

intoxicating or a daunting experience – depends on your perspective.

Agile lessons – Product Owner

• A Proxy Product Owner is all very well

• A Surrogate Product Owner is another

thing entirely

• You can only have one Product

Owner – beware of multiples

Surrogate in this sense means Substitute and Proxy means Empowered

Deputy. Your job as a Proxy Product Owner is to represent the interests of

the customer when they’re not around – this will sometimes put you in

conflict with your own team.

Don’t shrink from this important responsibility but you are there to raise the

concerns, offer advice and get answers – you are not there to take the

decisions for customer. Get your customer alongside as often as you can

and keep them actively engaged.

The Agile mis-selling scandal

An appealing aspect of Agile is its innate simplicity

Succinctly described in a few sentences and boiled

down to four core principles – the Agile Manifesto

All you need to is a few three-layered user stories and a

self-organising development team to deliver them

It’s very easy to be seduced

Agile is not being mis-sold, it is being misinterpreted and misunderstood.

People use Agile as an excuse and try to hide behind the methodology. • Not documenting properly or at all

• Scant and under-developed requirements (the three-layered user story trick)

• Cherry picking of work rather than prioritising by value

Be on the look out for these and other deviant interpretations of Agile

Agile lessons – no easy option

• Agile (and Scrum)

• Simple to understand

• Difficult to master

Agile is really hard to do well – you need a lot of support

and coaching. Peer networking, knowledge sharing and

mentoring are essentials to success.

Agile lessons – don’t be fazed

• Break down user stories – engage

with your customer and ensure

robust and regular challenge

• Be clear that the Product Owner

sets priorities for a sprint

• Document as required and not for

the sake of it

Roles - whatever happened to…

The Project Manager?

Some turn up as Scrum Masters

If you are a Command & Control PM…

…Scrum Master is not for you

Some dislike this ‘hippy agile stuff’

A PM can still add real value

Agile thrives on the conversation

Most PMs I know are great communicators

See some tips for PMs on the next slide

PMs – Agile survival tips

PMs that manage people well will flourish in

Agile and Scrum environments

Those that have a high task-focus can also

do well

but will need to rein back slightly on any

tendency to over-manage and micro-

manage.

PMs with a strong command and control

outlook might need to start polishing up

their CV if their World is going Agile – they

are not going to enjoy it!

We’re all developers now

Agile and Scrum doesn’t offer hiding places

All those ‘invented roles’ you sometimes

get on projects…

…much harder to get away with in Scrum

T and M-shaped people

If you’re not adding value – it’s pretty

obvious

Tools and techniques

Lots of low-tech tooling available for Agile

and Scrum

Whiteboards and Post-It™ notes remain popular

Magnetic laminated cards are also very common

Integrated wikis and scheduling software

JIRA and Confluence

Redmine

Axosoft

There are lots of solutions out there

Be wary of letting the solution take over

Agile lessons - tooling

• Tools are all very well but they can

dominate

• Don’t over-complicate

• Standardise what really matters

• Stick to core principles

• If in doubt – strip it back

• Let the team decide what works,

what adds value and what doesn’t

Team velocity

Establishing cadence

Maintain a pace

Team diagnostic

Self-appraisal

Feeling the burn

0

10

20

30

40

50

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Story Points

Burndown rates and velocity will start

out low but will increase rapidly as a

team matures. It will suddenly increase

after a few sprints and then begin to

plateau and hit a stride or cadence that

should be consistently achievable

Agile lessons – velocity

• an internal measure and planning

metric

• not a measure of productivity

• not a sound basis for an incentive

scheme

• Try it and watch the gaming

commence…

• …as you sink under a mass of

technical debt

Comparisons with PRINCE2

Sprint boundary

Sprint planning

Product Owner

Sprint retrospective

User story/ Epic

Sprint demo

Business value driven

Document light

Stage boundary

Work breakdown

Project Executive

Lessons learned

Work package

End stage report

Business case driven

Not so document light

The new PRINCE2™ Agile product from Axelos will be an

interesting juxtaposition and it will be fascinating to see how it

is received by the PRINCE2™ and Agile communities

At one client – moving to Agile - I overheard one of the permanent staff express their

frustration at an apparent inability to add some content to one of the existing wiki pages on

an Agile project. Unable to resist, I suggested they clicked a few buttons on the new

application and they found one that enabled them to create a new page.

Initially they baulked at this, saying:

“You can’t just have people creating pages all over the place, you need to have some

structure and order. What we need is training and guidance on how to add content.”

“What’s to stop you from creating the page?” I queried. “Isn’t it better to share something

in the wrong place than not to share it all; after all what’s the worst that can happen?”

They considered my view for a moment and then – to my surprise and delight –

went right ahead and created the page.

The organisational and workplace culture that conditions us to recoil from a natural instinct

to create in the absence of rule or instruction is a sad reflection on the modern workplace

and something that Agile can help to counter – small but significant wins really matter and

I believe that Agile can help your people re-discover their passion for what they do.

Agile – disruptive and empowering

Thank you

I hope you enjoy working with Agile and

Scrum as much as I have

I am the proof – if any were needed – that

you really can teach an old dog new tricks

Andrew Ball Consulting LtdInformed analysis for your organisation