Quite often I get to see engineering teams – upto middle management being new to agile, are ready to give it a try. But they have real problem on hand that is – coaches asking them to:
- Embrace change from business and at technical practices level
- Question traditional approaches of development
- Do some planning not much
- Do some analysis not much – leading to analysis paralysis and list goes on…
But engineering teams have to give their management:
- Long term plan
- Have to commit to project estimates at the start
- Accept all the scope changes keeping time almost same and goes on….
Saying “NO” to unrealistic expectations, scope and time is biggest cultural change. We see it so often. You can read more about this in my earlier post Sustainable Pace: Does Culture Play Any Role At All
One of the biggest myths in the industry or mis-understanding is: “Agile is for engineering teams”. It is engineering team who has to adopt to agile way of working to deliver sooner than they were doing earlier. It is them who have to accept changes from business. This kind of agile implementation fails miserably. Even business must be ready to accept surprises or changes from the engineering team. If engineering teams hit a roadblock and unable to deliver few stories(assuming product team was informed timely) then management should try to accept this. Business must be flexible to accept change.
Hence embracing change is both ways. Management can not be practicing traditional school of thought like “I want everything by this time” – “command-and-control behaviours” and expect their teams to be fast, agile and flexible.
Harish Chander says
I would rather say that agile adoption should be top down, if an Organization want to succeed. If Management is not aligned to agile thinking, the experiment is likely to fail and the blame would wrongly be put on Agile.
Avienaash Shiralige says
Just top down may not work if people don’t support it. hence pilot projects route are taken by many companies. Mostly you have huge resistance at middle management layer.
Harish Chander says
Pilot project route is fine for smaller and relatively independent projects. But in case there are many dependencies across the teams, pilot projects fail miserably. In such a scenario, top down approach seems to be the only workable idea.