agile development

What is Agile?

Agile is a set of product development values, principles and practices based on incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Agile was developed in 2001 by a group of software development thinkers who got together to find common ground in their fight to promote better ways of developing software. This group included representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.

What emerged from this discussion was an agreement on a common set of values and principles that are the foundation of the new lightweight approaches to product development. This was the Manifesto for Agile Software Development which says:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

It’s important to note that Agile does not advocate abandoning the values on the right. These values do help you develop products it’s just that they have been overemphasized by most organizations.

“We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

We welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Many people think Agile is just a set of useful processes and tools. This is not the case. Agile is a set of common values and principles that the processes and tools have in common.

The practices themselves are evolving over time and new Agile practices such as Kanban are emerging. These practices should not be implemented rigidly because they are only a means to an end. You can and should select the practices you need and tailor them for your situation. As long as you’re sticking to the core values and principles you are still being Agile.

Conceptually Scrum is a subset of Agile and Lean principles and practices which overlap. Both Agile and Lean are in turn a subset of Systems Thinking.

The founders of Scrum acknowledge that Scrum was inspired by Lean Product Development practiced by Japanese companies such as Fuji-Xerox, Canon, Honda and NEC in the 70’s and 80’s. In the past few years this has been fully developed in Lean Software Development. Lean in turn is about seeing the whole system and understanding its assumptions and feedback loops which is explored more fully in Systems Thinking.

To help you learn more about Agile I have listed what I think are the classic texts on the field by subject. Start reading and try it out for yourself.

Traditional projects are developed in stages by specialised functional teams. These projects usually spend 60% of their time in analysis, design and planning and yet often go way over time and budget, reducing scope and delivering low business value.

Agile is a much better way of delivering projects and yet I often run into managers who are opposed to agile because they think it is an adhoc approach that requires an open check book.

But Agile isn’t an ad-hoc delivery process at all. Its something new. Agile takes the best of adhoc and waterfall to reliably deliver initiatives on time and on budget with high quality.

What is the evidence for those who haven’t tried it?

Case Study 1- Telco Projects

In 2007 I worked on a series of large projects for a large Australian Telco using a heavy Prince 2 waterfall process to deliver a billion dollar IT transformation. The CIO was famous for saying that it didn’t matter if the car crossed the finish line broken and burning as long as it crossed it on time. And true to his word, a broken, burning, descoped platform was delivered on time.

After our team delivered three large waterfall projects , the business asked us to deliver the most important features that had been de-scoped in the next three months before they lost their remaining budget. We estimated three new projects with our vendor using the usual waterfall approach and found that they would take 4 to 8 months to do. Since time was short I asked the business, the vendor and IT management to let me use an Agile approach to deliver as much as we could in the time remaining.

We delivered the first project in half the estimated time for 10% less cost than the waterfall estimate. We delivered the second project in 30% less time and 12% less cost than estimated with half the functionality deployed early. And we delivered the third project with 40% better results in 60% less time and 50% of the cost of a similar project done two years before. On average using agile on these projects increased the features delivered by 13%, reduced delivery time by 45% and reduced delivery cost by 33%.

Case Study 2- Ericsson Mobile Core

In 2009 Ericsson Mobile Core recognized that their established practices were failing. Projects were delayed. Quality was difficult to maintain. And even with the best project management oversight, they still had problems obtaining a believable picture of where they were.

For many years SAS used a waterfall methodology to develop the SAS Platform and implement new solutions for customers; but from 2005 SAS found that they were unable to keep pace with customers’ demands for new features. So in 2008, SAS decided to implement Agile to improve speed to market and trained over 2,000 staff.

In a 2013 paper Agile Adoption: Measuring its Worth SAS reported that teams that implemented agile have been more engaged, more productive, produced higher quality products and delivered faster. SAS found that the return on investment in Agile has been substantial irrespective of project size and length.

The 2011 IT Project Success Survey

Scott Ambler, found similar results in the 2011 IT Project Success Survey of IT industry professionals. The 2011 survey showed that Agile projects (iterative, agile and lean) are much more likely to be successful than traditional and ad-hoc projects. Respondents said that 67% of agile projects in their organization were successful compared to 50% of traditional projects.

Agile projects were more successful because more of them delivered a quality system, met stakeholders real needs, provided a return on investment and delivered on time.

Drilling down we can see that more than 70% of Agile projects were effective at delivering a return on investment compared to only 30% of traditional projects.

I’m a big fan of agile. I find it’s a faster, more flexible, higher quality, lower cost and lower risk way of working. I also find it a refreshingly honest and adult way of dealing with people. But I didn’t always think this way.

When I first started developing software in the late 80’s for EDS (now HP), most big software projects used a strict step-by-step methodology. We used an approach called Method/1 from Anderson consulting (now Accenture). It came in 20 white binders and was commonly known as methadone because it put everyone to sleep.

Lightweight agile software development methods evolved in the mid-1990s as a reaction against these heavyweight waterfall methods. In 2000 I switched from traditional requirements to agile User Stories and found it so much better.

In 2004, I worked at Seek with Dean Netherton who gently persuaded us all to implement agile and eXtreme Programming. On the job application and job mail project I managed we had a cross-functional team of developers, testers, a business analyst and product owner, daily scrum meetings, a feature backlog, progressive elaboration of requirements, automated unit testing, continuous integration and deployment, a project wiki and burn down charts. To my surprise and delight this was by far the smoothest, easiest and most successful project I’d ever worked on! Ever since then I have been reading as much as I can about agile, lean and systems thinking and implementing an agile approach whenever I can.

I am convinced that Agile will give you a much better outcome than the traditional ways of working that you’re used to.

Follow Blog via Email

Enter your email address to follow this blog and receive notifications of new posts by email.