Post on 28-Jun-2018
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