Book Review: The Agile Samurai

I'm continuing to burn through my reading list this year.  I recently finished reading The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson (Amazon link).

Rasmusson provides a very good introduction to the Agile process and how to implement it in your projects. The approach is friendly and conversational -- which ends up underlining the point that much of Agile is about communication.  The book itself is filled with diagrams that reinforce the points at hand and each section ends with a conversation with the Master Sensei to review points and answer questions that the "aspiring warrior" may have.

Ultimately, this leads to a set of reinforced principles that describe how to be successful with Agile.

The Parts
The book is broken down into sections that provide a logical procession through a typical project.

Part 1 - Introducing Agile
The first two chapters give an overview of what Agile is and some of the primary principles.  One example is "Done means done".  There is no 80% complete.  A feature is either done or it is not -- this includes everything through acceptance testing.  A feature is not done until it is ready to be deployed.

Another key feature of Agile is the self-organizing team.  Chapter 2 talks about the different members of the team, how each of them are vital to the project success, and how people fall into these roles naturally or by choice.

Ultimately, everything is the responsibility of the Team.  So, if you see something that needs to be done, go ahead and do it (with proper communication, of course).

Part 2 - Agile Project Inception
The next three chapters talk about how to get an Agile project started.  This starts with getting everyone on board with the process.  The next thing is to make sure that everyone is on the same page with the proposed project.

This book has a very practical approach to starting a project: The Inception Deck.  These are 10 items that need to be completed before the project is actually started.  These items make sure that we (as a Team) know where we are going, where we are not going, and start to determine how we are going to get there.

One of these items is creating the Elevator Pitch.  If you only have 30 seconds to describe your project, how would you do it?  Think about your current project; how would you describe it?  If you struggle with this, it could mean that your project does not have a clear purpose.  It could mean that your project is trying to do too many things at once.  It could mean that you're not quite sure where you are going.

Another item is to create a "Not List".  This is a list of things that the project is not going to do.  This again helps make sure that everyone has the same expectations.  If we say up front that we are not going to try to integrate with the legacy system, then we have that out in the open for everyone to see.  If any of these "not" items are an issue, then we have a discussion to determine whether they should be moved to the list of things we do want in the project.

These are just 2 of the items in the Inception Deck to determine whether the project will give us the benefits that we expect and to make sure we're all headed in the same direction.

Part 3 - Agile Project Planning
The next three chapters have to do with planning.  We've figured out what our project is all about (with the Inception Deck), now it's time to start planning.

Estimation is always a big part of any planning.  One of the things that makes estimation a bit harder with Agile is that we don't have all of the requirements up-front.  We have a general idea of the pieces that we need, but the specific "this function needs to do this, this, and this" comes later.  So where do we start?

We start by creating User Stories.  These are the functions that we want in our project.  It could be things like logging in to the system, things that are a bit bigger like showing an inventory list, or things that are much bigger such as checking out a shopping cart.

The idea is that we take these user stories and assign relative levels of effort.  We don't know exactly how long each item will take, but we do know which items are bigger or smaller than other items.  We take this information and organize these according to some system.  A point system (1 for small, 3 for medium, 5 for large) will give us an idea of how long (relatively) each feature will take.

At this point, we don't know how long the project will take to complete because we don't know how many "points" our team can handle on a regular basis.  It may seem odd to say "we don't know how long this will take to complete."  But the reality is that even if we give a hard answer in the beginning, things change so much that that original estimate is almost always wrong.

Part 4 - Agile Project Execution
The next three chapters are all about execution.  Now that we have our general plan, how do we execute on it?  An important tenant is to "Deliver something of value every week."  Now this many not always be practical (and it may be that we are delivering value every two or three weeks, depending on our plans).  But the general idea is that we are constantly moving forward with completed features.

This doesn't mean that we necessarily have a useful product.  Usually, we need a critical mass of features before the final product is useful to the end users.  But we are completing the features.

And remember "Done means done".  When we get to the delivery part of the process, we have completed features that are ready to deploy.  We don't have a whole bunch of 90% complete features.  If we find that we aren't actually finishing everything, then we need to stop any new development and go back to finish up the things we have in progress.

Once we start delivering, we find out the velocity of our team -- how many "points" we are able to handle during each of our development cycles.  This will take a couple of cycles to figure out (the first one will be slow, and there will always be things that either speed-up or slow-down the process).

As mentioned earlier, communication is a huge part of Agile.  The customer is part of the Team.  Face-to-face communication should be happening regularly (ideally daily).  But in addition to the people who are part of the team, we need to communicate with the larger group.  The recommendation is to set up regular "showcases" with the larger team -- this is often the user group, stakeholders, project funders, and others.  This gives the project team a chance to show off the regular progress on the project.  When the project is visibly moving forward, people are happy.  This is much better than a team disappearing for 6 months and coming back with the wrong thing.

This showcase accomplishes a couple of things.  First, (as mentioned), it creates a trust in the team.  Forward progress is seen as a good thing.  Second, there is more immediate feedback.  If a feature comes out differently than expected, there is a chance to adjust the feature to better fit the users' needs.  Third, if there is no progress, don't cancel the meeting.  This gives the Team a chance to get up and say "nothing significant was done."  Yes, it's embarrassing.  But it is honest communication, and the Team will not want to go through that again, if possible.

Agile is all about change.  We need to figure out what to do when the users want new features, or one of the items in the low-priority list gets moved to the top of the list.  Again, communication is the key.  If the expectations were set during the project inception, everyone knows what happens next: compromise.  We figure out (as a Team), if we want to do a swap (trade a high-priority feature for a low-priority one) or extend the scope by adding the new feature (this is generally not recommended as it leads to scope-creep and a project that never gets released).

Part 5 - Creating Agile Software
The four chapters of the book talk about processes that help with Agile development.  These include Unit Testing, Refactoring, Test-Driven Development (TDD), and Continuous Integration.  These are all introductions to the topics at hand with recommendations to look into them further.

One thing that I appreciated about these chapters is that Rasmusson emphasized that these techniques may or may not work in your environment.  Take and use what works and leave the rest (but be sure to give them a try to see if they do work).

Wrap Up
The Agile Samurai is a very practical introduction to Agile and techniques that can help you be successful.  Throughout the book are useful examples and specific things that we can do to keep moving forward in a productive way.

The general approach of "do what works for you" is a good one.  The book provides a number of techniques but advises that you determine which are appropriate for your environment.  I would recommend this book to folks who are interested in looking further into Agile techniques and how they can be successful with them.

Happy Coding!