Scrum is a popular project process in the world of development. However, it’s not necessarily always the choice that makes sense or is feasible.
In some cases, such as performing work for a highly-regulated industry, it may not be be realistic to employ scrum, as the ability to iterate and explore ideas during the development process may be constrained.
Projects implemented under this context may feel more like we’re building a well-formatted static document rather than a dynamic, interactive website or app.
So what then? Should we use waterfall? Well, that depends. Even though the requirements may be rigid and constraining, that does not mean they are unchanging. In my experience there is still change encountered in these scenarios- from the client, from the regulatory body, or from (gasp) previously unrealized requirements or scope on the part of the project team.
In that case we can implement waterfall- collecting all of our project requirements and assets at the onset, but we cannot depend on 100% efficacy in those parameters.
One way I’ve observed teams try to mitigate this is using a sort of hybrid approach of the two methodologies- scrummerfall, as Kenneth Rubin refers to it in his book Essential Scrum.
This approach attempts to take the stable features of waterfall and blend them with the more agile abilities of scrum.
This can have some benefits and drawbacks. It does help ensure up-front demand for delivery of project assets.
However, it also can lead to a scenario where we are trying to shoehorn waterfall-shaped project assets into a scrum-shaped hole. For instance, when building a waterfall timeline in a regulated industry, that timeline is likely to be primarily sequential, with milestones that must happen one after the other.
To achieve some scrum benefits, we may translate that timeline into a kanban board with tasks. Unlike true scrum, where a backlog is set up for a sprint and developers pull tasks from the backlog as their availability allows, those tasks are distributed to sprints purely based on timing. Tasks within the sprint have likely also have specific start and end dates inside of the sprint’s start and end date, meaning they cannot be pulled to active by the dev until that date.
Whereas true scrum seeks to focus on idle work and not the idle worker, in this scrummerfall scenario emphasis is shifted to focus on the idle worker. Where can a task with appropriate start and end dates be found to keep this worker busy becomes the primary concern.
No one methodology makes sense across the board, and all teams will need to make a decision on how best to handle their specific project needs. This is not an indictment on any particular process but only an evaluation of what are some of the implications between process choices.
Leave a Reply