Since I joined Scott Logic I’ve worked on three separate teams which have, in one way or another, made a transition to Agile. This has meant either introducing development processes such as Scrum, technical practices such as TDD and iterative development, or indeed both. On top of this I’ve always tried to bring an Agile mindset to the development work I’ve been involved in, as well as promoting this approach within Scott Logic as a whole. This has involved trying to spread an understanding of the principles behind the Agile Manifesto, and encouraging teams and developers to refine their own best practice based on this.

Scott Logic has recently introduced Assured Agile which aims to make the introduction of Agile a more standard part of our engagement with clients. This leaves me feeling like this is a good time to take a closer look at how we work with clients to transition them to Agile. I have a habit of second guessing everything I write though, and the first question that comes to me when planning to write about transitioning to Agile, is why do it at all? So in this blog post I’m going to have a look at why I think we should be encouraging clients to transition to Agile, and in a couple of follow up posts I’ll look at the different approaches we can take, and how different clients will affect how we transition to Agile.

Why do I think our engagements should be Agile?

Introducing Agile development to a non-Agile company or team is widely regarded as a risky and difficult process. It involves a huge amount of change, and inevitably there will be people within a company or team who resist that. As a consultancy firm it would be far easier to adopt the client’s existing process and work within that. In many ways it would make sense to do exactly this. After all, if clients aren’t aware of Agile methods, then they won’t know what they are missing. We could then do a good enough job to satisfy our clients, even if we aren’t developing in the best possible way.

So why do I think we should continue to encourage Agile as the best approach for developing software?

My experiences tell me Agile is better

In my time at Scott Logic and with previous companies I’ve seen a mixture of Agile methods and more traditional approaches used.

I’ve worked in an inexperienced but Agile team, which quickly developed features relevant to our customers. Alongside this team worked a group of hugely experienced, but traditionally managed developers who spent their time doing little more than battling through their backlog of bugs.

I’ve seen a client with no experience of software development who was amazed at the progress placed before him at the end of every two week iteration.

And I’ve worked alongside developers who have become enthused with their work, when they realise they actually have control over what they do and how they do it. Developers who have worked for years knowing that they weren’t doing things the best way, but never feeling like they have the power to change it.

All of this leads me to believe that Agile is the right way to develop software.

The evidence suggests Agile is better

Measuring the success of software projects has always been seen as a difficult task. In an Agile team, gathering evidence of the effectiveness of certain practices is seen as a key part of improving those practices. As a result several companies have put work in to measure the effectiveness of Agile as a development methodology.

One of the key groups involved in analysing the success or failure of development projects and the reasons why, are The Standish Group who produce the annual CHAOS report. This analyses tens of thousands of projects, looks at whether they succeeded or failed, and why this was the case. The 2011 version of this report indicated that the failure rate for Waterfall projects was three times higher than for Agile projects. The 2013 version of this report analysed the reasons for this concluding that Agile made it easier to break large projects into smaller projects due to the iterative development processes commonly used. By building iteratively, and releasing early, Agile projects discover early if they are not on track. They can then adjust to compensate. This ties in to the single factor which the CHAOS report considers the most important in a successful project, customer collaboration. Customer collaboration is one of the four core principles of Agile, and customer collaboration is the leading factor in determining the success of software projects.

Yahoo! went through a well documented and very successful transition to Scrum beginning in 2004. As part of this they tracked progress by following the perception of the developers towards the work they were producing. 64% of respondents considered that the business value of the work under Scrum had increased, with only 2% thinking it had decreased. In the years after the transition over 80% of respondents to their survey wanted to continue using Scrum.

Salesforce also completed an incredibly successful transition to Agile in 2007. They had similar results to Yahoo! in terms of developer satisfaction, with 92% agreeing that they would recommend Agile to others. The proportion of their work force having “a good” or “the best” time increased from 40% to 86%. They also measured an increase in productivity, with features released per developer increasing by 38%.

Scott Logic’s clients are already paying for our expertise in Agile

Clients often expect to provide Business Analysts to decide what work should be done, Technical Architects to decide how it should be put together, and Testers to ensure everything works at the end. Agile promotes cross-functional teams that contain all of these skills. Rather than employing developers purely for their coding ability, Scott Logic recruits and trains rounded engineers who can fulfil all these roles. If the client uses a staged, Waterfall approach, then they will not typically be getting the best out of the developers they are employing.

As well as this, part of what clients are paying for is Scott Logic’s expertise in software development. As well as the ability to write software, a key part of this expertise is understanding how software is written. I feel we would be short changing our clients if we did not share that expertise with them.

I enjoy working in an Agile way

One of our teams was recently supplied with a tester by the client to test the software they had been developing for the past few months. They immediately contacted her, walked her through the project, and asked her about the approach she would take to testing, as well as how she would like to test the work they were developing going forward. In short, they included her in the development team. The tester was delighted that so much interest was shown in her. She was used to being handed software by developers, who would usually be resentful as she would find bugs in software they considered finished. Her delight fed back to their satisfaction in the work they were doing for the team.

This is a common feature of Agile teams. The close collaboration between all stages of software development results in software being more fun to develop. Having other developers care about your work, not just when it’s finished, but as you develop, is a great feeling. I imagine most developers will be familiar with the feeling of spending several hours stuck on a problem one afternoon, only to solve it in minutes when you look at it with fresh eyes in the morning. In an Agile team you constantly have a group around you willing and able to provide that fresh set of eyes, to stop you getting bogged down in the first place.

On top of this there is the satisfaction that any professional gets from doing high quality work. My experience of Agile teams is that they produce higher quality work, with fewer bugs, and this is a great source of pride to me. Having someone else put in charge of the way I develop usually results in that person asking you to cut corners to get work done to a deadline. This is hugely unsatisfying.

All of these factors make us feel like it is worth taking the risk and trying to sell Agile to our clients. If they are not keen then we need to be willing to work with that. Buy in is an important part of Agile, and if our clients are not keen then there is no point in pushing them. But as far as possible I think we should try to work in an Agile way with our clients. In the next part of the blog, we’ll have a look at how we might go about introducing Agile to our clients.