Agile Success Case Study: There is Only One Way to Eat an Elephant: One Bite at a Time
How a step-by-step approach leads to a successful agile transformation
In the last issue we focused on the most critical aspect of agile: changing culture and mentality. Many organizations and their leaders see an all-in approach to agile transformation as too radical, and something that would require extreme courage (and representing a massive undertaking). We reflected on our own practical experiences and wanted to share how a step-by-step approach can lead to agile transformation success, and help you achieve quick wins in the shortest amount of time.
“Analyzing the requirements for a year or two is not an option. We need to deliver in three months” were the words of our client as to why the initiative, unlike the rest of the organization, was designed to run on an agile basis. The client, a reputable large bank operating in Europe, required support to launch an extension to an existing product that would create an additional revenue stream with existing clients. Given the current organizational structure, technical and team agility, technology stack, and – most challenging of all – governance and release and deployment cycles, we were faced with a tough challenge to solve, along with some uncomfortable discussions with the client.
Do These Challenges and Conflicting Goals Sound Familiar to You?
While the rest of the organization was only just getting started on the agile journey, this product had to be developed in a very short period of time due to market pressure and the “early adopter” advantages. So the car had to accelerate from 0 to 100 in no time.
Download your «Agile Life Hacks» poster now and get to read more articles on «Agile Transformation».
Run a Pilot Project in Agile Mode
Here are some of the key lessons learned that helped make the initiative a success.
1. Senior management backed the execution of the project, among other things by attending the daily stand-ups and ensuring impediments were resolved as quickly as possible.
2. Before starting the initiative, we designed and adhered to some agile design principles together with the client. Applying an agile mindset was beneficial for the execution of the initiative. As this project was treated as a pilot, it was much easier to label it as a playfield rather than a radical transformation of the whole organization.
3. The product owners were fully trusted and empowered to manage their backlog and to interact with the required experts (developer, tester, etc.). This resulted in a lean decision-making process with the full involvement of the experts. This didn’t mean objectives and key results weren’t considered, but it certainly meant that senior management was able to think in terms of value streams[1], and features were prioritized in the context of short-term sprints rather than final products.
Technical and Team Agility
Although team agility often seems the quickest to accomplish, you shouldn’t ignore the fact that humans are naturally hesitant to change. In particular, old working patterns have gotten employees a long way in their careers – so why suddenly change to new ways of working? Communicate actively why the adoption of new ways of working brings benefits to the whole team.
Another key to helping a team perform is a skilled scrum master. An experienced scrum master can effectively coach the team to work in agile mode and enable other team members to live up to their role. It’s also helpful if a scrum master gives training to the team in addition to the day-to-day work at the beginning of the agile journey. He or she should work to support the product owner in their daily business, for example by:
- Rightsizing stories
- Making sure stories have clear acceptance criteria
- Enabling the product owner to prioritize which stories/epics are to be implemented first (it’s usually tempting to heavily overload the first couple of sprints, leading to unrealistic goals)
- Ensuring technical feasibility, which usually can be best assessed by a technically skilled person such as a scrum master with technical experience.
To conclude, setting up a high-performing team requires time, but the more experienced a scrum master and the team are, the quicker this can happen – resulting in higher productivity and increased delivery pace.
Release and Deployment Cycles
Although a fully working DevOps setup such as those at Spotify or Facebook would be the dream of any product owner, the reality is that many banks have IT legacy issues, with only a few release cycles per year. This shouldn’t hold you back from planning frequent deployments if “continuous deployment” can’t be achieved from the start.
If constraints and dependencies are known, they can be managed, and solutions worked out.
In our case, the first release of an MVP[1] needed to be delivered after six sprints. Although this was very little time for what needed to be done, release management was involved from sprint 1 as part of the technical enablement feature. Furthermore, providing test results at the end of every sprint enabled development up until a few days before the actual deployment date.
Organizational Structure and Processes
Often, product owners are appointed to steer a significant initiative on top of their daily workload. This often results in a stretch and the product owner can end up in a capacity shortage with insufficient time to thoroughly fulfil their role as a product owner.
Another point we noticed was that senior management was still used to having the final say in even minor decisions. As they became familiar with a full agile setup, senior management quickly learned that most decisions with little impact are much better handled if there is enough information flow. You might imagine that this led to some uncertainty at the beginning, but delegating authority doesn’t automatically have to mean less transparency. White boards (e.g. JIRA and Confluence) do a great deal to foster transparency and ultimately save time for many senior management stakeholders, who no longer have to attend all meetings.
Facts and Figures – and How It All Became a Success
The lead time from project kickoff to “go-live” of the first MVP was only 3 months. We estimate that an initiative of the same size would otherwise have taken almost one year (conducting business analysis, designing front ends, re-designing requirements, testing, etc.).
The amount of reworking and waste was reduced to a minimum by optimizing value streams during the initiative. The team ensured a full understanding of each story and made sure their understanding was aligned with the product owner’s in order to continue with preparation (detailing out) and planning for a sprint.
Conclusion
Implementing an agile organization (not only for IT development, but for operations as well) doesn’t necessarily need to be a radical all-in exercise. On the contrary, we strongly believe that executing pilots and experiencing their benefits early on can create trust and bring value to the organization. When implemented according to the organization’s requirements, agile pilots not only generate clear and measurable benefits, but also create useful learnings that will help the organization scale new ways of working.
To summarize, an agile transformation can start small and evolve into an organization-wide initiative over time. A few straightforward steps may help you along the way:
Get in touch for more insights on agile methods at large and medium corporations. Subscribe to our Agile Article Series here, and schedule a virtual coffee talk with us: mischa.delpy@synpulse.com and pascal.wagenhofer@synpulse.com.
Download your «Agile Life Hacks» poster now and get more articles on «Agile Transformation».
