Describing two project archetypes: the tech-centric project breakdown, and the customer-centric alternative.
For the sake of discussion, let's consider a change to a fictitious software system that has administrators and regular users. It's not important what the system does; we'll be discussing a specific pain point for administrators: administrators should be able to choose between minimalist and advanced editing modes. The minimalist mode has a simplified view and the most common operations. The advanced mode has detailed reporting and more complicated inputs for advanced operations. Currently, all administrators see the "minimalist" editing mode when they log in, and they can switch to "advanced" mode via the settings menu. Most administrators only ever use one of the two modes (and about 42% of admins use the advanced mode). Many of the admins who use advanced mode are frustrated that they have to click into settings and toggle the mode every time they use the application. (Because of their elevated permissions, they must be logged out after each session so they log in and choose the advanced mode regularly.)
The following is the approach that I've seen most often. It could be characterized as "the traditional way" or "big design up front".
This approach is counter-intuitive because it apparently requires more throw-away work. It requires imagining the system in an intentionally incomplete state. That said, in practice, I've found this approach actually reduces throw-away work and guesswork.
In both cases, we had UI work, API work, and database work. In the tech-centric approach, we worked exclusively on one layer before moving on to the next. In the customer-centric iterative approach, we worked primarily on one layer at a time, with some small changes to other layers to integrate. (For example, for the second step we updated API and UI; for the third step we updated the DB and called it from the back end code.)
In the tech-centric approach, the primary slicing strategy is technical. In the customer-centric iterative approach, the primary slicing strategy is based on customer value (but we slice in such a way that the technical complexity is still distributed across all the slices). In both cases we split the technical complexity across multiple tasks; the difference is whether we track our changes in terms of the customer capabilites that we enable or in terms of the technical changes that we make. This is significant because the customer-centric tasks leave us open to finding creative technical alternatives that achieve the same outcome. On the other hand, in the tech-centric task breakdown, we need to complete each task as planned because we are counting on the collaboration of all the technical components to satisfy the customer requirements.
In the customer-centric iterative approach, we did four releases instead of one. This means:
If we don't have the automation to keep the release cost low, then we're incentivized to postpone releases.
In a case where our release cost is high, we can still take a customer-centric iterative approach. Instead of launching after each step, we present a demo of the new behaviour. Although the demo doesn't resolve customer pain, it does still earn trust and solicits feedback (allowing us to correct our course early if needed). At the end, when all the steps are complete, then we can perform the costly release activities to launch the changes to customers.
In the tech-centric approach, the design document author made all the interesting technical decisions for the feature. Then, everyone who helps to build will implement the decisions made by the document author. On the other hand, in the customer-centric iterative approach, the document only specifies the customer capability which must be enabled at each step. There is a suggestion for how to implement it, but it is brief and independent of the other tasks. This means the coder gets to make the final decision. If you're in an organization that values detailed design documents, then the coder can produce a wiki or other written artifact as part of their work. (This is also may be a great time to use Architectural Decision Records.
The result of the customer-centric iterative approach is that all team members get to participate in the design (because the intersting decisions are made just in time, concurrently with the development).
Whereas the tech-centric project approach requires up-front design review where we anticipate problems, the customer-centric iterative approach postpones that assessment until we have something executable to experiment with. Personally, I find experiments more rewarding than "predict-the-future" meetings because I'm not very good at predicting the future, and I don't like being wrong. I'd rather do experiments so I am wrong less (and can code more) than discuss weeks or months in advance of building (and risk guessing wrong). I have found that guessing is often more expensive than designing the project in a way that makes experimenting cheap.
In my experience, it's more natural to take the tech-centric approach to implementing features, but it's safer, more rewarding, and more helpful to customers to take the approach that I've called "customer-centric and iterative". It comes down to preferring to adapt to change over following a plan.
Something to add? Continue the conversation on Twitter