Statoil is transforming its IT delivery model to an agile approach to better tackle volatility in the energy sector. It has established an agile transformation team to help 700 IT employees in 55 projects adopt agile practices through training, workshops, and continuous monitoring. The new framework prioritizes continuous delivery of high-value features through self-managed cross-functional teams and product owners. This represents a cultural shift from single projects to optimized flow.
5. Statoil IT Delivery Framework
2015-01-215 Classification: External
Portfolio
Program
Team
SprintBacklog
Prioritized
Program/
ProductBacklog
ITMasterPlan->
Prioritised
ITPortfolio
Backlog
Business Epics
Business Epics
Architecture
Concepts and
Upgrades
DefineResourceallocationfor
Architecture
Concepts
and Upgrades
Business Epic Owner Business User
IT Delivery
Team Member(s)
IT Investments/Modifications Operations
Bugfix, oper impr,
maintenance, ops
Program
Epic/Feature
Technical/
Architecture
Epic/Feature
User Stories
(Business features/minor
mod/Arch/Operations)
Agile Product
Lifecycle Team
Enterprise IT Arch
Delivery Manager
(IT Line Manager)
Release Planning
Release 4 Release 5 Release 6 Release 7 Release …n
Release
Coordinator
BA Line Mgmt
CIO
Product Owner
Portfolio
Responsible
Program/Product
Area Manager
IT Master Plans/
IT Portfolio
PerSubProcess/
ProductArea
Planning:3–18months
PerProcessArea
(OM,EXP,M&S…)
Planning:0,5–2years
PerITProduct/
Productarea
Planning:2-16weeks
Prioritization
of Portfolio
Backlog
Demand
Capacity
Planning
Portfolio
Vision and
Roadmap
Business
Epic
maturing and
scoping
Business
Value
Realization
IT Architect
Prioritization
of Program
Backlog
Product/
Program Area
Vision and
Roadmap
Functional
Release
Planning
Product Owner Delivery Manager
(IT Line Manager)
Program
Backlog
Refinement
Product
Backlog
Refinement
Technical
Release
Planning
Sprint
Planning
6. 2015-01-216 Classification: Internal
IT Projects and agile deliveries
Projects
•Are planned as part of the IT Master Plan process
•Have a owner in the business (asset owner)
•Projects can span products and organizational borders
•“Clash” between project teams vs “stable delivery
teams” in the line organisations
•Project reviews 1 year after final delivery. Business
Value delivered?
12. Cultural change:
I need my project and time/cost estimates!
Yes I have a fixed scope (is there
really any other way…?).
2015-01-2112 Classification: Internal
What will it cost?”
When is it finished?
Deliver continouous flow of low risk
- high value stuff first, then consider
what else you need…
Based on our capacity we can give you
an rough estimate, but it really
depends on when you have received
sufficient business
value
Critical and high priority
deliveries first,
next you decide what else you need
(based on business value)
13. Cultural change – Agile Leadership:
Resource optimisation vs flow optimisation
2015-01-2113 Classification: Internal
As long as all my
employees are busy
with their tasks I´ve
told the to do – I´m
HAPPY!
Hmm… how can help my
teams increase business
value and deliver features
even faster to our
customers??
“Resource Owner Leadership”
Command and Control
Agile Servant leader
15. IT Governance
Model interface
Team collaboration,
sharing and
motivation
Team transparency
Team Agility and
improvement culture
Team Autonomy
Not wanted Observed behaviour and practices Wanted
- Team is responsible!
- Team have mandate, competence and trust to deliver "start-to-finish“
- Team have required infrastructure privileges to deliver "start-to-finish“
- Dependencies outside the team are continuously managed and minimized
- Minimized handovers (team internal- and external)
- PO defines product vision and owns the product backlog
- PO is empowered and prioritizes backlog (what), team decides how and who
- Team plan and execute work to control technical debt – aligns with PO
- PO has knowledge to prioritize and is aligned with business and IT master plan
projects
- Team and PO collaborates as a team, and PO drives backlog refinement process
- PO’s coordinates across products (other PO’s)
- PO owns a functional release plan
- Team rapidly adapts to changing customer priority
- [Software development] The complete software delivery process is automated
(Continuous Delivery practices)
- Team work in short iterations to enable fast feedback loops with stakeholders
- Structured measurements are used to support improvements
- “Time to market” is measured and used to evaluate improvements
- Experimentation and improvement initiatives are actively supported by Leaders
- Fail early - failures are shared and considered as an opportunity to learn
- Task priorities and status are visualized and shared openly
- Early/frequent deployment to test and production
- Definition Of Done (DoD) is defined and used for all steps for all backlog items
- Frequent communication with PO and end users
- Team openly shares successes and failures
- Team is co-located
- Team members have broad competence in all relevant areas
- Team have shared commitment for all work
- Team members often work in pairs
- Team members are enthusiastic about supporting each other
- Team members are motivated and happy (HIGH score on HappyIndex)
Securit
y
- Insufficient Backlog refinement to clarify dependencies
- Team is depending on competence /infrastructure found in
other units/teams to be able to deliver to end user
- Throughput is often blocked/delayed due to "waiting for
others”
- Team prioritizes user stories on the product backlog
- PO and IT Leader in GBS not aligned to clarify demand VS
capacity
- Dependencies between products/Product Owners not managed
- Product Owner unavailable for team
- PO disconnected from Business (demand)
- Projects use resources/team capacity directly (bypasses PO)
- No structured process for improvement
- Little time available for reflection or improvements
- Short term focus on delivery over capabilities (for long lived
Products)
- Improvement agenda kept internal within the team
- Leader not engaged in continuous improvements
- Too many parallel improvement/change initiatives
- Failures are only considered as negative
- No shared view on status for work in progress
- No defined process for how the team works
- No visual management of tasks and status
- Team does not expose delivery status until “finished”
- Distributed team in different time-zones
- Competence Silos within the team (risk & bottlenecks occur)
- No real common commitment/shared goals
- Team members not sufficiently allocated to team
- Team members work individually to solve tasks
1 2 3 4 5 6
16. Value stream mapping - steps
Value stream
All of actions, both value added and
non-value added that bring a product or service to
the customer.
Value stream map
Serves as a blueprint for lean implementation
1. Identify the value stream or process to focus on
2. Map the current state value stream
3. Identify the “pain areas”
4. Develop the future state value stream
5. Change the current state into future state
Steps to value stream mapping:
17. ”Agile Transformation Team” to fuel change
• Statoil IT Vice President is Product Owner
• Continouous monitoring of progress of agile
transformation – adjusts priorities accordingly
• Training and coacing of teams, scrum masters,
leaders, product owners and IT portfolio
managers
• Facilitating workshops (Team Maturity
Workshops, Value Stream Mapping, etc)
• Success measured by happy teams and happy
customers!
2015-01-2117 Classification: Internal
18. Summary
2015-01-2118 Classification: Internal
• Optimize on flow
• Experiment - change what doesn´t work!
• Embrace change – and don´t under estimate the effort it
takes to change people behaviour
• Be brave – and have fun!
19. Smidig Eierstyring I Statoil
Tor-Ivar Hals
Leader Agile Transformation Team
E-mail address: toriha@statoil.com
www.statoil.com
2015-01-2119 Classification: Internal
Notas do Editor
Innspill:
Definere setup i Statoil – Triangel – det store bildet. Suksess med tydelig forankring.
Fokusere på grensesnittene – være oppmerksomme på de. Ikke late som at alt er greit.
Statoils IT-funksjon er tredelt, og
har fordelt ansvar og myndighet på hhv Corporate IT som ledes av vår CIO – Corporate IT styrer ”overall” IT-spend i selskapet og spiller en veldig viktig funksjon i å ha styring på overordnet kostnadsnivå.
Corporate IT setter også rammer for IT Governance, retningslinjer for våre leveranser osv.
Business Area IT er strategisk plassert i hver forretningsenhet, og har ansvar for å koordinere all IT-aktivitet innenfor forretningsområdet. De skal jobbe tett med forretning og forstå forretningsbehov og utfordre forretning på prioriteringer. GBS IT er intern tjenesteleverandør av all IT.
GBS IT leverer utvilkling, drift og rådgiving av IT på vegne av hele selskapet. GBS er også ansvarlig for håndtering av eksterne leverandører av IT-tjenester.
Her får dere et bilde av det oppsettet som utgjør IT i Statoil.
Figuren viser overordnet modell for IT-styring og IT leveranser i Statoil. Vi deler inn i tre nivåer + IT Arena som utgangspunkt for finansielle rammer.
Porteføljenivå styrer overordnet prioriering av all IT aktivitet innenfor et forretningsområde.
Innenfor området leveres IT på forskjellige måter, både som prosjekter, smidige leveranser gjennom team eller via tredjepartsleverandør.
Vi skiller mellom ulike typer IT-leveranser – både mht finansiell styring og eierstyring.
Prosjekter planlegges og initieres som en del av IT Master Plan-arbeid.
Vi ønsker å redusere gjennomløpshastighet for våre prosjekter ved å kjøre prosjektet I fase.
Analyse og gjennomføringsfase I iterasjoner – hvor prosjektscope deles inn I “chunks” og leveres iterativt via team og product owner-konstellasjonen.
I store prosjektoppgaver ser vi også behov for å håndtere avhengigheter på tvers av team.
I stor grad handler dette om koordinering av prioriterte aktiviteter på tvers av product owners. Her tester vi ut forskjellige praktiske gjennomføringsmetoder, I noen tilfeller håndterer product owners denne koordineringen selv, men ofte ser vi behov for å bruke enten prosjektledere eller cross team koordinatorer for å få til dette på en god måte.
Vi er en stor og kompleks matriseorganisert organisasjon.
Det er en høy grad av kompleksitet i vårt oppsett, både mht organisasjonsstruktur, men også mht ansvarsforhold og hvem beslutter hva.
Levere effektivt i en matriseorganisasjon er krevende.
Prosjektmodeller tradisjonelle utfordres av smidige gjennomføringsmodeller. – leder over i kulturendring
Vi jobber kontinuerlig med forbedring. En av våre viktigste verdier knyttet til IT er å etablere en kultur hvor man på alle ledd i organisasjonen gjør ”Continouous improvement”-øvelser – for å finne bedre og smartere måte å levere/jobbe på. Endring er krevende men nødvendig!
Verdisett uttrykkes på flere måter, gjennom Statoilboken, her er fokus vi har for IT. Vi har overordnet mål om verdiskapning levert raskest mulig for våre kunder.
Team som jobber med endring
Team som jobber med endring
Command and control management vs Servant leadership
Relevant at all