In my previous post I looked at why I think we should be transitioning our clients to Agile. Having decided that we want to help our clients work in an Agile way, the next thing to look at is how we approach this.

My first instinct when thinking about introducing Agile is to take it step by step, introducing new technical practices and process improvements as they are needed. Continuous and incremental improvement has always been a key part of Agile, so extending this to introducing Agile seems to make perfect sense.

How this works

The key part of this approach is not to put too much upfront work into it. We can mention to the client that Agile development is part of our expertise, but there is no need make a big deal about changing things from the start. Instead the idea is to work with the client, introducing ideas as they become relevant.

For developers, this will often focus on technical practices. So if there are a number of bugs appearing in the same area then it would make sense to encourage developers to unit test and refactor that area prior to changing it further.

For other roles this is likely to be more related to process change. So when working with a project manager who works by defining work, breaking it down, and then parcelling it out to individual developers, it would be a good idea to introduce the concept of self-organising development teams. Self-organising teams let the project manager define what work should be done, but lets the team decide how to do it. The team is typically best placed to decide the best way to complete work, and will be most motivated if they are given the freedom to do so. This also frees up time for the project manager to focus on generating business value.

It isn’t important to make a big deal of these practices being Agile. Whilst they may be practices that are described as Agile, the important thing isn’t that they are Agile, it’s that they work.

The benefits of this approach

Introducing individual practices over the course of a project removes the risk of encouraging Agile upfront. Whilst we may be convinced by Agile, our clients might not be. Introducing individual practices as they become relevant is less problematic, as they will be introduced in order to solve a particular problem on the project.

Following this approach also allows our clients the time to get properly familiar with the practices that we are introducing. It is easy to forget how big a mindset change is involved in moving from more traditional methodologies to Agile based methods. Pair programming is a great example of this. It is a very simple concept to explain, you have two developers at a computer, one typing, one observing, and you swap occasionally. Making it work in practice is a very different matter. How do you stop the observer drifting off and checking his phone? When is it appropriate? How does it relate to test driven development? All these questions are best answered by day to day coaching of developers, rather than just introducing pair programming upfront.

Alongside getting more familiar with practices is the idea that not all Agile practices are appropriate for every situation. Agile does not have a one size fits all policy. Introducing practices slowly gives time to see what works, and adapt practices to the constraints that the client faces. Introducing practices as we work will inevitably be more effective for technical practices than process changes. We commonly work as part of larger client teams, or have our own teams supplemented by developers from the client. This means we are working on a day to day basis with client developers. This is the ideal format for introducing technical practices.

Weaknesses of this approach

The flip side of this of course is that we do not typically get to spend as much time with the client’s project managers, so process changes are harder to introduce. Traditional processes do not typically have process improvement built into them, so if we are working with a traditional process, changing that process is more difficult.

Alongside the difficulty of introducing process changes, the other major disadvantage of this approach is that it is difficult to introduce the mindset change behind Agile. Often lost behind the vast array of Agile processes and practices is the fact that Agile really is just four core values. Introducing Agile as a set of practices may mean that people miss out on why those practices are important, and when you should apply them.

This risks two things. Clients may reject certain practices as it is not immediately clear why they are important. As an example, one of the benefits of pair programming is that the interaction between the developers creating a feature will likely result in a higher quality feature that provides more value to the customer. It will however often make individual features slower to develop. A client may see this and choose to reject pair programming as a result, costing the project down the line.

Also, clients may also stick to practices because they are “Agile”, rather than because they are beneficial, being incredibly un-Agile in the process. Again pair programming provides a good example here. One of our developers whilst working for a previous employer was mandated to work 8 hours a day pair programming with another developer. The employer probably thought they were being very Agile, whereas in reality they weren’t at all. They were completely ignoring the fact that pair programming is only suitable for certain tasks, and developers do not work on those tasks 8 hours a day every day.

Experiences with this approach

This approach has had mixed results. Progress can sometimes feel slow, but this is inevitable as we are introducing a radically different way of working to our clients. As mentioned, this approach is far more effective at introducing technical practices than process and mindset change. This sometimes adds to the feeling of a lack of progress. It is possible to succeed in getting daily stand ups, retrospectives, code reviews and pair programming in place, but still not have the team working in an Agile way. In other words, you can use as many Agile practices as you like, and still not be Agile, as Agile is a mindset not just a toolbox or prescriptive process. This is something that introducing processes and practices in a piecemeal way tends to overlook.

On the plus side this approach allows projects to progress effectively whilst the transition occurs. The clients with whom we’ve tried this have always been incredibly happy with the work we’ve done, and the new practices we’ve introduced. There is often a recognition that we are introducing a better way of working, even if there is not a clear desire to push us to follow it through.

So whilst this approach is effective, and keeps our clients happy, there is a nagging feeling that more could be done. Next time I’ll look at an alternative approach which might have better results.