CIO's! Why aren't you seeing your Agile benefits ?

CIO's! Why aren't you seeing your Agile benefits ?

 

Agile ways of working promise significant benefits to a business, creating a more responsive, efficient and effective organisation, improving business performance and increases customer satisfaction. However, companies that have ‘gone Agile’ often aren’t realising the benefits that they are expecting. This article looks at one reason why.

Have you tried to adopt ‘Agile’ ways of working, and aren’t seeing the expected benefits? It could be that you’re stuck in a halfway house to Agile having implemented ‘Water-Scrum-Fall’.

What is ‘Water-Scrum-Fall’?

‘Water-Scrum-Fall’ is term coined by Forrester, and used as a way to describe a position in which Scrum, as an Agile framework, has been partially implemented as a way of addressing issues with a non-Agile or Waterfall ways of working.

‘Water-Scrum-Fall’ is something which usually happens with some organisations that are aiming to ‘be Agile’, but have a culture and inertia that forces embedding Agile practices into a siloed IT organisation, with functional departments executing a standard requirements phase, a test phase, a build phase and a release phase.

While the ‘Water-Scrum-Fall’ model is not inherently bad, organisations that find themselves falling into its use are unlikely to realise the business benefits of Agile adoption, such as; faster time-to-market, increased business value, and improved flexibility and responsiveness.

In essence, it’s waterfall software delivery using an incremental scrum-style release cycle rather than either a pure “big project” waterfall approach or a pure “agile prioritisation” scrum approach.

Development teams are run in an Agile (Scrum) fashion with Scrum ceremonies, artifacts and roles, but follows a sequential quasi-waterfall methodology outside of the design and development activities.  The outcome is that each sprint, or group of sprints, becomes a mini-waterfall with lots of documentation produced as an input and output of the process.

From a process perspective, ‘Water-Scrum-Fall’ can be evidenced by three distinct phases:

  • Detailed planning and design (Water)
  • Development based on the Scrum method (Scrum)
  • Strict and managed delivery of the product/service (Fall).

It is often a case that the frequency of deliveries as part of the ‘Scrum’ phase is out of synchronisation with the cadence of the production release process.

‘Water’

The initiation and planning activites of the delivery process. Governance rules often require many organisations to define requirements and plans before starting work, forming the basis of a contract between the business and IT that defines project direction, timeline and budget.

This results in time having to be spent upfront, with the business, to build the requirements and plans, ensuring that they know what they want, how long it is going to take and how much it is going to cost.

Spending too much time upfront does not increase the quality of the release, if fact it is often very wasteful, as, at this point, the business will frequently not know what they really want.

Upfront requirement documentation is a poor proxy for working software, and thus any requirements documented should be just enough to introduce the problem area and allow high-level planning and development work to commence.

‘Scrum’

The design and build activities of the delivery process. The business often only fully understands their requirements, or the problem that is being solved, after they have seen a solution. Feedback late in the release cycle is less than welcome, as this can lead to the development team having to balance the cost of changing the application with the benefits of the working functionality.

Utilising Agile ‘Scrum’ techniques helps to address this by providing the business with early visibility of the working functionality, allowing feedback and modifications to be made without significant impact on the overall costs and timescales.

Using Agile ‘Scrum’ techniques provide a strong focus on collaboration, teams and team dynamics, with the business, developers, testers and business analysts working towards a common goal.

The reality of ‘Water-Scrum-Fall’ is that change continues. By supporting change, while at the same time ensuring that the team understands the impact of that change, the team not only builds better applications, but also learns more about its process for future implementations.

‘Fall’

The activities around the assurance and deployment of releases as part of the delivery process. Adopting Agile development processes do not, in themselves, change the firm’s underlying architecture and operational culture; therefore, teams often have to make the best of the situation. This can often result in limits being imposed on the frequency of releases and the benefits of agility not being realised.

Frequent software releases to the customer enable rapid feedback and ensure that valuable software is being used as early as possible. However, there are rarely the facilities required to support dynamic, flexible releases; instead, infrequent releases are carried out backed by heavy processes and governance.

While unit testing is carried out as part of the ‘Scrum’ activities, and performed in an iterative manner, helping to generate a stable delivery of code from build phase, all other testing activities are carried out using a sequential ‘Waterfall’ methodology relying on lots of documentation for input and set outputs.

Moving from ‘Water-Scrum-Fall’ to Agile Delivery

It is important to challenge the status quo of infrequent releases and push to better integrate release processes into the development team, incrementally adding to sprints release process activities such as preproduction testing, data migration, security and performance testing.

Including testing within each sprint not only gathers more rapid feedback for the team, but also encourages the team to automate these processes, increasing the overall fidelity of their results while also automating governance. Consistent automation of the complete delivery model also allows Release Managers to better understand the status of the software releases.

Conclusion

‘Water-Scrum-Fall’ tends to highlight the inefficiencies in the way that an organisation currently works, and does not sustainably realise the benefits of really being Agile.

The aim should be for ‘being Agile’ rather than ‘doing Agile’ and to try to avoid getting stuck in ‘Water-Scrum-Fall’ pretending you are Agile when you are not. ‘Water-Scrum-Fall’ is fine as a starting point but it should not be the end goal of the Agile journey of an organisation.

Are you struggling to reconcile that you are being told that you have implemented Agile methods and yet aren’t seeing the promised benefits.  Can you see that you have ended up implementing a sub-optimal ‘Water-Scrum-Fall’ approach? iCore can help you understand your current operating model and ways of working, help you develop an improvement plan leveraging Agile, DevOps and Lean IT techniques to help realise the promised benefits. iCore can help you break out of the ‘Water-Scrum-Fall’ paralysis and deliver true Agile ways of working.

 

iCore can provide you with independent insight to your existing processes, helping you understand where there may be challenges within your ways of working and supplying pragmatic recommendations for improvement aligned with your specific business needs.

iCore provides consultancy and pragmatic approach to delivery helping many organisations to change their IT Service Delivery to adapt to new and emerging technologies, frameworks and working practices. iCore consultants have practical Service Management experience, working in technology departments for top 250 companies.

If you would like to discuss how iCore can help you then contact us on +44 (0) 207 868 1600 or email us at info@icore-ltd.com