Why is Agile like a light bulb…

Since this is my first entry into this blog about Agile software development in big company corporate America I’m going to start by talking about how you can convince your organization to adopt Agile as its primary SDLC (software development life cycle).  And I’m going to start it by telling you a light bulb joke. Why a light bulb joke?  Because I think that there is a light bulb joke for almost every situation in life, more on that later.

“How many psychiatrists does it take to change a light bulb?… Only one, but the light bulb has to really, really want to change.”

This is the joke I tell everyone the first time I try to teach them Agile.  Agile is not a difficult concept to grasp, nor is it a difficult SDLC to practice… if the people who are going to use it really, really want to change.  And that is the thing that is most often the most difficult point to grasp and the most difficult barrier to overcome.

So why is Agile like a light bulb?   Because people, in general, do not like change, and companies are the people who work there.  They reflect the attitudes, prejudices, preferences and inertia of those people.  So, before you can be successful practitioner of Agile you have to convince those you work with that Agile is the thing to do.  You have to convince them that, like the light bulb, they really want to change.

So the question becomes; how do we do this?  How do we convince those we work with that Agile is the thing that they really, really want to do?  I can quote you the dozens of arguments that have been made before for agile; that it produces better product faster, that it allows you to listen to the voice of the customer and incorporate those insights, that it lowers risk by producing product in bite size releases, etc.  And they would all be correct. But none of them are going to help you convince someone, who does not want to change, that they should make the change to Agile.  The key, is self interest.  It might be enlightened self interest, but it is self interest none the less.  You need to make this choice about what the individual stands to gain from making the change to Agile not just about what the benefits are to the company as a whole.  Because, in the end, if you are not the lone voice in the wilderness you will be that much more likely to succeed in gaining the adoption of Agile as the preferred SDLC in your company.

So how do we make this about the individual and not about the company?  First, the argument is going to be different for each group of individuals that you deal with.  The point you make with the marketing team is going to be radically different than the point you make with the development team.

So how about some examples of the benefits that you can talk about?  If you are reading this entry then I am assuming that you at least know the basics of agile so I am not going to go into the details of each of these sample points.  These are a few examples of the types of points that you can make when arguing for the move to agile, not an exhaustive list of what you can try

• For the BA and the product owner.  No cumbersome detailed requirement documents need to be created.  Agile uses the concept of a story that fits into a space no larger than a 3×5 card.  You will write less documentation that no one is ever going to actually read once it is written and you will have greater access to the development team
• For the Developer and the QA Engineer. You don’t have to read long and pointless detailed requirements documents that become obsolete the minute that they are written.  You will have more direct contact with the people who decide the things that you will be working on, and that means a greater opportunity to influence those people
• For the business stakeholder.  You get glimpses early and often into what has been created through the show-and-tell process.  You no longer have to wait until the product is completed to see if what you are getting is what you asked for.
• Etc.

As I mention above these are only a few of the arguments that you can make when trying to convince people that Agile is the better way to develop software.  It has to be personal, it has to be about what benefits the individual directly and it has to be a personalized and targeted message.

So do you really want to change?

Feel free to drop me some questions.  I’ll be happy to address them and if it makes sense add the answers back to the body of the blog.