Fighting feature creep with a few easy steps.

Nothing is more frustrating for a software developer or project manager than hearing a customer say the product you built is not what they wanted. Technology projects involve long hours, loads of frustration, and mental exhaustion, so when that effort is fruitless, it feels like you have wasted your time. The truth is that you can avoid this futility by applying some agile practices and experience. Today, I want to discuss giving the customer what they want.

When developing software, like any creative enterprise, it is crucial to align expectations between those paying the bills and those doing the work. That is why sprinting and iterations are so important. You do a quality check at regular intervals to ensure you are building what the customer wants. The people in the SAFe world call this inspection and adaptation, and scrum professionals refer to it as a sprint review. Both serve a vital function and act as a quality check and progress report for the people paying the bills.

The Agile Manifesto is very clear about change. The team should always respond to change over following a plan. The iterative process of agile methods makes this happen when a change occurs, whether a new color scheme or a shift in business logic; the team should be able to adjust. It also allows stakeholders to understand the cost of frequent changes in time and money. 

Where change gets scary is with fixed time or money projects. Numerous project managers and software developers tell stories of customers adding more work to the project as the deadline approaches. The practice is known as feature creep. If you are in a leadership position on a project, you need to be on the watch for feature creep because it will grow into a metaphorical monster that will crush you.

Feature creep begins innocently enough. A customer or stakeholder asks for a favor, which seems trivial, and then asks for more. Eventually, you will spend more time granting these favors than building what you agreed upon. Developers with experience become highly sensitive to feature creep because it has impacted their careers negatively at least once. If you are a project manager or a scrum master, you must be on the lookout for this dysfunction.

To fight feature creep, a scrum master or coach must practice some petty tyranny. Log each favor or new request in the product backlog. If someone is working on something not in the backlog, they must stop. Agile people have an apocryphal saying, "If it is not in the backlog, it does not exist." Favors and requests for new work must go into the backlog and go through a process of refinement and coaching. Otherwise, this undocumented work will threaten your project.

Next, you must have frank conversations about what is essential and what can wait. Often, people are inspired in the middle of a project and feel they can help by offering suggestions. It is a good thing, but it usually leads to feature creep. So, the first question you must ask when someone makes a suggestion is whether the suggestion is necessary to improve the product or is just a nice option. A question like this generates healthy conversation about the priority or importance of work. Saying what things are nice and which are required will provide plenty of clarity.

Finally, if something is required and is a high enough priority, it is up to the stakeholders to remove something else from the project. It introduces the notion of trade-offs to people paying the bills. If data accuracy is vital to them, the new request for speed might impact that feature because caching impacts the number of times the system gets fresh information. A UX change may not work on legacy web browsers. Making trade-offs like everything in business, technology, and politics would be best. In project management, someone must resist magical thinking and impotent manifesting to be the voice of reason and common sense; that person is often the scrum master.

So welcome change in your project, but ensure everyone understands the repercussions of change. Document all ongoing work in the backlog and prioritize tasks through open and honest discussions about what is essential and what can wait. Finally, when priorities change, do not be afraid of sacrificing previous priorities to accommodate new ones. Everything is a trade-off, and everyone should understand what those trade-offs entail.

By approaching your work this way, we can significantly reduce this risk, making it much more manageable. By approaching your work this way, we can dramatically reduce this risk, making it much more manageable. It is a goal we should strive for in each project.

Until next time.