6 Deadly Sins of Agile Implementations: Value Proposition

August 5, 2020 | Peter Cronin

In the previous article, we discussed ‘sacred cows’ and how these can negatively impact your business’s momentum if not slain. In this article, we will look at the difference between ‘doing’ Agile vs. ‘being’ Agile, and how to resolve this common dilemma.

 

“To be specific, ‘being’ Agile is about living the principles and values of Agile, while ‘doing’ Agile is more about following the Agile processes to accomplish a task.”

 

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.

 

‘Doing’ Agile

Let’s start by exploring what it means to be ‘doing’ Agile. One of the problems that arise from only focusing on Agile as a methodology is that no two businesses are the same and neither are two teams necessarily the same. You might have a completely different way that you sell, market, or deliver software or it may be that you have a separate branch of the business that isn’t actually software-related at all. The ‘unique’ landscape of your business when one or more of these things comes together may mean that a ‘generic’ application of the different Agile techniques and benefits are not going to provide good value for your business.

So, carefully consider each of the techniques and methods that you are trying to implement, and ask:

  1. Why does that technique or method actually work?
  2. What are the effects that that technique or method is giving me?

 

“In some cases, Agile techniques and methods will go in and they will work well, but not great and, in other cases, they will get taken out as they don’t apply.”

 

When you start thinking about the effects that you want from your Agile implementation, you can then start being Agile by considering the best approach to delivering it to your business and its unique requirements.

 

Timeboxing Sprints

Sprints are effective for a number of reasons. One of the main reasons is that they are successful at lowering work-in-progress. When tasks are handled in ‘chunks’ of time, rather than given total focus until completion, the gross time spent on a task can be reduced significantly. By reducing work-in-progress, through the use of short and structured sprints, there is less multitasking, less picking up and putting down of tasks, and shorter handovers between resources. Setting the length of a sprint, or processes within a sprint, is timeboxing.

Smaller and smaller timeboxing means there is less availability for work that is being committed to suddenly be impacted by external changes and variation. Let’s say you are doing a four-week sprint and your customer requests tweaks to their design. The design would already have been in your sprint, and now you are making adjustments to something that has already been planned. So, the required tweaks cause minimal disruption.

 

‘Being’ Agile

So, this is how you start to be Agile. To be Agile, you need to step back from any methodology that you have and consider what the benefits of implementing Agile are and why it has these benefits. For this reason, it is important that somebody in your business has this fundamental understanding of Agile, and recognises why quality-improvement techniques like Agile work. Without this understanding in the business, nobody will be able to correctly apply these and the maximum benefit of the Agile implementation will never be realised.

Consider, also, your daily Scrum stand-ups. In many businesses, these have gone off the rails, and people are regularly heard saying, “Why do we even do these things?” Most of the time is spent talking about tasks that are being worked on! Why not spend this time more productively? You may, for example, use this time as an opportunity to update everyone, or a specific person, on when work will be ready, or clarifying handovers.

 

“What’s not being considered is the underlying effect of these mechanisms. You are wanting to jam something in, regardless of the structure of your business.”

 

If you have some work ahead of you after lunch, it makes very little sense to start on a large job that is going to take you all afternoon. Instead, you are better using the time to clear through a few smaller jobs, ready to receive the handover. As a result, work now moves faster through the system. This thinking underpins many of the other shortcomings we have been looking at throughout this series around why Agile transformations do not get the effect people wanted, or don’t produce the benefit they expected in their business, or both.

 

“Figure out the benefit of the mechanism and figure out how to change it and apply it to your situation so you can think Agile, be Agile, and implement Agile.”

 

Reassessing Timeboxing

The idea that an iteration of software is one week, or two weeks, or four weeks, is unrealistic! An alternative approach, instead, is to have a timebox based on each individual iteration. For example, “We want to do this iteration, or chunk of iterations, and we are going to do a few bug fixes amongst this, and this one is going to take six days.” Now, you have a six-day sprint. The next one is nine days. That’s fine, too! You can do that.

In most cases, businesses are implementing Agile as intended, by ‘being’ Agile. However, there are still some businesses that are ‘doing’ Agile. Don’t be one of those businesses! Instead, figure out why these techniques and methods are effective, and change these so that you can best apply them to your own business.