Getting to grips with Agile

Edward Scotcher, director at Agility in Mind, runs over the basic ideas and methodology behind Agile

If you’re working with an IT delivery team in one way or another you will have heard of Agile. People have strong opinions about it. Some people love it, some people think it is a passing fad. Either way, it’s a feature of the landscape that delivery teams work in so it’s good to know what it is. In itself, the word Agile is no more than an umbrella term for a lot of tools and techniques that allow us to build responsiveness and flexibility into software delivery as it progresses. This is in contrast to trying to guess the future and lock it down before we start, which is the common feature of traditional or "waterfall" ways of working.

Where did Agile come from?

In IT, change happens fast. The industry is continually evolving, with new technology and tools giving us exciting ways to develop products that were previously unfeasible. As a result, a product being planned now that is set to go into development in a year and be delivered in two years' time, is likely to be woefully out of date by the time it is shipped. Change will happen, regardless of what we have planned. Understanding this, in February 2001, a group of practitioners met to discuss how they could build into the process the ability to respond to change during development. The resulting principles were made into a document called The Agile Manifesto. This helped bring Agility into the mainstream and gave credibility to a number of Agile project management frameworks that embrace the ethos of the manifesto, such as the Dynamic Systems Development Method (DSDM), Scrum and Extreme Programming (XP), among others.

What does Agile do?

Agility favours various ways of working over others. Crucially it supports the belief that individuals and the interactions between them are paramount to getting work done. This means getting software development teams to work collaboratively with their customers, continually getting fast feedback to help guide the direction of a product. Being able to respond to changing demands as the product is developed means that you are more likely to deliver what the customer wants to use and enjoys using.

This collaborative way of thinking that Agility promotes is only one part of the story. The other key area is that of value delivery. Requirements on an Agile project are written in a format called "User Stories" and are kept in a prioritised shopping list of ideas, known as a backlog. These user stories are typically written on index cards so they are easy to re-­prioritise. Indeed, they should be continually monitored so the top, highest-­priority stories are always the ones being worked on by the development teams. The stories are prioritised by "value to the business" – meaning the most important requirements for the user, or business, are done first, and that the low value, low impact requirements are done last.


Whilst technology is in no way trivial to build, there is an understanding in Agile circles that the really hard issue to address is how to get people working together effectively. Fundamental to this is the role of the product owner, an individual whose job is solely to manage the scope, scale and vision of the product being built, someone who is there to represent the interests of the business and the customer. It’s a demanding and political role that sees them manage the requirements that the developers build products from. They work closely with a project manager who works with the team to help them deliver effectively and efficiently. This style of split product and process leadership leads to pragmatic and realistic decisions being made about what is achievable, so that timescales and scope are realistic, not idealistic.

Where does it work best?

Agile particularly lends itself to working in an environment where the inevitability of change is acknowledged and accepted. However, it is also good at delivering high customer value early, and also builds in the ability to get feedback – and therefore guidance – along the way. In turn, this means that if you start to develop a product and it’s not meeting the expectations of the users or customer, you can find out early so you can do something about it.

Agile projects are also quicker to get started, as they deliver incrementally, so that you can very quickly see what is being built and input into the process, gently guiding it in the direction you want. The impact of this means more than just helping the reality of the product stay close to your vision, it increases confidence that something is being done and helps you build better working relationships with development teams.

Organisations that have employed Agile tools and techniques successfully are spread across many sectors, such as not-for-­profit, government, media, banking, retail and publishing.

What next?

More than anything else, Agility is about involvement, interaction and collaboration with people. The best place to start your journey is by looking at Lean Principles and The Agile Manifesto. So, try them out and start using them, beginning with what you are working on right now.


Edward Scotcher is a director at Agility in Mind, a company that uses Lean and Agile principles to deliver better people, teams and products.