
In which cases Agile should not be followed / implemented? - amirmm
Based on my understanding, Agile (Scrum) is empirical. We should be transparent, inspect, learn from our experiences and adapt. However, nothing is limitless and without weaknesses! 
With my experiences in the past, we could not implement Agile when team members were always changing. For example, a back-end developer was working on a task for 3 days, if all tests were passed or tester was busy, the back-end developer would move to another project, if any of the tests were passed the developer was called again to fix bugs then front-end would start working, etc.
The reasons behind that were because of not having a reliable velocity and having high flexibility in the team. We could not implement Scrum; I am not sure if Kanban was a good idea though.<p>Please tell me what were your experiences? When did not you use Agile deliberately? What alternative approaches worked for you?<p>Thanks
======
johncoltrane
Agile can only work if every part of the organization is agile.

HR too slow? Can't be agile. Upper management obsessed with numbers and
reports? Can't be agile. Hard to recruit new people? Can't be agile. IT
department incapable of creating accounts and prepping laptops in less than a
week? Can't be agile. Ever-shifting requirements because we are "Agile",
aren't we? Can't be agile. Client insists on a deadline? Can't be agile. Hard
dependency on non-agile third parties? Can't be agile. Unstable teams? Can't
be agile. Etc.

~~~
amirmm
Let me make myself clear, I agree Agile is not useful for all environments.
Just need some example of cases that it has not been useful and reasons for
that.

If I get you right, you mean any team that is too slow cannot be agile. I
disagree, transparency in agile is useful to find the issues and retrospective
meeting can be used to fix the issues. Thinking out of the box, I can say a
business analyst can help with improving the process and making it more
efficient. To bring the slowness problem to the surface, I would use a Kanban
board to make everything transparent and figure out what the problem is, and
hire a business analyst to review the process and find the bottlenecks.

Also, I had experience of working in a agile (scrum) team while our client
(whom sent the requirements) was following waterfall. Would you elaborate
further? Cannot we wait for the other team to finish it work and then use
Agile to develop what is required? Or if something is going to be delayed
cannot we remove that from the current Sprint and move a ready item to the
current Sprint while waiting for the other team?

In addition to above, which other approaches did you use to develop software
applications when Agile did not work? and which approach would you use if you
were in our situation?

~~~
johncoltrane
> If I get you right, you mean any team that is too slow cannot be agile.

No, I meant that agility is what you get when you got rid of every impediment.
Sadly, a small team working on building a product or delivering a set of
features can be as agile as they want but they _will_ face impediments that
they have no power over, no matter how much introspection they do.

Sadly I have no solution for this.

------
mindcrime
Agile and Scrum are not the same thing. In fact, there is no such thing as
"Agile" \- as a methodology.

That said, you can always be "agile". Re-read the Agile Manifesto and think
about it. There's nothing about story points, velocity, or any of that crap.

~~~
amirmm
I agree, Agile and Scrum are not the same. Agile is a framework, Scrum and
Kanban are two ways of adapting this framework.

On your point about story points: I am not too fussy with story points,
velocity etc, based on Agile guide, we need to have Sprints in Scrum and the
team should complete the tasks that it committed for a specific Sprint.

So how does the team know which one is too small or too big when adding
requirements to the Sprint during Sprint planning meeting? The team needs to
have a way to estimate requirements and make sure it wont commit to a long
list of tasks without acknowledging their sizes. To achieve that we need to
use story points, T-shirt sizing or any other method to estimate requirements,
right?

Please let me know how was your experience of estimating requirements and
adding them to your Sprints? and which approach would you use if you were in
our situation?

