Alexandre Lim

If you've been working in the software industry, you probably heard about Agile. The word Agile is now used a lot. Few people know its true origin and how Agile only partially fulfilled its initial promise. With this little book, it's time to return to the basics. You don't need to agree with everything, but it's worth listening to Robert C. Martin. He probably has one of the best overviews of Agile since its introduction.

Notes

Agile is a small idea about the small problem of small programming teams doing small things.

Iron Cross of project management: Good, fast, cheap, done. Pick any three you like. You can’t have the fourth. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. They manage the coefficients on these attributes rather than demanding that all those coefficients are 100%.

Agile is a framework that helps developers and managers execute this kind of pragmatic project management.

Agile provides data. The kind of data managers needs to make good decisions.

Agile development is, first and foremost, a feedback-driven approach.

The world of the software development team is a world in which dates are frozen, and requirements are continuously changing.

Waterfall was not an absolute disaster. It did not crush every software project into rubble. But it was, and remains, a disastrous way to run a software project.

The size of an iteration is typically one or two weeks.

The process of writing stories, estimating them, planning them, and designing never stops. In an Agile project, we are always analyzing and designing.

There is simply no way to know how complicated a task is going to be until that task is engaged and finished.

We practice Agile to destroy hope before that hope can kill the project.

Agile was never been about going fast. Agile is about knowing, as early as possible, just how screwed we are so that we can manage the situation.

The best possible outcome is not often the originally desired outcome.

Brooks’ law state: 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 evaluate the schedule continuously. Features are implemented in the order of business value. Quality is kept as high as possible. The schedule is primarily managed by manipulating the scope. That’s Agile.

XP is the prototype, and the best representative, of the essential core of Agile.

Systems should be technically deployable at the end of every iteration.

Customers and managers don’t expect software teams to slow down with time. Agile practices of Testing, Pairing, Refactoring, and Simple Design are technical keys to avoiding that.

Our jobs depend on our ability to accept and engineer changing requirements and to make those changes relatively inexpensive.

Continuous steady improvement is what users, customers, and managers expect.

Why don’t most software systems improve with time? Fear. More specifically, fear of change.

Customers, users, and managers expect fearless competence. They expect that if you see something wrong or dirty, you will fix and clean it. They don’t expect you to allow problems to fester and grow.

You are responsible for ensuring that one or more of your teammates can cover for you.

Provide estimates based on what you do and don’t know.

Acceptance implies responsibility.

A technical leader might ask a developer to take a task but has no right to force a task on anyone.

Agile is not a process. Agile is not a fad. Agile is not merely a set of rules. Rather, Agile is a set of rights, expectations, and disciplines of the kind that form the basis of an ethical profession.

The temporary lack of details makes a story manageable, schedulable, and estimable. Stories must start out cheap because many of them will be modified, split, merged, or even discarded.

There is a beautiful thing about vague and fuzzy numbers. It’s called the Law of Large Numbers.

It’s important to realize that velocity is not a commitment. The team is not making a promise to get 30 points done during the iteration. This is nothing more than their best guess regarding how many points will be completed by the end of the iteration.

The purpose of an iteration is to generate data for managers. There’s no such thing as a failed iteration because we didn’t complete all stories.

The best predictor of the progress of an iteration is the previous iteration.

The project is not over when all the stories are implemented. It’s over when there are no more stories in the deck worth implementing.

Stories follow a simple set of guidelines:

A spike is a meta-story, or rather, a story for estimating a story.

It is far better to let programmers negotiate amongst themselves for stories assignment.

The definition of “done” is this: acceptance tests pass.

Velocity is a measurement, not an objective. Don’t put pressure on the thing you are measuring.

The term “release” means that the software is technically ready to be deployed.

Requirements should be specified by the business.

Behavior-Driven Development's (BDD) goal was to remove the techie jargon from the tests and make the tests appear more like specifications that business people would appreciate.

A story is not specified until its acceptance test is written. A story is not complete until its acceptance test passes.

A software project is a marathon, not a sprint, nor a sequence of sprints. You must run at a Sustainable Pace.

Working overtime is not a way to show your dedication to your employer.

No one owns the code in an Agile project. The team as a whole owns the code.

The continuous build should never break.

Without TDD, Refactoring, Simple Design, and Pair Programming, Agile becomes an ineffective flaccid shell of what it was intended to be.

In TDD, every required behavior is entered twice: once as a test and then again as a production code that makes the test pass.

The tests are the perfect kind of documentation for programmers: code.

Test coverage is a team metric, not a management metric. Managers should not use this metric as a goal or a target. The team should use it solely to inform their testing strategy.

Do not fail the build based on insufficient coverage.

We practice TDD because it gives us the courage to keep the code clean and orderly. It gives us the courage to act like professionals.

Refactoring is the practice of improving the structure of the code without altering the behavior, as defined by the tests.

Writing code that works and writing code that is clean are two separate dimensions of programming.

Simple design is the practice of writing only the code that is required with a structure that keeps it simplest, smallest, and most expressive.

Kent Beck’s rules of Simple Design

Pairing is optional and intermittent. No one should be forced to pair.

Pairs are not scheduled. They form and break up according to the programmers’ preference.

Pairing is the best way to share knowledge between team members and prevent knowledge silos from forming. It is the best way to ensure that nobody on the team is indispensable.

Never, ever, ever, ask for permission to pair, test, refactor, or… You are the expert. You decide.

Adopt the full Circle of Life, especially the technical practices.

The transition from non-Agile to Agile is a transition in values.

The tops and bottoms of the organization value the Agile mindset, but the middle layer opposes it.

Does an Agile team need a coach? The short answer is “No.” The longer answer is “Sometimes.” Agile coaches are team members who defend the process within the team. This role rotates between team members based on need. The coach is not a manager. Its role is strictly internal to the team. A mature team may not require a coach. Neither the managers nor the customers know who the coach is, nor even whether there currently is a coach.

The Agile certifications that exist are a complete joke and an utter absurdity. Do not take the certifications seriously. It is foolish to train just one special person. Every member of an Agile team needs to understand the values and techniques of Agile.

Agile is for small to medium-sized teams, period. It works well for such teams. Agile was never intended for large teams.

Software is really like nothing else. So, to organize a small team of software developers, we need a special set of disciplines that are tuned to the unique aspects of software.

Agile is about software. It is about small software teams. There is no such thing as Agile in the large.

Workers use and control tools; tools don’t control and use people.

Some companies are still not mature enough to understand that technical problems are business problems.

An ideology is a system of ideas and ideals. A methodology is a system of methods and practices. An ideology defines ideals to be aimed at. One or more methodologies can be used to reach those ideals—they are a means to an end.

Craftsmanship promotes software development as a profession. 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, however, is part of who we are.