Monday, March 29, 2010

A Simple Algorithm for Agile Adoption

Here is my simple algorithm for anyone attempting an agile adoption:
1. Stop doing what doesn't make sense.
2. Start doing what does.
(Of course I believe you can't do either effectively with out continuous learning and reflection!)

Below is a diagram I've used to explain some of the many different terms generally flung around under the umbrella of "Agile" to help folks just getting started.

About the diagram...
[DISCLAIMER] I know most of the methodologies do not necessarily build off Scrum "officially" and, in most cases, were developed on their own, but Scrum seems to have distilled down the basic incremental, iterative, reflective processes they all have in common, leaving various details out (intentionally) so teams could adapt the processes to their situation.  I believe XP, Crystal, and most other methodologies add that detail (although many could argue that Crystal is also a framework).

As for Kanban, I'm more than willing to take and make corrections on this as at the time of this writing my knowledge of Kanban is very weak.  I believe it can stand on its own, but I've also heard of Scrumban, so it seems it can also be used as yet another implementation of the Scrum framework?  Wouldn't mind some education here :)

Consider this (please!)...
It is important to understand the problems Lean, Agile, and all the various methodologies were intended to address before going off and attempting to implement a solution.  It is important to educate from the bottom up.  I've seen and heard of more problems or failed "agile implementations" because the powers-that-be knew something wasn't right but just wanted to adopt or buy into a methodology or process that would fix it. 

Also, most things must actually be tried first, before claiming "they wont work here"...they might not, but you wont know how to tweak them to get them to fit if you just stand around talking about what wont work.  Generally more information is gleaned from action than inaction, theory, and speculation.

How agile are we now?
In the diagram, I make reference to using the 4 values in the Agile manifesto as a sliding scale.  I first read this idea somewhere out in the blogosphere, but cant remember where; but I'd like to think that it's a great place to start when considering how agile anything is; from an idea or process to a project or organization. Here is what that sliding scale looks like to my mind's eye:

Now you can use this to evaluate all kinds of things.  You can ask yourself questions like:
  • Is this process focused more on individuals and interactions or on processes and tools?
  • Does this organization more value working software or comprehensive documentation?
  • Does my project rely more on customer collaboration or on contract negotiation?
  • Will my idea help more with responding to change or does it simply follow a plan?

Remember, the manifesto doesn't say the stuff on the right is bad or unneeded, it just says that things which are more agile tend more towards the things on the left.

Hope this may be useful to someone out there.  It helped me just to write it up :)  I would certainly appreciate any thoughts of feedback about the diagrams or opinions in this article (especially with regard to Kanban!)


  1. After having met Alistair Cockburn in November, I blogged about his explanation of the eight values in the Agile manifesto viewed as dials here:

    I'm not sure if you picked it up from my write-up, but the idea with the sliders is neat. I don't have made my mind up whether the values are dependent on one another, which would support the slider view, or if they are independent from each other, which would support Cockburn's dialer view. The concept is the same, though.

  2. Agile is something to be sought after and must implement kind of.. in every project irrespective of its requirements.

    Working Software is always on the first hand but there should be enough documentation to maintain it.

    Processes and tools play an important role as much as people/developers. I believe that Processes and tools streamline the development across projects and couldn't be seen from one project end.

    Following a plan and Responding to changes share an equal value in a project.

    Finally I conclude that Agile is more of its principles plus with a mix of traditional software methodologies.