3 Reasons Why I Would Not Do Agile Project Management
by Kelly Waters
Agile software development has been a revelation for me. It has brought me and my teams much success, and a very rewarding working environment.Sometimes I hear people say that agile project management isn't appropriate in all circumstances.
In fact, I used to say that myself; however now I'm not so sure.
There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:
1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.
2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.
3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.
In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!
When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.
I think I would do agile on a fixed price, but I would be very careful to:
- Understand the client's attitude towards scope up-front, and be very clear about the fact it's fixed price, not fixed price and fixed scope. In other words, they can add or change features throughout development, giving them the benefits of flexibility, but will need to remove other features to do so.
- Build in sufficient contingency and allow for a reasonable number of changes to happen without too much debate. You are taking the risk on a fixed price project. The client needs to pay a premium to offload that risk to you.
On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.
I'd love to know your thoughts on this: When wouldn't you do agile software development?
Kelly.
Photo by dominicmercier
25 March 2009 02:05
Do you think that any methodology would work under the circumstances you mention?
In (1) you have process-driven development (as opposed to product-driven development). When "managers" get to check items off a checklist, and "done" is when all items are checked off, what really has been accomplished?
In (2) you have all the signs of a political struggle; any project begun under these circumstances is almost guaranteed to be a failure.
(3) seems to be a subset of (1)
After having suffered thru (1)'s and (2)'s in my career, as well as a few successes, I look back on the failures and successes; the successes were so because there was either an explicit or implicit agile methodology. The failures would have failed regardless of the methodology.
I'm beginning to believe that agile methodologies are the *only* ones with a consistent chance of success. Admission of ignorance is usually the first step on any journey of learning.
25 March 2009 04:46
We are actually doing agile and fixed price AND scope contracts, BUT we have work orders for all the user stories which are done in the next iteration. The difficult part is about it is that you have to estimate the next sprints user stories before it actually starts. In the sprint planning we commit which user stories will be done according to MoSCoW.
25 March 2009 08:34
I'd summarize your criteria under what I call "YAM" - "Yet Another Methodology". Meanwhile, Agile (capital 'A', yes) Software Development is so hyped that it gets "implemented" as YAM, obliterating the value base that it needs, replacing that base with the old Input-Process-Output thinking: "look, it's YAM, just with new artifacts and new activities".
Interaction isn't an "activity", though. It is an attitude.
25 March 2009 10:51
Working with non-colocated teams is often cited as a reason not to implement agile. I have seen it partially successful in some situations, but when dealing with teams who speak different languages you must be particularly careful. It is very difficult to be agile when your daily stand ups are conducted by conference call and some of the team speak English, others French, and others Tamil.
Do you think Agile can ever work in such teams?
25 March 2009 12:22
You left out the obvious case: when all your clients demand fixed price because it's a buyer's market and you happen to live in a low-trust country which is pretty much all of them except for US, EU and Japan, and you just MUST accept it.
Even in the high-trust ones people often demand fixed price whenever it's a buyer's market.
Shenpen
25 March 2009 14:04
Thanks for this concise insight.
I had the same gut feeling when I wrote:
Scrum pigs - musing about commitment
... and tried to make a funny story out of it.
My follow-up question is: What do you do, when you find yourself in an environment that claims to do agile but actually falls in one of those categories you mention?
25 March 2009 14:17
How about the case where your software development methodology is partially dictated by external parties? For example, companies that must comply with PCI/PA-DSS compliance? These companies are required to follow "accepted" development and testing methodologies whose descriptions often preclude the use of Agile.
25 March 2009 17:00
Agile says "do me and you will be more successful", but as you've noted, there are a bunch of often-unstated prerequisites.
It is probably true that you cannot be agile with the restrictions you mention. However, you can still be Lean, which may be even better in the long run. Lean says "expose the process, and use this set of principles & practices to find your own ways to be more successful".
25 March 2009 17:02
There is some friction between Agile and typical UX design methodologies. Not that it can't be overcome, but some do argue that (UX) design should be done up front and, potentially, feed into an Agile dev approach.
26 March 2009 09:21
Unfortunately, you confuse sales with development.
Sales baits them and dev switches them.
Unless you havent heard of capitalism? sry my bad.
27 March 2009 21:48
I think "agile" had meaning before the manifesto... Flexible, quick, adaptive.
The manifesto attempts to isolate principles that are THEORETICALLY required to meet these goals. The pundits immediately discount anything that does not salute their own view, REGARDLESS of whether it is IN FACT agile... in spite of their beliefs.
They commonly hold up their approach alongside waterfall... Even the guy who originally wrote about waterfall presented it as what NOT to do!
I personally have seen software construction & delivery in hours, not days or weeks... using NONE of the practices in XP or SCRUM or any of the packaged agile toolsets.
"Agile", as you discuss it here, is a development-led revolution against bad process; But it has become blind dogma... if you do not drink the Kool-aid and salute the process(never implemented twice the same way as it turns out)... and close your mind to any ideas that challenge it... you are then a fool or worse.
I used to credit my developer peers with open minds and honed logic. More and more, I see a growing pool of religious zealots. I can name a dozen situations when you don't use "Agile"... without trying hard; The question I have is when this "silver bullet" is going to be seen for its weaknesses.
The developers have become the new enforcers of bad process... We have seen the enemy and it is US!
Please - don't pass the koolaid.
16 April 2009 00:55
I disagree that these items are counter indicators to using agile. In fact, these are the types of teams in which agile will have the biggest impact. To require a team to hold agile values before they are agile is putting the cart before the horse. Instead, if we use agile and they begin to see the process and the benefits, they will gradually come around. I included a more detailed analysis of the sitations describes in my blog post: http://www.emptyyourglass.com/2009/04/16/why-i-wouldnt-do-agile-development/
24 April 2009 22:32
Interestingly, I have in my experience identified 2 specific types of organizations which seem to not be willing or able to follow an agile methodology. In each case it is due to factors that you list under points 1 to 3.
1. Governmental organizations due to their rigidity and often unwillingness to invest themselves in a software implementation/development
2. Environmental organizations for their tendency to procrastinate and thus refuse the pressure imposed by the involvement requirements
12 May 2009 00:32
I would add to your list:
- organizations where individuals have a substantial lack of trust toward one-another
- organizations that do not value their people
- and any organization that cannot accept the Agile principles.
28 November 2009 14:54
Agile is a silver bullet. Just go "agile" and it solves all your problems.
lol
25 February 2010 16:35
If the following web artical titled "3 Reasons Why I Would Not Do Agile Project Management
(https://agile-software-development.com/2009/03/3-reasons-why-i-wouldnt-do-agile.html)
you use the terms Agile project management and Agile Software developement (see quotes below).
Can you provide some clarity around the these two terms?
More specifically can you argue that Agile is a proeject management methodology more than
a software development methodoloogy?
Thanks
Steve
--
Quotes from the article
Quote 1
"Sometimes I hear people say that agile project management isn't appropriate in all circumstances."
Quote 2
"At the moment I can think of only 3 reasons why I wouldn't do agile software development:"
26 February 2010 08:05
Hi Steve. I have used the terms 'agile software development' and 'agile project management' interchangeably here, because my comments in this article I think apply to both.
The difference, in my mind at least, is that you can use agile software development techniques on projects or on ongoing development and maintenance. The term is fairly broad and generic and refers to the engineering practices and also some of the development management practices (for example Scrum).
Agile project management, however, is slightly different in my view. When you are managing a large project, there are lots of other considerations, for instane scope, timescale, budget, maybe a client contract, risk, stakeholder management, release planning, etc. Although agile methods do not provide for all of these things specifically, using agile software development methods in the context of a bigger project is a little different. Personally I sometimes use the term 'agile project management' to make this differentiation.
Hope that helps,
Kelly.
3 March 2010 22:23
Thanks Kelly, your answer was somewhat helpful but my key consern was to get at the reasons why the seemingly interchangeable use of 'agile software methodology' with 'agile project methodology exists (IMO) in the agile community. I was also curious as to how this situation has come about.
To me Agile is more (though one could ague to what extent) a software developement methodology than a project managament mathodology eventhough Agile does have imputs (ex: estimates, backlogs and burndown velocity) to asist with the management side of things.
The reason I say more is simply based on looking at where the predominant effort is taking place on daily basis: to me this is the developer/subject matter expert interaction.
Questions/comments?
Thanks
4 March 2010 20:46
Hi anonymous - interesting points!
I don't know why the terms 'agile software development' and 'agile project management' are sometimes used interchangably in the agile community. I do it. And then other times I differentiate very definitely.
I hadn't really thought much about the semantics of it to be honest.
Re your comment about agile being a development methodology more than a project management methodology, I think that depends which agile methodology you are actually using.
I would describe XP (extreme programming) as an agile development/agile engineering methodology, yet I would describe Scrum as an agile management methogology.
I think true 'project management' is something you overlay over either of these agile methodologies, but Scrum does provide a lot of management structure to help manage agile development teams, whether they're on projects or on ongoing development and maintenance.
I'm not sure that's any clearer! Anwyay...
Kelly.
30 March 2010 13:56
I work for Federal Government (Dept of VA) and several folks here are trying to implement an Agile philosphy. I have many concerns on how to go about implementing this for some of the very reasons that are mentioned in this article and comments.
-lack of flexibility and need to strcuture
-lack of communication or commitment to support the details
They are also looking to push a Firm fixed price approach which to me either restricts the needed flexibility or will cost the government a very large amount of $$ due to the "premiums" for taking on these risks. (I would consider the FFP referenced in the article really a scoped Time and Material effort, not FFP)
Any comments/recommendation on how to address in this forum, including contractually?