In my previous post we looked at introducing Agile at the start of a client engagement. Prior to that we had a look at making a slow transition across to Agile. There are clearly benefits and weaknesses to both approaches, and typically a blend of the two will be used. This allows us to make it clear the kind of changes that we want to make to the client, and the kind of impact it will have on the stakeholders, but to make the change in a way that will last and that will be supported by everyone involved. The exact approach used is heavily dependent on the specifics of the client engagement. Here we look at a few of the things that can affect our choices.

Technical practices vs process

It is important to be aware of who is involved in a transition to Agile, and which parts of Agile are relevant to which people. Self-organising teams are a key component of Agile. Self-organisation means that managers should be hands off as to how software is developed. This means that whilst the technical practices used in Agile are important, the specific practices used do not hold a great deal of relevance for the management team.

It is important however that managers are heavily involved in the choice of features which are developed. They need to be closely engaged with the development process so they know how to shape the end product. Similarly the developers must understand and continually refine the development process as it will affect their day to day work.

As we’ve discussed, it is easier to introduce major process changes upfront. As everyone needs to be involved in the process changes, everyone needs to be involved in those upfront discussions. When it comes to introducing technical practices, this is best done over the course of the project, and only really requires the involvement of developers. Assured Agile advocates the idea of a having a toolbox of Agile practices, where you pick and choose practices as they are appropriate. This fits nicely with introducing technical practices over the course of a project.

Working as an Agile team in a non-Agile company

This blog has worked on the assumption that we can successfully sell Agile to everyone involved in a project. It is important to understand however, that the influences on a project spread throughout a company. An Agile team will work best with an Agile accounting department who do not demand to know at the start of a year how much a product will cost. Similarly it demands an Agile marketing team who are willing to work with flexible release dates, or flexible feature lists. The size of many of our clients makes it unlikely that we will transition the entire company over to Agile, even if that is the ideal scenario.

It is widely accepted that the most effective Agile teams work within Agile companies, however even if this is not possible there are still many gains to be made with Agile. One of the ways of maximising this is to introduce buffers between Agile and non-Agile parts of the company.

A lot of the benefit of Agile comes from the quality of the work produced by self-organising teams. This benefit can be lost if the team is constantly hit by non-Agile demands from the business. As an example of this, developers may be unwilling to put proper effort into testing a feature if it has an excessively tight deadline. This will damage the quality of the project down the line.

In order to prevent constant interaction between non-Agile portions of the company and the Agile development team, you can channel these interactions through a buffer. This buffer is responsible for converting the non-Agile actions of the rest of the company into something that fits with the Agile team. This could involve converting estimates from the team about the size of certain features into projected completion dates for marketing, or prioritising the backlog to maximise the chance of different features being complete by the various deadlines demanded by stakeholders. The importance of this buffer is largely the reason that Assured Agile retains the project manager role. The project manager may well not end up doing much traditional project management, but they will often have to mediate between an Agile team and a non-Agile company.

In a general sense, the more interactions you have between an Agile team and a non-Agile company, the weaker the benefits you gain from Agile. In an ideal world you would not have to do this at all, but if you do the best way is usually to do it through a single buffer.

Team augmentation vs managed delivery

Team augmentation and managed delivery are both common services offered by Scott Logic. Team augmentation occurs when the client has an existing team that we need to supplement. Managed delivery is where we run the whole project internally and provide the whole team. There is also a range of scenarios in between, where the customer might provide roles such as project managers and testers, or even developers to augment our teams.

As the team is the key component of an Agile process, the makeup of that team heavily affects the success of a transition to Agile. When creating a team entirely within Scott Logic, from scratch, it will be relatively easy to get them following an Agile process. However it will be more challenging to transition when a small number of developers from Scott Logic are augmenting an existing non-Agile team. As mentioned previously, buy in from the development team is absolutely key when transitioning to Agile, so this must be gained prior to making any transition. If this is not possible then the transition should not be made.

Bought in client vs sceptical client

Buy in is a key part of the success of Agile, and something I’ve referred to throughout this blog. It comes down to the idea that something is far more likely to be successful if everyone is committed to it. If people are committed to an idea then they will go all out to make sure it succeeds, adapting as necessary to handle problems that arise. If people are sceptical of an idea then they will not make this effort, indeed they might not even fully implement the idea. This allows them to then be critical of the idea when it fails.

This is probably the single factor that most affects the chance of success or failure, and probably the factor that most affects our approach. One thing that Agile promotes, and that a bought in client will typically understand, is that failure is acceptable. Indeed failure should even be encouraged. Whereas a sceptical client might point out any short term problems as evidence that Agile doesn’t work, a bought in client will realise that experimentation, and thus failure, are a key part of the Agile mindset. This allows us to try out ideas with the client that we know might not succeed, but will be hugely beneficial if they do.

It is worth noting that most of our clients do have some awareness of Agile, and do have some interest in seeing it implemented. In many cases they will have some form of Agile process already. There is often a further step that they have to take, from having an interest in Agile, to understanding and accepting some of the implications of Agile. After all, it is perfectly possible to imagine a client who has heard of the success of Agile, and wants to see it implemented, and wants to retain complete control over the implementation, even if doing so would be un-Agile. This step from interest to understanding is one that we need to help the client make as smoothly as possible.

The ideal scenario

I thought I’d end with a quick look at what the ideal scenario is for a transition to Agile. What is it that will make a transition as successful as possible?

The first thing I would say is that a transition is more likely to be successful if a client approaches us about moving to Agile, rather than us pushing it on them. It is not uncommon for senior management to know about Agile and to be aware of some of the benefits, but not know how to implement it. Being approached regarding Agile removes the risk of clients being put off by the mention of Agile, and virtually guarantees buy in from senior management.

The next most important thing would be for the team to have a chance to meet prior to work beginning on a project. This would include all the developers on a project, as well as analysts, project managers and testers who will be involved. This would allow them to agree on the best way to work together, and make them feel like a team. In the ideal world any team members supplied by the client would be aware of and keen on Agile.

The final stage in the ideal scenario is running the project itself. Whilst there are a number of ways of running a good project, there are a couple of components that are absolutely key. The main one of these is close collaboration between team members and stakeholders. All the team members would work closely together, allowing them to deliver high quality software. Just as importantly though, all team members would work closely with the stakeholders, meaning they don’t just deliver good software, they deliver software that the client wants.

I’ve been fortunate enough to work on a project that looked an awful lot like this scenario, and I have to say, it’s hard to go back.