http://itrevolution.com/a-personal-reinterpretation-of-the-three-ways/
A note from Gene Kim:
Last year, I got an email from Tim Hunter that blew me away. Among many brilliant things, he sent me a rewrite of The Three Ways, which are intended to be a set of principles from which you can derive all the observed DevOps patterns from.
When I read what he wrote, my jaw dropped. It was like having a poet rewrite your dissertation thesis. I've incorporated his language of Flow, Feedback and Continual Experimentation and Learning into all my talks now, and it will be incorporated into the next printing of "The Phoenix Project."
I hope you all enjoy this as much as I did!
I would like you to join me on a bit of a journey. This journey brings us to my current state in IT and reveals bits about how I came to this redefinition of the Three Ways that Gene Kim and the team on the Phoenix Project defined.
I have worked in various facets of IT since the 90's, starting off in a dialup ISP, building and selling systems, working with the sysadmins on our internal servers and helping people who had no idea why they wanted to be on the internet get onto the internet. This was my first taste of the Flow of Value. The faster we got our custom built $3000 PCs out the door, the more money we made, etc.
Next I spent a good deal of time working on, and then helping run a call center for a large company. Our 'value' was realized at the end of a call when the systems were working again, our Work In Progress was the call itself, we had 3 to 20 minute cycles on average. At one point, the company signed an agreement to support a Food Chain's Servers and Point of Sale terminals. Apparently, we decided that our SLA was 7 minutes for every call (decided by some sales person).
This should have been OK, as some calls were resolved quickly, others not so much, but we could probably average it out to 7 minutes. Unfortunately the customer had just deployed an extremely buggy back end system 'upgrade' that coincided with our takeover of support. Our cycles were averaging 40 to 50 minutes! We had a backlog at almost all times, and there was no way we could average that down to 7 minutes (we eventually got to know the bugs, and could resolve them much faster, but I don't think we brought our average below 15 minutes).
As a company, we paid penalties like mad for this, and eventually the customer took support back internally. This particular position made me realize that even if your pipelines are sized appropriately, Flow is affected by many different factors.
Now I will jump to the last couple of positions in my career (ya.. there was a bunch between this call center and now, but not as relevant as these next two)
I took a job as a network admin for an automation company — we built robots… (ya I know.. cool isn't it?) Our robots were self-contained assembly lines most of the time. They had their own networking gear, they had raw material inputs and something cool came out the other end. The really neat part was watching the Toolers and the Developers working together to get the Value Flow just right inside of each of these machines. They would build the machine to spec, write the PLC code to make it do what it needed to, and then they spent a long time tuning the systems to address bottlenecks and constraints, to make sure that the Inputs didn't back up at any time, and that we had the right input and output rates. Flow and Feedback were king, and no one silo or team was elevated over the other, everyone worked together to get it right.
Next I joined a pure Development company, a 7 year old start up working in Knowledge Graphs (Interest graphs… 7 years ago!) We had a Disruptive product that already had some time to mature, until the market realized that personalization and interest graphs were going to be our Next Web Technology. Then we needed to increase our Flow rates. It was with this company that I started trying to break down the silos and move past the Way of Flow. When I started Development was Development and Ops were the guys who said 'No' and worried about stability. QA was the gateway to OPs and we spent hours troubleshooting deployments. With a lot of hard work from all of our teams we brought deployments down from most of a day to under 30 minutes. (There were some edge cases that were faster or slower… but on average…). We recognized our constraints and elevated them to the best of our abilities, near the end of my time with this company, we had OPs attending the Devs Standups, we (Ops) knew about infrastructure affecting changes before they were checked in, and had an environment ready to support those changes. Our Developers and Business folks were all on the appropriate mailing lists to know about outages when they happened. We were continuously deploying 2 separate environments (Not prod though) and iterating much faster on our experiments.
When the Phoenix Project was about to release, I received the preview of the book from IT Revolution Press, and found myself thinking (on numerous occasions) "I have been Bill in this situation before" or "I remember
No comments:
Post a Comment