Why have we seen the proliferation of so much “SOMETHING Driven Development” in Agile? A quick internet search for “Driven Development” came up with this list:
[one_third]- Test
- Feature
- Perceived Value
- Behavior
- Design
- Career
- Hypothesis
- Support
- API
- Problem
The reason most of these exist is to identify what to build and assign value to that effort. This is because of what many companies actually do: Marginally Useful Driven Development (or MUDD).
MUDD is the process by which requirements are created in several ways:
- In the absence of any real business need
- In the absence of any real business or competitive analysis
- In the absence of concern for cost or value
- Trying to keep stories in the backlog to appear busy
Identifying MUDD
Identifying MUDD takes a little practice. However, the fundamental rule is requirements and directions need to come from the business. The business is responsible for defining “what” to build and “why”. They are responsible for communicating the business need and the value of what is being built. They’re also responsible for researching marketing risk for user adoption for a particular product or feature. You can identify MUDD if there is no market value and risk analysis. The best way to identify MUDD is to identify the source of the product requirements. If they are sourced from the development team, you’re likely in MUDD.
Why MUDD Persists
Rarely do development teams question if a feature request or product is MUDD. A full backlog equates to job security for developers. So, there’s no incentive to question the value of features. In addition, if the developers are working, business and management don’t have to get involved. This makes MUDD very difficult to address.
Clean out the MUDD
Teams and individuals which raise MUDD concerns are your most valuable employees. They care about the product and company. The goal of identifying MUDD is to remove it from the backlog. This creates space and pressure to be creative and do the market research to identify actual customer needs. Listen to the MUDD identifiers, justify the existence of the feature requests, and prioritize stories with the most customer value. You will have an organized team working on something of value. People will work much harder on something if they know it’s useful and has real value. In the end, you’ll deliver a higher quality product which meets the needs of the customers and have happier employees.
- Everything is a P1 - July 22, 2020
- The Danger of Agenda-less Meetings - April 21, 2020
- Strictly Agile - February 12, 2018