9

First of all, I like Agile.

But, as well known, "there is no silver bullet". Obviously, if agile methodologies still not "rule the world", agile approach have some shortcomings.

So, questions are:

  • What are disadvantages of agile methods?
  • In what kind of projects better not to use agile approach?

closed as too broad by Mark C. Wallace, Mark Phillips May 6 '15 at 1:35

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I assume you talk about agile project management (like scrum) and not agile software development (e.g. continuous integration)? – Tob Apr 29 '15 at 14:50
  • 1
    List-generating questions are always off-topic on Stack Exchange. Please update your question so that it is more focused on an actual problem you face, and has the potential to be answered in a canonical way. – Todd A. Jacobs Apr 29 '15 at 14:51
  • @CodeGnome As I understand, the second part of my question (in what kind of projects better not to use agile approach?) will be "list-generating question" too? – Sergey Kudryavtsev Apr 29 '15 at 15:02
  • 3
    About "list-generating question". There are a lot of not-closed question of such type in pm.stackexchange.com. For example, everyone can search questions with words "advantages" or "disadvantages". I do not mind if my question will be closed, if it does not comply rules. But I don't understand this inconsistency in closing of questions. – Sergey Kudryavtsev Apr 29 '15 at 15:19
  • 1
    Context matters, and each question has to be individually assessed for quality. If you see other questions that should be closed, please flag them for moderator attention or bring them up on meta. That's always a great way to participate on any SE site. – Todd A. Jacobs Apr 30 '15 at 15:34
15

Predictive planning vs adaptive planning

Agile methodologies and frameworks are better suited where technology is fast moving and requirements either cannot be stated fully upfront or tend to change often.

Let us take the example of a B2C (business to consumer) software project that has a graphical user interface (GUI). You will build many gates for validating usability or user experience:

  1. Wireframe testing prior to the development of a functioning website.

  2. Alpha testing when a website is barely functional and populated with just enough data for participants to complete the essential tasks.

  3. Beta testing when a website is fairly stable and approaching full function.

  4. A/B Testing post launch.

At every one of these stages, you look at the feedback and make changes to your design so that the final outcome is easy and appealing to the users and, most importantly, accomplishes the business goals.

To take another example, in one of my previous projects, we had integrated with a vendor product for media storage that was a key feature of our web site. Half way through the project, we found that the vendor support was so bad and the cost was so high we decided and built the capability ourselves and eliminated the need for the vendor.

These are the reasons why among software developers you hear such extreme statements like, "Most GanttCharts are lies from the get-go. Most GanttCharts' lies get bigger as time goes on." enter image description here

Looking at the Stacey Complexity Matrix above, Software Development, New Product Development and Applied R&D Projects all belong in the complicated or complex category. Use an adaptive planning methodology, such as Agile, for these. Frequent inspection and adaptation is key here.

What are disadvantages of agile methods?

  • Cannot track dependencies as precisely as in a Gantt Chart (try creating FS, FF, SS and SF dependencies in an Agile tool).

  • Cannot monitor cost and schedule variances very well (goal oriented product roadmaps will work to some extent).

  • Not well suited for functional specialization (prefers cross-functional resources).

In what kind of projects better not to use agile approach?

On the other hand, Construction and Engineering projects benefit from clearly contracted requirements and well established technology. The type of changes that we see in software requirements is neither expected nor is easy to accomplish in construction. Predictive planning works better for these. That is why very large construction projects are run successfully with the help of good upfront planning Gantt Chart and exception reporting.

  • Great answer. Do you think these are more true of frameworks that implement Agile values and principles than they are of the values and principles themselves? I focused on that, since it's what was called out, but I think this will be an incredibly helpful answer for future viewers of this question too. – Daniel Apr 29 '15 at 19:26
  • Thanks. I believe Agile values and principles came about as a response to efforts by management to put the square peg of traditional project management and Gantt Charts in round holes of software development. More recently, Agile is finding traction in knowledge work in general. But Agile is not suited for construction and engineering projects unless you are developing a new product (R&D). – Ashok Ramachandran Apr 29 '15 at 19:56
4

This is an odd question, but let's see if I can give you a good answer. First, in the comments you said that you're thinking about the agile manifesto itself, not a framework like Scrum. The agile manifesto contains 4 value statements and 12 principles. It would be difficult to answer the question "On what kinds of projects would having a ton of documentation and no working product be a preferable outcome?" or similarly "On what kinds of projects would sticking to a plan with the clear understanding that the plan is wrong be preferable to modifying the plan?"

There are cases where the agile manifesto may be too difficult to follow all at once in an organization. For example, one of the principles states "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." If you have a whole development organization used to huge swings of downtime and crunchtime, they probably don't know how to set a sustainable pace and this principle becomes more of a goal to work toward.

So the best answer I can think of to your question is that I can't think of any project type that wouldn't work with these values and principles, but there are organizations and engagements that don't have an existing culture that will support them and cultural change takes a lot more time.

  • Thank you for your answer. I can show you an example of that kind of project: software development for carrier rocket. There are too many dependencies. Any change in the project will lead to a chain reaction of changes. So "contract negotiation" is more important then "customer collaboration". – Sergey Kudryavtsev Apr 29 '15 at 18:03
  • In example below most of dependencies are not flexible, so even if it is easy to make change in software, re-assemble part of rocket will be much more harder. So "following a plan" more preferable than "responding to change", because in that kind of project should be no changes at all. And of course, if we talk about principles, nobody needs frequent deliveries, because launch time is fixed. And so on... This is just an example. But I would like to formulate general principles of projects, where agile is not applicable. – Sergey Kudryavtsev Apr 29 '15 at 18:11
  • I don't think stackexchange's format lends itself well to digging into where agile might be beneficial in that example, so I just want to focus on the fact that I don't think this example shows a case where agile values are a bad fit. For example, I'm not sure that you can say that working alongside of the person who designs and builds the release clamps for the rocket would be detrimental to the project in favor of a very thorough SOW on the same piece. – Daniel Apr 29 '15 at 19:02
4

Agile methodologies is not just about methodologies, is a lot about culture. And, as it is related to culture, a very long time is needed to run it in the best way you can.

You can think the agile methods as a framework and adapt this to your reality and not just as a process or method.

To know the pillars of agile methodologies: http://agilemanifesto.org/

So, reading the agile manifest we will can ask: When it doesn't work?

  • When following a plan is more important to respond to change (civil construction, some factories);

  • Contract negotiation is more important than customer collaboration;

  • Comprehensive documentation is more important than a working product;

  • Processes and tools is more important than individuals and interactions.

Is important to mention that the agile manifesto doesn't say the documentation, contract negotiation and tools/process aren't important. It say that theres other things that you need to look first if you want to become more agile.

Normally is because of that is so hard to run agile in a big company, for example, theres a lot of cultural change needed for run this type of framework. So, if you can't ensure in any way you will follow the agile manifesto values in your company, maybe you can't run agile methods. But, if you really want to run agile, you will need to be a culture change agent first.

Not the answer you're looking for? Browse other questions tagged or ask your own question.