More on this book
Community
Kindle Notes & Highlights
This physics constrains all projects to obey an unassailable trade-off called the Iron Cross of project management. Good, fast, cheap, done: Pick any three you like. You can’t have the fourth.
The reality is that a good project manager understands that these four attributes have coefficients. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. A good manager manages the coefficients on these attributes rather than demanding that all those coefficients are 100%. It is this kind of management that Agile strives to enable.
It is a critical goal of Agile to get those two charts on the wall. One of the driving motivations for Agile software development is to provide the data that managers need to decide how to set the coefficients on the Iron Cross and drive the project to the best possible outcome.
Agile development is first and foremost a feedback-driven approach. Each week, each day, each hour, and even each minute is driven by looking at the results of the previous week, day, hour, and minute, and then making the appropriate adjustments. This applies to individual programmers, and it also applies to the management of the entire team. Without data, the project cannot be managed.19
Make sure the managers know how fast the team is moving and how much the team has left to accomplish.
This is the world of the software development team. It’s a world in which dates are frozen and requirements are continuously changing.
Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.
software is not a reliably estimable process. We programmers simply do not know how long things will take. This isn’t because we are incompetent or lazy; it’s because there is simply no way to know how complicated a task is going to be until that task is engaged and finished.
This loss of hope is a major goal of Agile. We practice Agile in order to destroy hope before that hope can kill the project.
Some folks think that Agile is about going fast. It’s not. It’s never been about going fast. Agile is about knowing, as early as possible, just how screwed we are.
Brooks’ law22 states: Adding manpower to a late project makes it later.
The only way to go fast, is to go well.
any rational organization, the data will win.
Agile is a process wherein a project is subdivided into iterations. The output of each iteration is measured and used to continuously evaluate the schedule. Features are implemented in the order of business value so that the most valuable things are implemented first. Quality is kept as high as possible. The schedule is primarily managed by manipulating scope.
that code is not kept clean and orderly, it will put a back pressure on the team that slows progress. The bigger the mess, the higher the back pressure, and the slower the team. The slower the team, the greater the schedule pressure, and the greater the incentive to make an even bigger mess. That positive-feedback loop can drive a team to near immobility.
a change to the requirements breaks your architecture, then your architecture sucks.
QA should find no faults with the system. When QA runs their tests, they should come back saying that everything works as required. Any time QA finds a problem, the development team should find out what went wrong in their process and fix it so that next time QA will find nothing.
manual tests are expensive and so are always a target for reduction.
The whole point of software is to be able to easily change the behavior of our machines.
the business has no right to force developers to ruin their professional reputations or violate their professional ethics.
Estimates are never commitments.
Programming on a team involves working closely together with juniors and seniors. The team has the right to collaboratively decide who will do what. A technical leader might ask a developer to take a task but has no right to force a task on anyone.
Programing in a team
Agile is a set of rights, expectations, and disciplines of the kind that form the basis of an ethical profession.
An estimate is a guess; we want some idea of how long the project will take without actually building the project. We want the cost of estimation to be low. Therefore an estimate is, by definition, imprecise.
Iteration Planning Meeting (IPM). This meeting should be scheduled to be one-twentieth the duration of the iteration. The IPM for a two-week iteration should require about a half a day.
The purpose of an iteration is to generate data for managers.
The goal of each iteration is to produce data by getting stories done.
Rising Velocity If we see a positive slope, it likely does not mean that the team is actually going faster. Rather, it probably means that the project manager is putting pressure on the team to go faster. As that pressure builds, the team will unconsciously shift the value of their estimates to make it appear that they are going faster.
that velocity is a measurement not an objective. It’s control theory 101: don’t put pressure on the thing you are measuring.
the only failing iteration is an iteration that fails to produce data.
The term “release” means that the software is technically ready to be deployed. The decision to deploy becomes solely a business decision.
QA folks are hired for their ability to figure out how to break the system.
There’s a saying among older programmers: “I can meet any deadline you set for me, as long as the software doesn’t have to work properly.”
software project is a marathon, not a sprint, nor a sequence of sprints.
Working overtime is not a way to show your dedication to your employer. What it shows is that you are a bad planner, that you agree to deadlines to which you shouldn’t agree, that you make promises you shouldn’t make, that you are a manipulable laborer and not a professional.
The team owns the code collectively.
Every required behavior is entered twice: once as a test, and then again as production code that makes the test pass. The two entries are complementary, just as assets are complementary to liabilities and equities. When executed together, the two entries produce a zero result: Zero tests failed.
The only information that the passing tests give you is that nothing tested is broken.
We want to create a suite of automated tests that tells us that it is safe to deploy the system.
How do you keep functions easy to test? You decouple them. Indeed, testability is just a synonym for decoupling.
Over the course of a week, each programmer will spend about half of their pairing time on their own tasks, recruiting the help of several others. The other half of their pairing time will be spent helping others with their tasks.
We pair so that we behave like a team. The members of a team do not work in isolation from each other. Instead, they collaborate on a second-by-second basis. When a member of a team goes down, the other team members cover the hole left by that member and keep making progress towards the goal.
Pairing is the best way, by far, to share knowledge between team members and prevent knowledge silos from forming. It is the best way to make sure that nobody on the team is indispensable.
Finally, never, ever, ever, ask for permission to pair. Or test. Or refactor. Or… You are the expert. You decide.
It is reckless to conform to a schedule by sacrificing quality.
The belief that quality and discipline increase speed is a courageous belief because it will constantly be challenged by powerful but naive folks who are in a hurry.
You can learn most of what you need in minutes. The rest is available online.
Workers use and control tools; tools don’t control and use people.
Agile as an algorithm for finding the highest-value-producing features in the market and then turning them into revenue faster.
Good collaboration removes some of the blocks people have to do their jobs but does not necessarily make them more skilled.
