At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Here is one of the most powerful Agile principles, and what I think is one of the least utilized.  And, this really strikes to the heart of what it means to be agile … do what works.  Let me explain.

There are quite a few really good Agile methodologies like Scrum, Kanban, FDD, XP, Crystal, and others.  Each of these methodologies have been used successfully and refined over time to make them the perfect fit for a project that their authors worked on.  But, that doesn’t mean they are a good fit for YOUR project.  It does mean that picking one of these methodologies give you a good starting point that you can then deviate from to meet your project’s specific needs.

I am reminded of the concept of Shuhari.  When you first start a project using Agile it is best that you simply follow the rules of an established Agile method.  Let’s say you pick Scrum.  Great.  Grab yourself a copy of Ken Schwaber’s book on the methodology and try to follow it exactly for the first sprint.  This is the “Shu” phase … follow the rule.  When you first start you should just use the best practices established by others to get you moving.  Stand on the shoulders of giants and enjoy trying to figure out what they meant when they wrote Scrum.

But, once you get started you will notice friction.  This is normal and it happens on every project.  Scrum and Kanban are amazing and very well though out but there is no one-size-fits-all solution to project management, team motivation, and world peace.  I think this is why Scrum is more popular these days than FDD, Crystal, or eXtreme Programming.  Scrum is much less prescriptive on your daily activities so if is a little less disruptive when you first roll it out.  But, Scrum has a practice called the Sprint Retrospective that, as an Agile coach or ScrumMaster, you should focus on. In the retrospective, you gather the team after a sprint and ask them what went well during the sprint and what could have worked better.  I like to get the team to pick one thing that they could do differently in the next sprint that they think would make their jobs a little easier, then we try it in the next sprint.  Making this only one thing at a time stops the team from accidentally throwing out Scrum and it helps them to empirically identify if that change was actually helpful or not.  This is the “Ha” phase of Shuhari … break the rule.  Now that they team has some time under their belt using Agile, they start to experiment with how to adapt the process to their project’s specific needs.

The sprint retrospective is one of the practices that I most often see teams skipping or just glossing over, but it is arguable the most important.  Without this step your team will never progress from “trying to do Scrum” into a truly agile team that adapts to the business situation with grace.  The secret of Agile is do what works so, you need to have a retrospective practice in order to find out what works for you.