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!)