2. Who is here today?
● Me
– Rudiger Wolf
● Twitter: @rnwolf
● LinkedIn: http://uk.linkedin.com/in/rudigerwolf/
– Agile Consultant & Scrum Master
– Been using Agile approaches since 1998
● Why are you here?
– Name
– Role
– Interest in book /Event
– What do you want to get out of event?
3. My Objective
●
Get more people to read “The Phoenix Project”
–
●
Provide some thinking tools and references
–
●
Make a difference to more people
Speed up your learning and adoption
Learn from you and your experiences
4. Poll
●
●
●
How many have read “The Phoenix Project”?
What is the cycle time in your team from code
to production?
How many of you have Ops represented in Dev
teams?
–
How long has Ops people been embedded in Dev
teams?
6. Why is this important?
High Performing DevOps Teams
●
They’re more agile
–
–
●
30x more frequent deployments
8,000x faster cycle time than their peers
They’re more reliable
–
2x the change success rate
–
12x faster MTTR
●
MTTR = Mean time to Restore/Repair/recovery
Source: Puppet Labs 2012 State Of DevOps: http://puppetlabs.com/2013-state-of-devops-infographic
8. More success stories - GAP Inc
“The Phoenix Project” which outlines what a hypothetical Agile and DevOps
transformation looks like. While the novel is a great way for people to understand
how agile/devops change can happen, it might be great to hear about a real success
story.
Let me offer up Gap Inc as an example of how you can take massive legacy enterprise
IT and make a real transformation happen. The actual implementation of Agile
processes by a business with a heavily traditional structure and workflow is not
without pain. Being successful requires a strong spine and executive leadership that
is willing to put everything on the line. For Gap, the CIO (Tom Keiser) and VP of
Infrastructure (Naveen Zutshi) were key to pushing the transformation through
successfully.
http://padgeblog.com/2013/01/20/agile-and-devops-at-scale/
See Slides and Paper
Look at the first few slides http://www.scribd.com/doc/121410817/Enterprise-DevOpsat-Scale
12. What does Gene Kim Say about the
book?
●
http://www.youtube.com/watch?v=FpEd-QKVIrw 5 min
13. The Phoenix Project - The Authors
●
Gene Kim
–
●
George Spafford
–
●
Gene Kim is a multiple award-winning entrepreneur, the founder and former
CTO of Tripwire and a researcher. He is passionate about IT operations,
security and compliance, and how IT organizations successfully transform
from “good to great”.
George is an author and speaker, consulting and conducting training on
strategy, IT management, information security and overall service
improvement in the U.S., Canada, Australia, New Zealand and China. Coauthor of “The Visible Ops Handbook” and “Visible Ops Security,” George is
a certified ITIL Expert, TOCICO Jonah and a Certified Information Systems
Auditor (CISA).
Kevin Behr
–
Kevin Behr is the founder of the Information Technology Process Institute
(ITPI) and the CTO of Assemblage Pointe. Kevin has twenty years of IT
management experience and is a mentor and advisor to Chief Executive
Officers and Chief Information Officers.
14. Book Introduction
●
Bill is an IT manager at Parts Unlimited. It’s Tuesday morning and on his drive into
the office, Bill gets a call from the CEO.
●
The company’s new IT initiative, code named Phoenix Project, is critical to the future
of Parts Unlimited, but the project is massively over budget and very late. The CEO
wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire
department will be outsourced.
●
With the help of a prospective board member and his mysterious philosophy of The
Three Ways, Bill starts to see that IT work has more in common with
manufacturing plant work than he ever imagined. With the clock ticking, Bill must
organize work flow streamline interdepartmental communications, and effectively
serve the other business functions at Parts Unlimited.
●
In a fast-paced and entertaining style, three luminaries of the DevOps movement
deliver a story that anyone who works in IT will recognize. Readers will not only learn
how to improve their own IT organizations, they’ll never view IT the same way again.
15. Cast at Parts Unlimited
●
Parts Unlimited: Business Executives
–
–
Dick Landry, CFO
–
Sarah Moulton, SVP of Retail Operations
–
Maggie Lee, Senior Director of Retail Program Management
–
Bill Palmer, VP of IT Operations , former Director of Midrange Technology Operations
–
Wes Davis, Director of Distributed Technology Operations
–
Brent Geller, Lead Engineer
–
Patty McKee, Director of IT Service Support
–
John Pesche, Chief Information Security Officer (CISO)
–
●
Steve Masters, CEO, acting CIO
Chris Allers, VP of Application Development
Parts Unlimited: Board
–
Bob Strauss, Lead Director, former Chairman, former CEO
–
Erik Reid, Board Candidate
–
Nancy Mailer, Chief Audit Executive
16. Why a novel?
●
Who has read “The Goal”?
●
Storytelling
Is The Most Effective Means Of
Creating A Shared Understanding
●
The pattern is everywhere:
The core of the solution-selling,
good copy-writing and the best TED talks: Describe the problem, show its
significance, describe how the problem is solved and the value it will creates.
●
Storytelling becomes very important when the problem we’re trying to point out is not
fully recognized, or when the solution being proposed flies in the face of common
wisdom.
○
PS - And the summary is http://de.slideshare.net/goldrattinstitute/understandingthe-goal
○
http://itrevolution.com/learn-more-about-concepts-in-phoenix-project/
http://www.youtube.com/watch?v=oP3c1h8v2ZQ 5 min
18. How to create a “Problem”?
http://www.coso.org/documents/coso_erm_executivesummary.pdf
http://www.youtube.com/watch?v=b7JldvsY7Ac
The ERM framework by the Commission of Sponsoring Organizations of the Treadway
Commission (COSO) provides a more disciplined and consistent standard against which to
implement and assess a company’s ERM program.
19. Strategy
●
Strategy: as embodied by the Phoenix Project,
which the entire future of the company depends
upon. It requires that IT be a core competency.
20. Reporting
●
Accurate financial reporting: as embodied by
the third year repeat audit findings around the
IT general controls, but also the loss of
accounts payable and inventory management
systems which prevents the closing the
financial books at the end of quarter. Even the
payroll failure resulted in inaccurate payroll
numbers, which led to financial reporting errors.
21. Compliance
●
Compliance with laws and regulations (e.g.,
SOX-404, PCI DSS): failing the SOX-404 audit
results in an adverse footnotes by the external
auditor in the SEC 10-K statement, and there
are grave implications for failing the PCI DSS
assessment.
22. Operations
●
●
Operations (e.g., IT application and project
delivery, IT operations, information security)
The Project Phoenix was $20 million overbudget and three years late, and when it finally
was deployed into production, everyone would
have been better off it hadn’t. Furthermore,
virtually all of the critical business systems that
run daily operations require that IT services be
running correctly, which they often weren’t.
23. Generic problems – Downward Spirals
● Fragile artefacts become more fragile
● Technical debt grows
● Date-driven application projects focus only on features,
sacrificing non-functional requirements, which results in more
fragile artifacts in production
● Application deployment take longer, more difficult, getting gets
worse
● IT Ops is stuck fire fighting and therefore cannot do preventive
work or new projects
● Long feature delivery cycle times result in more political
decision making, meaning more focus on features (vs. nonfunctional requirements)
25. Breakthrough 1 - 3
●
●
●
Breakthrough 1: discovering too much WIP in IT
Operations and gob-smacking amounts of
reliance on Brent for both project and recovery
work
Breakthrough 2: elevating preventive work to
prevent unplanned work (especially for Brent)
and making work visible
Breakthrough 3: throttling the flow of work into
IT Operations by the project freeze
(subordinate)
26. Breakthrough 4 - 6
● Breakthrough 4: identifying and limiting the flows of work to
Brent (it was genuinely surprising to find out after the fact at
how much this resembles the green/red tag pattern used in
“The Goal”) Kanban Board
● Breakthrough 5: documenting and defining standardized work,
and managing handoffs to reduce time spent in queue (through
use of kanbans), and further reducing reliance on Brent
● Breakthrough 6: correctly identifying reliance on IT systems to
hit Dick’s corporate objectives (via Gartner RVM model) and
correctly scoping audit and infosec (via GAIT and GAIT-R)
27. Breakthrough 7 & 8
● Breakthrough 7: building DevOps flow of work to better design
in non-functional requirements in Dev, reduce batch sizes and
enable single-piece flow through Development and IT
Operations and better enable operational resilience (replicating
the work described by Jez Humble, David Farley, Paul
Hammond and John Allspaw)
● Breakthrough 8: when they discover the constraint moves
outside the organization, they bring back those resources inhouse (replicating one of my favourite Theory of Constraints
plays: when there’s idle plant capacity, it’s often cheaper to
fabricate parts in-house than to pay a supplier. Lovely.)
28. 4 types of work
●
Business project work,
●
IT project work,
●
changes and
●
unplanned work.
29. Thee Three Ways
●
Way No. 1: The flow
●
Way No. 2: Consistent feedback
●
Way No. 3: Continual learning
Page 99 – Erik Introduces the concept.
Page 297 – Bill learns how important The Three Ways are.
“But I learned that the practices that Allspaw and Hammond
espoused are the inevitable outcome of applying the Three
Ways to the IT value stream. It totally changed how we managed
IT and it saved our company. “How did they do it?” I ask,
dumbfounded.”
30. Way No. 1: The flow
1. Understand the flow of work.
●
Without understanding, any changes will have
random effects.
2. Always increase the flow
3. Never pass on defects downstream
4. Never allow local optimization to cause global
degradation
5. Achieve profound understanding of the entire
system
31. Way No 2: Consistent Feedback
● Understand and respond to the needs of all customers, both
internal and external.
● Shorten and amplify all feedback loops.
– Kim said this rule is modelled after the Toyota Lean
manufacturing line, where any employee can stop the line
immediately if they see any defect.
● Create quality at the source.
– This means pro-actively building quality into everything.
There's no need for developers to rely on QA to find their
errors.
● Create and embed knowledge where we need it.
32. Way No. 3: Continual learning
●
●
●
Create a culture that encourages
experimentation
Learns from failure
Recognizes repetition as the prerequisite to
mastery
33. Thanks
● Thanks for your time and attention
● Thanks to the authors of “The Phoenix Project”
● Thanks to Matt Gelbwaks for hard copies of the
Book!
34. References
●
More details on Kim’s thinking
○ http://www.evernote.com/shard/s200/sh/30e59bbe-83f1-4e51-ad4760a114bd01b5/30ef83900ee48717a8fc7f0e47e64a89
●
●
●
●
●
●
●
http://itrevolution.com/learn-more-about-concepts-in-phoenix-project/
http://itrevolution.com/a-personal-reinterpretation-of-the-three-ways/
Free 170 page excerpt:http://itrevolution.com/the-phoenix-project-excerpt/
●
●
●
●
SAFe DevOps reference http://scaledagileframework.com/devops/
http://puppetlabs.com/2013-state-of-devops-infographic
○ https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf
http://slideshare.net/realgenekim
TOCICO http://www.tocico.org
Understanding the Goal - http://de.slideshare.net/goldrattinstitute/understanding-thegoal
Dr Holt's TOC courses at Washington State University
○ http://public.wsu.edu/~engrmgmt/holt/WSU-TOC-Flyer-Web.htm