More on this book
Kindle Notes & Highlights
If your team can’t make progress, but no impediments seem to stand in your way, rely on Willem Larsen’s TRIPE: Tools, Resources, Interactions, Processes, and Environment. [Larsen2021] Add each category to the questions in the preceding list: What Tools slow us down? What Resources slow us down? What Interactions slow us down? And so forth.
The team’s code is production-grade and the latest work is deployed to a production-equivalent environment at least daily.
The team’s business representative may release the team’s latest work at will.
Deploying and releasing is automated and takes no more than 10 minutes of manual effort.
No manual testing is required prior to deployment.
Most teams, even Agile teams, use a phase-based approach to development. They may work in iterations, but within each iteration, they follow a phase-based approach of requirements analysis, designing, coding, testing, and deploying,
Agile is inherently iterative and incremental. Each story is only a day or two of work. That’s not enough time for high-quality phases. In practice, design and testing get shortchanged. Code quality degrades over time, teams have trouble figuring out how to schedule necessary infrastructure and design work, and they run out of time for testing and bug fixing.
It’s the right and responsibility to make improvements to any aspect of your team’s code at any time.
When you discuss how to break down tasks, talk about your design. Write tasks in terms of how your design will change: “Add endpoint to UserReportController.” “Update ContactRecord.” “Add columns to GdprConsent database table.”
your team will swarm each story: everyone will choose tasks for the same story and focus on getting the story “done done” before moving on to the next. This minimizes work in progress
I recommend pairing on all production code.
A good rule of thumb is to pair on anything that you need to maintain, which includes tests and automation.
A good developer works quickly and well, but the best developers help everyone do so.
there are many ways for a programmer flying solo to be productive without touching production code. They can research new technologies or learn more about a technology the team is using. They can pair with a customer or tester to review recent changes, polish the application, or do exploratory testing. They can take care of administrative tasks for the team, such as responding to team emails.
Use a real programming language for your scripts.
Treat your scripts with the same respect as real production code.
The ultimate goal of continuous integration is to make releasing a business decision, not a technical decision. When on-site customers are ready to release, you push a button and release.
If you’re using feature flags and practicing test-driven development, you can integrate any time your tests are passing, which should be every few minutes. You shouldn’t ever be in a position where you can’t integrate. If you’ve gotten stuck, it might be a good idea to delete the unfinished code. If you’ve been integrating frequently, there won’t be much. You’ll do a better job with a fresh start in the morning.
Although broad tests seem like a good way to get test coverage, they’re a trap. Broad tests are slow and unreliable.
Conceptually, narrow integration tests are just like unit tests. In practice, because they involve the outside world, narrow integration tests tend to involve a lot of complicated setup and teardown. They’re much slower than unit tests: unit tests can run at a rate of hundreds or thousands per second, but narrow integration tests typically run at a rate of dozens per second.
the core six safe refactorings you need are Rename, Inline, Extract Method/Function, Introduce Local Variable, Introduce Parameter, and Introduce Field.
A spike solution, or spike, is a technical investigation. It’s a small experiment, in code, to research the answer to a problem. It usually takes less than a day. When you have the answer, the spike is discarded.
Balance technical excellence with delivering value. Neither can take precedence over the other.
Simplicity is hard, and you’ll have to iterate your design to get there.
When you use keystones and feature flags well: Your team can deploy software that includes incomplete code. Releasing is a business decision, not a technical decision.
Deploying the reverted code should proceed without incident because you’re deploying the same code that’s already running. It’s important to do so anyway, because it ensures your next deploy starts from a known-good state.
Deploy code that understands both the new and old schema. Deploy the data migration code at the same time. After the deploy is successful, run the data migration code. It can be started manually, or automatically as part of your deploy script. When the migration is complete, manually remove the code that understands old schema, then deploy again.
A bug is anything your team considers “done” that later needs correction.
“Building quality in” means keeping internal quality as high as possible while keeping external quality at the level needed to satisfy your stakeholders.
Bugs that aren’t important enough to fix should be discarded. If you can’t do that, the bug needs to be fixed. The “fix,” though, can be a matter of documenting a workaround, or making a record that you decided not to fix the bug. An issue tracker might be the right way to do this.
some testers are business-oriented: they’re very interested in getting business requirements right. They work with on-site customers to uncover all the nit-picky details the customers would otherwise miss. They’ll often prompt people to think about edge cases during requirements discussions.
Other testers are more technically-oriented. They’re interested in test automation and nonfunctional requirements. These testers act as technical investigators for the team. They create the testbeds that look at issues such as scalability, reliability, and performance. They review logs to understand how the software system works in production. Through these efforts, they help the team understand the behavior of its software and decide when to devote more effort to operations, security, and nonfunctional stories.
“Bugs are for other people.”
Bugs aren’t something to be tolerated; they’re a sign of underlying problems to be solved.
so many teams think of their job as building the product they were told to build. They act as obedient order-takers: a software factory designed to ingest stories in one end and plop software out the other.
Don’t just assume that your team should build what it’s told to build. Instead, assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team’s job is to take those ideas, test them, and learn what you should really build.
The data can be subjective, but the measurement should be objective. For example, “70% of our customers say they like us” is an objective measurement of subjective data.
building repeatable test plans that comprehensively validate the system. Although this may seem more reliable, those test plans have blind spots of their own. Most of the tests end up being redundant to the tests programmers create with test-driven development. At best, they tend to find the same sorts of issues that exploratory testing does, at much higher cost, and they rarely expose problems that the other techniques reveal.
Incident Analysis
This is a rather important chapter; consider the whole chapter highlighted
If failure is inevitable, then the important thing is to detect failure as soon as possible; to fail early, while there’s still time to recover; to contain failure, so the consequences are minimal; and to learn from failure, not place blame.
Everybody knows Agile teams are supposed to be autonomous, but organizations with Optimizing teams really mean it. For them, autonomy is more than just enabling teams to work independently. They give their teams full responsibility for their finances and product plans, too.
To meet these deadlines, Optimizing teams will often build a “safety” increment before embarking on a more ambitious idea. The “safety” increment fulfills the demands of the deadline, in a minimal way, leaving the team free to work on its more ambitious ideas without worry. If those ideas doesn’t pan out, or can’t be completed in time, the team releases the “safety” increment instead.
