More on this book
Community
Kindle Notes & Highlights
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.
another way to visualize dependencies via your kanban board using a swimlane of its own.
Or, visually call out dependencies between different teams so they can be broadcasted widely to reduce expensive business pain.
To avoid the “out of sight, out of mind” issue, visualize work flowing between teams.
Visualizing important cross-team information helps communicate across teams.
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.
It may even help you to get leadership buy-in for organizing by product teams instead of by project teams—something to consider if your current organizational structure isn’t serving you very well.
organizing teams by product decreases dependencies during hand-off to ongoing operational support.
Projects are delivered as one big monolithic thing, meaning that coordinating all the activities within a big release is difficult and slow.
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.
Instead of teams, call out software components in the dependency matrix.
and why we need to plan for unplanned work. Because unplanned work can wipe out your objectives, unplanned work deserves visibility.
There’s usually resistance to this in the form of Platform Operations Manager Erik, who says, “I don’t have time to create a ticket every time I get interrupted!” But after weeks of interruptions, the CIO wants to know why Azure isn’t up and running in production. And what does Erik say? “We’ve been busy.”
When unplanned work is made visual, other people can see it and understand why work isn’t done—and steps can be taken to prevent, or at least limit, unplanned work from taking over in the future.
Interruption Busters
consistency of work times and break times help establish habits to minimize interruptions. Consistency signals to people when they can have your attention and when they cannot. Consistency helps to minimize the damage from unplanned work.
HiPPO (highest paid person’s opinion).
Beware the lack of good rules for prioritization—remember, when everything is a priority one, nothing is a priority one.
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.
We are often confident even when we are wrong,1 and it can be hard for us to see when we are wrong. This is why making prioritization policies visible is vital—it drives the right conversations for delivering ideal outcomes.
When work goes on hold because someone says you need to do this other thing now, show that in your visibility efforts.
Quantifying the cost of the work that gets delayed is useful.
CoD can be used to negotiate prioritization of work and to bring visibility to projects that have a bigger impact on the bottom line than the others. Visualizing CoD drives the right conversations and decisions around cost and revenue.
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.
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?”
once work passes the line of commitment, it explicitly signals that it’s been prioritized and is moving forward.
“Let’s add this other fix while the hood is up.”
Once the work has sat untouched for weeks or even months, we forget the details, and it takes a long time to dive back in.
Multitasking is an effective way to get less done.
Neglected work is another term for partially completed work. Consider a partially completed bridge. It is already expensive, but it provides zero value until it’s finished.
short-term revenue-generating work is top-of-mind for business people, but the long-term health of the platform system is rarely contemplated. As a result, revenue protection work takes a backseat until something blows up, such as a distributed denial-of-service attack or a corrupt finance database that brings down credit card fulfillment.
There’s a chance that you might want to hold off on moving the work to Done in order to get visibility on work that isn’t providing any value to the requestor yet.
new feature isn’t done until it’s working right in Production. Done Done signals the real finish line, often quite awhile after the code is considered shippable or even delivered to production.
PDCA (Plan-Do-Check-Act).
The additional stress that comes with procrastination is avoidable. Instead of the out-of-sight, out-of-mind that occurs when long-term assignments are hidden on different calendar pages, make all the student things visible on one page.
kanban brings a smooth flow to home life.
Exposing time theft is one giant step for humankind—a step that is relatively easy to take once you know where the five most wanted time thieves hide out.
Capturing data for metrics can help you become the voice of reason and prompt change in your organization. Metrics get attention.
If expectations are set correctly, not everything needs a due date. Being predictable is what counts. Being predicable saves time.
Whatever the cause, they begin to miss due dates when these unanticipated obstacles prevent them from staying on schedule.
A lack of data often leads to people making decisions based on opinions, which are likely to be more problematic than decisions based off of good data (i.e., visible work).
lack of visible data in IT makes us blind to problems because we don’t have anything to tell us how we are actually doing.
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.
Humans are predictably horrible at estimation, even in their area of expertise, myself included.
Optimism is a near universal human trait when it comes to answering the question “When will it be done?” Software estimates are no different.
Estimates are filled with more uncertainty than confidence.
Flow time is a measure of how long something took to do from beginning to end.
Lead time and cycle time are types of flow time metrics. They both measure duration.
People who order pizza care about lead time. They want their pizza delivered quickly. Internal teams care about cycle time.
I’m convinced now that the doctor’s offices that don’t have long wait times are the ones that understand why 100% capacity utilization doesn’t work.
