Product Development

From Tune Phase to Upfront design

Florin Zalum

• 7 min read

Blog post available in read-mode

The Value Engine is an Agile Framework built to promote value and reduce waste in the product developement. It might be also many other things, that is why I recommend watching a introduction to the Value Engine [1], before reading this Post.
The Framework defines a set of phases with a specific purpose that each initiative should pass to be successfull. One of these phases is called the Tune phase, and its purpose is to do the last business improvements and reduce Technical Debt. In this Post I will share my opinions about the Tune phase with a focus on the Technical Debt reduction, from a programmer perspective.

What you can read about

Bringing tech and product development closer.

When I started to work with the Value Engine, it was the first time the product development team (Product Owner aka PO & stakeholders) refer to Technical Debt in their discourse. And it is not only that they started to use it as a buzzword. They, as users of the Value Engine, integrated it in the product development lifecycle.
You already see, that I am speaking with they (as product team) and we (as engineering teams). Some may think how come we still talk like this. The Agile Manifesto tried to reduce the friction between the roles by giving them a single goal: working software. But there is one point of tension which is: PO-s have to deliver features, developers have to deliver quality software. Every time one is endangering the other's goal, bang a conflict might happen. You might say: No, we have no conflicts. Of course, because we are adults, and we negotiate our goals. But isn't it strange that this source of conflict between features and quality even exists. Another voice might say: "This paragraph in the Agile Manifesto is addressing exactly this conflict". Yes, maybe. As far as I am concerned, the Agile Manifesto was showing the way, leaving a lot of interpretation freedom. And none of the interpretations that I used until now, were explicitly addressing the technical debt as part of developing a business idea.

Naming things.

While in the description of the phase, one can hear about all the things which the technical heart seeks for like: refactor, redesign or redo, its name is a bit deceiving. It does not say what it is actually means: reduce technical debt. If you want to send a rocket in the space, and you do a tweak before launch, you do not expect to rebuild the whole rocket. It creates a wrong expectation towards the sponsors of a business initiative, when the team announces that the initiative is a success, and it just needs a Tune phase.
The value of the Tune phase it that it eliminates the technical waste for 9 failed ideas out of 10. And the name should not suggest shrinking the technical investment step for the single idea that brought results. I would rename it to "Fix phase" or something better than "Tune".

Methodology Yoyo.

There is one mistake that all organizations do when they adopt a new methodology. It usually starts with a success story. One IT team starts to use Scrum for example, it proves to do the job, and then it is ruthless implemented in the whole organization, through an agile transformation process. After some years of doing stuff by the book, it tragically fails and the organization is moving to another transformation, maybe even back to waterfall product development, and so doing a Yoyo move [2] between two or multiple methodologies. There are two types of forces that creates the impulse of the Yoyo movement. One are the methodology's parents. They are happy to see their child being used in different situations, even if sometimes it is not the right place. Secondly, the euphoric users that apply a new tool as much as possible (like an exaggerated Microservice Landscape). And this can happen also to the Value Engine. That is why it makes some sense to provide some guidance on how to use the new methodology and how to adapt it if needed.

Problems by complexity.

The Value Engine is very good at addressing uncertainty. When you deal with x millions users, it is absolutely impossible to know what will work and what not. What I like in the Value Engine is the ability to challenge everything. However, a part of daily product decision are addressing simple problems. If you want to show your customers delivery information of the current order, you do not need to do an experiment. You can not do much wrong by just showing it.


An uncertain situation and a simple one are sitting on two extremes on the complexity scale. Treating a simple problem as a complex one or a complex one as a simple just does not sound good. It is more sensible to choose the right tools for the right situation. A simple problem has a simple answer. A complicated problem can be solved by experts in a domain. And a complex problem with a lot of uncertainty screams for experiments. Treating a complicated problem as a complex one, might be a trap [3] Why? Instead of searching the answers in your organization, you search the answer in the wild by doing an experiment, which is a source of waste in this situation.

Make or buy.

There is a trick on how to avoid implementing complex solutions to complex problems. One can look at the evolution stage of what you want to build. If it is a totally new product on the market with a lot of uncertainties, there is no way out. Experiments are a given. Instead, if the product is already on the market it makes sense to just buy it. If you open an online shop nowadays, it probably does not make sense to build it yourself, because e-commerce has become a boring product that you can just use it as a service provided by someone else. But if you want to deliver your parcels with a drone (being unaware about the progress in this domain and considering that there is no current solution), you are just condemned to prototypes and experiments. How come we are rebuilding stuff in so many organizations? Mainly because there is a missing service, or we are in love with our solutions.

I agree that customer interaction is one of the most difficult things to deal with, and you can only tackle them with experiments. I do not know any product that can predict the customer behavior by building the perfect interaction from the start, but I know customers that are used to existing products/services. When building a service, it forces you to do experiments, but using a service to satisfy your customers, means that the experiments costs are well covered in the development of the service that you are using. If a music producer is searching a way for publishing musical content, it might be crazy to build a music platform, where he could just publish the content on Spotify&Co, as they already solved the customer interaction problem.
Watching evolution, from new to product and to commodity [4], is an important tool to know if you want to tackle complexity or get complexity out of your way.

Methods by evolution.

One can use evolution not only to decide if you avoid experiments by buying a service, but also to choose the methodology. It creates waste if a methodology is used to build for uncertainty in situations where the things are standardized. As my street is getting fiberglass wired the process looks like the following. The whole neighborhood gets a 3 months plan for whole installation. Each 3 days a new street gets the cables underground, and we have 30+ equal sized streets. The activity is repetitive and extremely precise, as no hole in the ground is done by mistake and afterwards everything looks like new. Do we need experiments, or sprints for such an activity? No, a proper plan done by experts and with the help of standards in a waterfall style project is enough. Some might say: "But 2021 is a bit late to get high speed internet, so something, somewhere went wrong". Nothing went wrong with the organization of the project but with the technical solution itself: which is ground wiring (air Cables are faster to implement, but uglier, and satellite internet has a future).

Technical skill on mute.

The Tune Phase is telling the programmer: "No worries we will address that technical aspect at the end, for now just don't think about it." Why should a programmer just forget the skill, which was trained over years to have a right balance between quality and speed? This skill can still be useful if activated. Especially for cheap decisions that become very expensive later. One classical example is seeing a design flow in the datamodel when starting the experiment. The fix would be cheap, though it is postponed for the Tune phase. The experiment is a hit. It floods the datamodel with millions of records and suddenly the datamodel is expensive to change. Early expensive decision which remain the same as expensive later, is the real opportunity that the Tune phase opens.

For inexperienced programmers, it should be still given the chance to take technical decisions during the whole process, otherwise we won't build a highly skilled technical team.

Evolving the Technical skill.

For the experienced programmer though, the challenge of the Tune phase is giving the chance to sharpen the skill. With the years of experience, besides the skill, each programmer builds up also strong bias towards technical excellence. For example CI/CD can be a strong prerequisite for each buildable piece of software. Though the context of some experiments might create non-standard CI/CD pipelines setups, that would need more time to create than the standard pipeline. If we are at a phase when we do not know if the idea will succeed or not, it is a waste to prepare it for the next hundreds of deployments.

In short.

The Tune Phase is addressing Technical Debt bringing the product and engineering team closer, though it does not benefit the name to express this.

Technical decisions should not be exclusively postponed for the Tune phase, especially when they are cheap earlier than later.

The Tune phase might have different effects on the team members which should be considered.

The Upfront design and Tune Phase are sitting at the opposing ends of the software design. I suggest to use complexity and evolution as criteria to choose the right approach.

The value engine has other good built-in ideas for the digital product development, so I would not drop using it when Upfront design is required, but rather use Upfront design and its flavors for individual initiatives that flow through the Value Engine.

References

[1] - Value Rebels, The Value Engine

[2] - Simon Wardley, Methodology Yoyo (30 seconds)

[3] - Michael Sahota, “Agile” Culture & Leadership Training

[4] - Simon Swardley, "Crossing the River by Feeling the Stones"

Comments

Sign up for more like this.

Enter your email
Subscribe