Agile is great, but it doesn’t guarantee success! In this article we’ll take a look at Agile success stories … and the reasons some critical programmes using it had to be rescued.

Let’s start with projects that were a resounding success.

Sales and Marketing Solution

A major hospitality organisation used the Agile DSDM framework to develop a sales and marketing system. The company had previously used Waterfall for all projects. DSDM was selected after a workshop on the pros and cons of Waterfall and Agile. The project had strong support from senior managers, business SMEs and technical specialists. A third-party company was responsible for the development. 

Before starting the project, DSDM training was delivered to the project team. This approach was much more effective than training the team during the project. Everyone understood their role and the differences in activities compared to Waterfall projects.

The business had been considering the project for several months before it started and had a long list of features that they wanted to include. MoSCoW was used to prioritise them.

The senior stakeholders welcomed the benefits of the DSDM structure, especially the deliverables from the timebox approach. Seeing the priority features delivered instilled a high level of confidence in the project. Additionally, the approach alleviated initial concerns about the risk of going over budget. The core functionality was released on time and to budget. Additional features were added to the backlog, and they were included in subsequent phases. 

The review concluded that the project provided the required business benefits and that the use of DSDM had been successful.

Transformation Programme

This was a complex transformation programme for a media company. The project involved replacing legacy editorial systems and the infrastructure. It highlights the importance of planning on an Agile project.

• The sprints were planned in detail for eighteen months, with the critical features (required for each phase go-live) aligned to sprints. 
• The project included replacing legacy applications and building new infrastructure. A high level of assurance regarding the sprint schedule was critical due to the dependencies and business requirements.
• It was implemented in phases, with go-lives occurring at regular intervals over an eighteen-month period.
• Some features/backlog items were moved (some brought forward and some moved to the next sprint) but the critical items were delivered in each sprint, and all cutover phases were delivered on time.  

The project was managed using Agile with additional project management governance relating to the infrastructure transformation. The business processes were time critical, with process dependencies at each step. Each sprint had key features/deliverables that were mandatory for that phase.

Dress rehearsals were a key part of risk management. They highlighted 90 additional issues that were not discovered in testing, and 45 were resolved before go-live. One of the issues relating to the timing of a critical BAU process. The deadline for completing all BAU activities would have been missed on the first day of go-live. The error didn’t show up in UAT because of assumed timings. When the complete process was run end-to-end during a dress rehearsal, the issue was discovered. The matter was resolved, and there were no issues with the timings after go-live.

Now let’s take a look at some projects that had to be rescued and the reasons.

Project example – Reluctance to document integrations

An organisation implemented a major transformation project that included new integrations with associated data mappings. The team was reluctant to document the data mappings or integrations because they were following Agile and quoted the Agile Manifesto every time the issue was raised.

The integrations took considerably longer than expected, with the resulting delay in cutover to the new system.

They were also reluctant to document the configuration for the support team and referred to the Manifesto again. The support team made their position very clear: ‘If you don’t deliver the information, how do you expect us to provide support?’ 

The key learnings for the organisation from this project were a deeper understanding of the Agile Manifesto and the importance of communicating with everyone involved in the project, especially the support team you are going to hand over to.

Note: When the manifesto refers to comprehensive documentation, many IT professionals believe this refers to the 300-page requirements documents that were common at one point on Waterfall projects. I think we’ll all agree that such documentation is not required on an Agile project, but it doesn’t mean that a project team doesn’t do any documentation.

Reluctance to Plan an Agile Project

Let’s start by dismissing one of the greatest misunderstandings of Agile; that it doesn’t include planning except for the current sprint. This is not correct, and people that argue otherwise probably haven’t worked on major Agile programmes. 

If you have been involved in rescuing a failing Agile project, it’s not uncommon to hear statements like, ‘We are Agile; we don’t do planning,’ and ‘I haven’t prepared a roadmap; this isn’t a Waterfall project.’ 

Common issues with the lack of planning and preparation of a roadmap include:

• Short-term sprint planning that does not align with the strategic business objectives.
• Challenges in delivering features on time. This dilemma is especially evident when you are managing a major project with sprints that span two or more years.
• Lack of visibility for critical dates. The infrastructure, data, security, and other teams that the Scrum team relies on require advance notice of the dates they need to deliver. It’s not uncommon for complex infrastructure builds to take weeks or months. The teams will not appreciate you notifying them on Friday that you need another environment on Monday that includes data that replicates production data. The likelihood of this happening is very low.  
• A short diversion – there was a giant sign on the back wall of the test suite of one of the leading UK banks. It read, ‘Lack of planning on your part does not make an emergency on my part.’ When people made an ‘Emergency Friday afternoon’ request, the team responsible for building the test environments would point to the wall and then start the discussion to agree on a reasonable plan. 
• As part of the development iterations, consider updates that will be required to ensure that the tests are valid. This includes updates to APIs, environment components, security configuration, data, data mapping and possibly many others, according to the specific requirements of your project.
• Include these requirements in the roadmap along with the cutover and go-live dates for all phases. 
• The roadmap should also include decommissioning activities. These activities usually have a long lead time, and it is not uncommon for them to be pushed back if a team is under pressure.
• There is debate regarding the level of detail in roadmaps. Some people believe it should be high level and cover key monthly or quarterly activities. My recommendation is to develop and maintain the roadmap to cover all the sprints in the project. This leads to greater clarity and focus, which helps keep sprint delivery, business objectives, and IT dependencies aligned.
• If you need to summarise the roadmap at a higher level for management reporting, it is easy to do with a roadmap that is aligned with the sprints. 
• Another planning consideration is the type of environment you are working in. If it is a regulated environment, include any specific requirements in the sprint planning sessions and remind the team of them during each meeting. Some regulators require separation of development and test functions. Take such factors into account when planning the sprints, especially resource requirements.

Please note: Some regulators may not approve the use of any application developed using Agile. Scrum for Safety may be acceptable in some regulated environments, but ensure you have formal agreement from all stakeholders before deciding to use any Agile framework on a project subject to regulation. 

Estimating an Agile Project

There are a number of different approaches when estimating Agile projects. It is critical to remember that, on average, activities take over twice as long as expected. This was highlighted by a research project by a leading UK university. They reviewed actual time against estimates for a number of industries and found that people tend to underestimate both effort and elapsed time for activities. Please factor this into your plans.

• Estimating – There may be some debate on projects about timing for completing estimates for the backlog items. I’ve found that it is beneficial to estimate them as early as possible and as far forward as you can. This allows you to sanity check the total effort required for each phase and the complete project at an early stage in the lifecycle. It also highlights areas where there are unknowns. For instance, the team may be working on sprint one while implementing a new API in sprint four. There may be a high level of uncertainty about the effort required to implement it. By looking forward, you can identify the unknowns and gather additional technical information.  
• This improves the accuracy of the estimates and helps mitigate delivery risks.
• There are different methods a team can use, including T-shirt size, points, affinity mapping, dot voting, bucket systems and others.
• Dependency management. This is an area where Agile can be weaker than other methodologies. An example of this is developing a feature that has a dependency on infrastructure components; therefore, it can’t be tested before the infrastructure component is deployed. Include people from the infrastructure security and data teams as required in the planning meeting. The product owner will update the business stakeholders but also consider wider comms and invite someone from the communications team if appropriate.

Just Holding a Standup Does Not Make an Organisation Agile

One of the most frequent issues seen on failing projects is Agile not being used properly. Doing nothing more than holding a standup each morning does not mean that an organisation is following Agile methodology.

Deliverables

Regardless of methodology, agreeing on and tracking deliverables is key to managing a successful project. Whether it is the deliverable from a sprint in Agile or a milestone in a Waterfall project plan, stakeholders will require updates on progress. Understanding, tracking and managing dependencies between deliverables is essential.

User and Stakeholder Management

In some Agile frameworks updating stakeholders isn’t a high priority, but it can be critical. Please consider this scenario:

• A team is delivering a business-critical application with a deadline of two months. Best practice would be to update all stakeholders at the end of each week in this case.

Delivery Date Information

It isn’t uncommon to hear that the only information available is the sprint completion dates, not the contents of the sprints. This isn’t correct and it may contribute to project failures. A sprint should contain features that will be delivered, and if a critical feature isn’t going to be included, the product owner should review this with the team, analyse the impact and update the relevant stakeholders. 

On a project that had to be rescued, the team said that they were following Agile and the content of the delivery depended on the quality assurance process. Therefore, they could not confirm the deliverables until the day before the release. This was not acceptable to the senior stakeholders, and changes were made to provide advance notice and assurance of deliverables in each sprint.

Common Misunderstandings about Agile

On many programmes misunderstanding the Agile Manifesto and principles were major contributing factors that resulted in project rescue.

Agile Manifesto 

The Agile Manifesto was created in 2001. It describes the four principles of agile development:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Manifesto for Agile Software Development (agilemanifesto.org)

There’s an important point to consider. Many people misinterpret the principles in the Agile Manifesto, and this can have serious implications for projects. They mistakenly assume that the items on the right are not important (or don’t apply at all) on an Agile project, but their assumption isn’t correct.

The Agile Manifesto's principles prioritise the items on the left, but the ones on the right are still included. They are important, and the degree of importance depends on:

• The complexity of the project.
• The type of project. (Does it include new infrastructure, dependencies with other teams and complex data mapping?) 
• Scope of delivery.
• Number of people on the project and number of teams.
• Contract negotiation based on the scope of activities and responsibilities of third parties.
• Requirements for post-go-live documentation. 
• Processes and tools definitely have a place in Agile. Test automation is one example.

Another common comment is that plans aren’t used with Agile. A plan is recommended if you are working on a major transformation programme that involves:

• Significant business change.
• New infrastructure.
• Complex dependency management.
• Data extract, transform and load. (ETL)
• Integration build.
• Data warehouse and data lake builds.
• New security configuration.
• Third-party API integration.
• Communication to the entire organisation.
• Application updates from third-party suppliers during the programme.
• Data mapping.
• Decommissioning legacy systems.
• Business and technical architecture activities.
• Programme risk management.
• Third-party security testing.

This does not diminish the value of Agile on the programme, especially for the development, but an overall plan will usually be required to coordinate this level of activity.

Agile Principles 

The following 12 principles are based on the Agile Manifesto.

1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. People in the business and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

12 Principles Behind the Agile Manifesto | Agile Alliance

Agile Best Practice in the Real World

For best practice, please consider the following:

• View your project holistically and enhance Agile as required.
• Give very careful consideration to managing dependencies and ensure you have the appropriate processes and tools (including project plans) to manage them.
• Ensure that everyone on the project understands the Agile Manifesto and principles. Items on the right have value, and the value tends to increase on large, complex programmes.
• Governance, when managed properly, does not reduce the effectiveness of Agile.
• Planning is an integral part of Agile. Real-world projects must deliver product features to the business on agreed dates. This is impossible without sprint planning.
• Training is critical. On many projects that were failing, the main activity was a standup each morning. Just holding a standup does not mean that an organisation is using Agile!

Please use the contact form below if you have any questions or would like to discuss any training, coaching or mentoring.