Component procurement time, component cost, and the variety of skills needed on most hardware development projects are greater and represent in our opinion the top three reasons why hardware new product development is different from software.
Let's look at how these differences impact Agile values.
What is Agile development?
The Agile values as described in the Agile Manifesto are as follows:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
As stated in the Agile Manifesto: “…while there is value in the [four] items on the right, we value the [four] items on the left more.”
Each of the eight values listed provides some benefit in software development, but often the value on the left is in conflict with the corresponding value on the right. For example, sometimes responding to change requires deviating from the plan. When in conflict, the left value is more important in software development (usually).
When I read these values, I see them as best practices - high-level best practices.
For example, it is usually better practice in software to respond to changes than to stick to the plan. This is better practice because it results in more profitable products, which is the goal.
Goals, values, principles, best practices, and system requirements are all different ways of saying pretty much the same thing at a different level. They are like floors of a building. The lower ones support the upper ones.
So, to me, best practices are simply lower-level requirements for a smooth flowing product development system. And where there are requirements, there are usually risks. I will illustrate this point using a Playbook Requirements and Learning Map.
Requirements vary in value
In both hardware and software development, requirements vary in value. In the figure below we show how we can indicate the importance of a requirement by where it attaches to the higher level requirement or goal.
Being a mechanical engineer, I think it helps to consider the value of the top goal as a weight being supported by the lower-level requirements, as shown below. The relative value of the lower level requirement is represented by the strength of the spring which supports the goal. The greater the value of the sub-requirement, the stronger the spring and the more weight of the goal that sub-requirement supports.
However we picture it, the Agile values indicate there is a differing value placed on each of these often conflicting requirements.
For Hardware development projects, we think it looks more like this:
Where the requirements on the right, namely process and tools, documentation, contracts, and following plans each support profitability more than they do in Software products. This is because the conditions of hardware development create different costs and risks, as depicted below. The negative impact of a cost and risk is indicated by where it is attached to the requirement.
Where there are additional costs and risks, the strength of that spring (value of that practice) is reduced. In order to support the same profits, the weight is transferred to other springs, which must be necessarily stronger. I will elaborate.
Applying Agile Values in Hardware
1. Agile Value: Individuals and interactions vs. processes and tools
As team size and variety of skill sets increases, the number of interactions increases exponentially.
The greater the number of interactions, the greater the complexity of the system, and the more likely there will be communication breakdowns or individuals following a far-worse-than ‘best practice’ on something. As a result, development goes more slowly and company profits are reduced via Cost of Delay.
In order to combat this increasing complexity, a good framework of processes and tools which keeps everyone on the same page, in sync, using good practices, and communicating well is even more essential.
That said, most processes and tools are not very good at replacing individuals and interactions, so face-to-face, real-time communication is still often the fastest way to get something done. This is often true in hardware development as well. However, there are more people who are impacted by each piece of information, and a wider variety of backgrounds involved in the interaction. Some of these people will not be able to be present and interact when the change is made, and/or some words make less sense to people within other disciplines, so a good communication framework (processes and tools) are the best alternative. The key is to minimize the effort involved.
Agile Value 2: Working software vs. comprehensive documentation
It has been the dream of mechanical designers for over 20 years now to never need to create a drawing. We are still dreaming. Slowly, we are getting away from it, but we are still at a point where many companies rely on drawings to procure parts. This is one example of documentation we cannot yet eliminate, though we will keep working toward it.
In addition, as mentioned above, with larger, multi-disciplinary teams necessary for hardware development, we can’t effectively be in the same room at the same time, so documentation of decisions and changes is typically more valuable. The list goes on, and includes documentation about the design, the factors (knowledge) driving our design decisions, and the results of those decisions. While I know it is often difficult to look at some software code and understand what the person who built it was thinking, it is often more difficult to look at a mechanical or electrical design and gain much understanding and knowledge. Knowledge is often better transferred through documentation when face-to-face transfer isn’t possible.
In addition, as we will discuss more in later posts, one of the primary challenges in applying Agile to hardware product development is the difficulty of breaking down design tasks into small, distinct, manageable chunks. One good practice to resolve this issue is to capture what we really do, daily, so we can use that to guide the breakdown and estimations the next time we do something similar. Minimizing the effort required is key here, too, which is where a tool like Playbook can really help.
Because we are considering how these values fit hardware product development, we can replace ‘Working Software’ with ‘Working Product’. A working hardware product is certainly of very high value, too, despite the increased value of good documentation. Again – we just need to be careful to keep documentation effort at a minimum, so we can focus on getting our product working. It can be minutes a day, if we have the right framework and tools.
Agile Value 3: Customer collaboration vs. contract negotiation
This is one comparison which translates most directly to hardware development. Despite our best attempts we still cannot predict the future or read our customers’ minds very well in either software or hardware. Therefore, customer feedback is essential to insuring our profitability.
That said, the cost of customer collaboration is much larger in hardware development, largely because of the cost of the parts. Good feedback often requires expensive parts so customers can see, feel, and use our product, or at least a subset of the product. Our ability to get feedback is limited by how many test units we can afford to procure and have time to move around from one customer to another. Where the latest software can easily be provided to many people across the globe at the same time, hardware is not so portable – not until we invent teleportation, anyway.
Just as valuable as minimizing the effort involved in necessary documentation is minimizing the effort, delay, and expense cost involved in collaborating with customers. While we continue to make strides to improve customer collaboration, the benefit/cost ratio (value) of collaboration is smaller because the cost is larger. The benefit still outweighs the cost until you reach the point of diminishing return which comes earlier with hardware.
Agile Value 4: Responding to change vs. following a plan
Changing hardware is more costly than changing software. The cost and procurement time required to get new parts causes delays and involves scrap or rework costs. As a result, changing plans is often costly. One of the key ‘plans’ in hardware development is the ‘build plan’ – how many units of each product iteration will we build and test. Careful coordination of this impacts our ability to get customer feedback, find issues, and accelerate our project and profits. Late changes to the number of units we will build often causes delays and increases costs.
One part of the plan which is especially costly to change is the Launch date. If our marketing and sales departments, our suppliers, and our production facilities do not know when to be ready to ramp up, costly delays will occur. There is greater value to confidence in our launch date in hardware development. As such, at least some parts of the plan (the end date) need to be sufficiently accurate, early (so they can be followed without extensive costs).
That said, certainly increased flexibility and response to change is as valuable in hardware as it is in software. Again – it just costs more. Therefore, it pays to plan a little bit more up front. We will discuss this in more detail in further posts.
Summary
While the Agile Values do apply to hardware development, there is a smaller difference in benefit between the values on the left and the right, largely because the cost of achieving the values on the left is larger and always will be.
There are necessary, unavoidable differences in hardware development which produce additional costs.
Hardware development existed long before there was software, and many paradigms in software were born in hardware development. It makes sense that the Agile Values were established to contrast how software is different from hardware. So rather than attempt to transfer Agile practices directly to hardware development, some careful consideration about what the differences are, and what works and what doesn’t, will improve our results.
In the next post, we will review the 12 Agile Principles, which again are simply underlying requirements for a profitable software product development system. We will discuss specifically how each of these 12 principles apply to hardware development. Stay tuned for Part 3…
----
Free ebook - Applying Agile to Hardware Product Development eBook (pdf)
Alternatively, download the Applying Agile to Hardware Product Development eBook (pdf).
Related articles
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
Agile Principles 4 - 12 to Hardware Development
Guide to Kanban
Guide to Applying Agile to Hardware Development
