Guest post from Bart Huthwaite
Quick time-to-market comes from getting the small things right. Here is a check list to follow:
- Smaller is better. Keep your product team small, typically no more than 6-8 members. And make sure all know the importance of product speed and are totally committed to it. Communication is faster when fewer are involved.
- Get the “Big Picture” first. Don’t start without a clear “end-in-view” and a strategy for getting there. Build your strategy on the strategic values which will make your product or service a long term winner. Your team members will be able to make decisions faster. Strong “buy-in” to a team’s game plan encourages faster response time when crises arise.
- Work in parallel. Parallel work compresses product launch time. Constantly work to build confidence and trust, thus encouraging early understanding and commitment of these parallel teams.
- Avoid “sand bag” solutions. Sand bag solutions are those which slow down a new product effort. These can include specifying a new, untested manufacturing process, launching a product with an untrained sales force and implementing a new CAD system the same time you are developing a new product effort. These kinds of innovation are best done “off-line,” and are only inserted into the product development cycle when they are fully proven.
- Create a “Team Efficiency Charter.” Identify and agree on the characteristics of a highly efficient new product team. Good product teams build standards of excellence and then adhere to them.
- Measure both product effectiveness and team efficiency in “real time.” Product effectiveness is how well your product is attaining its goals. Team efficiency is how well your team dynamics are working, such as the speed decision-making and follow-through. Fast track product teams keep a stop watch record of everything.
- Think ahead. Develop your product in three generations. This helps your team anticipate the future. I call this technique “step”, “stretch” and “leap.” This helps you prepare for future shifts in technology, competition and marketplace changes. This helps you avoid “re-inventing the wheel.” Only insert new technology into your product when risk has been reduced to a minimum.
- Get management involved and committed at the early concept stage. Management buy-in “up-front” reduces your team’s fear of failure. Do this beginning at the early product concept stage.
- Be time driven. Never start a meeting or a task without first setting a specific time to finish it. And stick to your guns. Avoid trying to get the entire job done in one sitting. Shoot for 80% and then come back to the issue later. Iteration is a hallmark of effective design teams.
- Let us know how we can help. LEAN Product Design is our passion. Contact us to learn about our onsite programs to help you.
The first goal of a lean design is to be directionally correct. Starting out in the right direction is the first priority. Teams should worry about the precision of hitting their target later.
This is in stark contrast to traditional software development methods in which teams are encouraged to gather all of the project requirements upfront. Often teams will spend weeks and months merely gathering system requirements. However, in lean development, the assumption is made that not all requirements can be known up front.
As the story goes, the IT developer went to the client and asked for all of their requirements. And the client said, show me what your system can do, and then I can give you my requirements.
Developers know intuitively that not all of the requirements for a system can be determined up front. While some gathering is needed, teams can often suffer from “analysis paralysis” if they spend too long at this phase.
Lean development seeks to be direction-ally correct in the beginning, and then worry about converging in on a solution later. A US Navy captain, Maurice Gauthier, put it this way, “Three successive pursuits of the 80 percent solution produce the 99.2 percent solution. However, pursuit of the 99 percent solution on the first attempt is a very poor investment of resources.”
The way to apply this to software development is to collect 80 percent of the requirements at the start, and then launch a series of rapid learning cycles. The end goal or target is set, or as Bart Huthwaite calls it, ‘the End-in-View” is determined upfront’. Then the team designs a series rapid learning cycles to learn, show feasibility, and to determine the course to take to hit the target. Taking the client, or future user, along with you on the journey is key. At the start of the learning cycle, tell the user what you expect to accomplish and what the team hopes to learn. Outline the questions that you hope to answer during the learning cycle. During the learning cycle and at the end, share your prototypes and your knowledge and ask for their reactions.
Every rapid learning cycle includes experiments and prototypes. In the IT system, this means that you are doing some type of rough prototype even in the earliest learning cycles. Showing the user the prototype might seem like a risk, but not if you tell them that ultimately it is an experiment that might even be thrown away later. At this stage the direction is set, but it has not been fine tuned. Then, listen to the user and let them help you inform the direction of the solution. In listening, additional requirements will be gathered and this will help to set the system in the correct direction. This is where you can gather the additional 20% of the requirements.
Each learning cycle should include some form of knowledge capture for the team for later reference. The metric sized A3 (11″ x 17″) sheet of paper, is the appropriate size to capture enough knowledge without over documenting. A lot of information can be recorded on one side of an A3sheet of paper. The A3 acts as a beacon marking where the team has been, and describes what has been learned.
I have seen this approach work with teams both large and small. It improves both the quality of the end solution, but it can also dramatically reduce the need for later user validation and testing because they were included in the early learning cycles. It is not agile development which assumes the requirements are set and the developer is merely writing code. This comes at the later stages of the project.
For a further description of rapid learning cycles, please refer to Innovative Lean Development. Thank you. And please send comments on how you have used learning cycles in your software development process.
Development problems and making designs lean
Early in my career, I was a product developer. However, I quickly became disenchanted with the whole development process. I loved the engineering part of the job, solving problems and finding solutions. It was the lack of alignment, loop backs, and rework that discouraged me. I found that the whole process lacked focus and that projects spawned huge amounts of rework. Rework appeared in many forms – late design changes, added requirements, and a general lack of focus. I found that development only address part of the value equation, and usually did not address the problem of anticipating manufacturing wastes and design inefficiencies.
My career took a few turns. I left product development after a few years, working as an IT project manager and then as a manager. It was during this period of time that I found lean methods. I studied how lean was applied to manufacturing and also the office. I found that the lean tools provided a framework for looking at problems, and working on root cause elimination. The idea of continuous improvement appealed to me as a way to move an organization to be more efficient. Lean became my new passion. Nearly 10 years and 120 workshops later, I had mastered the art of applying lean to the carpeted areas of the business. It was during that journey that I discovered another application of lean.
Have you ever wondered if lean could be applied to the design world? Could it be used as a method to design more efficiently? Could it inform a product that was still on the drawing board, or should I say still in the CAD system? It is clear that it could be applied after the fact, once products were designed and hit the factory floor. Lean applied in manufacturing creates efficient value streams that run at a constant TAKT time with minimal inventory. But what does lean look like when applied to design?
The discovery I made was that lean could be applied to design just as well as it has been applied to manufacturing. Much of the language is the same, but the tactics are quite different. About 5 years ago, I was introduced to the topic of designs that are lean at a Huthwaite Institute Summit. It allowed me to synthesize my thinking and explore the world of design in a new way. This proved to be a thinking model as well as a guide for individuals and teams on how to apply lean to their development process. Thinking and reading Bart Huthwaite’s books inspired me to create LEAN products.both products and processes that are lean from the start.
The methods works well with teams who need to innovate quickly and speed development along. It is unique in that it works on both the process of development and on the product that is being designed. One of my favorite quotes is that for something to be lean it has to be lean from the start. In other words, wastes have to be designed out for the system upfront.
I was inspired to write about how development could generate innovative products and lean process. The book Innovative LEAN Development was one of the ways that I explored the idea of lean applied to development. I co-authored the book with my colleague, Mark Swets. It is our attempt to make a contribution to the knowledge base of lean development and design.
If you have been frustrated with the development experience as we were, then I encourage to investigate the lean development method. We have witnessed many teams who successfully applied lean development to improve their process and the quality of their products.
If you find the idea of lean for development intriguing and would like to learn more, please respond and tell me your challenges and frustrations with the development process. Let’s explore together how lean can remove your most difficult development gaps. I only wish that I had found the lean method earlier in my career.
Development cycles in many organizations last from many months to years. The challenge with long cycles is that requirements will shift and change over time. And if the customer’s need changes and the project doesn’t adjust, it will miss the mark. The goal is to make the development cycle nimble and quick. In order to do so, the cycle time is shortened to something quite short. These short bursts are called rapid learning cycles. They are constructed to be very short. In some cases just a few weeks or even days. This is how long a development cycle on any new system should be: just long enough to answer the impotant questions or generate a new piece of knowledge – and prototype a solution. To apply a rapid learning cycle, try dividing a larger project into short bursts of learning. This creates a faster pace and measureable progress for the team.
mystery (asking what might be), to heuristic (discovery) and finally to algorithm (or repeatabili
ty). Moving through the knowledge funnel requires the user to practice abductive reasoning, which is described as asking what “might be” as opposed to “what is”.
I found it very interesting that many of the same topics found in Roger Martin’s method also found their way into our book. In Innovative Lean Development, Mark Swets and I talk about heuristic problem solving, and how to set up learning cycles to move from general ideas to something more concrete for the customer. We showed our own learning cycle funnel.
Why is the concept of the funnel so important? The concept is to have many ideas, or options, available to the team up front, and then weed them out. The team will also refine requirements, moving from general ones to
more specific. But, for the activity in the learning cycle, the team must have a structured way to create value and find the optimal solution. Using learning cycle exposes the gaps in the product or solution space. Learning cycles help to outline the questions and then focus the team’s direction in that ar
ea. Learning cycles become a tool to move from concept
s (mystery) through the other two phases of insight driven heuristics and algorithm . The team can use learning cycles to expose the gaps in the problem, refining both the requirements and the product design.
We (Mark Swets and Tim Schipper) have written a book (Innovative Lean Development) which is about applying learning cycles and lean principles to the discovery process in Product and IT Development. Our intent is to apply learning cycles to learn about blogging. Learning cycles are rapid bursts of learning to accelerate the development of something new and innovative. They can be applied to create new solutions, services, products, business models, etc. The intent of learning cycles is to speed up the discovery process. Since blogging is a new area for us, we thought, “Hey, why not apply learning cycles to the development of our own blog.”
So this is the start of our journey. For the initial series of entries, we are going to write about learning cycles and how we are using them to learn how to blog. We hope you find it interesting and valuable, and we are interested in your thoughts and ideas.