The Nature of Software development: reading breadcrumbs, quotes, thoughts
Preface
The Natural Way serves end users well because it delivers value to them sooner.
serves the business […] because it provides important information quickly, and because it provides the ability to adjust direction as needed.
serves management […] see what’s really going on inside the project so that when action is needed, there will be time to act. And it reduces management’s problems by making information visible […]
[…] easier for developers. […] clear direction and allows them freedom to use their skills to build what the organization needs, when it’s needed.
(p. xv)
Part I: The Circle of Value
Chapter 1: The search for value
Value. “what you want.”
(p. 5)
On the building blocks of value or to produce value:
Guiding. We produce value by creating teams with responsibility for creating value.
(p. 5)
The value in guiding is not related to creating value in itself, but to help others so they can create value.
Therefore, the value of guiding depends on the value of the value-producing people
Organizing […] We organize around features, because features give us the ability to plan and build value most rapidly
(p. 5)
Planning […] selecting the features we need, in the order we need them.
(p. 5)
Building […] product feature by feature
(p. 5)
Slicing […] smallest possible value-bearing size
(p. 5)
Quality […] always has a good design and that it is as nearly defect-free as possible
(p. 5)
Chapter 2: Value is What we Want
we generally get value by delivering features. Features that have value. Features that we want.
(p. 7)
software can save time or money. Software can help us earn money
(p. 7)
I think of value as simply what we want […] Each choice gives us something we value
(p. 7)
A project delivers value only when we ship the software and put it to use
(p. 8)
Since most users don’t use all the features, a smaller set of features can provide real value, and provide it sooner.
(p. 10)
pieces that make sense to us, and to our users. […] minimal marketable features (MMFs)
(p. 12)
Chapter 3: Guiding Goes Better “Feature by Feature”
With a monolithic project, late in the game we can’t do much to cut costs. We have already written requirements for things we’ll never get
(p. 22)
We laid out this project with an all-or-nothing mentality.
(p. 22)
When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management.
(p. 24)
Chapter 4: Organizing by Feature
To get the work done, different parts require different skills. The work won’t be done […] until it has had the attention of people with each needed skill.
If we organize teams by skill-set, each piece of work will need to be passed around among teams
(p. 26)
organize into small teams, each of which builds features that the Product Champions can understand. Make sure that each team has all the people and all the skills necessary to build the entire feature, not just part of it
(p. 27)
[…] we can allocate work across teams easily […] Responsibility and authority are aligned.
(p. 27)
the people belong to the feature teams.
(p. 30)
You belong to your family; you’re a member of the golf club
(p. 30)
A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.
(p. 30)
Chapter 5: Planning Feature by Feature
Vision is about big ideas, not tiny bites.
(p. 32)
General Eisenhower said, “Plans are useless, but planning is indispensable.”
(p. 33)
We do need to plan. We don’t need a detailed list of what will happen and when
(p. 33)
[…] software people are terrible at estimating, because humans are terrible at estimating.
(p. 34)
set a time and money budget; produce the most valuable features first; keep the product ready to ship at any time
(p. 34)
It’s not good enough to plan just at the beginning
(p. 36)
I don’t recommend working with larger stories and breaking them down into technical items, often called tasks
(p. 36)
Stick with stories
(p. 36)
[…] break down stories into smaller stories, each making sense to the business-side people.
(p. 36)
the team itself should decide how much work it can accomplish in the next two-week interval
(p. 37)
The point isn’t to make good estimates—the point is to do good work at a consistent pace.
(p. 37)
There are some serious risks to estimates: we have an almost irresistible desire to “improve” them, or to compare them. […] business and management get the best results by selecting the work to be done and the work to be deferred
(p. 38)
Is prediction better than steering?
(p. 38)
Planning with “stretch goals” is destructive.
[…]
Hurrying, they’ll inject more defects. Since defects take longer to fix than they do to prevent, hurrying will slow you down. […]
[…]
Dirty code slows you down as well […]
Pressure is destructive. Avoid it.
(p. 39)
[…] estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value.
(p. 40)
Chapter 6: Building the Product, Feature by Feature
We need to sharpen our vision of what the product must do—and what’s just “nice to have.”
(p. 45)
To be sure we’re free of defects, we need to check everything, all the time […]
(p. 48)
[…] grow the design as we go. If we design too much, we won’t get as many features, and that will show up. If we design too little, features will be hard to do, we’ll slow down
(p. 49)
Chapter 7: Build Features and Foundation in Parallel
Each feature needs a solid foundation of design, a solid “infrastructure.”
(p.52)
We need to do as little work as possible to deliver the best possible product by our delivery date…and we need to do that work as soundly as we can afford.
(p. 53)
Developers are often trained to try to design a system up front
(p. 59)
Chapter 8: Bug-Free and Well Designed
Our product is made up of a growing set of correctly working features, built on a growing, evolving foundation of design.
(p. 61)
Defects amount to negative features. Progress is uncertain. Eliminate defects to provide clarity on what’s done.
We’re trying to plan by features, grow by features, and manage by features
We cannot work effectively in a world of defects.
(p. 62)
At the end of every iteration, we need to have the software as close to defect-free as possible. The only way to get there is to test it.
We test at two levels, with “Business” tests and “Programmer” tests.
(p. 65)
If we don’t check something, we don’t know whether it works
(p. 66)
We need to have a good design at all times. A bad design slows us down, because it is hard to change […] We need a high-quality design at every moment.
(p. 71)
Chapter 9: Full Circle
Value is what we want. Features deliver value. Delivering features early gives us value sooner.
Managing by looking at value works better than managing by dates or artifacts that don’t deliver value.
Planning features is easy enough to do. Estimate if you must. Selecting the work based on Yesterday’s Weather works better.
Building by features requires us to build a small, complete product, every couple of weeks. That product must always work correctly, and it must always be well designed.
Development must deliver real working features. The product must be well tested. Business-side people and developers contribute to testing. The product must be well designed. Developers keep the design alive all the time.
[…] A commitment from the top of the business, down to the individual managers and developers […]
(p. 77)