Agile in a Nutshell

Agile in a Nutshell

The Agile Samurai - Chapter 01: Agile in a Nutshell

From the book: The Agile Samurai: How Agile Masters Deliver Great Software

  • Get a high-level understanding of agile planning

  • How to measure success on an agile project

  • The 3 simple truths of agile to help you face tight deadlines with ease

Deliver something of value every week

This means the regular deliver of working, tested software.

1. Break big problems down into smaller ones

2. Focus on the most import things, forget everything else

3. What you deliver must work

  • Whatever you deliver, it must work -- this means that you start testing - early & often.

  • Daily testing becomes a way of live.

4. Look for feedback, often

  • Regularly stop and ask your custom for feedback.

5. Change course when necessary

  • Something that was really import one week can be unimportant the next.

  • Dont't follow plans blindly.

  • Be prepared to change.

6. Become accountable

Becoming accountable means:

  • Owning quality

  • Owning the schedule

  • Setting expectations

  • Spending money (and time) as if it was your own on the line

Delivering something of value every week is not for the faint of heart, it puts the spotlight on you. You either produce some thing a value or you don't.

Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile Planning

  1. Master story list

  2. Iteration

  3. Team velocity

  4. Adaptive planning

Master story list

This is your project to do list

It contains all of the high-level features (called user stories) that your customer will want to see in their software.

It's prioritized by the customer an estimated by the development team.

It forms the basis of the project plan.


An "iteration" is a 1-2 week period where the team takes the most important stories and transforms them into tested software that works and could potentially be deployable if that is the intention.

Team velocity

Team velocity refers to how much you can get done per iteration.

Buy tracking the velocity you can use it as a predictor of how much you'll be able to get done in the future which helps keep your plans, honest from overcommitting.

Adaptive planning

Adapter planning is a corner stone of agile.

It basically means that the planning of the project is a continuous mission and that you should expect things to change an adapter accordingly.

Done means done

An agile, the definition of done means that you are delivering a feature that has everything necessary to produce shippable deployable code that works.

Everything from analysis, design, coding, testing, usability experience, etc. is all included.

It does not have to be the future with every possible option completed but whatever it is, that you deliver must work.

If it can't be deployed, it's not done.

Agile Principle: Working software is the primary measure of success.

3 Simple Truths

  1. It is impossible to gather all requirements at the beginning of a project

  2. Whatever requirements you do gather are guaranteed to change

  3. There will always be more to do than time and money will allow

Truth #1

  • Requirements are meant to be discovered.

  • If you want to proceed on a project until you've gathered everything that would mean never starting.

Excepting this first truth means, you're not afraid to begin the journey without knowing everything upfront.

Truth #2

  • Winter Change is coming.

  • You expect it and you accept it.

  • When change comes, you adapt your plan and move forward.

Accepting this truth means you no longer fear or avoid change.

Truth #3

  • Having more to do than time and money will allow is a normal state for any interesting project.

  • You do the things that you can and you set priorities to get the most important things done first.

Accepting this truth means you no longer get stressed when your to do list exceed your time and resources to deliver.

There is no "one way"

There are multiple flavors of agile - Scrum, XP, Lean, etc.

No one way is right or wrong.

No method or book can give you everything that you need and you cannot stop thinking for yourself.

You must make it your own.

From the book: The Agile Samurai: How Agile Masters Deliver Great Software