Agile methods in plain terms

Where it came from

Projects used to run like this: six months writing a detailed specification, a year building, then showing the client. By then the requirements had gone stale, and correcting course was late and expensive.

The agile approach proposed the opposite: build in small pieces, show results often, and change plans along the way, because nobody knows everything at the start.

It isn't a method but a mindset. Several concrete methods are built on it.

The core idea in four points

The original statement ran:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The caveat that gets forgotten constantly: the items on the right still matter. Documentation is needed, a plan is needed, a contract is needed. This is about priority, not abolition.

That forgotten caveat has produced any number of teams who "work agile" and possess neither plans nor documentation nor an understanding of what they're building.

The most common method

Work runs in fixed-length periods, usually one or two weeks. At the start the team takes on an amount it considers achievable. At the end it demonstrates the result and reviews how it went.

Roles: someone accountable for priorities and content; someone who helps the team work and removes obstacles; the team that builds.

Meetings: planning at the start, short daily check-ins, a demonstration and a review at the end.

The second common approach

No fixed periods. There's a board with columns, tasks move across it, and the main rule is a limit on how many tasks are in progress at once.

The point of the limit: when everyone has taken three things, everything sits half-finished. When everyone takes one and finishes it, work moves faster, although it feels slower.

It suits places where the flow of work is unpredictable: support, operations, small fixes.

What interviews ask

Beginners get shallow questions:

• What's the difference between the two approaches? Answer: the first has fixed periods and planning for them, the second has a continuous flow with a limit on work in progress.
• What happens at a review? Answer: the team discusses what to improve and agrees changes.
• Why a daily check-in? Answer: so the team sees the picture and notices obstacles early. Not for reporting.

Answer briefly and to the point. Reciting theory doesn't impress.

Honestly about reality

At most companies what runs isn't the textbook method but a local variant. Somewhere the periods exist but the review doesn't. Somewhere the board exists but the limits aren't observed.

That's normal. Don't try to fix the process in your first job — first understand why it's like that. There's often a reason behind the oddity.

Trying a method on your own team project is worthwhile, though: two weeks, a limited scope, a review at the end. One cycle of your own teaches more than ten articles.