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 .
The requirements of an Agile process should be defined at the beginning of a sprint and reviewed towards its . Am I right in this?
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".
I think the question you should be asking is: Why are you overrun by requirements changes? Common causes include:
- The developers don't have (enough) contact with end users so they can't understand the users' needs. Instead they treat requirements like an abstract Rubik's cube - they follow the letters of the requirements without even trying to understand their spirit
- Somebody (e.g. from marketing) is adding requirements that don't make any sense for the end user (but e.g. sound good on a brochure). So there's a battle between "real" requirements and "other" requirements that's fought on the backs of developers
- The scope of the project is undefined ("Well, if you're implementing a word processor anyway, couldn't you just add a small module that does our payroll accounting? Oh, and Bill from the other development team asked how hard it would be to make the word processor compile C++ code, too?")
Whatever the root problem is, you need to fix that. Drowning it under layers of "Agile" (or any other methodology) won't work.
In Scrum at least, which seems to be the Agile process that's most popular with management types these days, the scope of a Sprint is fixed. If your Sprint Backlog is changing during the sprint, that's not Scrum, it's chaos. The Sprint Backlog should be created at the start of the sprint and remain fixed until the end of the sprint (at which point you create a new Sprint Backlog for the next sprint).
If your Product Backlog is changing during a sprint, it's no big deal. The changes just become new work that's prioritized, estimated, and selected like any other requirement for the next sprint. If the requirements change so much that the Product Owner has to cancel the sprint on a regular basis, though, you've got Trouble with a capital 'T'.
Maybe you need shorter sprints?
For the sanity of the programmers it is best if requirements do not change during a revision/sprint.
In your situation, there are two obvious options:
- shorter sprints
- get the customer to agree not to alter the requirements during a revision/sprint unless the entire revision/sprint is cancelled and re-planned
I highly recommend both.
The main problem is that you believe that you are using Scrum but you don't. Especially your product owner doesn't follow it. In Scrum a sprint is a safe zone and no changes to committed user stories can be made unless current sprint is canceled. It is responsibility of Scrum master to enforce this. If this doesn't work in your environment then it is a process problem = you are not using Scrum.
The simplest change you can do (if you want to follow Scrum) is make your sprint shorter - one week for example. 4 week sprints were considered as option in early days of Scrum but today common is 1 - 2 weeks and 3 weeks is considered as upper boundary. 4 weeks is very long time in changing environment.