Common challenges of implementing agile delivery

A lot is written about ‘agile’ delivery. About how iterative delivery is key and about the tools and processes needed to achieve success. I’m a big advocate of an agile delivery approach, and I know that the technology challenge is one that can be (relatively easily) overcome. The hard part is in changing people and processes.

Over the last few months, I’ve been working with a number of our enterprise clients in the US and Europe on identifying and overcoming the fundamental issues with the way the business processes work. This is well before we even get into conversations about route to production, business value and continuous integration. Often, organisational constraints can be overlooked when trying to implement an agile project, yet they are fundamental to a successful delivery.

There are a number of common challenges that I see time and time again with our enterprise clients as they mature digitally.

Project vs. product

Everyone is comfortable with a nice, big project. It has a start and it has an end. It has a fixed scope. It will also probably be delivered a bit later and a bit more expensive than was planned, but that’s accepted. When it’s complete, you can sign it off and move on to the next project. That’s how businesses have worked for decades on IT projects. Internal processes, governance, roles and responsibilities have been created to manage large projects. However, in the new digital-first world, nothing is ever ‘complete’.

As a result of continuous development and a ‘test and learn’ mentality, projects often become products. These products are developed via ongoing deliveries which constantly iterate and release. This can become a challenge to the funding models in place, specifically funding processes that require extensive due diligence and business case development phases before anything is started.

The key to starting to change thinking around funding and approach is to instill a belief that failing is good. Learn from failure and move on in the right direction. However, failure must be quick, it must be ‘cheap’ and the organisation must not have a blame culture.

Delivery vs. process

A company’s internal process and governance approach to digital projects is initially created to reduce risk and maximise success. But as delivery approaches and the tooling and appetite for risk changes, these internal ways of working are often not updated. Subsequently, these processes work against a team striving for agility in a continuous delivery environment.

Often, these processes can, at best, slow down delivery and, at worse, block the project completely. For example, it may be that an external team is allowed to work on projects, but has no route to production without another team being involved who have no understanding of the project. Other challenges that we have experienced include being denied wifi access, despite having been brought in by the senior team to work on-site (this resulted in a high number of 4G dongles)!

With a well-defined plan for the use of automation software such as Jenkins, Chef, Puppet, SonarQube etc. in delivery, as well as through the quality assurance process, we can ensure a lot of risk is removed. However, often internal policies and processes have not allowed for the security this tooling can bring, and fall back to a manual and less secure process.

Non-agile dependencies

It’s important to remember that just because one team is working in an agile fashion, that other dependencies may be working in a different manner. It’s vital to understand the approach of any dependencies in your project and mitigate any risks straight away. For example, in a large project we were involved in, the data was being delivered by third parties. While our normal approach would be to deliver a thin slice of functionality as soon as possible, we weren’t able to as the other team was working in a more waterfall approach.  As such, we quickly de-coupled our project from this dependency to de-risk the release, while also ensuring we worked closely with the data team to help plan their delivery in a more iterative approach.

Hierarchy

All organisations we work with will have some level of hierarchy. Unfortunately, the hierarchy and structure that may work for an organisation in its main business function can work against the agility of a delivery team.

In a process where you need rapid approvals, to test out ideas and make quick decisions based on data, you require an empowered product owner. This role should be someone who can make decisions; they shouldn’t need to wait six weeks for a board meeting to get direction on the next steps, and should have the freedom to work directly with the development team. We have worked on many projects where a company believes they have a Product Owner working to agile principles but are, in fact, blocked by a hierarchical challenge.

Bringing people along for the ride

A change to working patterns can cause conflict for internal business teams, usually because they aren’t clear about the reasons behind the change. Implementing an agile delivery approach is normally mandated from the top of the organisation; an agile team is dropped in to deliver a key project, but the internal team is often not informed about the end goal. In order to help with the success of the delivery, the teams who will be impacted need to be aware that the agile team will be influencing change. The aim is for them to be trained in new ways of working, and that a new governance will be designed.

Remember, if the team doesn’t know the ‘why’, they can’t help with the ‘how’.

Agile delivery can truly help accelerate digital transformation, but you must ensure that your business supports (not hinders) this approach.