Updated: Updated: Architecture
There is a lot of debate going on these days about Agile, Fake Agile, Modern Agile. While I agree with much of it, I am not too keen to get into the middle of it. What’s clear, though, that there are a lot more subtleties to being Agile than might be apparent from the onset. One of them is naming things.
Time to value vs “efficiency”
During an architecture workshop the other week, we discussed and dissected why delivering new features takes so long. Now no business has ever complained that IT delivers too fast, but in this case a relatively simple feature took almost six months to deliver, so I was inclined to dive into the details to find where the friction sits.
During the workshop discussions we also identified several architecture principles to guide decision making. One principle was Short time to value over “efficiency”. The air quotes denote that what can be perceived as efficiency relies on the assumption that if we knew the exact requirements ahead of time, we could build the solution more efficiently than with an iterative approach. The catch, and the reason for the air quotes, lies in the base assumption of knowing all requirements in advance. As most of us have experienced, this assumption doesn’t hold for modern software delivery, rendering the search for this type of efficiency futile. Jeff Sussna has summarized this misconception in the very nice slogan “the new efficiency is the ability to steer”.
Incremental delivery considered harmful?
Following this principle, I suggested that we should break up the delivery schedule into smaller, incremental deliveries (dare I say “MVP” - Minimum Viable Product?). As so often, good ideas find unexpected obstacles in practice, though: the counter-argument in this case was the product team insisting that the feature would be useless unless fully built and a partial delivery hence wouldn’t make sense.
Such discussions between product manager (or owner) and delivery team are actually not uncommon. The most extreme example I have seen was a product owner straight out refusing to show an intermediate product to a small set of test customers - after all they had spent months discussing and documenting the requirements and UI mock-ups. No wonder people write about fake agile… sadly, though, a pain shared isn’t a pain halved in this circumstance. You’ll need the product team by your side make incremental rollouts work - IT can’t be agile on its own.
When finding such “conflicts”, my general approach is to see whether both sides can be right in their own way. If so, by showing a different model or finding a new solution dimension, you may be able to accommodate both views and move ahead.
Naming for incremental delivery
In this case the feature was relatively simple. Referred to as “Recent searches”, it would add a drop-down box to the search function so that a user could quickly select his or her recent searches. Part of the long delivery time was attributed to having to build a personalization function that identifies the user so that the associated searches can be retained.
Acknowledging that a partial feature delivery was considered not valuable, I contemplated whether choosing a different name for the feature could make it more natural to deliver incrementally. Specifically, my instinct was to rename the feature to “Suggestions”. This name would not describe the implementation, but the value the user would receive: instead of typing the user could choose from suggestions. Renaming the feature to highlight the user value instead of the implementation enables a series of implementations that deliver incremental value:
- Hard coded popular items
- Popular items based on recent searches across all users
- A specific user’s recent searches
- Paid placements (if deemed valuable)
Rolling out in such a sequence would not only allow delivering value before the difficult personalization function could be completed, it also provides the advantage that the list of suggestions wouldn’t be empty when the feature is still new. Naturally, it would also allow collecting feedback on the feature usage to perhaps develop even better ideas onhow to populate the drop-down, such as suggestions based on user profile.
Careful naming pays off
In summary, naming is usually a delicate affair. When looking to support incremental feature delivery, careful naming that focuses on the user instead of the implementation can help. Lastly, such nuances you only discover when practicing agile methods for a while, not from reading books.
Make More Impact as an Architect
My book The Software Architect Elevator helps architects and IT professionals play at the intersection of technology, organization, and transformation by sharing the real-life journey of a chief architect. Buy it on Amazon US, Amazon UK, Amazon Europe
