feature – reflecting on the transformations he has supported, the author provides a few recommendations on how to get products to market faster.
words: néstor gavilán
smaller tasks are the way to go
my personal lean journey, like that of many practitioners, began in manufacturing. it is on the shop floor that i first encountered lean thinking and gradually learned to uncover its secrets. over the course of my career as a lean coach, i have also begun to focus on lean product and process development, and the more i work on it, the more commonalities i find between it and lean manufacturing. what i observe is that the lean work we do in engineering is no different from what we do in production.
before we dive into this topic, let me give you some context on a company whose lppd transformation i have been supporting. before lean was introduced there, the manager in charge of each new product would determine what each team member was tasked with doing – in collaboration with the product planning department. of course, this was a huge plan that, due to difficulties encountered along the way, was never completed. it felt like being on an airplane whose flying path cannot be changed even when bad weather is coming up. there was no choice but to go through the turbulence.
in response to that, we created a very high-level timeline in the obeya displaying the project’s key milestones rather than several detailed tasks. we then divided the project into sprints, establishing deliverables for each sprint and translating each deliverable into tasks. this made it easier to adapt the plan to the ever-changing reality. (in the plane analogy, it meant that when turbulence was detected, we could now go around it or fly at a higher or lower altitude.)
since we don’t know what the future holds, there is no point in planning what will happen in three weeks’ time in detail. instead, we focused on deliverables for the next three weeks based on a future target condition. to establish deliverables, however, we first had to explain what a deliverable is – what input is needed, what output is expected, and what is the risk inherent to each task making up the deliverable. we found that by properly managing risk we were able to ensure quality and on-time delivery for our deliverables.
assigning the to-do deliverables to each sprint (a responsibility of the project manager) using a visual board in the obeya meant knowing that delivering all those elements of the work on time would in turn ensure we reach project milestones in timely fashion. additionally, it told each sprint what exactly they had to deliver, increasing their sense of ownership.
the big revelation here is that to complete tasks more quickly we should strive to make them smaller – or, if you will, shorter (between half a day and two days) and more frequent. let’s use testing as an example. a week-long testing session is way too long: engineers might want to book a week for their testing, “in case things go poorly”, but what if they don’t? is it worth causing a delay in the next task in the process just in case a problem occurs? could this big task be divided into smaller ones, so that any potential problems immediately come to the surface?
set a pacemaker and establish customer-supplier relationships
when developing a product or service, we should try to clearly separate the system from its subsystems and assets. by creating subsystems, we can establish a supplier-customer relationship within the main system, which will act as a pacemaker in the development process. this is what will ultimately help you to cut your lead-time and time-to-market.
here, we immediately see a parallel with manufacturing, where the pacemaker process sets the pace of the work. in lppd just like in manufacturing, this approach enables pull and ensures the work happens at the pace set by the customer and meets their needs. as the program gets executed (read, the product is developed), suppliers are prompted to offer solutions – for example, a specific asset to be added on to the product. such assets – in production, we call them parts – can be either built-to-order, if they have not been developed yet, or come from a supermarket of existing solutions.
whether we are in a built-to-order or built-to-stock scenario, to establish this relationship between customer and supplier and regulate the system, we use a “deliverable kanban”. in the case i am referencing, the main system sends a kanban to the subsystem or asset team (anyone going to that board will have to find the kanban there). the asset team then took on the deliverable and created a tasks plan to make that deliverable possible and deliver the required asset (often using set-based concurrent engineering). exactly what happens in manufacturing with components! if the pacemaker is close to the end-customer and can pull from the upstream supermarkets, the lead-time will be shorter than it would be in a situation where the pacemaker is at the beginning of the process.
lowering lead-times is fundamental for a product development organization (time-to-market is a key indicator for them), and it can be achieved by simply placing the pacemaker later in the process rather than at the beginning. the same happens in manufacturing: toyota taught us that rather than building huge batches of the same product, we need to make our system flexible enough to follow the pace set by customer orders. so, shorten our changeover times so that we can quickly produce smaller batches and deliver to customers. such is the power of the pacemaker.
making knowledge reusable
for the company in our example, it was very important to clarify to product managers what solutions were available already in the supermarket or what alternatives there were. in their case, since we are talking about engineering, the supermarket is a repository not only physical parts but also past (reusable) knowledge – both successes and failures. to bring that clarity about, we improved the way they visualized the trade-off curves, so that teams would know that within certain margins, solutions were already available. isn’t this pure kanban? whether it’s an order for a pizza in a restaurant, one for a handle in door manufacturing, or one for a sub-system necessary for the development of a new product, the blueprint doesn’t change. the only difference is that lead-times in product development are longer.
by implementing kanban, we were able to reduce those lead-times, while helping team members understand why they were doing what they were doing. this gave a clearer purpose to their work: delivering the right information or product to the customer, in the right amount, at the right time.
as we have seen, you have solutions already developed and available in your supermarket, you have an opportunity to go to market more quickly, and then release updates as you go – by using trade-off curves or set-based concurrent engineering. this, however, forces you to manage the knowledge you already have.
indeed, as you progress in the development work, you get a product but also new knowledge. learning to make the most of that knowledge in the future is truly revolutionary: for the company in my example, it meant that less subsystems had to be developed from scratch. when in need of certain functionalities, a new product can now quickly rely on existing assets (aka reuse existing knowledge) and focus development efforts on the features that don’t exist yet. the mechanism making it all possible is kanban.
before kanban, programs and sub-systems were too separate: the product team was not seen as the internal customer, and sub-systems worked in push mode. after we put up the board, however, people understood what the sprint required and delivered exactly that.
to conclude
how do you ensure you keep learnings, both successes and failures, into the system so they can be used at a future time, thus allowing us to reduce lead-times? i’d encourage those of you who are starting out on their transformation to divide large tasks in small deliverables that are easier to manage, to see product development as a relationship between client and suppliers, and to make better use of the knowledge that is already existing within your company.
i hope this article helps those of you who might be taking part in a lean transformation in lppd to understand how lean thinking can apply to your setting, and how lean manufacturing lessons can guide you through the turnaround of your engineering department.
the author
néstor gavilán ferrer is director of learning at instituto lean management, in barcelona.