What Product Development Methodology is Best for De-scoping?
Which of the three product development methodologies should you choose.
You are going that extra mile on a project whose deadline is approaching. Unfortunately, some of the major functionalities are far from meeting the projected timelines. Why did the situation get out of hand, and what should the next step be?
There can be numerous ways to handle this situation. Project managers may fiddle with the idea of balancing scope, adding resources, playing with scheduling, requesting additional budget or time. Assuming you have tried all this and the only option left is de-scoping some features.
What will be the impact? Let’s start from the basics. What was your software development model or methodology? The question becomes vital as this might provide an insight into where things would have gone wrong and what can be done to bring the project on the right track.
This will not be the right time to change methodology, hence we will seek guidance without ever changing it. Most of the time, modern software development follows two basic methodologies: waterfall or agile. There has been a third one, that is up and coming which we will discuss later.
Waterfall Methodology
Waterfall involves project manager, architects, senior developers and business analysts to sit down, brainstorm and come up with a detailed design and project estimation. As soon as scope or requirement is changed, an experienced project manager negotiates with timelines or discuss de-scoping. Imagine this was not done in your case and you ended up in a situation where the project will not deliver all the functionalities and de-scoping is your only option. It becomes quite cumbersome to go back to the drawing board, play with your detailed plans and amend the design to eradicate few functionalities. In complex projects, this act in itself can look like a project.
Learning: If waterfall is strictly followed, either do not allow requirements to change (good luck with this), or proactively ask for more budget, resources, time or change of scope. Procrastination can burn out your team and have an adverse effect on your project. The team may end up cutting corners and eventually, the quality of the product takes a hit.
Agile Methodology
Agile helps you plan and develop in chunks. If product backlog is continuously groomed and sprint goals are well defined, such a scope creep can be handled very easily. This was probably one of the most important reasons for the creation of agile. As the scope creeps, it is very easy to understand which functionalities will be out of scope. There is no need for detailed brainstorming sessions. The tail of backlog is truncated.
Learning: An experienced product owner keeps the backlog refined and the team sticks to the sprint goals. The scrum master shields the team from burnout and de-scoping becomes easy sailing.
No Man’s Land
The third software development model can be found in projects with new project managers. Most of the time, projects do not realize that they fall into this category. At a high level, they might be using agile (scrum/kanban, to be specific) but the reason they may call themselves agile is that they are using Jira or having a status meeting that they call standup or retrospective. They might not be following most of the tenets of agile. Agile may confuse new entrants, hence it is highly recommended to have an experienced agile coach or scrum master, when you embrace agile. Otherwise, you may unknowingly fall into this category. Remember agile is not a technology or programming language that can be learned by watching videos or reading internet articles. Also, just certification without experience or guidance does not help. The industry is still looking for a name for this kind of project development. Some call it confused project management (because team doesn't know which methodology they are following), I call it fragile project management (acronym for fake agile and matches with the nature).
If your project falls into this category, de-scoping is going to be time-consuming. The functionalities that would have been implemented until now, might not be the most valuable as backlog grooming was ignored. You might not be having a demo-able product as sprint goals were never clear.
Learning: I did say that this might not be the right time to change methodology, but remember, your project was not following a specific methodology. Instead of pumping up development resources or stressing out your team to deliver more, get an agile coach or recruit an experienced scrum master and product owner. Let’s treat the cause of the problem not the symptom. To make a long story short, “follow a methodology.” Thousands of projects are delivered smoothly using these methodologies.
Hence, next time when you start a project and you think the timelines are tight, consider choosing the right project management methodology. There are numerous factors that should be taken into account while making this decision, make sure you include de-scoping as one of them.
