More on this book
Community
Kindle Notes & Highlights
Read between
July 8 - August 10, 2021
We overload ourselves and we overload our teams—this is the everyday reality within the information technology sector.
Kanban is a visual pull system based on constraints that allow workers to pull work when they have availability instead of work being pushed onto them regardless of their current workload.
Multitasking is a good way to screw up progress, as I’m sure many of you reading this book know from experience.
TOC is a way to identify the most important limiting factor (the constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor.
All it takes is a shift from haphazardly saying yes to everything to deliberately saying yes to only the most important thing at that time. And to do it visually.
The solution is to design and use a workflow system that does the following five things: Make work visible. Limit work-in-progress (WIP). Measure and manage the flow of work. Prioritize effectively (this one may be a challenge, but stay with me—I’ll show you how). Make adjustments based on learnings from feedback and metrics.
As Edwards Deming said, “A bad system will beat a good person every time.”
The five thieves of time that prevent you from getting work done include: Too Much Work-in-Progress (WIP)—Work that has started, but is not yet finished. Sometimes referred to as partially completed work. Unknown Dependencies—Something you weren’t aware of that needs to happen before you can finish. Unplanned Work—Interruptions that prevent you from finishing something or from stopping at a better breaking point. Conflicting Priorities—Projects and tasks that compete with each other. This is exacerbated when you are uncertain about what the most important thing is to do. Neglected
...more
Cycle time is the amount of elapsed time that a work item spends as work-in-progress. In addition, business value that could have been realized sooner gets delayed because of too much WIP. This is known as cost of delay. It’s a concept used to communicate value and urgency—a measure of the impact of time on the outcomes we want, such as customers buying our product this month instead of next month.
WIP is a leading indicator of cycle time. The more items that are worked on at the same time, the more doors open up that allow dependencies and interruptions to creep in.
There is a relationship between the amount of WIP and cycle time—it’s called Little’s Law, where the average cycle time for finishing tasks is calculated as the ratio between WIP and throughput.
“The joy is in the pursuit more than the realization. In the end, mastery attracts precisely because mastery eludes.”
All too often, when someone asks you, “Do you have five minutes?” and you say yes, you end up working late.
When you are the only one on the team with a special skill set, you can be the bottleneck pulled in many directions. Expert skills in high demand are often unavailable when you need them. Thief Unknown Dependency snickers in delight.
You know Thief Unknown Dependency is stealing time from you when: Coordination needs are high, and project managers run around trying to get everyone aligned. People aren’t available when you need them. A change in one part of the code/outline/plan unexpectedly changes something else.
When we attempt to increase the performance of individual teams by breaking them down into smaller groups, hidden dangers await if there are unknown dependencies.
This is the problem with unplanned work—it sets back planned work. It increases uncertainty in the system and makes the system less predictable as a result.
Focus is a matter of deciding what things you’re not going to do. —John Carmack
“Many things may be important, but only one can be the most important.
Busy people, however, do not signal productivity—delivered value does.
Time is what we want most, but what we use worst. —William Penn
There is a reason our schools and offices are plastered with whiteboards. We acquire more information through vision than through all the other senses combined.
Multitasking is merely the opportunity to screw up more than one thing at a time. —Steve Uzzell
It’s the WIP limits that create the necessary tension in the system. They give permission for people to say, “No, I can’t take that on right now; my plate is full.” They are the constraint that enables the completion of work.
Waiting on feedback from others is one of the biggest delays in workflow. The longer it takes to get feedback, the easier it is to forget details and the harder it is to be able to pick the work back up again. Like rotten fruit, knowledge decays faster than we’d like.
“By the time you find out you suck, you have sucked for a very long time.”
Just realize that by moving fast as an individual team, you’re less able to move fast at the organization level due to the high coordination impacts from having a large number of dependencies.
However, large organizations with many teams are not so lucky in this regard. At a certain point, the organization has grown to where it’s impractical for lots and lots of people working on lots of different projects to be aware of every decision that impacts them (such as architecture changes and new third-party integrations). The more teams, the higher the probability that more dependencies are going to sneak into your day, project, objective, and so on. The more WIP, the greater the likelihood of Thief Unknown Dependencies hunting you down.
Organizing teams around a product allows the people who developed, tested, and delivered the functionality to stay in their area of expertise. There is no need for complex, dependency-driven hand-overs. Instead, organizing teams by product decreases dependencies during hand-off to ongoing operational support.
Project teams tend to be measured by vanity metrics (e.g., test teams within a project team are measured by the number of software bugs), whereas product teams are measured by the business value derived.
The preferred architecture is loosely coupled components, individual microservices, built by individual teams—autonomous product teams, not project teams.”
Knowing the ratio of unplanned work to planned work helps when planning your workload capacity. Why? Because you’ll have an idea of how to set WIP limits to accommodate important, unexpected, and urgent work.
After that discussion happened, the projects were reprioritized based on the VP’s input, a classic prioritization strategy known as HiPPO (highest paid person’s opinion).
Cost of delay (CoD): A way of communicating value and urgency, CoD is a measure of the impact of time on the outcomes we want. This is an excellent approach for determining business risk, but difficult for many people to actually do.
Weighted shortest job first (WSJF): WSJF gives preference to the shortest job with the highest CoD. WSJF is calculated by dividing the CoD by the job duration. The Scaled Agile Framework (SAFe) model uses a variant of WSJF, which attempts to include time critically.
Work takes a long time to complete because it sits in queues waiting for stuff to happen. It’s not unusual for wait times to be more than 80% of the total time. Many organizations are blind to the queue problem. They tend to focus on resource efficiency instead of applying systems thinking to improve the efficiency of the whole system, end to end.
Cost of Delay combines urgency and value—two things that humans are not very good at distinguishing between. To make decisions, we need to understand not just how valuable something is, but how urgent it is.2
Simply put, CoD has to do with two constantly changing variables: value and time. CoD asks the question, “What value is lost by the delay of something? How much will we lose if we deliver this thing twelve months later?”
And because things are delayed, people want to pile on more things—you know, “Let’s add this other fix while the hood is up.” This all causes work to take longer than it should and delays the delivery of business value.
In the same way that cross-team boards make hand-offs visible, multi-level kanban designs make multiple projects and cross-functional teamwork visible. A multilevel board design provides a big-picture view from the portfolio level to the team level, providing visibility of all the WIP.
The good news is that there are some CFOs out there who get it and are evolving from traditional project-based resource allocation and cost accounting to a faster, lower-overhead financial management model. Yippee! (For some examples, check out Brian H. Maskell, Bruce Baggaley, and Lawrence Grasso’s Practical Lean Accounting: A Proven System for Measuring and Managing the Lean Enterprise.)
It’s all about the expectations. Setting better expectations makes leadership happy and helps make those uncomfortable stand-ups and retrospectives surprisingly fun.
Imagine trying to fly a plane without a fuel gauge, compass, or airspeed indicator. How risky would that be for a pilot?
When it comes to forecasting how long things are going to take (remember Hofstadter’s Law), it’s useful to look at metrics that measure progress instead of activities.
Some of the best metrics that show actual progress (or lack thereof) are lead time, cycle time, WIP, and aging reports.
Attempting to load people and resources to 100% capacity utilization creates wait times. The higher utilization, the longer the wait, especially in fields with high variability, like IT.
Have you ever worked for a company that has a 20% “creative” time policy? I’ve read that the main reason they do that is not for innovation (that’s just a bonus) but to keep capacity utilization at 80% rather than at 100%.4 In 1948, 3M gave its workforce 15% slack time, which years later resulted in sticky notes.
We don’t let our servers get to 100% capacity utilization, so let’s not do that to ourselves.
Some people have a bias for large batch sizes because of the concept of economies of scale. Economies of scale is the cost advantage that arises with increased output of a product. The cost advantage is seen in some areas of manufacturing.
