5 ms·
In which cases Agile should not be followed / implemented?
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.
Please tell me what were your experiences? When did not you use Agile deliberately? What alternative approaches worked for you?
Thanks
- johncoltrane 9y agoAgile 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 9y agoLet 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 9y ago> 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 9y agoAgile 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 9y agoI 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?