In my experience, having to make a software feature cut within the waterfall software development cycle come from poor initial planning and lack of understanding the feature’s complexity and its dependencies. This in my opinion, is mainly due to how the waterfall model works and its implementation within software product teams. The waterfall software development model is a sequential design process. It is used in software development processes in which progress is seen as flowing steadily downwards (like a waterfall) through phases i.e., system planning, requirement definitions, design, development, integration & test, and user acceptance.
Yet even with proper initial planning and understanding of the feature’s complexity and its dependencies, a time within the waterfall software development cycle may come when cutting or more features is required. It is thus in my opinion, better to use an Agile software development cycle rather than waterfall software development cycle. Using an Agile software development cycle properly, one should rarely experience the need to cut a feature currently in an Agile software development cycle.Use Agile software development rather than waterfall software development! Click To Tweet
The Institute of Electrical and Electronics Engineers defines the term ‘feature’ in IEEE 829 as:
“A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).” A system is said to be feature-rich when it has many options and functional capabilities available to the user.
Reasons for a Feature Cut
Regardless of which software development cycle ones uses, reasons for making software feature cuts are not limited to:
- An unexpected loss of resources to complete a feature
- New cost restraints unforeseen during planning
- Feature complexity was under estimated
- Unfulfilled dependencies
- Time to market changes a features value
- The completed software needs to get released sooner
- And many others.
No matter what the reason is or reasons are for making software feature cuts, actually making the software feature cuts requires tactful thought and processes planned out before any cuts are needed. Proper project management planning includes managing the risks of making feature cuts.
Understanding a Feature Cut
Looking up the word “cutting” in a thesaurus, you find such words as; wounding, hurtful, unkind, spiteful, and harsh define it. The word, “cut” is defined as slash, hack, and sever. Just using the words cutting and cuts in a sentence could make someone shiver a bit inside used in that context. We are not however, discussing making cuts with knifes or cutting using other types of sharp objects. We are talking about cutting features from software which is still under development but, it can feel that way.
While we are not talking about cutting and cuts as done with knifes and other sharp objects, we can make the feature’s owner shiver inside and generate some very strong reactions from people within the software development process. Mention cutting a feature and making feature cuts to a Program Manager (PM) who designed it or Developer (Dev) who worked to implement it, you could get wounded. You could get hurtful, unkind, and spiteful looks shot your way. You risk being called a few choice expletive names which I’ll not include in this post. The conversation could come to really harsh words being spoken to you. These reactions to cutting features from software I’ve seen and have experienced firsthand. Sometimes they come from a PM or Dev that I least expected reactions like those to come from too!
Why would someone get so upset and do such things when we are just talking about cutting features from a software program? Many different answers could answer this question but the three that I’ve most experienced are:
- The feature is one that the PM and/or Dev have worked on for so long, they are comfortable with the feature and do not want to give up all the work that they have done on it.
- It is a “pet feature” for the PM and/or Dev that they think of as a beloved pet, they don’t want to give it up because they thought of it and/or that they really like it.
- A very strong believe that the feature needs to be fully developed because it was scheduled to be developed.
Take a moment and think about an upper level Dev manager who has worked many years at the major software company and how this person has a very strong believe that this pet feature needs to be in the software… now for whatever the most valid reason it is, you as the Project Manager, need to tell this upper level Dev manager that this pet feature needs cut. Kind of makes you shiver a bit, doesn’t it? It made me shiver when I had to do it.
Pitfalls of a Feature Cut
If the feature must be cut, it must be cut. If it must be cut, then you need the facts supporting why, how, and when. The logic of “why” the cut needs made; “how” will this cut impact the overall project; “when” will the work come in with the cut and how over without it needs answered and communicated out to the development team. This is where previous planning for cutting features comes in and communication skills come into play. Hopefully, your communication skills are good enough to get the point across about why the software feature cuts are being made because you had already set everyone’s expectations prior to the start of the development process about what happens when features need cut.
Once the decision is made to make software feature cuts for whatever reason, the development team needs to make sure that the proposed feature cuts do not:
- Break any key scenarios
- Make the code base less stable
- Creates security issues
Also, it needs determined if cutting the feature actually accomplishes what it is expected to accomplish. By cutting the feature, are you actually going to hit the schedule date or will cutting the feature take longer than implementing it? Will cutting the feature save money or cost money? Does it matter if cutting the feature costs more money than implementing it? These are just a few items that need answered and hopefully, early in the planning stage they (and many others) were discussed and worked through.
Planning and a Feature Cut
The key to making software feature cuts is to have a plan to follow before making the software feature cuts. Having a plan thought out well ahead of the time of making cuts helps to not overlook the areas the feature touches. Planning feature cuts ahead of time helps to not break key scenarios and helps make the code base more stable. You should consider having whole scenarios described how related features work together and how if one or more of them is cut, what happens. When items are known so that if it does come down to making cuts, you have the most information at hand available to know the impact made by the cut being proposed.
A couple of the biggest things to consider about the proposed feature cut if looking to save the schedule is, will it really save time and where will it save time? A cut for example, could save dev time but cost more in test resources and time and make the schedule go out even further. Again, this comes back to detailed planning prior to having to make cuts to help understand how much and where the time will be saved when making cuts. The best cuts save time and money overall but these are cuts that are sometimes difficult to find and often even harder to make in the waterfall model. The better approach, use an Agile model. The Agile model properly used by default saves time and money and rarely encounters the need for a feature cut during its cycle.
The best things to do to help alleviate the pain of cutting a software feature is to:
- Plan ahead of development time to understand how each feature works together in scenarios and work items.
- Find out and document how the features, scenarios, and work items interact with and w/o each other.
- Set priority orders on scenario, features, and work items including the implementation order and cut order and estimated amounts of time saved and where the time is saved if the cut is made.
- Understand when a cut can be made and when it cannot and the impact of making the cut at different times throughout the development cycle.
Avoiding a Feature Cut
It is in our nature to want to finish something once we start it. We often do not want to stop (cut it) once we’ve planned to do it and have started it. If we plan ahead and understand the how the features interact and how a feature cut impacts beforehand, it could be the best thing to do to get things back on track.
So, remember, take cutting software features seriously even if it is not done with knives or other sharp objects because there just may be more to it than you think and it could come back and hurt you and your project if you do not. Better still, look into Agile software development processes and move away from waterfall software development!
Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. Thus, needing to make a feature cut while using proper Agile software development methods, is highly unlikely.
Are you using the waterfall method? Have you had to make any software feature cuts? If so, how did it go?
I have 20+ years at Microsoft (Office, O365, Windows, Windows Phone, Exchange, SQL, MSN, Bing, SharePoint, SharePoint Online, Xbox).
I have Project Management Professional (PMP), Certified ScrumMaster (CSM) and Six Sigma Black Belt certifications. And I aided the successful release of over 150 Microsoft software products and services.