You do not want agile

No really….. you don’t. Well, maybe you do, but the boardroom certainly doesn’t. They have never heard about agile, let alone what it is all about. Is this something that will help us solve our problems or just a new IT buzzword?

Upper level management doesn’t think in terms of agile, they think in terms of business outcome. For instance: “We need to improve our position in market-segment ”A” and we need to cut costs while doing so.”
At this point, someone usually shouts: “We need to “be agile” to achieve this big hairy audacious goal, let’s roll out an agile adoption program!”
But is “being agile” really the factor that produces/causes success or is it (just) a helpful factor or co-producer that sets you on the right track towards the desired outcome? Of course we have seen changes in people and outcome during our projects. But does implementing agile on software development really solely form this improvement?
Next to that, you could discover that a “non-agile” development department is already able to deliver software at an acceptable rate and quality. Your focus in this case might be on making sure the right things are being made and connecting the business in another way. Probably there are other non-agile measures you could think of, that are also thought to be helpful in moving towards your goals.
So here is what you should do:

1. If a client says they want agile, the least you should do is ask how they think agile can help them support business goals. Keep track of key performance indicators with regard to these goals to track progress and see if your change efforts have any effect.
2. Propose agile to management by relating agile benefits to company goals. Being agile is never the goal, but a means to achieve business outcome.
3. Never implement agile through a fixed regime. First evaluate the current situation (preferably together with all stake-sharers and takers) and check what you really need to do to (help) achieve your client’s goals.
4. Try to think up your plan and measures together with your customer instead of being the sole agile expert. Maybe aim for the role as agile expert on an ETC and leave room for other thoughts and measures to move towards goals next to your own.
   Having said this, please think about what position you have in your project/ assignment. Are you some kind of Oz-like wizard that magically changes the organization to move towards the desired goals? Or are you more like a guide; leading the change, together with the people, changing, sharing and consciously experimenting your way as a group towards validation of business outcome.
   Agile is never a goal in itself, nor is it the silver bullet to kill your problems. First know what your problems are, and then discover what things help to solve them. Amongst this list you might just encounter “be agile!”