Agile has come to stay, so there is no debate on whether we need to adapt to it or not. Here are some tips on how to do an agile transformation carefully, since it is a methodology that needs a cultural change, not just operational change.
To start a new project for a new account, the “agile way” is the “simplest thing” an IT vendor can do. Nevertheless, life becomes tough when they have to do an agile transformation. Yes, this is very cultural and needs a very good ecosystem to succeed and flourish.
New agile kickoffs are easier than transforming an existing delivery system to agile way.
Before I even talk further about challenges and the solutions, an IT vendor first needs a good Agile Coach, who can bring the spirit of agile into the organisation. Just forming a team and training them on agile and engaging a Certified Scrum Master (CSM) will not help.
Agile transformation can pose challenges in many places of the life cycle. The picture broadly below depicts that:
Challenge 1: If the wrong person is a Product Owner. The Product Owner should be empowered to take decisions on functionalities and should truly represent the Business. Engaging a non-empowered person as Product Owner will complicate development and will increase cycles of production and thereby its cost.
The BEST THING is to have the Product Owner from business. He/she should have a vision for the application developed. He /she should be able to take call on the features, as well as should be able to clearly prioritise features. The NEXT BEST is to have a person who has got full business buy-in on the application being developed. Still, the risks are too many if the Product Owner and business are disconnected.
Challenge 2: Long sprint durations. When migrating from legacy/conventional delivery lifecycles, some people are uncomfortable to work in 2-week sprints. They decide to have longer sprints and duration the more comfortable they are. This will be counter-productive. Spirit of agile is to deliver working software ASAP!
Here is a very interesting article of Cognizant that elaborates about various impacts of the sprint duration. Agile teams should be ‘self-managing teams’ and by giving too long duration sprints decreases the agility and subtly encourages lethargy. The agile team will be more than happy to commit to meaningful/short sprint durations when “done” definition is clear. A hazy “done” description leads to thoughts of longer sprints.
Challenge 3: Daily scrums will be effective only if they are timeboxed like the sprint. When migrating from a legacy lifecycle, which has a longer duration but less frequent reviews, people tend to overeat with their updates. This would make daily scrums lose focus and not get full visibility of what’s happening in the team.
There should be a very effective Scrum Master who can articulate well and ensure a very effective Daily Scrum. Any points that could go beyond the 15 minutes duration of the daily scrum can be taken into the sidebar for later discussion.
Various other points that would pose challenges in an agile transformation are:
- Billing model for agile – remember ‘requirements are evolving’
- Resource utilisation – remember ‘everyone is responsible’
- Team bonding – this decides many successes
- Servant leadership – enabling the team to perform
- Senior management appreciation for agile style
- A clear understanding of ‘ideal hours’
- Careful re-prioritising when the sprint is running
- Being fully focussed on ‘delivering value’
There is a very interesting read on agile obstacles by Michael James. Read through it to know the western challenges of agile; some of them apply very much for Indian IT Vendors as well…!
So, Agile is in, and to get the best out of it, we should adopt it carefully so that the full benefits are reaped!