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.
“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.
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.
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, and features were prioritized in the context of short-term sprints rather than final products.
 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:
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 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.
 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.
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.
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.
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: