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

The truth about the '7 truths about Agile and Scrum that people don't want to hear' that people don't want to hear :)

I was reading through the intro and first two parts of Kai Gilb's seven part series entitled "7 truths about Agile and Scrum that people don't want to hear" and I had a strange sensation of yes-but-no.

The yes feeling comes from the very general underlying theme of the articles.  I'm a big proponent of having specific, measurable features to deliver in a software product and I agree that it is important to ensure stakeholders are getting a good value for the cost.  Further, I believe strongly in developer creativity and that software development is in general a creative social process.

So in general I agree with all the stuff that Kai seems to be saying is important and that we should be doing.  So where did my but-no feeling come from?  It's the blaming of agile for these shortcomings.

Before going on, I'll state some of my opinions about agile and scrum.  I see agile as a general philosophy or a mindset for developing software .  The agile manifesto (also referenced by Kai) lays this  out using four values and twelve principles, but at the end of the day its about programming in code to create a deliverables.  As for Scrum, I believe it is merely a framework that gives a team the ability to adhere to agile values and principles, but again, Scrum is about actually programming within a controlled context to create a given product or feature set.

I guess the key here is that neither agile nor scrum addresses much if anything about gathering or defining requirements, only what to do once the requirements are obtained.  Perhaps this is Kai's point, but is this a truth people don't want to hear?  I don't think so.  It's true that requirements gathering and definition is still important, just as much now as they always have been, but I believe agile doesn't address these issues because it was not intended to.

This assertion to me would be akin to claiming that agile and scrum don't ensure developers write clean code, use best practices, or have appropriate architectures.  Well of course they don't!  The principle "Continuous attention to technical excellence and good design enhances agility." doesn't explicitly define clean code or writing tests first or any other best practice, nor should it.  

By the same token, the princple "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." doesn't explicitly define valuable or how to determine value and, again, it shouldn't.  Please do not misunderstand that I don't think this is important.

I do agree with Kai's claim that use-cases are not the same as specific functional requirements, but again I would say they were never meant to be.  I do like the small examples of what I assume is the Gilbs' Planguage tool to define requirements, but that would be an example of a tool used for the job it was intended, not a shortcoming of agile or Scrum.

After reading and thinking about Kai's articles, I felt like I was missing something; like I didn't get the title or many of the claims (maybe I am as I've only read 2/7 of the series, but at this point that's all there is).  Was it just intended to be a blog to attract attention?  I wasn't sure because to me Kai was stating a lot of the obvious.  Perhaps a better title would be "Dont forget to gather and define the requirements for your software project before implementing it with scrum"? (probably too long)