Evolving towards agile

Agile I always understood as being a beast of synergy.

If you followed all the principles of the methodology then they would feed off each other and create a singularity of productivity. Fail on the implementation of some of the aspects and you end up in the well and lose productivity. This means that implementing agile is a gamble for the business, since no one wants to end up in the well in an attempt to catch the high.

It is very unlikely that this is true.

Singularities in any system are rare and even tough productivity and methodologies would make for a complex domain it is unlikely that singularities exist, and let alone that we could find one. So chances are that there is a path to agile that involves individual steps where each and every step improves productivity in itself. So what would the order of these steps be that would allow for an evolution towards agile?

We know that the transition towards agile has some pitfalls and adoption is not always successful. The reason why adoption often fails is because some of the steps taken make fundamentally no sense. An example of this is starting out by going to the business and saying that you want to make the scope of releases flexible if they want to keep the dates fixed. Sure it is part of the package, and sure some people will get this to work as a first step; but for many companies this is too big an impact of the organization to warrant the change. And the implementation loses steam or fails completely

So order likely matters. And possibly there is an order that is maybe slower but less risky.

So let’s consider some of the core technologies that Agile is based upon, and the drawbacks to the business.

  • Customer integration
    • Are developers fit to talk to customers (social skills, etiquette)
    • Do the developers speak the language of the customers
  • Business integration
    • Does development and the business speak the same language
    • Is there mutual respect
  • Self-organizing teams
    • Is there enough contact between the teams to allow for organization
    • Does the organization have the capabilities to support this
  • Retrospectives
    • Is there a culture of constructive criticism
  • Short iterations
    • What are the current commitments of the development team
  • Dynamic prioritization of tasks
    • What is the current workflow associated with prioritization
  • Unit of work segregation
    • Does development share the same language
    • Is there a tracking mechanism
  • Visualize project status
    • Is there space
    • Is there interest

*(I have had to create my own as I did not find suitable information elsewhere. I’m sure that there are some that people use that are missed but these were the core technologies that I’ve seen in implementations. )

Over the next set of posts I’ll be shaping an evolutionary path to putting these technologies in place. Creating an 8 step program towards agile while gaining momentum along the way.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s