In hindsight, was there a better transition path that you would have designed for your organisation to move into Agile ways of working?

Context

There is always considerable fanfare and excitement when senior management makes formal announcements of transitioning into an ‘Agile’ way of working. This announcement opens up a myriad of potential benefits ranging from shorter delivery times, reduced documentation, ability to accommodate continuous changes, identifying and addressing potential challenges early on and the list goes on. Invariably across organisations of varied sizes and structures, this situation throws up interesting revelations that help understand the underlying motivations for going Agile. While the destination is clear, the paths and the motivations to get there could vary depending upon the stakeholder perspective.

While organisations do make sincere attempts through introductory and hands- on training sessions on Agile ways of working, often the implications and the expectations from each stakeholder are aspects that need closer attention and alignment. The initial preparatory phase before diving into Agile ways of working is therefore key to set the expectations and recalibrate the ways of working of the various teams to avoid misconceptions on the way ahead.

Problem statement

Stakeholders across the various functions of the organisation come in with different expectations of what Agile can do for them, without realising the fact that their current ways of working may not necessarily be aligned. This leads to different expectations from stakeholders throughout the project phases, resulting in misalignment in the project delivery scope and timelines, leading to avoidable delays in the project timelines.

Suggestions and key considerations:

While there are recommended practices for organisations to transition into Agile ways of working, the context and culture of the organisation is a key determining factor in chalking out this roadmap.

Following are the commonly observed situations in organisations, which need attention in this journey:

1. Your definition of Agile seems different.

Often expectations from Agile ways of working are open to each stakeholder’s interpretation, based on their understanding and experience and leads to unrealistic ask from them. Alignment of all stakeholders on the Agile ways of working, as the organisation transitions is an important first step that needs considerable investment of time and effort from the function driving implementing the Agile framework in the organisation, in most cases the Enterprise PMO. An internal campaign to promote awareness and ensure alignment across the organisation would be a key preparatory activity before initiating any project.

2. Deliver now, define later!

Transitioning into Agile does not dispense the responsibility of the Product Owner to clearly define the product / service offering. While the approved business case will provide the required justification for the product / service, the visualisation of the proposed product / service plays a key role in its delivery. The product / service vision, customer journey, business process and controls, operational performance metrics, etc still need to be clearly articulated to ensure these are accommodated in the design. Grooming sessions that involve discussions on workflows, feature backlogs, customer journey storyboards, sample UI /UX designs, and user stories are effective to articulate the requirements and thereby come up with a realistic effort estimation.

3. Design is not frozen!

One of the challenges with transitioning to Agile is the constantly changing or evolving solution design which causes discomfort with the technical teams trying to freeze the middleware and infrastructure requirements. While the high-level solution architecture is baselined, the lower-level design elements undergo constant changes to accommodate the non-functional or performance requirements. The flexibility to revisit these and update them, need to be incorporated based on sprint reviews and feedback.

4. Apologies will join if time permits.

While Agile mandates dedicated team members across all functions, this is often found to be difficult given the fact that, often team members are involved in multiple Business as Usual (BAU) activities that need their attention. Therefore, ensuring that the designated team members are available and able to block time to participate meaningfully in the sprint sessions is necessary to ensure timely inputs and keep the project on track.

5. Welcome to the real world!

While the project teams are engrossed in constant rounds of iterative development sprints, the support functions such as change advisory, release management, monitoring and support often continue to operate in the legacy Waterfall method due to multiple reasons. This situation results in an inadvertent and forced transition back from Agile to Waterfall at this juncture, nullifying the benefits reaped till this juncture. A separate track to support Agile projects needs to be established in these areas of project support to ensure end to end Agile delivery.

?6. Sounds like great progress but are we on track?

While there is always a list of metrics to report the list of user stories that are in ‘Doing’ and ‘Done’ statuses, often the question of whether the project is on track for the planned delivery needs additional probing and discussion. Clarity on the scope of the MVP to be delivered needs to be established at the inception and sprint performance measured and reported against this baseline, serves as a helpful compass for the senior management.

Conclusion

While investing time and effort to communicate the expected Agile ways of working is key to eliminating the most common roadblocks, the approach for every organisation is bespoke based on their context and culture. Assigning the responsibility to a specific function to roll out and report would help in understanding and putting in place the most optimal approach. Piloting cherry picked initiatives for the Agile journey could be an effective way to get started and understand points of potential friction before rolling out the approach across the organisation.

Disclaimer

Views and opinions expressed are based on empirical data from past Transformation programmes pertaining to banking and financial services and may not necessarily be in exact alignment with leading practices or established frameworks.