Agile and Event-Driven Management

Eli Lopian    Agile, Management for Geeks    

I have read an article on VentureHacks on Lean (Agile) Companies. In this article Agile = Less Waste

At Typemock we are take Agile development and being an Agile company seriously. In the development we use a scrum/XP hybrid and we use Event-Driven Management for the company. I will explain Event-Driven Management later, but I want to show you the problems that I found in the Agile Development Process.

The End of Iteration is too late

Lets take an example of a feature request that a major client needs. This feature was added as part of the development iteration and the client was told that the feature will probably be ready in 2 weeks. But at the end of the iteration due to its priority the feature was not created. The agile process says that this is ok – as we produced higher value features!

But we have a problem here: The client is stuck without his feature, but only at the end of the iteration that we knew the feature was not going to be implemented. There was no time for management to react to this problem and to solve it. For those who want to know there are a few ways to solve this

1. Change Priorities
2. Add a developer from another team
3. Tell the client when the feature will be ready

How can it be better?

This is where Event-Driven Management comes in. It start by everyone saying what they intents to do that iteration and if they can’t do it (for whatever reason) they have to immediately tell everyone that they can’t make it as soon as they know about it (=the event).

A good example are meetings. Suppose there is an 8:00 am meeting, when I accept I am saying that I intend to be in the meeting. If at 7:45 I am in traffic and I know that I just can’t make it, I can do one of the following:

1. Turn back and miss the meeting
2. Try to get to the meeting as fast as possible and appear 30 minutes late
3. Phone the person I am meeting and tell him that I will be 30 minutes late.

Event-Driven means that we choose option 3. we immediately tell people about the change. Doing this will allow the other person to react to the change and for example reschedule the meeting. At least he won’t sit around and wait.

Event Driven Agile

Doing this with Agile will mean that once we understand that a feature that we intended to do won’t be done – we DO NOT wait to the end of the iteration but immediately tell everyone that we won’t be doing the feature. There can never be a case that we know about missing features at the last minute.

It is quite simple once you use a burn down chart, when the time left on the burn down is more than the time actually left – we can raise the Event and immediately tell the team about it, allowing the company to find solutions to the problems as they arise.

Communication by Events versus Communication by Polling

An event driven company is one where everyone knows what the other teams intent to do and they get are notified when these are postponed.

Whereas polling driven companies are companies where the employees are constantly asked ‘what is the status of’ (because we can’t know if we are going to be there on time). People will wait for others and poll at intervals – leading to waste.

Being an event driven company – will stop waste and make the company much leaner.

If you enjoyed this article please consider sharing it!