Disclaimer
I do not believe these books are a "magic bullet" that work for all or any situations. But it is nice to have another perspective and a lens I can use to see what implementing some of this would look at my previous work experiences. But also, how hard would it be to reverse and apply some other framework to previous work experiences?
After reading/listening to the books/audio_books "The Phoenix Project", "The Unicorn Project" and "The Dev Ops Handbook", I found it most helpful to write down the core concepts so that I could explain them to others without them needing to read the books.
Having these concepts helps to talk about these ideas with other people who may never read the books on my suggestion.
Unfortunately I find myself being that guy who says. "Interestingly enough what you just described relates to this book in this way." However, I think it is better to reference a book than having an unsubstantiated opinion on a topic or no opinion on a topic.
I do not see these comments as "right" but they provide a framework a language and a potential "what you might do" and leaves you to question and chew on "how you might implement them in your situation" and what that would look like and where it would be good and where it would be bad and something else better.
(End Disclaimer)
In order to quickly find these items I looked up some summaries like
this summary: https://www.runn.io/blog/the-phoenix-project-summary
this summary: https://www.markhansen.co.nz/the-unicorn-project/
this video: https://youtu.be/vLHFuQjJR8Y?si=QYHunAsxd85QBUqh&t=670 (the bit about sprouter is really interesting!)
simplicity video Rich Hickey: https://www.youtube.com/watch?v=SxdOUGdseq4
Concept 1. The Three Ways of Dev Ops
- Flow
- Feedback
- Continual Experimentation and Learning
Concept 2. The Four Types of Dev Ops Work
- Business Projects
- Internal IT Projects
- Updates and Changes (Maintenace)
- Unplanned work (Recovery Work)
Concept 3. The Five Focusing Steps (Theory of Constraints)
- Identify the system constraints.
- Decide how to exploit the system constraint. ("exploit" means make full use of and derive benefit from the resource)
- Subordinate every thing else to the above decisions.
- Elevate the system constraint.
- If a constraint has been broken in a previous step go back to step 1. Do not allow inertia to cause a system constraint.
Concept 1. The Five Ideals of Dev Ops
- Locality and Simplicity
- Locality:
- Simplicity: Rich Hickey https://www.youtube.com/watch?v=SxdOUGdseq4
- Focus, Flow, and Joy
- Focus
- Flow
- Joy
- Improvement of Daily Work
- Psychological Safety
- Customer Focus
Concept 2. The three horizons:
(below bullets grabbed from: https://www.cascade.app/blog/mckinseys-three-horizons-of-growth)
(not pulled explicitly from the book, because I like how simply it is presented.)
(also that url has a good photo of the three horizons.)
- Horizon 1: Maintain and defend the core business
- Horizon 2: Nurture emerging business
- Horizon 3: Create genuinely new business
Concept 1. The Andon Cord
( pulled on average 3600 times a day in a manufacturing plant! ).
Concept 2. WIP limits:
When we limit wip we find that we may have nothing to do because we are waiting on someone else. Although it may be tempting to start new work (i.e. "better to do something than nothing"), a far better action would be to find out what is causing the delay and help fix that problem.
Concept 3. 9 types of waste
(extrapolated from "Poppendieck, Implementing Lean Software and Edwards, DevOps Kaizen")
- Partially done work - becomes obsolete and loses value as time progresses.
- Extra Processes - work performed in a process that does not add value to the customer.
- Extra Features - "gold plating", building features not needed by the organization or customer.
- Task Switching - requiring switching contexts and managing debendencies between work.
- Waiting - any delay requiring a resource to wait.
- Motion - handoffs, additional communications. The amount of effort to move information between people / groups.
- Defects - As time between defect creation and defect resolution increases difficulty to resolve defect increases.
- Non Standard / manual work - any manual work that can be automagted should be automated.
- Heroics - performing unreasonable acts, sometimes at unreasonable hours.
Our goal is to make these wastes and hardships - anywhere heroics become necessary -- visible, and solve these burdens and hardships.
Additional Definitions:
takt time: the cycle time needed in order to keep up with customer demand.
lead time: the time it takes from customer request to customer recieving benefit.
process time: the time it takes from the company begining work on request until customer recieveing benefit.
(process time is also known as touch time, task time)
kaizen blitzes: periods when engineers self-organize into teams to work on fixing any problem they want.
└─ It turns out there are many other kaizen examples outside of dev ops: https://en.wikipedia.org/wiki/Kaizen
https://itrevolution.com/articles/resource-guide-to-the-unicorn-project-part-1
Patrick Lencioni's five dysfunctions of a team :
- Absence of trust.
- Fear of conflict.
- Lack of commitment.
- Avoidance of team accountability.
- Inattention to team objectives.
Disclaimer (Cont.)
(Begin Disclaimer)
Creators of ideas present their thoughts as "the best", "the magic bullet", they do not talk about situations where other models fit better. These books often describe "what to do", I like to chew on the challenges of "how" you would implement the "what" that is described, which is usually not easy. Also continually re-evaluate, is this way of thinking still best, what are other perspectives, and how easy is it to remove these practices if they turn out not to be helpful for your team/organization.
(End Disclaimer)
(Note to self) I need to break this document into smaller pieces, I think in this long form it probably does not communicate the ideas effectively to others. (I think I could just break the top section out into its own gist and link it so people can ignore it but I can still refer to it to be of a better frame of mind when I talk about these subjects).
link to toil from google sre book: https://sre.google/sre-book/eliminating-toil/