In 2001, several of the great names in software development got together and came up with the Agile Manifesto, which became the basis for a revolution in software development, the influence of which is still felt today.

The Agile Samurai by Jonathan Rasmusson, published by the wonderful Pragmatic Bookshelf, is a light-hearted look at Agile practices, in a practical context. At the time of writing (2017), the book is seven years old, which is a lifetime in software terms, yet it remains relevant.

As with anything worthwhile that looks likely to become popular, the commercial / enterprise software behemoths jumped on the bandwagon and tried to make Agile their own. This has been a cause of some distress for the early pioneers. One doesn’t do Agile. One might behave according to Agile principles, one might do Scrum or Kanban, but one doesn’t do Agile.

This page is a distillation of some of my main takeaways from the book. I hope it will provide a useful reference for fellow readers, and I hope that those of you want to get into Agile, will buy it.

Throughout, Agile principles will appear like this.

Agile has many flavours - I have attempted to stick to Scrum terminology.

Part 1 - Introducing Agile

Chapter 1 - Agile in a Nutshell

What would it take to deliver something of value each and every week?

Deliver something of value every week

Put yourself in the customer’s shoes. What would give you confidence that the development team was delivering? Documents and notes? Or working software?

When doing this, good things happen. You:

  1. Break big problems down into smaller ones (make things manageable).
  2. Focus on the really important stuff and forget everything else (get lean).
  3. Make sure that what you’re delivering works (testing).
  4. Go looking for feedback (stay on the right path).
  5. Change course when necessary (roll with the changes).
  6. Become accountable (made the commitment, own it).

Our highest priority is to satisfy the customer through early and continuous delivery of working software.

How does Agile planning work?

There is no point being unrealistic. “Management by miracle” is doomed from the start. Working transparently with the customer is preferable.

Done means done

Done means doing everything necessary to produce shippable code. This includes:

If it can’t be shipped, it’s not done.

Working software is the primary measure of success.

Three simple truths

  1. It is impossible to gather all the requirements at the beginning of the project.
  2. Whatever requirements are gathered are guaranteed to change.
  3. There will always be more to do than time and money will allow.

This means we don’t:

  1. Wait for everything to be defined, before moving forward.
  2. Worry about change, it’s inevitable.
  3. Stress about having too much to do, it’s the normal state.

Chapter 2 - Meet Your Agile Team

No pre-defined roles, anyone can do anything. Yet high-performing Agile teams produce quality software.

How are agile projects different?

  1. Roles blur, like working in a mini-startup, yet people have core competencies.
  2. Analysis, coding, design, and testing are continuous, not isolated. People need to be joined at the hip, daily.
  3. Quality is a team responsibility.

What makes an Agile team tick?

Engaged customers

Core team members, full-on partners, who will:

Business people and developers must work together daily throughout the project.

If customer is not engaged, build trust.


How to do this?

The best architectures, requirements, and designs emerge from self-organizing teams.

Accountability and empowerment

A good team wants to be agile. They know customers count on them and relish the responsibility.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

If there’s an issue with accountability, ask the team to demo the software. The team will see that real people count on them to deliver. A bad demo can raise the interest level in making sure that everything works.


Serve the customer end-to-end. Have the expertise to take any feature and deliver it fully.

Recruit generalists who are comfortable walking the full stack. No need to wait for permission or negotiate for resources.

Roles we typically see

There is little formality with Agile.

The Agile Customer
The development team

Cross-functional group who can take any development requirement and turn it into production-ready, working software. Taking a traditional team and telling them to self-organize is unlikely to work well. Need to present Agile in understood terms:

The Agile analyst:

The Agile programmer:

The Agile tester:

The Agile project manager:

The Agile UX designer:

Other roles in the development team are treated just like anyone else on the project. It’s natural and expected that people will wear multiple hats.

Tips for forming your Agile team

Part 2 - Agile Project Inception

FIXME: Come back to this, it's relatively rare compared to planning.

Part 3 - Agile Project Planning