For my inaugural post on a very new blog, I'd like to discuss the concepts of reuse and reinvention, or the danger of mixed paradigms, from a lean point of view.
In his book The Toyota Way Jeffrey Liker writes about the importance Toyota place on "this and" solutions as opposed to "this or" trade-off's. One example given in the book talks about the development of Toyota's luxury vehicle Lexus.
During the development of its flagship luxury product, Toyota wanted to ensure a very quiet ride, but they also wanted to provide a good amount of horsepower to the vehicle, so that it could perform to the levels that a consumer would want in terms of acceleration and overall top speed.
The engineering team believed that excellent horse power could be achieved, but that the mechanics of the engine meant that it would be a loud engine at high speeds. The usual approach to this problem in the car industry was to increase the amount of soundproofing in the firewall between the engine and the car cabin. This soundproofing, however, weighs a lot, which conflicted with Toyota's goals of having a very light car. When Toyota began the project, many of the engineers on the team viewed these factors as trade-off's.
The chief engineer, however, Ichiro Suzuki, would not accept such compromises. (The title of this chapter in the book is "The 'No Compromises' Development of Lexus). He challenged the engineers to determine a way to keep the sound quiet at high speeds by analyzing sound at its source - the engine. Through some clever engineering and cross-functional collaboration Toyota was able to improve the elements within the engine that create noise, solving the problem at its source, and meeting both the goals of a luxurious, quiet ride, and a powerful engine.
Coming back to software development - how can we have a "this and" approach to reuse and architectural design, whether it be SOA or anything else, while also maintaining a fitness to purpose necessary for a good, flexible piece of software?
I'm not a developer, but more of a peripheral participant as a servant leader in our software organization. At different times I've been a systems admin, a Project Manager, and a Business Analyst. The "this and" effect applies to requirements and UX design as well as code, though. Specifically, I've been thinking about how loss aversion bias affects the work that we do in acquiring the knowledge to build a software.
In lean, inventory is a cost you carry, and is a fundamental (although sometimes necessary) waste. In agile, knowledge about what a software should do is inventory that expires and changes, losing its value as time goes on. Many Agile practitioners agree that it is a fallacy to try to know everything about a software before you begin building. They believe that the moment you know the most about the software is the moment when you are done with it. So we buy knowledge by doing the most fundamental and value-added aspects of a project first, capitalizing our gains by prioritizing our time toward value.
So when we are first imagining a release, or a new software, we are making the investment necessary to determine what that high-priority item is. During the beginning of a project we use those first assumptions to determine our first investments.
But how often are our fundamental assumptions at the beginning of the project correct? More importantly, how do we get to those initial prioritized value-driven features, and thereby improve our initial investments, which are often the most critical investments of the project?
To come back to the title of this post, I am concerned about the question of how often the product owner's team (by this I mean BA's and UX design, along with product owners themselves) reuse features as solutions to problems when they are not necessarily the best response to that situation?
I assert that initial conceptualization of a software is a "this and" situation. That the value of the product owner and their team is in their alignment to the customer, whether the customer be internal or external to the organization, as well as the insight they bring to the problems that the customer has.
I believe that feature selection is really an extension of design, and that great design honors and exploits prior experience while also bringing a Shoshin or beginner's mind to the problem at hand, for all software is fundamentally composed of a solution to a problem and that solution's execution.
I think about it like this:
The simplest component is that a solution be aimed towards a problem. This sounds ludicrously simple, but how often have the weight of our solutions created their own orbit? How often do we develop solutions to problems that don't exist, or are solutions to problems created by previous solutions?
In my arrow analogy, the quality of the solution determines the quality and path of the arrow. The best arrow for the bull's eye at hand will do no good if it isn't shot well and straight. Execution is important. This is why we do TDD, CI, automated testing, and etc.
At the same time, if previous knowledge of a problem is true and valuable but does not apply to the problem at hand it is as if we are using a shoe as an arrow. It may be the nicest, best made shoe we've ever owned, but this will not make it hit the target. (No correlation is to be drawn between the shoe and the target in the form of President Bush's press conference).
By using "this and", a knowledge and respect for the work done previously on the problem, and a Shoshin mind, we can eliminate significant waste by making sure that we truly have the highest priority item identified for development - and that we will know the most about that which is the most important.
0 comments:
Post a Comment