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 is the world of the software development team. It’s a world in which dates are frozen and requirements are continuously changing.
For now, what do you think the odds are that the team will finish all the stories that they planned to finish? Pretty much zero, of course. That’s because 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.
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.
The day will come, if it hasn’t already by the time you read this, when some poor programmer is going to do some dumb thing and kill ten thousand people in a single moment of carelessness. Think about that for a minute. It’s not hard to imagine half a dozen scenarios. And when that happens, the politicians of the world will rise up in righteous indignation (as they should) and point their fingers squarely at us.
Management might try this a few more times because repeating the same thing and expecting different results is the definition of management sanity in some organizations.
We developers should celebrate change because that’s why we are here. Changing requirements is the name of the whole game. Those changes are the justification for our careers and our salaries. Our jobs depend on our ability to accept and engineer changing requirements and to make those changes relatively inexpensive.
Asking humans to do what machines can do is expensive, inefficient, and immoral.
Developers have the right to produce high-quality work at all times. This may be the most profound of all these rights. Developers have the right to do good work. The business has no right to tell developers to cut corners or do low-quality work. Or, to say this differently, the business has no right to force developers to ruin their professional reputations or violate their professional ethics.
When the acceptance tests for a story pass, that story is done. However, when a programmer says that a story is 90% done, we really don’t know how close to done it is. So, the only thing we ever want to report on our velocity chart is stories that have passed their acceptance tests.
When the Whole Team sits together in the same space, magic can happen.
That was the moment that I learned that a software project is a marathon, not a sprint, nor a sequence of sprints. In order to win, you must pace yourself. If you leap out of the blocks and run at full speed, you’ll run out of energy long before you cross the finish line. Thus, you must run at a pace that you can sustain over the long haul. You must run at a Sustainable Pace.
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.
Despite how essential programming has become to our society, we have not yet imbued TDD with the force of law. But given that lives and fortunes have already been lost to the vagaries of poorly written software, can that law be far away?
Workers use and control tools; tools don’t control and use people.
A truism of all change initiatives is that people do what they want to do. The key to lasting change is to find problems or opportunities that people are aware of and have a desire to invest in and then help them achieve their goals, offering expertise only as requested and needed. Everything else will fail.
Releasing software to production every two weeks requires a lot of discipline and technical skills—skills that are not commonly found in teams used to delivering software a few times per year.
The obsessive focus on a methodology or set of practices distracts teams and organizations from their real goals. The goal is to teach a child to ride a bicycle, not to adopt the training wheels.
Good practices are good until we discover better ones to replace them.
There is a difference between having a job and having a profession. A job is a thing we do but it is not part of who we are. A profession, on the other hand, is part of who we are. When asked, “What do you do?”, a person with a job would normally say something like “I work for company X,” or “I work as a software developer.” But a person with a profession would generally say, “I am a software developer.” A profession is something we invest in. It’s something we want to get better at. We want to gain more skills and have a long-lasting and fulfilling career.
