“Going Agile” should never be the goal of any enterprise transformation. There, I said it.

Some Agile transformations are analogous to someone telling you that everyone here in the US needs to start driving on the left side of the road. Why? We will get to our destination 16 seconds faster on average (time to market improvement). We will have less wrecks (better quality). Traffic jams will decrease by 35% (sustainable pace). And, postal workers will no longer have to learn a new skill – driving a delivery truck with a steering wheel on the passenger side.

Car with steering wheel on right side

OK, OK, but we still need to go Agile! For now, let’s ignore the fact that all street and highway signage will need to be adjusted. Ignore the fact that all lane arrows need to be erased and repainted. Ignore the fact that signal lights will need to be reprogrammed. Wait – can I do a left turn on red now? Ignore the fact that all cars will need steering wheels retrofitted to the passenger side. Ignore the fact that 242M adults will need a left-angle turn in their brain to learn how to drive on the left side of the road.

The culture shift alone could take 10 years. Instant adoption and default cooperation you say? Dream on. Welcome to the wonderful world of enterprise Agile adoption!

“Going Agile” should never be the goal of any enterprise transformation. There, I said it again.

One of the very first steps in any enterprise transformation is to understand the current situation. Stop. Slow down. Spend some quality time with teams understanding what is going on – especially any pain points. Do some flow analysis to understand how the product goes from vision to reality. Grok it. Coalesce it. Create a reasonably accurate picture in your mind of the situation. Avoid this step, and you risk applying a prescriptive solution to a perceived issue that may not even be there.

Once you have a handle on the current situation, then (and only then) explore the desired future state. Describe the desired future state as a small set of concise transformation goals. Gain consensus on these transformation goals with the stakeholders, leaders, and teams.

Example transformation goals might include:

  • Increase our number of product launches from 1 per year to 4 per year
  • Reduce our defects found after launch by 50%
  • Reduce our average launch time for a product from 12 months down to 6 months
  • Increase our employee satisfaction level from an average of 2.5 to 3.5 out of 4
  • Increase customer retention by 30%
  • Refocus our company around a small set of high-revenue producing products, while sunsetting non-profitable products
  • Etc.

Please note that you don’t see “Go Agile” on the above list.

When guiding an enterprise Agile transformation, think of Agile as a toolbelt of methods, techniques, and yes even “tricks” to help in certain situations along with other practical approaches. To make progress towards a specific goal, apply a relevant technique from your Agile toolbelt or from a host of proven techniques found long before Agile was a word pronounced two different ways (aj-uhl and aj- eye-l). Dare I say it, but it might even be possible to achieve a specific transformation goal without the use of Agile methods – the horror!

Tool belt with tools

Just remember – round peg in a round hole. Non-prescriptive. Every enterprise situation is different. Don’t go in thinking you can just apply Scrum and/or Kanban and everything will get better. You will be forcing everyone to drive on the left side of the road. Your client deserves better.

For a good example of an outcome-oriented Agile transformation approach, check out Agile Velocity’s Path to Agility framework here.

For a concise view of what all is involved in an Agile transformation, view here.