6 Deadly Sins of Agile Implementations








In this series, the 6 Deadly Sins of Agile Implementations, Peter Cronin discusses the six reasons that can cause Agile implementations or transformations to go astray.

Has your Agile implementation failed to produce the benefits and results you were hoping, or had planned on getting? Maybe it seems to be going alright, but it’s not what you’d really hoped. Or maybe worse, everything has reverted back to the way it used to be, the Agile implementation or transformation has been ripped back out. There are six reasons that can cause Agile projects to fall short of expectations. The first reason is a failure to get management buy-in to the project or transformation.

1 – Failing to get management buy-in

The most obvious benefits of Agile are to the way that software teams work and develop code, but of course we’ve also got that commercial side of the business where we’ve got to sell something to pay for development, where we’ve got to have some plans, so that the multiple teams and individuals are coordinated towards a common goal… all of which butts heads with the Agile Manifesto (which is not in favor of focusing on plans or  contract negotiations).

This is where we can lose the management buy-in.

If going Agile is being driven by the development side of the business, the focus is on the benefit to the development teams, and it can sometimes feel like the commercial drivers of the company are being forgotten about.

From the management perspective they look at it and go, “We can see how implementing Agile will benefit the software development teams but…” It’s not that they think it’s rubbish, but there isn’t quite the buy-in and motivation necessary where management will feel compelled to leap into a huge transformation project. They understand it, and they understand the value, but they’re hesitant, usually because of those commercial drivers that Agile could but at risk, or fear, leaving behind.

Read more…

2 – Failing to implement Agile throughout the organisation

“Implementing Agile in one part of the business alone can actually do more harm than good to the business as a whole.”


Failing to implement Agile throughout the organisation can lead to a failed transformation entirely. This is our sin number two.

In most organisations, there are two countering focuses:

  1. Looking at managing and performing locally
  2. Looking at managing and performing globally

Individually, we tend to err on the side of locally because we know our local considerations well, and it’s easier to measure isolated performance.

Read more…

3 – Failing to manage the change aspect of the transformation

Has your Agile implementation failed because people are unwilling, or unable, to accept change? If you are not able to successfully manage the change aspect of the transformation, your Agile implementation is less likely to produce the desired outcome and is, therefore, unlikely to succeed. This is our sin number three.

When it comes to implementing Agile, you can put all the plans that you require in place, but in order for the change to be accepted, and ultimately adopted, you need people to act differently. In other words, you need people to change what they are doing on a day-to-day basis, so that they produce a different outcome.

Read more…

4 – Failing to Scale Agile While Momentum is Present

You begin a new change project. Understandably, there are some nerves, but, there is a lot of excitement in the air about the positive change that you can create for your business. However, despite all the excitement, what ends up happening is people become focused on obstacles, the Agile implementation slows down, and

any enthusiasm that people had for the change project is quickly squandered. This is our sin number four.

It is natural for people to resist change or at best to allow change to happen slowly over an extended period of time to maintain the status quo for as long as possible. It may be that they are concerned about potential obstacles or challenges, or worried that there will be too many significant changes happening all at once.

In situations like this, it is common to want to slow the implementation down, so as to take a ‘gently, gently’ approach and, in doing so, break down all of the steps into small pieces, and roll these out slowly. Of course, people’s enthusiasm and motivation for a successful project will drop because you are not getting any of the successes, or ‘wins,’ for the change early enough for people to get excited. It is all happening very slowly.

Read more…

5 – Failing to slay the sacred cows

Most businesses, regardless of size and history, have what we call ‘sacred cows.’ These are people, attitudes, equipment, systems, or other issues that people get defensive about when challenged. As a result, these are not fairly questioned or corrected and little, if anything, changes. To be considered a sacred cow, there must be some resistance associated with it. For example, if it is a minor thing, and an employee asks his colleague, “Hey! Why do we actually do this?” and the colleague replies, “Good point! Let’s stop doing it,” then it is not considered a sacred cow. There has been no resistance by anyone to stopping or changing the procedure.

Rather, sacred cows are those things that, when questioned, usually receive a response like, “Oh, we just do that around here,” or, “That’s just the way we have always done it.” You may even hear people say, “I don’t know. The guy who taught me how to do my job told me to do that, so that is what I am doing as well.” But, the thing is, if you do not challenge these phrases and ways of working, you are not transforming anything!

Read more…

6 – Failing to understand the value proposition of Agile

Should you ‘do’ Agile or ‘be’ Agile? Despite what some people believe, ‘doing’ Agile is not the same as ‘being’ Agile, and understanding the differences between these two concepts is crucial. On the one hand, if you only ‘do’ Agile, then you do not necessarily understand how the fundamentals of these methods and mechanisms can help your business. Accordingly, your knowledge of how to apply them effectively can be limited. But, on the other hand, does ‘Agile’ really mean anything in itself? How can you be Agile? This is our sin number six.

The ability to do Agile is usually something that can be picked up in a two-day workshop which includes basic Scrum and Kanban training. However, if you actually want to be Agile then you must do more than just apply the practices without trying to understanding the principles behind them. You need to live and breathe Agile principles and values every day. In a sense, being Agile requires a cultural shift to an Agile mindset.

Read more…


Beyond Agile

Pace:  a new approach to software development

In some areas of software development projects, we need to go back to being less agile, and more rigid and robust with our planning. In other areas, though, some of the benefits of Agile aren’t agile enough; we need to push to be even more agile. For example, sprints in many cases are planned off what the team’s capacity is. A sprint aims to get x amount of work completed in a certain amount of time, i.e. 10 days’ worth of work completed by the team in 10 working days.

Pace is an approach to software development that has emerged as a solution to the negative side effects of the Agile approach. It’s not a radically, out-of-nowhere, different approach from Agile.

Rather, it’s much like the previous ‘evolutions’ of methodologies in the software engineering industry, where it seeks to address unresolved challenges.

Read more…