ShriKant Vashishtha

Implementing Agile in a big enterprise is not an easy task. The metaphor I sometimes use for big enterprise is to compare it with Elephant. It’s very easy for a small living being to move and maneuver. However when it comes to elephant, it requires time to build momentum and when it actually moves, it moves slowly. People involved in Agile transformation get frustrated because of all perceived delays. Frustration is understandable but not sure if much can be done other than understanding the simple reality that you are dealing with an elephant and not a tiger or mouse.

Now comes other bit. People are limited in their understanding of big elephant just because of their boundaries (silos) in the big environment. Agile transformation in big enterprises might get myopic as most of the people involved are not able to see problems in totality. That translates in focusing issues which require a lot of effort to solve but may not bring the business value you are looking for on board. Some important challenges to consider for Enterprise Agile transformation are as follows:

• Ability to clearly define the problems in hand.
• Are we focusing on the right problem?

The big picture could be something like this.

Based on the feedback of the customers or based on market trends, business comes out with an idea or a problem statement which needs to be solved. Now for many technical people, the obvious solution comes as technical solution but in reality solution can be completely non-technical (process improvement) or completely technical or mix of both. Most of the times software development is a part of bigger solution.

The business idea is explained to technology people and they start working on a software project. That’s the place where most of the Scrum, XP techniques are placed. Most of the times focus of optimization remains technology. People try to automate everything whatever is perceived as manual step.

However as you move further or before in the value chain, there are other very important steps of solution. For instance after software delivery, change management activities have very important role. For instance deployment to production, training, marketing of the new product etc.

From the inception of the business idea to its implementation and further using it, important components of the chain may not be knowing each other very well because of their implicit boundaries. People try to understand this whole bigger picture but at the end of it many times, they get something like this:

Here’s a real story of one big enterprise Agile project I worked with.

In this project Agile was instrumental in delivering the software product in a record time and with tight budget. People coming from waterfall background were very skeptical about it but at the end everybody was happy to see the project delivered within half time of what it could be delivered with waterfall methodology. People were happy and cheered. As project finished, people involved moved on and started working on other projects.

At one fine day I came to know from one of my peers that though software was delivered technically but it couldn’t go to production because training logistics will take additional 3 more months. Other than that there were other issues because of which the realistic time to put system live can be 3-5 months.

I was shocked and then wondered if optimizing technical work only should the right focus for Agile teams. Instead of looking at just one part (software delivery) of the whole solution, shouldn’t we be worried more on time to market. That actually translates to program management than just pure project management. In this case, if training could be considered earlier as part of solution (program) planning, intuitive UI could be the focus of software delivery. That could lead in the reduction of both training cost and time.

Conclusion

Optimization should be considered for whole value chain instead of just one isolated piece of the chain. Everybody in the team should get the visibility of the backlog required to implement the product in the market and not just technical tasks involved.