Agile Success Case Study: The Only Way to Eat an Elephant is Taking One Bite at a Time

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.

“Analysing 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 organisation, 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 organisational structure, technical and team agility, technology stack, governance, 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 organisation was only just getting started on the agile journey, this product had to be developed in a very short period due to market pressure and the “early adopter” advantages. So the car had to accelerate from 0 to 100 in no time.

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.

#1 Lesson learned: Set things up as a pilot and get full commitment from the organisation’s leaders to run it as such.

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 organisation.

#2 Lesson learned: Declare the initiative as a pilot so that leaders and managers don’t have to go all in at once. A playfield makes it safe to explore and learn. Also apply what worked well (and avoid what didn’t) in other initiatives.

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.

^[1] https://www.scaledagileframework.com/value-streams/ Value streams represent the series of steps that an organisation uses to implement solutions that provide a continuous flow of value to a customer.

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. If old working patterns have gotten employees a long way in their careers, 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 roles. 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 prioritise 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.

Setting up a high-performing team requires time. 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.

^[1] MVP = minimum viable product

Organisational 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.

#6 Lesson learned: Product owners should be ringfenced so they can devote their energy and time to the specific initiative, and the team itself should be empowered to perform best as an agile team. Help senior management to understand the consequences if the product owner lacks the required capacity.

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’s 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. Whiteboards like JIRA and Confluence do a great deal to foster transparency and ultimately save time for many senior management stakeholders, who no longer must attend all meetings.

#7 Lesson learned: It proved to be valuable for senior management to be trained as well. Even if they insist on their traditional status reporting, they can still receive their reports while slowly transitioning to the new agile world. To accelerate the process they can be given transparency by means of appropriate tools such as progress tracking on whiteboards (e.g. JIRA, Confluence). If management wants to participate at a stand-up, give them the opportunity to see and learn.

Facts and Figures

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 optimising 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.

#8 Lesson learned: Ambitious time-to-market cycles can only be met if agile principles are applied very strictly and senior management fully supports the initiative with things like decentralised decision-making. Ambitious goals do not mean unrealistic goals.

Conclusion

Implementing an agile organisation (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 organisation. When implemented according to the organisation’s requirements, agile pilots not only generate clear and measurable benefits but also create useful learnings that will help the organisation scale new ways of working.

To summarise, an agile transformation can start small and evolve into an organisation-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.