Agile vs. Agile

“Agile Development” has been a buzz term for quite a while, but people still manage to use it incorrectly.  When somebody comes to talk to you or your team and says “I think we need to be more agile”, it is always important to ask them what they really mean and make sure that they actually do mean “we” and not “you”.  Why does that matter?  What’s the difference?  Agile is good, right?

Well, not necessarily.  First off, lets define what Agile Development is.  If you ask any six pundits, you would probably get six different answers, but in general I don’t think anyone would disagree with:

Agile development is an iterative and collaborative approach to software development that allows teams to respond to changing demands of the business.

I am intentionally leaving it simple and leaving out things like how much process is needed / not needed, and what types of deliverables are required to avoid arguments and stick to the basics.  Anyway, that makes sense, who could disagree with that?

Plenty of people.  First off, let’s just state that agile development isn’t the right fit for every situation and not worry about why it might or might not be (that’s a topic that has been covered many times already).  The issue here is discerning what someone means when they say “we need to be more agile”.

There have been many times when the “uninitiated” project manager or company leader makes this statement, and what they really mean is that “you need to be able to respond to my every whim”.  O….kay.  That is one definition of agile, I suppose.  This manager hears agile and thinks, gosh, I really could get everything I want exactly when I want it, agile is about the team being able to respond to my every request.  Don’t laugh, there are plenty of people that think this, and why not, it actually has been the state of development for a long time.

This interpretation of agile only provides for one set of changing behaviors – that of the development team.  Agile behavior goes way beyond the development team, it needs to create change in an all-inclusive team that is composed of not only the development team, but those very managers and other stakeholders such as QA, Operations, and customers (internal and external).  A real agile development process touches everyone.  Agile is about everyone sharing the pain and the gain all together.  Agile is not about a couple of developers responding to issues whenever they arise, it is about the entire group understanding what is important and each taking a stake in the success of the delivery of whatever the end results may be.  Agile is about creating behaviors that lead to trust across an organization through predictability.

When everyone works together and takes responsibility for prioritizing what needs to get done and continuously communicates not just progress, but all apects of the work being done, the end result is more predictable and there are not any big surprises.  Predictability and trust are important – those are the cornerstones that help information flow throughout the collective group and provide the building blocks for everyone to not only appear successful, but actually be successful.

So, when someone comes to you to talk about agility, make sure you know what they mean, and if they don’t quite get the true meaning, gently give them a push in the right direction.



[ This particular post is just reused material from one of my other blogs at Blogspot that I thought was worth reporting here. ]

I was reading an article about innovation on ZDNET a number of months back about innovation. It was the standard argument about what innovation is … is it revolutionary or creation of something from scratch? The article had two different points of view that it presented as it related to the topic. (Unfortunately, I can’t find the link to the article now.)

I think that both of them made some interesting points, but that they failed to put together what I think is a holistic view of the situation. Innovation need not always be the creation of something from scratch and need not necessarily be revolutionary … Innovation can also be using existing parts in a new way. What would be truly innovative would be to create two entirely different applications or services using 90% of the same pieces; pieces that already existed from other projects in the company or as parts of open source efforts.

If you sit back and really analyze most applications you will find that a significant portion of the effort involved with creating an application is the same effort that goes into every other application – security, data source access, presentation, transformation, reporting, etc. While each application may use these services slightly differently, the general idea is primarily the same. Think of how efficient an organization could become (and agile) if it concentrated on the 15% to 25% that truly makes applications different from one another. That would truly be innovative.