Suitability and Unsuitability of Agile methods? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

Everyone is talking about Agile and how good this is. There are several advantages and disadvantages of Agile. I have studied them theoretically. Since there are experts here who have worked in many projects I want to know real two-two scenarios where Agile is unsuitable and suitable. Thanks

Answer 1

If it is possible to do agile well, then i believe that is always a good thing. If it is not possible to do it well, then i believe that it can be harmful. Not because there's anything intrinsically hazardous about agile, but because it would mean using a dysfunctional process.

So, agile is unsuitable when the conditions for doing it well do not exist.

Some things that could scupper the adoption of agile:

• Team members do not understand the process, and do not have either the time or the inclination to learn it
• Team members do not have the experience or maturity to assume more control over their own process
• Management requires detailed long-term plans as a deliverable
• The customer is unwilling to provide feedback on incremental releases before the final ship
• There is a high churn of members in the team
• The technology in use does not permit a build and test cycle of a useful length (i've done agile with a three-hour build and test cycle; this was very painful but just about doable), or does not permit it at all
• The problem domain does not admit incremental development of a solution (i'm not sure if this is ever true; the nearest i've come to this is when dealing with cryptography, where the thing either works completely or doesn't work at all)

To some extent, these can be remedied. An uninformed or inexperienced team can be shepherded by a cadre of informed or experienced members. Team leadership can write a long-term plan, then let the team ignore it and hope that delivering working code will pacify management. Business analysts or QA can act as a proxy customer for providing feedback on incremental releases. Branching strategies and build servers can be used to decouple build-and-test from commit and merge. These remedies are certainly not guaranteed to succeed, though, and if the problem remains insuperable, agile will not be succesful.

Answer 2

Agile may be unsuitable when:

• it threatens to expose overgrown management (some positions suddenly become clearly superflous)
• people actually don't want to have fun and do creative things, preffering 9-17 mode of mundane work (maintenance of legacy crappy software that just cannot wait to be disposed of)
• politics rather than professionalism run the company
• Human Resources run the company (Agile is about humans, HR treats them as things)
• the customer expects that you will figure out what he needs for him (Agile will make you asking him questions that he doesn't want to answer)
• Agile is expected to be a magic wand that will solve problems without anyone changing their habits (another buzzword, a fad)
• development is spread across multiple locations far away from each other, in different time zones (communication suffers)
• you have a pointy-haired boss ;)

or in general:

• it is misunderstood
• organization is devoured with serious patologies
• no one actually wants it

Answer 3

I worked with many different teams trying to move to agile. Some succeeding, other which did not succeed. Based on my experience, I can say that:

• Moving to agile is suitable when the software creators want to improve quality of their product(s) (whatever its mean in their context) so badly that they are even ready to work as a team to achieve it.

• Moving to agile is not suitable when everybody is happy with the current quality level and/or do not want to work as a team.

Answer 4

Sort answer: agile is suitable, when IT company is making its own product. e.g. visual studio is made in agile way couple of years. And you can see much better "idea to delivery time". Agile is not suitable for Internet Banking. Another example is client based in US and dev team or its part in azia. The time delay makes things complicated.

Long answer: First, if you want to run an agile project, your management should understand it and processes in your company should embrace it. If you try to workaround them, you will fail. See how management and internal processes are important here: https://www.youtube.com/watch?v=4u5N00ApR_k It's more important that the management and team leads understand agile processes than the programmers. Usually, opposite is true.

Second, your client's management and processes should embrace agile processes. A bank or financial institution will never sign an agile contract. Their processes requires deep planning and approval at multiple levels. See how clients misunderstanding of agile can cause a fail: https://www.youtube.com/watch?v=lAf3q13uUpE

I completely agree with Tom Anderson, that the circumstances are more important that the type of project itself. For example, if you have signed fixed contract (either because of your management, or a client), you probably have detailed requirements. If you have detailed requirements, you wont run scrum but "SCRUM BUT". It's against agile philosophy.

It may happen that the project is not suitable for neither agile, nor waterfall. Sometimes it's better to use agile internally having Product Owner role assigned to somebody from your company, who understand the domain best.

Suitability and Unsuitability of Agile methods?