Good Communication/Bad Communication: Software Planning Edition
In the world of software development, successful communication is like well-written code – it's precise, clear, and functional. Nowhere is this more apparent than in the software planning process. At the heart of this communication are terms and concepts that help technical and non-technical parts of an organization get on the same page. However, like any language, the jargon used in software planning can hide deeper issues or cause additional problems. Let's take a closer look at some of the most challenging phrases and examine how they’re used in both the best and worst cases, as well as questions you can ask to find out what’s really happening in the process.
Phrase: Technical Debt
Best Case:
Technical debt, at its core, is a way of acknowledging a past shortcoming in your system. It's like admitting you took a shortcut on your way to an important meeting – it helped you arrive on time, but now you need to fix your wrinkled shirt and crooked tie. Technical debt usually stems from trade offs made in earlier development phases that have, over time, stood in the way of your goals. In the best case, it's an honest conversation starter – "We cut corners here, and it's starting to catch up with us. Let's talk about it."
Worst Case:
Now, imagine if your wrinkled shirt and crooked tie were used as justification to buy a whole new wardrobe. This is the worst-case scenario for technical debt. Technical debt, the phrase, can be used as a means of slipping in a favorite feature under the guise of a necessary fix. Picture a product owner adding their dream feature as "technical debt" or a development manager pushing system changes that don't significantly benefit users or stakeholders.
Questions to Ask:
What are the consequences of waiting to address this technical debt?
Can this work be broken into multiple pieces?
How does this issue affect clients/users/stakeholders?
Phrase: Feature Creep
Best Case:
Feature creep is when stakeholders, product personnel, and/or developers add additional features to a sprint/product/release without putting the injections through the proper planning process. The phrase Feature creep is often used to call out this (mostly well-meaning) bad behavior. When used in this way, the phrase is a shield used by the product development team to protect their well-planned and functioning sprint from unwarranted interruptions. In the best-case scenario, it's used to ensure that only genuinely valuable features make their way into a sprint.
Worst Case:
In the worst-case scenario, feature creep can be a weapon to prevent outsiders from questioning the decisions of the product owner or the development lead. The phrase can be a brick wall built to protect personal agendas. Sometimes injections are needed, warranted, or strategically important. At these times, dev teams need to be agile.
[NOTE: some stakeholders are prone to interrupting sprints for features that could wait. The more you break a team’s cadence, the less likely they will believe you when you claim a feature is needed, warranted, and/or strategically important.]
Questions to Ask:
Is this feature already on the roadmap?
When could this feature be included?
Can we meet to discuss what this feature means for [client, company, strategy, etc]?
When is your next sprint planning and/or backlog scrubbing meeting? I would like to attend as a stakeholder and discuss.
Phrase: Minimum Viable Product (MVP)
Best Case:
Minimum Viable Product (MVP) is the absolute minimum product that can be delivered to a client while still providing value. An MVP may or may not have commercial value—meaning, you may or may not be able to sell it to clients and prospects—but an MVP always provides value to users of the product. In the best case, dev teams building an MVP deliver something users are happy to have, even when those users can envision ways the MVP could be better. A well-executed MVP focuses dev team efforts and creates excitement among users/clients.
Worst Case:
Unfortunately, the terms minimum, viable, and product are all up for debate. One of the most challenging decisions in early-stage product planning is whether an MVP is actually an MVP. Disagreement may arise on whether too much or too little is included in the first deployment (see Feature Creep above). Or arguments may occur around the level of product quality needed. Or conflict may bubble up on what product to actually deliver. Here’s a contrived example to illustrate these debates: Is an electric motorcycle with a range of 50 miles and whose kickstand binds up half the time an MVP of an electric taxi cab?
Questions to Ask:
Who are our primary users? What are their characteristics? What are they trying to accomplish?
How does the MVP candidate provide value to users?
Where is the MVP line drawn? What features are vital, which will wait, and why?
What will be included in the next iteration, and what additional value will be delivered?
When is your next product planning meeting? I would like to attend as a stakeholder and discuss.
Phrase: Refactoring
Best Case:
Refactoring is a process of improving a software system without changing the system’s output. These changes may make the system easier to test. Or they may enable the team to make faster, less invasive changes in the future. Or they may allow other teams to access the codebase for additional projects. Or make dozens of other types of improvements. Refactoring is often done as a natural component of a well-running sprint cadence.
Worst Case:
Refactoring, like other phrases on this list, can be used to justify pet projects or otherwise hide the real work being done by a product development team. At its worst, the term can be a software planning Trojan horse, concealing anything from system gold-plating to massive multi-system redesign, all under the guise of "making improvements."
Questions to Ask:
What is the scope of the refactor?
What are the consequences of waiting to do the refactoring in question?
How could the proposed efforts be broken up over multiple sprints?
How much improvement in testability/maintainability do you expect from these changes?
Conclusion
The terms above—technical debt, feature creep, minimum viable product, and refactoring—can be used in both product and counterproductive ways. Effective software teams tend to use these terms on a best-case basis, while ineffective teams tend to use these terms on a worst-case basis.
You can create an organizational culture in which effective teams can thrive by asking questions that build trust, openness, and accountability about the work being planned by your product development staff.
