More on this book
Community
Kindle Notes & Highlights
by
Gene Kim
Read between
January 13 - January 23, 2022
“every work center is made up of four things: the machine, the man, the method, and the measures.
You’ve already identified the constraint, exploited it to squeeze the most out of it, and then you’ve subordinated the flow of work to the constraint. So, how important is this monitoring project?”
‘Improving daily work is even more important than doing daily work.’
almost doesn’t matter what you improve, as long as you’re improving something. Why? Because if you are not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors, zero work-related accidents, and zero loss.”
repetition creates habits, and habits are what enable mastery.
These ‘security’ projects decrease your project throughput, which is the constraint for the entire business. And swamp the most constrained resource in your organization. And they don’t do squat for scalability, availability, survivability, sustainability, security, supportability, or the defensibility of the organization.”
Even though we have so much data on projects, changes, and tickets, we’ve never organized and linked them all together this way before.
“The wait time is the ‘percentage of time busy’ divided by the ‘percentage of time idle.’
CFO GOALS Health of company
what I believe are the more important company goals. I look at this slide every day.”
He talked about the need to understand the true business context that it resides in.
I’m pretty sure no one has linked Dick’s top measurements to the prerequisite it objectives.
“As part of the First Way, you must gain a true understanding of the business system that it operates in. W. Edwards Deming called this ‘appreciation for the system.’ When it comes to it, you face two difficulties: On the one hand, in Dick’s second slide, you now see that there are organizational commitments that it is responsible for helping uphold and protect that no one has verbalized precisely yet. On the other hand, John has discovered that some it controls he holds near and dear aren’t needed, because other parts of the organization are adequately mitigating those risks.
“Some of the wisest auditors say that there are only three internal control objectives: to gain assurance for reliability of financial reporting, compliance with laws and regulations, and efficiency and effectiveness of operations. That’s it. What you and John are talking about are just different slides of what is called the ‘coso Cube.’”
By showing how it risks jeopardize business performance measures, you can start making better business decisions.
“You’ll be ready for your meeting with Dick when you’ve built out the value chains, linking his objectives to how it jeopardizes it. Assembling concrete examples of how it issues have jeopardized those goals in the past. Make sure you’re prepared.” And with that, he says, “In
“By describing what could go wrong in it that prevents the business outcome from being achieved, we’re helping the business process owners get their bonuses. This should be very persuasive. We may even be thanked by the business for doing all this work, which would be a refreshing change.”
you’ve deployed an amazing technology, but because you haven’t changed the way you work, you haven’t actually diminished a limitation.”
It’s about how good you are at detecting and responding to changes in the market and being able to take larger and more calculated risks. It’s about continual experimentation, like Scott Cook did at Intuit, where they did over forty experiments during the peak tax filing season to figure out how to maximize customer conversion rates. During the peak tax filing season!
Wouldn’t you love to do these types of changes in production routinely, without having to break all the rules to do some sort of emergency change?”
Chris thinks for a couple of moments before responding. “Interesting. I would normally call those types of fixes a patch or a minor release. But you’re right—those are deployments, too. It would be great if we could roll out fixes more quickly, but come on, ten deploys a day?” Thinking about what Erik said, I add, “How about enabling Marketing to make their own changes to content or business rules or enabling faster experimentation and a/b split testing, to see what offers work best?”
Countless configurations need to be set correctly, systems need enough memory, all the files need to be put in the right place, and all code and the entire environment need to be operating correctly. Even one small mistake could take everything down.
‘value stream map.’
“deployment pipeline.” Even though you can’t see our work like in a manufacturing plant, it’s still a value stream.
“With the current process, two issues keep coming up: At every stage of the deployment process, environments are never available when we need them, and even when they are, there’s considerable rework required to get them all synchronized with one another. Yes?”
“Having each group cobble an environment together obviously isn’t working.
automation.
Brent, what would it take for us to be able to create a common environment creation process, so we can simultaneously build the Dev, qa, and Production environments at the same time, and keep them synchronized?”
“If we had a common build procedure, and everyone used these tools to create their environments, the developers would actually be writing code in an environment that at least resembles the Production environment. That alone would be a huge improvement.”
I propose we change that requirement. At each three-week sprint interval, we not only need to have deployable code but also the exact environment that the code deploys into, and have that checked into version control, too.”
“On the manufacturing floor, whenever we see work go backward, that’s rework. When that happens, you can bet that the amount of documentation and information flow is going to be pretty poor, which means nothing is reproducible and that it’s going to get worse over time as we try to go faster. They call this ‘non-value-add’ activity or ‘waste.’”
William walks to the whiteboard and points at a box called “code commit.” “If I could wave this magic wand, I would change this step. Instead of getting source code or compiled code from Dev through source control, I want packaged code that’s ready to be deployed.”
She would be responsible for the Dev handoff. When code is labeled ‘ready to test,’ we would then generate and commit the packaged code, which would trigger an automated deployment into the qa environment. And later, maybe even the Production environment, too.”
By doing this, we could develop, test, and even run in operations without impacting Phoenix or other business critical applications. And by decoupling ourselves from the other projects, we could make all the changes we needed to without putting other projects at risk. At the same time, we wouldn’t get bogged down in the processes that we didn’t need to be a part of.
