When should you use Agile?

Agile is a set of software development values, principles and practices that help your organization change more effectively. If you need to make any software changes then agile is simply a better way of making these changes than traditional methods.

Some people argue that if a project has a clear, fixed scope and solution then there’s no need to use Agile. I disagree. If the project scope and solution are fixed throughout the project then an agile project can substantially increase your return on investment by delivering incremental benefits early as shown in the diagram below.

Agile ROI

But project scope and requirements are never fixed throughout a project no matter how hard you try. That’s because software development isn’t like making widgets in a factory as many people think; it’s like designing a new car and the factory you need to build it in. In every software project we learn what the real requirements and solution are as we go and it’s not until the end that we understand them fully. Agile understands the need to learn along the way and helps you implement what you learn quickly and effectively.

The only time you shouldn’t do Agile is when you don’t have the capability to do it or the will to resolve the organizational blockers that Agile reveals.

Jonah Lomu rugby superstar leaves competitors in the dust

Jonah Lomu rugby superstar leaves competitors in the dust

For example, if your software project needs a new environment and it usually takes your organization six to twelve months to get one then your Agile project will be blocked in a few weeks. If your senior management are unable or unwilling to provide an alternative environment straight away then the project will stop. As a result any project that depends on a new environment would not be a good candidate for Agile.

Or, let’s say that your organization has a strict waterfall methodology and little experience with Agile. If you start your Agile journey on a multi-billion dollar program of work then you will probably fail because your organizations structure, beliefs, processes and policies will block your Agile program at every point. Agile can be done successfully on large projects using the Scaled Agile Framework or Disciplined Agile Delivery but this requires a high level of Agile capability that you won’t have to begin with. If you haven’t done Agile before you need to start on small projects and remove organizational barriers to progress before you move onto big projects.

Some critics have claimed that Agile is an evangelical fad that won’t work on large, complex, mission critical projects. These people claim that Agile is an open ended, time and materials approach with no clearly defined roles or requirements and no guarantee of a specified outcome for a specific price. The underlying assumption seems to be that Agile = Scrum = Adhoc.

These critics are wrong. The 2011 IT Project Success Survey shows that Agile projects are much more likely than traditional projects to deliver a quality system, meet stakeholders real needs, provide a return on investment and deliver on time and schedule.

Rather than being adhoc, Agile is a highly disciplined approach with clearly defined roles and requirements that can be tailored to your needs as you can see at NetObjectives Lean-Agile Pocket Guide to Scrum teams.

And rather than being open ended, Agile projects can deliver a guaranteed outcome for a specific price if required. In fact Agile projects are better at doing this than fixed price projects because Agile is faster, higher quality and more efficient than Waterfall.

When we do fixed price Agile projects at Kiandra IT we work closely with the client to understand the features (or epics) they want; we get the development team to size each feature (or epic) based on previous examples (with a contingency for risk); and then we work closely with the client to develop a roadmap to deliver the features in order of priority within the client’s time and budget. This roadmap includes a plan to release features every few weeks so that the client can get a return on their investment as soon as possible. If requirements change then we can substitute features of similar point value for the same cost.

In my experience, if you have the capability to do Agile and the will to solve the problems it reveals then you can benefit from using Agile on all your projects.

Advertisements

2 thoughts on “When should you use Agile?

  1. I think you’re right and totally agree with the contents on your post.

    When reading your analysis of what’s required for a succcessful agile adoption there’s one thing that you never mention: The team. You’re just focusing on the organisation around the team and how that organisation can support or block the agile team’s path to success. I think that’s right.

    With scrum and other agile methodologies I think that we as programmers have finally been able to take the step away from adhoc work with bad, unpredictable results. We are now more mature and can no longer be blame for every failed software project. With no obvious flaws to be found in the development team, the focus now moves back to where it should always have been: The organisation’s ability to interact with and support a development team.

    For decades, software development has been a blame game where we as developer has lost most battles. With agile, the tides have changed and we can now finally help the business side to understand their role in a project. With clear communication and acceptance criteria for when a story is ready for development we can help them understand that without their commitment and hard work nothing will work in the end.

    Requirements are as important as ever – but it has now been made more obvious thanks to agile development processes that actually work. Now it’s time for the business side to take the next step, if they don’t, we’re facing an even deeper Product Owner Crisis as agile helps development team mature.

    • Thanks for your input Anders. In my experience Technical teams are well aware of the problems with waterfail and are keen to do things a better way. They just need to be give permission and a bit of coaching on agile and they will be on their way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s