LinkedIn is fun. Every now and then a person from the past pops in. A colleague from my early days at Teradyne had just heard about agile and she asked me what it was and how to learn more. Here’s what I told her.

I started with Extreme Programming Explained in 1999. A lot has happened since then.

Basically, Agile is about iteratively developing software in a collaborative way.

You can start with the Agile Manifesto for the original statement and some of the underlying principles.

The goals of agile are:

• to show measurable and visible progress against a plan (that evolves).
• to deliver high quality software based on business priorities.
• to allow the business the flexibility to change priorities based on the needs of the business and market.

There are a half a dozen, or so, flavors of agile. The most popular are Scrum and Extreme Programming (XP). I teach and coach a pragmatic mixture of those.

Scrum is enjoying a lot of adoption right now, but it covers only part of the story. Scrum describes how a self managed team should self manage itself, relying mainly on a few practices around iterative planning and delivery. Scrum provides no advice for how the team should get the technical job done. There are essentially no engineering practices in Scrum.

To learn about Scrum look here

• Agile Software Development With Scrum – Ken Schwaber, Mike Beedle

To dig a little deeper look here

• Agile Estimation: Mike Cohn
• User Stories: Mike Cohn

There are plenty of resources on the web too.

Extreme programming on the other hand is rich in technical practices. One of the cornerstones is Test Driven Development (TDD). Tests and the code to satisfy them are written nearly concurrently in a tight feedback loop, with the test leading the way. It is a very productive technique that eliminates a lot of debugging and quickly reveals side effect defects. This blog describes a logic chain of where the benefits come from in TDD.

For technical practices and advice

• Kent Beck, XP explained, Test Driven development
• Agile Software Development, Patterns, Principles… Bob Martin.

I happened to have a paper with the XP practices ready for cut and paste, so here they are:

Customer Team Member – Teams have someone (or a group of people) representing the interests of the customer. The customer decides what is in the product and what is not. The customer is responsible for acceptance testing the product. This means the customer team will likely have skilled QA people.

User Story – A User Story represents a feature of the system. Stories are small. Small enough to be completed within a single iteration by a single person. If the story is too big to complete in an iteration, split it into smaller stories. A story is like the name of a use case. A story should be customer visible, and have customer value.

Planning Game – In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimate the effort to complete each story. Customers select stories and package them into iterations that do not exceed the team’s capacity. Stories are ordered by the customer according to their value and cost. Scrum provides specific advice somewhat different and more robust from the planning approach in XP.

Small Releases – The system is built in small releases. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Acceptance Testing – Acceptance tests demonstrate that a story is complete. They provide the details behind a story and are defined before a story is started. Customers own the acceptance tests. The bulk of the tests must be automated so they can be run at any time, usually multiple times per day.

Open Workspace – To facilitate communications the team works in an open workspace with easy access to other team members, equipment, and project status information.

Test Driven Development – Programmers write software in very small verifiable steps. First, a small test is written, followed by just enough code to satisfy the test. Then another test is written, and so on.

Metaphor – The system metaphor provides an idea or a model for the system. It is part of the high level design, facilitating communications. It provides a context for naming modules, classes, data, and functions in the software.

Refactoring – Refactoring is the process of keeping the design clean, incrementally. When systems evolve, the design will get messy. The idea of refactoring is to detect, identify and fix design problems are they come up, while they are small and easy to fix. Refactoring is built on the realistic assumption that software design is never done. Systems will evolve and refactoring skills are needed to keep the design clean. Automated unit tests make refactoring safe, because refactoring mistakes are revealed immediately by test failures.

Simple Design – The design is kept as simple as possible for the current set of implemented stories. Frameworks and infrastructure evolve with the code through refactoring.

Pair Programming – Two programmers collaborate to solve one problem. Programming is not a spectator sport. Both programmers are engaged in the solution of the problem at hand. Pairs switch often to spread the knowledge, maybe a couple times a day.

Coding Standards – The code must have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style. Team members agree to follow a standard. The goal is that the code looks like it was written by the same person.

Continuous Integration – Programmers integrate and test software many times a day. Big code branches and merges are avoided. Last programmer to merge looses, and has to merge.

Collective Ownership – The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes. The knowledge of the system spreads throughout the team and is not stored in knowledge silos.

Sustainable Pace – The team needs to stay fresh to effectively produce software. Too much overtime will result in reduced quality, burn out and unpredictable outcomes. Tired people make mistakes and mistakes cost time. Everyone works hard but works within what is possible. Agile teams do press hard for deadlines but do not make a steady diet of overtime.