smidig transformasjon i statoil
Post on 30-Jul-2015
62 Views
Preview:
TRANSCRIPT
Agile IT in Statoil- Tackling new business realities with IT
Tor-Ivar HalsAgile Transformation Lead
Statoil ASAtoriha@statoil.com
@torivarhals
Our energy sector is volatile
2015-01-212 Classification: Internal
IT Governance
2015-01-083 Classification: Internal
Corporate IT
Business Area IT
GBS IT(Internal Service
Provider)
2015-01-214 Classification: Internal
700FTEs
55IT projects in 2014
75+Product Owners
50+IT Managers
3170Applications
60+ IT teams
Statoil IT – the setup
Statoil IT Delivery Framework
2015-01-215 Classification: External
Por
tfol
io
Pro
gra
m
Team
Spr
int
Bac
klo
g
Prio
ritiz
ed
Pro
gra
m/
Pro
duc
t B
ack
log
IT M
ast
er
Pla
n ->
Prio
ritis
ed
IT P
ort
folio
B
ackl
og
Business Epics
Business Epics
Architecture Concepts and Upgrades
De
fine
Res
ourc
e al
loca
tion
for
Architecture Conceptsand Upgrades
Business Epic Owner Business User
IT Delivery Team Member(s)
IT Investments/Modifications Operations
Bugfix, oper impr, maintenance, ops
Program Epic/Feature
Technical/ArchitectureEpic/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 MgmtCIO
Product Owner
Portfolio Responsible
Program/Product Area Manager
IT Master Plans/IT Portfolio
Per
Su
b P
roce
ss/
Pro
du
ct A
rea
Pla
nn
ing
: 3 –
18
mo
nth
s
Per
Pro
cess
Are
a
(OM
, E
XP,
M&
S…
)P
lan
nin
g: 0
,5 –
2 y
ea
rs
Per
IT
Pro
duct
/P
rod
uct
are
aP
lan
nin
g: 2
-16
we
eks
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
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?
2015-01-217 Classification: Internal
Handling some practical issues...
2015-01-218 Classification: Internal
Transforming to an efficient agile IT delivery ”engine”
…is a long journey in cultural change…
The foundation in our framework
(based on Agile – Lean Thinking)
2015-01-219 Classification: Internal
2015-01-2110 Classification: Internal
Cultural change:From ”Single Hero” to ”team based deliveries”
2015-01-2111 Classification: Internal
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 youan 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)
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
14
…some practical tools …
2015-01-21Classification: Internal
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)
Security Classification: Internal - Status: Draft
- 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
Value stream mapping - steps
Value streamAll of actions, both value added and
non-value added that bring a product or service to the customer.
Value stream mapServes as a blueprint for lean implementation
1. Identify the value stream or process to focus on2. Map the current state value stream3. Identify the “pain areas” 4. Develop the future state value stream5. Change the current state into future state
Steps to value stream mapping:
”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
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!
Smidig Eierstyring I Statoil
Tor-Ivar HalsLeader Agile Transformation TeamE-mail address: toriha@statoil.com
www.statoil.com
2015-01-2119 Classification: Internal
top related