We agree. Hardware product development is different than software. So when we apply Agile principles, we need a different approach.
This series is a comprehensive review of Agile and how to apply Agile to hardware product development. We look at which Agile Principles work in hardware, which don't and why, and explore best Agile practices for hardware product development.
Principle 4: Business people and engineers must work together daily throughout the project.
Principle 6: The most efficient and effective method of conveying information to and within an engineering team is face-to-face conversation.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
As we’ve discussed before, product development is all about information. We spend every day generating, translating, and transferring information. The key to success is to do this as quickly as possible by eliminating unnecessary delays and not wasting valuable time on useless information.
Agile principles 4, 6 and 11 are all about helping more valuable information flow more quickly.
Daily stand-ups and decentralized project planning
The practices which embody them are daily standup meetings, chief engineers or product owners, team-oriented organizational structures, decentralized project planning and management, paired programming, and more.
In traditional organizations, information sits around for days or weeks at a time in someone’s queue, just waiting, doing nothing, because the system is all clogged up and we think we can save a little time by doing things less often (creating bigger information batches). I won’t delve any more into that enormous fallacy in this post and instead just leave it at this – it’s just plain wrong (costly). (See the last post for the benefits of de-batching information.)
Delivering information in large batches is even more costly in a world of high innovation (uncertainty about what to do and how to do it), high integration between components with different owners, and low understanding of what other people are thinking. All three of these factors are even greater in hardware development than in software, and so the value these three principles bring to hardware development is even greater.
In fact, these principles are often insufficient for many hardware development teams. Recall from the first post, that my #3 big difference between hardware and software development is the larger number of people and variety of disciplines and knowledge involved in hardware. Daily stand-up meetings are not so easy with a team of thirty or more people from marketing, two to ten engineering disciplines, quality, manufacturing, scientists, regulatory, purchasing, and more. It helps to break out into smaller stand-ups (a scrum of scrums), but whenever we separate people who must share information, the information flows more slowly.
This is where hardware teams need to supplement Agile principles with an effective information framework. With this framework we can more quickly transfer and even generate and translate information among a large group of people with very different thinking. There is of course more to say about this, but I’ll move on to the other principles for now instead.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Principle 8: Agile processes promote sustainable development. The sponsors, engineers, and users should be able to maintain a constant pace indefinitely.
The Theory of Constraints established that people are the constraints in our product development systems. We can think of them as little pipelines which we often try to push too much work through, except these pipelines have thoughts, feelings, desires, families, and lives to live.
If we push too much work in, we clog up these critical pipelines. Among other big problems this causes, eventually some of the pipelines simply leave. We have to replace them with a smaller pipeline who won’t be as productive as the one they replaced until they get up to speed on everything. If people are not engaged and motivated, the flow becomes even more restricted, as they lack focus and desire to get the job done.
Losing some availability of an already over-utilized resource has a huge impact on throughput. It is like an accident blocking a lane on the freeway at rush hour. It causes huge delays, which is a real profit-killer because most projects have a high cost of delay. We already operate far too close to the right end of this curve.
Figure 1: Cycle Time vs. Resource Utilization
Instead, we replace push with pull. We make sure everyone on the team has what they need including maximum availability to the most important tasks. We make goals and expectations of them clear and realistic. We make the risks, work and progress highly visible, and we trust them to get their work done. In return we get happy people and great throughput.
Principle 9: Continuous attention to technical excellence and good design enhances agility.
Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.
Principle 10 is often a bit confusing, so I will paraphrase it in more common terms don’t do non-value-added work. In other words, minimize the work you do in order to achieve your goal.
I think it’s important to clarify further – value is defined from the point of the whole system in simple terms like profit and ROI, not by any individual component of the system and not in any proxy term like expenses. It is realized and measurable via sales (happy customers) and working product.
I read into it this principle a little further and see that "value-maximizing" work is really what to focus on, rather than just 'value-added' work. If we can get more value per hour of work on Task B than we can on Task A – Task A is non-value-maximizing work. We should focus our limited time on value-maximizing work. For example, the documentation and processes the first Agile Value refers to are value-added, but not value-maximizing. We often maximize our profits and ROI-- even long term--by building the next new feature instead.
Both of these principles certainly apply to hardware product development as much as they do to software. Referring to Principle 9 - absolutely a good, modular architecture (good design), and few existing errors (technical excellence and good design) enhance agility and our ability to adapt to new information. Certainly, the simpler things are and less work that is involved, the faster we can achieve the value we are working toward. (Duration = Work / Availability)
Unfortunately, in both hardware and software, it’s a continual balancing act between these two principles.
Technical excellence and good design generally increase the amount of work we need to do, and yet minimizing the work is important.
For example, we might create a high-fidelity prototype which helps us better identify existing errors, get better customer feedback, and achieve greater technical excellence, but that will take more work and time. Or we can do a quick, simple prototype which we think maximizes the work not done, but it doesn’t necessarily provide all of the information we need for good feedback and technical excellence. This often results in more work (and/or reduced sales) later.
“Everything should be made as simple as possible, but not simpler.”
-Albert Einstein
Albert Einstein is credited with saying; “Everything should be made as simple as possible, but not simpler.” But where is the line between not simple enough and too simple? It is wide and fuzzy and it takes skill (not art, I would say) to see it and to really maximize the work not done.
These skills include the ability to analyze our system and make these tradeoffs mathematically. They include knowing how to identify, manage, and burn down our work and our project risks most quickly, part of which is knowing how to determine the best (fastest) ways to get good (reliable) information.
Speed is a critical factor in these tradeoffs. ‘Fastest’ partially comes from lower work, yes, but there is more to it when component lead times are involved. The ROI of some work is a function of the amount of work involved (expenses) and the length of time until we realize the value of that work (duration). The ROI of some work is also a function of the delay to other activities caused by the work and the cost of that delay. But more importantly, it is a function of the value we achieve. To determine value-maximizing work we must include all of these factors.
We can ultimately strike this balance by maximizing our risk burn rate (confidence in future profits gained per day). By focusing on this, we maximize our value-achievement rate which maximizes our overall profit production rate.
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We simply can’t get better unless we look at the past and learn (change) from it. The Scientific Method in its many forms (Plan-Do-Check-Act, Build-Measure-Learn, LAMDA, A3 Sheets, Design-Build-Test, and more) is very effective, but only if there is an experiment (Check/Measure/Test) or some other form of reflection on what we did.
Our products, development processes, and ultimately profits will also only improve when we take action from that reflection and actually tune or adjust what we do. Profits will increase faster if we do it more often because we shrink the information batch size and therefore realize value earlier.
Really effective software and hardware teams do this at a daily cadence (interval) with daily stand-up meetings. In 15 minutes we reflect on the day before and adjust our project’s short term plans, priorities, tasks, and resources to be more effective. We do it on a weekly or bi-weekly cadence in team meetings to adjust our mid and long term project plans. And we do it bi-weekly, monthly, quarterly, and/or annually in order to adjust and improve our processes to make them more effective.
I’ve primarily used my own experiences in writing this series, enlightened by the teachings of Don Reinertsen, Eric Reis, Eli Goldrat, Jeff Sutherland, and other ‘fathers’ of Lean and Agile NPD. However, I am not alone in my conclusions. In the process of developing this series, I’ve had the pleasure of reading similar findings among many other colleagues. I would like to share some of these.
We’ve now completed the review of the Agile principles and how they work or don’t for projects which involve physical components. To summarize, principles 1 through 3 don’t exactly fit hardware development as well as they do software development. However, principles 4 through 12 very much do, depending on how we define a working product (principle 7).
Along the way we have touched on some of the Agile practices and discussed some of what works and some of the challenges. In a future series we will review many of the practices in more detail to determine which practices, in what form, apply to hardware product development.
However, we’ll defer that series in lieu of a series of blogs focused on the Playbook Principles. While there are certainly similarities with Agile principles, there are some differences, too. We won’t compare them at length. Instead, we will describe the Playbook Principles and how they improve the products, projects and profits of hardware companies and more.
Download the eBook about applying Agile to hardware development and share these concepts with your colleagues.
Agile Development
Applying Agile Values to Hardware Development
Agile Principle 1: Early and Continuous Delivery of Value
Agile Principle 2: Welcoming changing requirements
Making Hardware Development More Agile
Early Learning in Hardware Development
Agile Principles 4 - 12 to Hardware Development
Guide to Kanban
Guide to Applying Agile to Hardware Development