The Agile Approach


Why become 'Agile'?

Traditionally, projects have taken a sequential, step by step approach, starting with the gathering of detailed requirements, design, coding, system and user acceptance testing, bug fixes, and delivery. Lengthy review and approvals often need to take place too. Some benefits of this Waterfall approach are:

  • Agreement on what will be delivered, making planning and measuring progress more straight forward.
  • Customer engagement is not required after the requirements gathering phase, beyond reviews and status meetings.
  • Knowing the full requirement can allow for more careful design rather than a piecemeal design where new components are bolted on and made to fit.

The main negatives are:

  • Gathering requirements is often difficult, as users describe the system they already use, plus they find it hard to understand or visualise all of the documents that they are given to review.
  • Users tend to really understand the designed system towards the end of development, when it is difficult and costly to change.

Agile addresses these problems:

  • The customer has frequent and early opportunities to see the work being delivered, and introduce change as required.
  • A scaled back version of the product can be released early, with successive iterations adding more and more functionality.
  • The process is focused on the customer, bringing the customer into the project team.

But of course, there are disadvantages

  • The customer must be given time to be fully and continuously engaged. BAU must be given a back seat.
  • Piecemeal iteration may give need for frequent, wholesale redesign, to correct inefficient design made earlier.

In a world of rapid change and usually uncertainty in what we need to build, the reality is that we can't always afford long development cycles, for projects that may need to be scrapped and rebuilt later on.

The Agile principles

A short summary, encapsulated as a manifesto describes the culture of being 'agile' It states that we 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

The 12 Principles underlying this are below. Click on each one to understand what the principle actually means.

Agile vs Traditional

Agile is all about a set of values and principles, and being able to adapt and adjust. Waterfall projects might become fewer in number but how Agile we can be depends on how prepared the organisation is to change.

With traditional development, it can take a long time before something is delivered, but today we need to deliver faster and faster to gain or maintain a competitive edge.

Other Considerations

To help us decide which approach we should use, consider the following:

  • Requirements are constantly changing (Agile)
  • People such as developers and product owners are dedicated to the project (Agile).
  • People are distributed or located off-shore (Waterfall).
  • Continuous and frequent feedback is avaiable from the customer (Agile).
  • There are fixed costs, or any other restrictions (Waterfall).

Just because a characteristic tends towards Waterfall, think what might need to change to allow a more agile approach to be used. For physical location, video conferencing and teams that are dedicated to the task might mean that off-shore projects don't have to be Waterfall.

In order to improve speed to market, maybe a transforming organisation will break a big project down into mini-projects - or mini-waterfalls. It's not Agile, but at least faster delivery of working software is the outcome.

So to conclude, choose the best method for the project and organisation, but no matter which approach is taken, in the spirit of agile, do, learn, change. Become an agile organisation in increments if necessary.

Traditional v agile model
It might look it, but being Agile is not a series of mini-waterfalls.

Scrum and Kanban

Scrum and Kanban are the most commonly used Agile project management frameworks. Both place a high value on continual improvement, optimisation of the work and the process. Both are highly visible and keep everyone informed on what is being done and what is to come.

The key differences for each are:

Delivery Timelines
  • Kanban - Products and processes are delivered continuously on an as-needed basis.
  • Scrum - Deliverables are determined by set periods of time (sprints) in which a set of work must be completed.
  • Kanban - Team members can pick new tasks out of the backlog according to priority once they have completed a task.
  • Scrum - A number of tasks are 'pulled' from the backlog for each time boxed iteration (sprint).
  • Kanban - Changes can be made at any point, allowing for continuous improvement.
  • Scrum - Changes are encouraged only at the sprint review, and not mid-sprint.

The similarities are:

At heart, they both follow agile principles. Both methods use a physical or digital board where people move work between roughly three categories:

  • Work that needs to be done
  • Work that is in progress
  • Work that has been completed
Illustrative Kanban board
1) Visual signals / colour coded - Project and work items go onto cards and are clearly convey that they are being worked on. Colours can signify some relevant meaning.
2) Commitment point / To Do - A backlog containing project ideas will be picked up from 'To Do' and be 'committed' to complete
3) Columns / status - Each column represents an activity or status in the workflow. 'To Do', 'In Progress', or 'Done' is the simplest workflow.
4) Work in progress limit - Limits can be set in each column, and when reached, the team will 'swarm' to move them onto the next stage in the workflow.
5) Delivery point / done - This is the goal of each item of work. The time between commitment to delivery is the 'lead time'.

Shall we talk?

Lets have a conversation

If you would like to know more about how I've helped to transform some the world's biggest and well known businesses, across diverse industries in the United Kingdom, Singapore, and Hong Kong, then please drop me a line. Let's have a chat and I'll buy the coffee!

Multiple screens showing responsive web developement next to a hot drink for a meeting

Turn your idea into digital reality

Many of my clients requiring web design have been small or start up businesses and need a lot of guidance. I love these kind of projects as I feel I can be a part of a new and exciting business from the very beginning!

What can I call you?
Enter your email address
It would be nice to tell us why you are contacting us!
To prevent spam mail, enter the sum of the spam captcha