When Should You Use Agile?

 

NOTE:  Going forward, when using the word Agile to represent the several methodologies and frameworks associated with Agile, I will use the phrase "flavors of Agile," unless I am quoting someone.  If I am talking about a specific framework or methodology, I will identify it by name, i.e. Scrum, Kanban, and so on.

I was recently asked, "Which projects should you use Agile on?"  I'm not sure if my answer was satisfactory, so I thought I would address the question in more detail, here.

For starters, you should always use the Agile principles that apply to your project, even if you're not using a specific flavor of Agile.  (See my previous post for further explanation.)  There are several variables that need to be considered when evaluating when to use a flavor of Agile.

1. Is your organization already using a flavor of Agile?

If your organization is already using a flavor of Agile, the question of when might be out of your control.  If you're not using it for every project, you should have specific guidelines for determining when to/not to use it.  One of the basic guidelines should be whether the project would benefit from or be hindered by iterative development.  Don't assume that just because you have been successful with one flavor of Agile that you will be successful with another.  You're headed toward organizational change, and it doesn't always work that way.

2. Do leadership and non-IT components of your organization understand and support Agile processes?

If your organization is not currently using a flavor of Agile, this is a must.  You must have top-down and lateral support.  If 'Going Agile' is just an IT initiative, you will fail.  If the experience is too painful, people may never want to hear the word Agile again, even if the failure was caused by others not understanding the benefit of the specific flavor of Agile or how it works.

You also need to make sure that everyone using your flavor of Agile is trained on how to participate in it and what to expect from others.

3. What is your company culture?

Does your company embrace change and face organizational issues head on?  Switching to a flavor of Agile is an organizational change, and you will have to face organizational issues in order to change successfully.  The first time one of your teams uses a flavor of Agile, it will be bumpy.  If you're not prepared for bumps, and if the organization cannot handle bumps, it would be an understatement to say that adoption will be difficult.  When working on a large CRM implementation, overseas, I found myself regularly telling the team, "Remember, it's not about whether or not we encounter issues, it's how we deal with the issues that matters.  There will be issues; it's up to us to make this successful."  Are you ready to be a cheerleader?

4. How much is known about your project?

Do you have a strong understanding of the complexity of the project and how complicated the work is, when looking at requirements, technology, and process?  If it is a well-defined and/or simple project, you may not realize any greater benefit from a flavor of Agile than you would from Waterfall.  As details become more vague and the project begins to take on more of an exploratory feel, a flavor of Agile becomes a stronger candidate for success.  As you foray too deeply into the unknown, you may find your time better spent adding a little more definition to your project before choosing a methodology for how you will execute it.

5. What type of project is it?

1. Hardware or software roll-out (internal or third party) - You might be able to use a flavor of Agile if this includes software development, but COTS (Commercial Off The Shelf) rollouts tend to be straightforward (at least on the surface), with little room for iterative discovery.  Changes may go into sprints and releases, but you may be looking at an Agile influenced (hybrid) release management process, as opposed to a flavor of Agile.
2. Process change - This is not a strong candidate for a flavor of Agile.  As noted in a previous post, Scrum is not used to roll out Scrum in an organization.  Organizational change, while it may be progressive, leans toward linear change, as opposed to iterative.  This is not to say that nobody has ever made this work; it's just not a strong candidate.
3. Software or Product Development - These types of projects are often good candidates for a flavor of Agile.  Just keep the above information in mind, as well.
4. Researching/Prototyping - Discovery-type projects are the strongest candidates for a flavor of Agile.  Being able to learn, adapt, and repeat is an important part of these types of projects.

Am I missing something? Probably.  Feel free to share in the comments.

It seems like the next question should be, "What are the flavors of Agile, and which should I use?"  I'll need a little time to prepare answers for that.  Scrum and Hybrid seem to be getting the most attention, lately, but I'm not convinced that it is that simple.  Give me a few weeks to gather my thoughts on the matter.

Need free PDUs?  I'm going to let PMZilla keep you busy for a while.  I haven't checked the links, yet, but the page lists 24 ways to earn from 0.5 to 30+ PDUs.  If I come across anything significant NOT on this list, I'll let you know.