Balancing act between delivery excellence vs engineering excellence – that tough last mile
It isn't what you don’t know that gets you into trouble. It’s what you know for sure that just isn’t so. ~Mark Twain
Innovation is the key to success for any Product Development Company. Innovation is important in whatever we do and is necessary to sustain in today’s market place. Else a competitor will overtake us very easily. Often considered as the Holy Grail for which every organization should strive for, sustainable innovation needs a strategy from start to finish. Over the years, working in the Product development area and working with quite a few talented and smart developers, has exposed me to see what they do and what outcomes they get on a day to day basis. They will also get to hear a lot of standard advices as to how should be product development managed. In reality, what works is different from these standard advices.
In his book on “The principles of Product Development Flow: Second Generation Lean Product Development”, Donald G Reinertsen argues that, what actually works is usually different from the standard advice even when the team includes a group of smart and experienced developers.
His argument is his words, “I believe that the dominant paradigm of managing the product development is fundamentally wrong. Not just a little wrong, but wrong to its very core. It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing. I believe that a new paradigm is merging, one that challenges the current orthodoxy of product development”
The teams, on the other hand, face the dilemma in terms of what should be focussed on among the following:
- Whether it should be the best quality code or should it be on time delivery.
- Doing everything that we do, at best quality, the very first time.
- Understanding and defining what value can we deliver to the end user.
- Having the best developer experience
Most of the developers tend to repeat the behaviour that yields them the desired results, which in theory isn’t supposed to be so. But discovering the best way of getting the results that is desired is not enough to develop something that is significant. Every now and then, there should be a focus on innovation that should be inculcated as part of the Product Development process. Not by force, but by explaining the value that it can bring in.
I remember this example from my developer days. I was working on OEMization of hardware products, wherein we had to customize a set of device driver files manually to reach a situation where we project the product as a new product by giving it a new identity. After that, the approach was to make it work with all languages for the target market that the product was designed for, test it, validate it and get it released. The entire process used to take around four to six weeks’ time depending on the time that we would get the whole process working. Of course it was product development. Of course we had new challenges every release with either the devices or the firmware or the drivers or the translations. There were releases that demanded us to stretch our working hours, just to meet the time lines. It took some time for us to realize and come with an approach that can be completely automated, based on a data file and translation files. This step in the direction of innovation brought down the overall product development time significantly, to just a few minutes once we knew and had the required data. The outcome was very evident, scalable and significant and made us think even more in the direction of innovation.
But the challenge is when we don’t know that the facts that we know aren’t the facts, but are the working assumptions that we go with, while building products. This calls for the hypothesis that are supposed to be validated based on the outcome of every release of a product to the end user.
The challenge is in optimizing the development cycle time, which may be perceived as optimizing the development team’s time. However, efficiency of a team is as important as innovation which is the life blood of the product development teams.
When achieving delivery excellence, the focus is to make the end user happy by having early feedbacks in the development cycle (mostly being Agile), so that the feature requirements are understood well, adapt to the changes that may come as feedback, work through iterations by providing minimum viable product(MVP) that delivers a good value to the customer, release after release.
Whereas, while achieving engineering excellence, the success factor differs as compared to achieving delivery excellence, as the focus is on making sure everything that we do is done in the best possible way, with best design, with best code quality and with an efficient automated testing safety net along with automated integration and build processes that help the teams in achieving seamless and continuous integration and delivery.
Challenge for any Product Development department is that both are equally important to focus. And this amounts to the pressure that the teams go through, mostly towards the end of the Product Development life cycle. Agile and lean product development approaches address the problem in a way but in reality, the dilemma of balancing between Delivery Excellence Vs Engineering Excellence persists for the developers who work in this environment on a day to day basis. And hence Innovation may take a hit.
Some approaches that would work in making this balancing act easier are:
- Innovation should be part of the culture of the organization and that needs to be continuously nurtured.
- Keeping the Work in Progress limited to the agreed limit within the teams so that there is always work taken to closure, instead of having increased WIP, which means increased lead time and that in turn would mean increased time to market. Keeping the WIP within the limit also helps in avoiding multitasking which not many of us are very good at, except a few exceptions. In fact, I have heard complaints from developers that switching contexts quite often actually decreases their productivity.
- Value Creation should be a focus of the development process, whilst ensuring engineering excellence that motivates programmers is also achieved.
- There should be a good Idea Management Process so that the ideas won’t get lost in midst of tremendous amount of work that gets done on a day to day basis.
- Hackathons with specific goals should be part of the culture where people hack away the best possible solutions at an amazingly little period of time. Again, the work done in hackathons should be value driven so that they should solve problems while being excellent piece of engineering.
- Worship of efficiency in everything that we do.
References:
The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen