Rome Wasn’t Built in a Day
Debunking the Agile myth that transformations happen overnight
7 March 2016
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Working on Agile implementations for the past few years has been interesting for me. The growing trend among companies to move from traditional Waterfall to Agile is a testimony to companies’ realization that the markets across all industries have become dynamic. These dynamics have increased the pressure on vendors or IT service providers. Although Agile is supposedly one type of measure used to respond to changing market dynamics, IT systems continue to exhibit certain limitations and challenges.
Many organizations in today’s marketplace run on legacy systems. There might be several dependent systems that have been operating under the Waterfall model, and moving them to the Agile mode of delivery overnight would be next to impossible. This aspect of the IT landscape has brought a new set of challenges to consultants and IT professionals trying to bring about a change in the organization’s operations. The pressure for service professionals increases exponentially because of the tough competition, with every player trying to get their share of the pie.
I experienced a classic example of this during a consultation with a food chain company. The company had a set of legacy systems not suitable for quick changes. Because of the challenge posed by market dynamics, the company wanted fast response times. We had several discussions with the client about what they were looking for and what their expectations and long-term goals were. There had been a previous attempt at a major transformation to overhaul the entire machinery. During one such discussion we were informed that they were facing stiff competition, and, while they led the market space, to ensure that they could maintain the lead, we would need to be not only proactive but also reactive. The last part alarmed us because of the potential time frame they were looking at. To our surprise (and shock), they had planned for a release every two weeks, with one-week iterations.
This was one more assignment we had landed that would require us to learn how to manage unrealistic expectations. We were about to carry out a complete transformation while trying to stabilize systems. We were not in a position to take on several new requirements in the middle of building a completely new technology setup. We had to find a way to support the client’s initiatives for a major marketing push and enhancements within the given limitations.
To combat these challenges, we split the teams into two. A greater percentage of resources were allocated to what we called the Setup Team, and the remaining resources were allocated to the Integration Team The latter team would take a new set of requirements and figure out how to integrate them with our baseline. In the end, it was a goal that we achieved well, with only a few challenges here and there.
The idea I am trying to drive here is how the implementation of Agile has resulted in myths spread across companies that things can be done overnight. We need to understand that Agile is meant to smooth operations by doing multiple tasks simultaneously, applying a faster response time, etc. To build and get that client’s system rolling was an effort of the type that typically goes ignored and unnoticed. The beauty of Agile is truly experienced when it’s understood and implemented in its purest form, and that’s why it’s a never-ending love affair with the model.
Current rating: 2 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.