Has anyone had this issue of a project defined as 'Agile' being overrun by requirement changes ? I work on a development project which is run in 4 weeks Sprint but there are always changes in between these Sprints . Is it still defined as Agile then ? I feel it's sort of a sub Agile process – The requirements of an Agile process should be defined at the beginning of a sprint and reviewed towards its end. Am I right in this? Please let me know your experiences in this .
Agile vs Waterfall – Handling Requirement Changes
agileRequirements
Related Solutions
If you have been able to give a quote on a project with an exact final date on all the features, why did you switch to an agile approach? You and everyone else struggles with this and an agile approach is being up front with this fact. Use it as propaganda against the competition. Southwest Airline doesn't promise you an isle seat like everyone else who does and then gives it to someone else.
Of course the client wants an exact ending date. They want inexpensive, bug-free software delivered ahead of time regardless of any changes to the original request. Tell you sales team to learn how to sell a project using agile principles. The more interations you go through the closer you can get to knowing when the project will be finished. The client also learns to factor the effects of change requests.
What you are describing isn't Agile by definition (Agile Manifesto) it is Waterfall with daily status meetings. Agile means easily adapting to change, if there is no interactive feedback loop with the product owner and thus the customers, then what change is occurring?
Agile is about rapid failures, through constant communication with the product owner/customers. It is better to fail sooner than later, less work is done, and less is "lost". And you don't get stuck with the argument, that "we don't have time to do it correctly, since we spent so much time doing it wrong, we just need to continue on this same path, even though it leads to failure".
Sounds like your managment is doing "SCRUM, but ..." where the "but" is where they throw out all the SCRUM stuff that they don't understand or agree with and just do things the same haphazard waterfall way as always, but with new shiny buzzword names to it all.
In SCRUM the daily stand up is NOT about delivering status to management, it is to force developer interaction, so you know what your fellow team members are doing and can help each other out and not duplicate work. If it takes more than 45 seconds per person you are doing it wrong. It is about transparency for the team, if one person is giving the same status multiple days on something that should be a single days worth of work, the team can resolve the persons problem sooner than later.
If you aren't testing each others code as it is written, then you aren't doing it correctly either. Testing should be embedded into the process not an after thought. QA should be included in the planning sessions and give estimates on how long things will take to test.
If you are not meeting Sprint commitments and rolling things over, you aren't doing it correctly. Sprints are about commitments if you are committing to too much work, stop doing that, there is no way you can introduce any predictibility or repeatability if you can't accurately commit to deliverables.
Best Answer
No, this depends on the nature of the project (and the process).
There are some agile development models where requirements are meant to be fixed during a sprint, and should only change for the next sprint (a prominent example is Scrum).
However, there are also processes where changes can happen almost any time (as long as the customer accepts the delays and the extra work which the change causes). Kanban is often used to manage these workflows (although Kanban can also be combined with Scrum).
Which model you follow depends on the details of each project.
So yes, if the customer feels they need the possibility of constantly changing the requirements, then an agile process can accommodate this. However, the customer should be aware of the consequences of constant changes, and should understand that they will slow down the project.
This boils down to the principles from the agile manifesto - "Individuals and interactions over processes and tools", and "Responding to change over following a plan".