Hope this will help you

DOI: 10.1201/1078.10580530/46108.23.3.20060601/93705.4

Thank you, I know this article. I'm interested in knowing peoples real experiences on using various Agile methods. Which one helped them to be ambidextrous, which one did not and why? What was their working scenario or industry? What changes did they make to the agile method to work for them? etc.

In IT, one of the main requirements for implementing Agile is the understanding of its phylosophie in comparison with traditional development methodologies/frameworks.

The second requirement is the development of agile teams and make sure they embrace the culture of Scrum/DevOps or whatever methodology you have in-house through training and workshops.

Throughout my experience I have encountered the following issues with various organisations having implemented Scrum methodology:

1- Not sure when to use Scrum or Waterfall. Some organisations just decide to implement Scrum with all their SW development projects. The approach to decide which methodology to use is basically on the types of requirements you have for a particular project. If the requirements are lnown and guaranteed not to change then Waterfall will be more suited for this project otherwise Scrum/DevOps would be a better choice if requirements could change while the project is running.

2- User Stories (US) are expected to be just good enough and therefore not detailed enough and this leads many times to develop features that don't reflect customer needs. The outcome of this is of course rework, triggering the need for more resources leading to lengthier project duration and therefore incurring higher costs. It doesn't kill anyone by having slightly more detailed US's to avoid such scenarios.

3- Quite few organisations don't cater for bug fixing the way they should and therefore leave these tasks for later sprints which really defeats the objectives for implementing this methodology.

4- In projects where many product managers are assigned responsibility to scpecific parts of a big project, working under senior product managers, this could lead to a real chaos if the organisational structure isn't in place or if it is, it's not fully adhered to.

5- Outsourced development may lead to untested sprints if the customer doesn't provide test data or a test environment because of data safety reasons. Test data could be generated before implementation and doesn't need to be production data to test your sprints.

6- I have encountered this issue with every organisation I worked with for the past 35 years, the requirement phase is never given the time required to do a proper requirement elicitation and analysis. It's considered most of the time as a part where one shouldn't invest too much time on it but rather on implementation. The focus here is most of the time cost saving but it produces the opposite, it increases cost between 10 and sometime up to 50 times the cost if they had spent 30%-50% more time on the requirement analysis phase from start.