My client, a New Zealand government department, is in the process of introducing Agile-Lean. They are currently in a trial phase to see if it is for them and during the early stages they'd like to run Agile and non-Agile projects in parallel.

Fair enough, but how to choose whether a project should be run Agile or Waterfall?

There are a few factors that are important for the decision and I thought other people in a similar context might find this checklist of things to consider useful.

A checklist

1. About the Project

• Are you delivering software? (Unless the organisation has a high Agile maturity Agile is not a good fit for e.g. infrastructure projects)


• Is there uncertainty around what you are going build?


• Is there uncertainty about the complexity of the solution? (If the work is entirely predictable, repeatable and/or has been done before Agile is not the best fit.)


• Do you want to have the opportunity to adapt to changing requirements and/or new ideas throughout the project?


• Is this a high risk project?

If you have answered yes to any of the above questions your work would be a good fit for Agile.

However, apart from the work there’s the people factor.

2. About the People

In order to use Agile methods you’ll need a team who can do the actual work.

Here’s a checklist of things to get right if you:

1. have an experienced Agile team


2. have people with Agile experience but not a team


3. are starting a new Agile team

a) If you have an experienced Agile team:

An experienced Agile team is a team that has worked together with the same team members for at least 6 months.

• Do any of your experienced Agile teams have the capacity to take on the work?

If so you’re ready to go ...

b) If you have people with Agile experience but not a team:

• Is the team able to co-locate? (If not do you know how to work around this limitation?)


• Are the team members full time?


• Is the team cross-functional and includes all skills needed to deliver the project?


• Can the Scrum Master or XP-style coach be full time?


• Is the Product Owner/Business Representative able to commit enough time to the project (2-3 days per week at least)?


• Will it be possible to involve end-users throughout the project?

c) If you’re starting a new Agile team:

In addition to the above you should also consider the following:

• Will the team be able to implement the necessary tools and practice changes to allow them to deliver fully tested working software every 2-4 weeks?


• Are all team members prepared to deal with pervasive changes to the way they do their daily work?


• Do your team members have the right personalities to enjoy working in an Agile team? (small egos, team players, open, honest, happy to learn new things, etc)


• Do you have a coach assigned or will have a coach assigned before the project starts?


• If you don't have a coach does anyone of the team have at least 6 months full time Agile project experience?

Summary

Context matters: I wrote this for the context of a large organisation that is delivering relatively big projects and faces a cultural change from command and control to Agile/Lean/Radical Management (why have we made this terminology mess? ;-)

I am aware that this checklist might not apply for other contexts but I think the essence of the project and people readiness check will be useful also to people in similar situations.

Overall the question of ‘is my project suitable’ is less important than ‘can I build an Agile team’. Having the right mix of people - skills and attitudes - is key to project success.

Update: A graphic version of decision tree

You can download the pdf version here.

UPDATE

A friend emailed me after this post: “Sadly the answer to almost every question from 2.b and 2.c is an emphatic 'No' at my company. Puts it all in perspective for me really ... never stood a chance. RIP Agile”

I felt his disappointment but on the upside at least now he knows why his attempts at introducing Agile weren’t successful and he won’t have to blame himself. It’s an indication that he either should find a different way of developing software or focus on creating a proper context. Maybe Agile isn't for his company right now. But maybe it’s only his starting point that’s different from what he thought.