Lean, Agile & Scrum Konferenz 2014

#LASZH

@LeanAgileScrum

Delivering an Agile Framework

to a Global IT Organization.

Pete Jones

From 15:40 to 16:40

Conference Room 1

Platin Sponsor

Gold Sponsor

Silber Sponsor

The Theme

Early in 2013 the IT department of Sonova decided to

introduce Agility (SAP, SalesForce, Web etc.).

This presentation describes this journey from framework

selection through early stage implementation of that

framework.

The Paper

Describes both good and bad experiences to date.

Outlines the next steps towards completing this change.

2

Today’s Session

The abstract for today was submitted some

time ago.

When the Agile programme was developing some

traction and things were looking good.

I intended to contain positive messages, however ….

… the session will be heavy on lessons learnt.

Interactive Session

3

A caveat!

Brief History

Electrical and Electronic Engineer.

Software Developer (Assembler to Modula 2 / C).

Management of Change (1st start-up).

Import & Distribution (2nd start-up).

Requirements Engineering (Business and IT).

Telecoms Infrastructure, Banking, Medical, CE (WiFi)

Systems thinker / Very people centric.

4

Who am I?

Phonak – founded in 1947.

– Acquired Unitron (2000), Advanced Bionics (2009),

In Sound Medical (2009),

– Connect Hearing (global retail org)

Six years ago: 4000 employees, now 9000.

CHF 1.9 bn / year

5

Sonova

6

Sonova Geography

A global multi-brand organization

Approximately 200 staff

Provides IT service to all Sonova businesses globally.

Different brands bring contradictory requirements causing

implementation conflicts.

Two primary functions Support: Will move in the ITIL / Kanban direction.

Solution Development (SAP, SalesForce, Web etc.):

focus for Agile Development.

7

Corporate IT.

CIO Mandate

To improve service to our internal customers

Agile core team (CIO and his management

team)

No significant top management buy-in

CIO wants to show some results before promoting to the

Management Board (the Sonova way)

8

Why Agile?

Mandate: “The Common Agile Delivery

Methodology for Corporate IT”

Driven by the Need to “Increase Service to

Customers”

9

My Mandate.

IT is a Project Orientated Organization

Project Order and Project Plan drive finance & headcount

(however, this is not always followed).

SAP Blueprint !!!

Pain is Low

Perhaps too low for change?

Agile Effort is Sponsored by CIO

Limited buy-in outside of IT (technology focussed).

Limits scope to IT, makes addressing governance difficult.

10

Status Quo (Waterfall).

11

As I see it…..

Governance & Control (too much?)

Barrier to Customer Needs

High Pain

Low Pain

12

When I joined IT.

One IT team was experimenting with Scrum

Had not understood the real problem.

Scrum could help with Development, however, it can only

solve about 30% of the issues.

An early retrospective

Me: “Who is the product owner?”

Scrum master: “I am”

Me: “That is a business role”

Scrum Master: “We would have to train the business”

Me: “Yes!”

Two options on the table:

Scrum + invent stuff to fix the other aspects.

DSDM largely out of the box and tune to meet our needs.

DSDM was selected. After months of discussion (Team was too waterfall!!)

Too much focus on the differences between Scrum and

DSDM

To little focus on understanding the underlying problem.

13

Agile Framework Selection.

Dynamic Systems

Development Method

Agile development aimed at

projects.

Lightweight Planning and

Architecture.

Feasibility and Foundations play

the same role as a Scrum Sprint

Zero!

Picture courtesy of the DSDM Consortium

14

DSDM

I wanted to get the agile effort moving.

Having limited experience of agility in practice I needed

help

I invited an external DSDM consultant in to help

I have a lot of experience as a consultant

Based on previous projects I thought it was the right time,

however, in reality I had little experience of the time

before a consultant is called in.

In retrospect, I called him in far too early

15

Once DSDM was selected.

A joint session with our new advisor. Overall, it went well, until a rather worrying observation

A developer commented “I wouldn’t call it Agile, Agile has a bad name

around here, I would call it something else if I where you”

16

First Info. Session to IT.

More interestingly, many of the team members had never heard of

Agile Development!!

It seems that, in the past, our SAP team had some difficulty making

some 3rd party shipping software work with our SAP implementation!

http://www.agile-network.com/

100% IT Management Team

I repeatedly tried to include Developers and Testers (the

guys that do the work)

My peers would only accept Project Managers which felt

like more command and control.

Management of Change

Needs to involve the people who do the work, defining

ways of working is by far the easiest way to deliver.

ASI Example

17

Agile Core Team

A management team member joined the

team for retrospectives

The perfect way to make them fail.

After the retrospective I was asked my a number of team

members about how DSDM should be.

I asked the PM to call a second retrospective (just the

project team).

I joined and tabled these issues anonymously.

The team acknowledged the issues, came up with

solutions that worked for them and implemented them

18

Early Retrospectives

Business Counterparts

Our SAP team already have business counterparts (or

Process Owners) identified.

In our case we have 180 of them!

Many Vertical Specialisms

Automated Testing of SAP

“Can’t be done”

Experience - normal (in change management plan)

They will look properly when they feel enough pain

19

Some SAP Specifics

In order to reduce the direct influence of

senior management.

We pushed the Sponsor role down into the org.

We already have rules for DoA in the business.

This brings a problem

Pushing sponsorship down into the organization is good.

In DSDM, sign off is for the next phase of work!

DoA and phased sign off could break one of our core

governance principles.

20

Delegation of Authorities

Complex SAP/ Web / SalesForce & PC

solution PC team (different department) refused to engage properly

Pilot Killed

New global email marketing solution Worked really well, business really engaged and everyone enjoyed.

Some issues with in country companies.

New eStore roll out Development team tried to mix Agile and waterfall in a single release

which doesn’t work

21

Initial Pilots

EU Logistics

Feasibility & Foundations done before project

Took time to get into (especially business)

Planning Poker started to be used at User Story level. The

team liked it and it worked well.

Agile became “Waterfall in a Time Box”. Okay first step but…

100% close out of tasks within each Timebox (one Time Box

extended by 1 day)

DoD for Time Box was clear to the team

Leaner documentation (work to do)

22

Current Projects

Kanban evolution

Team jumping in to help each other

Large change dropped on the team late. Handled

seamlessly by dropping could’s and should’s.

Business / development communications

Bus / IT comms (Helen / Scotty)

Contract Change for major customer (20%)

End dates fixed by client and requirements fluid (ideal)

Team based an multiple locations (large time differences)

Working in Time Boxes was difficult (process changes)

23

Current Projects

Initially a very large team (30+) based on skill distribution.

Eventually focussed on key roles (8-10 people) which

worked better.

Foundations where done in a week which proved much

too short (resulted in architecture being done in Time

Boxes).

Team was not comfortable declaring the work could not

be done in the available time. It became clear to all in the

second Time Box and action was taken.

Key skills where not available in the early stages

(dedicated to roll out of another project)

24

Current Projects

Internal vs. External

Internal resource (me) tends to get bogged down with

politics.

Internals often seen as a threat. Wasn’t sure if people

were helping or trying to break the effort.

External resource is exempt from politics.

Difficult discussions become easier.

Can observe things that would be too high risk for an

internal.

25

Who Should Lead Change?

Involve business in the transition.

And yes, they will need to be trained / coached.

Involve all levels from the organization.

Bring in external help.

Neither too early or too late.

It is possible that some team members may

not have heard of Agile!

26

Summary – Take Homes

Agility needs to be based on TRUST

Knowledge needs to be shared between

teams

Trust and Listening are big topics

27

Summary – Take Homes

Team interaction (including business).

Was really positive.

Team collaboration.

Was excellent when collocated (people helping each

other with workload).

Distributed teams tended to focus on local (same TZ)

colleagues.

Priority Changes.

Are handled very well as a matter of routine.

Changed scope but not end date.

28

Summary - Positives

Framework selection should be simple.

Focus on similarities, Get going and adapt.

Command & Control and Agility do not sit

well together.

So, do something early.

Trust and Listening skills really are important!

Open Question: End-to-End Process

Testing

Can’t be done in a time box, so when?

29

Summary – Less Positive

People starting to leave the Ivory Tower.

Focus on learning from projects.

Trying to engage another change

consultant.

With strong soft skills to bring senior management with

us.

Personally, I would like to learn more! I would like to experience life in a mature agile

organization.

30

Summary – Next Steps

Pete Jones

petejonesbus@gmail.com

31

Questions?