More on this book
Community
Kindle Notes & Highlights
relentless heroism—staying late night after night, wearing two hats, and consistently playing catch-up—is unsustainable.
Cross team communication is hard. When a bunch of two-pizza teams with lots of dependencies between them spend a lot of time coordinating to avoid stepping on each other’s code (due to the merging of the different teams’ code branches), the benefit of the small team diminishes. Smaller teams can increase integration costs. We like small teams because they can move fast. Just realize that by moving fast as an individual team, you may be paying the price of not moving very fast as a whole organization.
FAST solves this
Neglected Work often plants invisible technical debt in the system, knowing that short-term thinking sways prioritization in favor of new features over protecting valuable assets. Like financial debt, technical debt incurs interest payments, which come in the form of extra effort required to fix software bugs and develop new features.
If I had to identify what kind of work is most neglected, it would be the work related to improving quality, including deferred maintenance, bugs, technical debt, and code without tests (legacy software, as defined by Michael Feathers).1 Time and cost often win when it comes to getting product out the door (“Just skip those tests. We need to get this delivered. We’ll come back to it later.”). The current corporate culture that focuses on people being “busy” all the time is absurd. Work is neglected when people are “busy.” Busy people, however, do not signal productivity—delivered value does.
Gabriel Casarini liked this
When a bunch of two-pizza teams have a lot of dependencies between them, how much time is spent coordinating? It’s true, we like small teams because they can move fast. 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.
FAST Agile solves this problem
Humans are predictably horrible at estimation, even in their area of expertise,
Optimism is a near universal human trait when it comes to answering the question “When will it be done?” Software estimates are no different. Developers present optimistic estimates that management approves because of the implied achievable business targets.
The problem with the traditional estimation process (add up how long each part of the process will take and then add a buffer) is that each step in a process on its way to completion is clouded with uncertainty.
Estimates are filled with more uncertainty than confidence.
As we move from 60–80% utilization, the queue doubles. As we move from 80–90% utilization, the queue doubles again. And again from 90–95%.3 Once we get past 80% utilization, the queue size begins to increase almost exponentially, slowing things down to a grinding halt as it pushes 100% capacity utilization.
When it comes to efficiency, time is wasted when there is too much focus on resource efficiency overflow efficiency.
In knowledge work, however, problems with coordination costs grow nonlinearly with batch size. Old school management assumptions about economy of scale do not apply to knowledge work problems such as software development.
The only time anyone does anything right the first time is when they follow directions given by someone else who has done it many times before. The first time doing anything is an experiment.
Today, when I hear the term “best practices,” I attempt to use my magic introvert powers to avoid physically cringing. I have to remind myself that there are appropriate times for best practices. When the pilot goes through the checklist before heading down the runway. When the nurse cleans a wound before applying a bandage. When the system admin pulls the server out of rotation before restarting IIS. Best practices might sound cringeworthy, but they do have their place, especially when you’re doing something routine but important.
Change is hard for humans and is often met with resistance, especially during dramatic transformations. Lean coaches refer to this as the J-curve (Figure 53). Big changes cause dips in performance due to a variety of reasons: learning new material, hiring more people, installing and using new tools, yada, yada, yada. That’s why small, gradual changes are easier to implement. Small change meets with less defiance.
