“We must do a microservice in the Cloud with a service mesh”. Another day, another technology choice. But when you ask “Why? To do what?” and get only a messy answer, it is better to stop the initiative.
I had this technological focus coming from an engineering background. As engineers, we enjoy solving complex problems through design, creativity and elegant solutions. The thing is, the problem must be valuable to be solved in the first place.
The Why and the What are essential elements of any software initiative. Precipitation due to impatience, pressure to deliver and organizational culture can create dangerous shortcuts, confounding being busy and delivering value.
This article shares the key elements of a structured methodology you can apply to any software initiative. The deliverable you will produce must be understandable by the whole team, including for the business stakeholders :
- A How is meaningless by itself
- A How must Start with Why
- A How cascades from a clear What
- A How is one of the possible Hows
- A How of value requires Methods
Let’s start by clarifying why there is no time for unclear initiatives.
A How is meaningless by itself
Some people would argue that some technology initiatives without a clear business reason are still beneficial: “It is better to have an upgraded software rather than an old one.” The thing is, would you use your entire salary just to upgrade your car?
Implementation requires time, energy and money. There is no time to lose in a digital world of accelerated competition and limited resources. Unclear initiatives are missing the importance of opportunity cost: the loss of other alternatives when one alternative is chosen.
Opportunity cost – the loss of other alternatives when one alternative is chosen – requires to prioritize the Hows in Quality Engineering.
Antoine Craske
Companies need economies of scale and speed to survive. Things change fast. One software asset of value today can be completely replaced while pivoting a company. This is why siloed initiatives that are missing clarity are most probably a waste of money.
Quality Engineering has no place for waste, only for value.
A How must Start with Why
The Why is essential to any activity. Simon Senek made the expression Start With Why popular in his best-seller book. It is also found in various points of the 7 Habits of Highly Effective People by Stephen R. Covey, also reaching millions in his life and behaviour advice.
The Why gives us meaning, purpose, and long-lasting objectives. The Why drives our action cascading on the What the How, and even on the Who. The Why materializes the value of our actions. Through history, why enable people to endure dramatic periods like in Man’s search for meaning by Viktor Frankl.
A compelling Why is an enabler of extended collaboration. People were able to build cathedrals and other lasting monuments by believing in the overall vision, mission and why. Organizations need a driving Why, led by its managers, to keep a value alignment during implementation.
In Quality Engineering, the Why is the raison d’être and drives the gap of value we must continuously deliver to our users. We create value in making our users successful in solving their problems. Software, as good as it is technically, is meaningless if not valuable to someone who matters.
All reasons to have a clear Why before moving to the What.
A How cascades from a clear What
A structured perimeter is essential to an effective implementation. There is no time to waste on the How until the scope is defined. That would probably lead to partially valuable, complex and lengthy implementations full of unnecessary rework.
The What cascades from the Why. It can be an experiment to assess the potential value of a feature to our users. It can be an addon to an already successful feature. It can be a fix detected from an incident or security report. Whatever it is, it should be clearly stated.
Delimiting the perimeter of a software change is vital. It forces to be more concrete about a proposed feature use-cases. It starts to raise out of scope elements and non-functional requirements such as device coverage, performance or security.
A clearly defined scope is also essential to the collaboration of expertises. Product owners and engineers must be aligned on what they are trying to achieve. From that point, they can even prioritize the most valuable What to focus on first.
Only then they can work on the different possible implementations.
A How is one of the possible Hows
There is no single How. Various solutions exist to the same problem. They respond differently and so have associated trade-offs. This is why a single How is not enough, a solution with no cons is not enough, and context is key.
Knowing the possibilities allows you to choose better. A single How is dangerous by lacking perspective on the problem to solve and involved trade-offs. You can eat at a pizzeria, a Michelin restaurant or a fast food, all answering the need to eat. The overall experience is different in terms of pricing, timing and nutrition. Once you have various options, you need to choose one. That’s the importance of trade-offs.
Trade-offs help articulate the pros and cons associated with a particular option. They are necessary to overcome specific biases of decision-making like confirmation or recency. They also help to factualize the options that facilitate collaboration. Trade-offs must not be mixed with decision-making. All options have trade-offs. A proposed solution with no cons must be challenged to identify them. But deciding if they are good or bad depends on context.
Context drives our decision-making by prioritizing certain criteria over others. The context contains the Why and possible evolutions of the organization, both essential elements of taking a decision. Buying a house is not always the solution. You can buy different houses if you are single, in a couple or building a family. You can buy, rent, or even rent with a buying option.
The power of structure is the result of this process.
A How of value requires Methods
The Why secures the real need to work on the initiative. The What challenges what to do, in which order and under which perimeter. The How gives the power of choice to articulate the most valuable trajectory in the system.
A structured process is the foundation of organizational performance. A systematic approach enables an increased output and better scalability. The decoupling of step-by-step phases accelerate the result, reduce complexity and avoid unnecessary reworks.
Quality Engineering is the continuous delivery of valuable software to our users. It is the achievement of Quality at Speed in an ever-challenging ecosystem. There is no energy, time and money to waste on unclear initiatives.
The Quality Engineering Framework, MAMOS, starts with the Methods. It is the way to implement total quality, lean and other valuable structured processes to software delivery.
So when it starts with How, stop it right now.