Is Agile for everyone? Do you think it’s right or best for every project? Or does it have some best fit scenarios? Furthermore, is it right for every industry or for every organization or even for every project manager, business analyst and tech team?
When a company or team make the big decision to shift to Agile development and project management practices, no one says it’s going to be an easy transition. New developers coming in might already be trained or might make an easier transition to new practices. But the current staff of project managers, techs and other developers who have always been doing it ‘another way’ may have a much more difficult time modifying how they think about projects and development efforts and rollouts in general.
When an organization is shifting to Agile practices, existing developers often raise concerns. Will they be productive in a changing and shifting workplace? Everyone is wondering how they are supposed to write code in an environment that involves shifting requirements and there seems to be little or no architecture. These concerns are legitimate and need to be addressed... no question. And they may be big enough to say that the Agile shift is not right for you or that organization now or ever. It depends. Let's consider five reasons that Agile may not be right for you or your organization now or ever... let's discuss and be thinking about comments or sharing your own experiences from a workplace that shifted successfully or unsuccessful or didn't make the shift for whatever reason after considering the change....
You run mostly low tech or no tech projects. Agile seems to be best for higher tech projects. The best projects for Agile are those that have aggressive deadlines, a high degree of complexity, and are unique … meaning you don't have a revolving door of the same type of project on every customer engagement. High tech projects tend to fit this description best and if these are the type of projects you are running, then by all means... go Agile. If you never run these types of projects, then you likely don't need Agile – at least not at the present time.
You or your organization resist change. If you're mostly “old school” and currently full of project managers and techies that are used to things the way they are and seem to always resist change, then you have a big choice to make. Slowly (or rapidly) get rid of everyone and replace them with staff that will buy in to Agile or are already “Agile” ready. That is going to be your fastest way for adoption, but also your most expensive and time consuming. So it may be best to just shelve the Agile conversion for now – sounds too much like a lose-lose for the organization.
No one in the organization or PMO is PMP certified. This isn't necessarily a show stopper. But it can can be very difficult to sell a completely Agile environment and workable project methodology without having a basically PMP certified project management office and staff. PMP means dedication. It means a proven process. It means repeatable processes. It means discipline, success and a common language. If you go to a client and bid on a project with a completely uncertified staff, then it will be very hard to win that client. Not everyone in the PMO needs to be certified, but there are going to be certain clients that will need to hear “Agile” and “PMP” used in the same sentence... guaranteed.
The requirements for most of your organization are both static and well-defined. No doubt Agile works best on a project that really needs it. And usually that is a project that has somewhat vague or changing requirements. Or uncertain requirements from the beginning. Or several phases that the client would like to have rolled out individually. In all of these scenarios Agile is an excellent choice.
I am still of the mindset that with all other things being equal, Waterfall is the way to go. If there were never going to be any sliding or changing requirements and everything is well defined and low-risk from the beginning, then it's very hard to argue against Waterfall. But a project without some change is unheard of. Waterfall can still be the best approach. But if you start to invite lots of requirements uncertainty or requirements that have to change and be defined along the way and a solution that needs to be rolled out over time with growing functionality, then Agile is always going to be the way to go.
Never need phases rolled out early on any projects. I've already touched on this a bit above. If you are managing very standard (boring?) projects that never need early functionality rolled out to the public or end users or whoever that user audience is, then you probably never have a need to make the big conversion to Agile. Depending on the organization, the change won't be fast or easier or without some turnover of sometimes good, experienced personnel. So don't do it if you don't have to. Never do it just to call yourselves “Agile.” Bring an Agile class in house and then call yourselves “Agile” even if you aren't leading any Agile projects … ever. It's a good thing to have in your hip pocket, but you don't have to fully convert if it's not necessary. It won't be free or painless.
Summary / call for input
These are just five potential reasons why Agile might not work for you or in your organization from a development and project management standpoint. Are there others to consider? Most definitely. But these are five key ones to look at first – at least from a high level.
Readers – what are your experiences? Do these reasons make sense? Have you been part of an organization that shifted to Agile? Did it work? What were the pain points? Did it fail or did you shelve the entire process after considering the pros and cons? Please share your thoughts and experiences.
When a company or team make the big decision to shift to Agile development and project management practices, no one says it’s going to be an easy transition. New developers coming in might already be trained or might make an easier transition to new practices. But the current staff of project managers, techs and other developers who have always been doing it ‘another way’ may have a much more difficult time modifying how they think about projects and development efforts and rollouts in general.
When an organization is shifting to Agile practices, existing developers often raise concerns. Will they be productive in a changing and shifting workplace? Everyone is wondering how they are supposed to write code in an environment that involves shifting requirements and there seems to be little or no architecture. These concerns are legitimate and need to be addressed... no question. And they may be big enough to say that the Agile shift is not right for you or that organization now or ever. It depends. Let's consider five reasons that Agile may not be right for you or your organization now or ever... let's discuss and be thinking about comments or sharing your own experiences from a workplace that shifted successfully or unsuccessful or didn't make the shift for whatever reason after considering the change....
You run mostly low tech or no tech projects. Agile seems to be best for higher tech projects. The best projects for Agile are those that have aggressive deadlines, a high degree of complexity, and are unique … meaning you don't have a revolving door of the same type of project on every customer engagement. High tech projects tend to fit this description best and if these are the type of projects you are running, then by all means... go Agile. If you never run these types of projects, then you likely don't need Agile – at least not at the present time.
You or your organization resist change. If you're mostly “old school” and currently full of project managers and techies that are used to things the way they are and seem to always resist change, then you have a big choice to make. Slowly (or rapidly) get rid of everyone and replace them with staff that will buy in to Agile or are already “Agile” ready. That is going to be your fastest way for adoption, but also your most expensive and time consuming. So it may be best to just shelve the Agile conversion for now – sounds too much like a lose-lose for the organization.
No one in the organization or PMO is PMP certified. This isn't necessarily a show stopper. But it can can be very difficult to sell a completely Agile environment and workable project methodology without having a basically PMP certified project management office and staff. PMP means dedication. It means a proven process. It means repeatable processes. It means discipline, success and a common language. If you go to a client and bid on a project with a completely uncertified staff, then it will be very hard to win that client. Not everyone in the PMO needs to be certified, but there are going to be certain clients that will need to hear “Agile” and “PMP” used in the same sentence... guaranteed.
The requirements for most of your organization are both static and well-defined. No doubt Agile works best on a project that really needs it. And usually that is a project that has somewhat vague or changing requirements. Or uncertain requirements from the beginning. Or several phases that the client would like to have rolled out individually. In all of these scenarios Agile is an excellent choice.
I am still of the mindset that with all other things being equal, Waterfall is the way to go. If there were never going to be any sliding or changing requirements and everything is well defined and low-risk from the beginning, then it's very hard to argue against Waterfall. But a project without some change is unheard of. Waterfall can still be the best approach. But if you start to invite lots of requirements uncertainty or requirements that have to change and be defined along the way and a solution that needs to be rolled out over time with growing functionality, then Agile is always going to be the way to go.
Never need phases rolled out early on any projects. I've already touched on this a bit above. If you are managing very standard (boring?) projects that never need early functionality rolled out to the public or end users or whoever that user audience is, then you probably never have a need to make the big conversion to Agile. Depending on the organization, the change won't be fast or easier or without some turnover of sometimes good, experienced personnel. So don't do it if you don't have to. Never do it just to call yourselves “Agile.” Bring an Agile class in house and then call yourselves “Agile” even if you aren't leading any Agile projects … ever. It's a good thing to have in your hip pocket, but you don't have to fully convert if it's not necessary. It won't be free or painless.
Summary / call for input
These are just five potential reasons why Agile might not work for you or in your organization from a development and project management standpoint. Are there others to consider? Most definitely. But these are five key ones to look at first – at least from a high level.
Readers – what are your experiences? Do these reasons make sense? Have you been part of an organization that shifted to Agile? Did it work? What were the pain points? Did it fail or did you shelve the entire process after considering the pros and cons? Please share your thoughts and experiences.
RSS Feed
