Agile for Hardware Development

Agile for Hardware Development. Agile for Hardware Development PLAYBOOK PLAYBOOKHQ.co

Contents Background Agile Manifesto Agile Values Cost of Delay Agile Principles Agile Methods Conclusion 3 4 6 7 9 11 12 2 Title of the book

Background In this ebook we explore whether or not Agile Values, Principles and Methods can be applied to hardware development. To meet the unique challenges of hardware development, we find that some modification of Agile is required. In addition, because of its unique requirements, we conclude hardware development is best suited to a hybrid methodology. There is no doubt hardware product development projects can benefit from the application of some parts of Agile. In fact, we ve adopted Agile practices as part of the PLAYBOOK Method. For example, holding daily stand-up (scrum) meetings, which create faster feedback loops and increase communication. However, due to the differences of hardware product development vs. software development, hardware product development projects ideally require a hybrid approach that includes not just Agile but practices from Theory of Constraints, and Lean as well. Why? Because Hardware development is different from software development. To begin the discussion, we first look at the Agile Manifesto and explore the four Agile Values and twelve Principles. Next, we explain the various constraints that are unique to hardware development. Then, with these constraints in mind, we look at why Agile Values and Principles as well as supporting methods such as Scrum, can or cannot be applied to hardware development. Let s begin by taking a look at the Principles and Values of Agile as described in the Agile Manifesto! 3

Agile Manifesto The Agile Manifesto prescribes four Agile Values and 12 Principles upon which Agile Methods are based. Let s look at the Agile Values first, and the implications for hardware product development. Agile Values 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 According to the Manifesto, Agile values the items on the left in each Value more than the items on the right. The Creation of the Agile Manifesto Seventeen people representing coders from Extreme Programming, SCRUM and Adaptive Software Development to name a few met at Snowbird ski resort in Utah to try to find common ground regarding a new and better approach to software development. What emerged was the Agile Software Development Manifesto. For example in Value #1, Agile values Individuals and interactions over process and tools. Interestingly, each of the Values listed above 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, when we look at Agile Value #4, sometimes responding to change requires deviating from the plan. So, can these Values be applied to hardware development? In order to answer this question, we need to look at the differences between hardware and software. 4

Agile Manifesto The most obvious difference between hardware and software is that hard goods cannot be undone, twisted, adapted and adjusted at the same rate, or minimal impact to cost and time as software. The Hardware Effect The most obvious difference is that hard goods cannot be redesigned or rebuilt as quickly or as cost effectively. Redesign and rebuilding often comes at a much higher cost. For example, a new casing for a mobile phone cannot be quickly built and rebuilt again in the face of changing requirements. This difference is fundamental. We call it the Hardware Effect. Ultimately, the Hardware Effect affects the rate and cost of the Build, Measure, Learn, cycle. The cycle at the heart of Agile. The Hardware Effect changes everything, and makes some Agile Values and Principles more applicable than others. For example, in hardware we place similar weight on both sides of each of the Agile Values, and don t necessarily see them as conflicting. Here s our take on applying Agile Values to hardware development A Real World Example If a team of developers is working on a new casing for a mobile phone, the casing may go through multiple iterations before the right material is purchased, tested, retested and finally confirmed. In creating and testing the casing there is lead time for purchasing, building and testing different materials. In a standard software project you may unit test a particular set of code, only to find it doesn t work and rewrite it. There is no lead time in procuring code, just more work in building and refining it. 5

Agile Values Applying Agile Values to hardware development. 1. Individuals and interactions over processes and tools Communication is critical to all development. Visibility of work, in real-time, supports early learning in the Build, Measure, Learn, cycle. One could argue that software teams are fraught with their own version of team complexity, comprising a number of skill sets such as marketing, design, developers and quality, not to mention personality types! However, hardware teams are typically comprised of these skills, as well as others. For example, team members that deal with molded components, optics, sheet metal, castings, cabling, piping, circuitry, assembly, research, supply chain, manufacturing, receiving/inspection, field service, quality, regulatory, configuration control, packaging, and many more. As team size and variety of skill sets increases, the number of interactions increases exponentially, and so does the likelihood of communication breakdowns. In order to combat this increasing complexity, good processes and tools are essential for keeping everyone on the same page. That said, processes and tools cannot completely replace individuals and interactions. In hardware development we need both to achieve our goals. 2. Working software over comprehensive documentation Delivering a working product and adapting to new requirements A working hardware product is certainly of very high value. However, delivering a working product (or changing requirements) in hardware takes longer and has a higher cost than in software. An important cause of the high cost of change is the highly integrated nature of hardware products. For example, change in hardware typically impacts multiple components and processes. Software teams have long understood modular architectures and have been using them to limit the ripple effect of each change. Hardware teams have not yet solved the modularity problem. Increasing modularity typically increases our Cost of Goods Sold (COGS), and degrades system performance including the often-important weight and size of the product. These forces counteract the benefits of modularizing. The higher our cost of change, the longer it takes to recover the cost and the longer the payback period of each new change and release. This fact alone is enough to drive the lengthening of optimal release rates. Let s look at a formula for calculating the cost of delay 6

Cost of Delay Cost of delay is key Whether we are developing software or hardware, some changes are not worth the time and cost required to make the change. We must trade off the costs against the value of increased sales, quality, and customer satisfaction. We can easily see the difference between changes which are worth making and those which are not by calculating the value and the cost associated with that change. Many cases can be analyzed using this simple formula for the Economic Value (EV) and ROI of a change or decision. EV = SVS * V + SPS * P - COD * D - UCS * C - E ROI = EV / E Where: SVS = Sales Volume Sensitivity SPS = Sales Price Sensitivity COD = Cost of Delay UCS = Unit Cost Sensitivity The other terms ( x) are what we refer to as the Economic Variables. V = Increase in Sales Volume (decreases are negative) P = Increase in Sales Price (decreases are negative) D = Launch Delay (earlier than current date is negative) C = Increase in Unit Cost (decreases are negative) E = Additional Project Expenses (savings are negative) If EV is significantly positive and ROI is sufficiently high, we make the change. Otherwise, we do not. More detail? Read our complete series on making economically driven project decisions. 7

Agile Values Applying Agile Values to hardware development (continued) 2. Working software over comprehensive documentation (continued) The need for documentation The delivery of documentation is still required in hardware development. It has been the dream of mechanical designers for over twenty years now to never need to create another 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. As mentioned above, with larger, multi-disciplinary teams necessary for hardware development, documentation of decisions and changes is typically more valuable. This includes documentation about the design, the factors (knowledge) driving our design decisions, and the results of those decisions. While 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. 3. Customer collaboration over contract negotiation This Value 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. That said, the cost of customer collaboration is much larger in hardware development, largely because of the cost of the parts. Getting dependable feedback from customers often requires expensive parts so customers can see, feel, and use the 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 documentation is minimizing the effort, delay, and expense 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. 8

Agile Principles What about Agile Principles? Are they applicable to hardware development? Based on these Values, 12 Agile Principles were developed. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. As you can see, the Agile Manifesto was not prescriptive in terms of implementation. The twelve Principles begin to define how to put those Values into practice, but still did not prescribe a method or process for implementation. The development community practices several Agile Methods. These include methods such as Scrum and Kanban. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 9

Agile Principles Agile Principles What about Agile Principles? Are they applicable to hardware development? In terms of the Principles, most of them are directly applicable. So we will focus on the few that need some caveats to be applied to hardware development. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. As discussed, the cost of change is much higher in hardware development due to the Hardware Effect. As we may welcome changing requirements, we must balance this change with the cost of delaying our project launch. In both software and hardware, the requirements changes referred to in Principle 2 almost always increase Sales Volume or Sales Price. And they almost always increase expenses. They may or may not cause a launch delay. In hardware product development, they often increase our unit cost (COGS). The difference between hardware and software appears in the launch delay and unit cost factors. In summary, the time between design and test in hardware is larger. This makes the delay we incur with hardware changes larger, which increases the cost and reduces the economic value of a change. As a result, fewer of the changes we would like to make turn out to be profitable. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Because of the cost of change and the constraints of hardware, the frequency with which we deliver working product is necessarily less frequent. That is not to say we can t once again approach development in a more modular fashion and implement methods such as scrum where we are learning earlier on smaller chunks of work. 7. Working software (in this case hardware ) is the primary measure of progress. In hardware, learning quickly is key to success. A working product may not be possible to deliver, but we can track the rate at which we are learning. As stated above, we can also break down our work into smaller batches as well as engage in many other practices to learn earlier. 10

Agile Methods Interestingly, many Agile methods can be directly applied to hardware development. Some great examples of these are the daily meetings and sprint planning. In terms of daily standup meetings, these are essential to communication, fast feedback and early learning. Since much of the work in hardware development can t fit in a two week sprint, we need to combine both long and short term planning. This is best done with Decentralized and Rolling Wave Planning. Decentralized planning begins with defining the overall project at a high level, and then having the team members fill in the necessary detail in the near term phases of the project. Rather than pick an arbitrary two week time frame, the teams normally plan to the next significant milestone. Then, once the project is going, the teams utilize Rolling Wave Planning to update the plans on a weekly cadence and continue to add detail as necessary.the delivery of documentation is still required in hardware development. It has been the dream of mechanical designers for over twenty years now to never need to create another 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. 11

We developed PLAYBOOK specifically to account for the differences in hardware projects. CONCLUSION While the Agile Values do apply to hardware development, in hardware, we don t place as much emphasis on the Values on the left at the expense of the Values on the right. This is largely because the cost of achieving the values on the left is larger in hardware projects. The difference in the Agile Principles is even smaller. And they were also driven by the cost and complexity of hardware projects vs software. And finally, several of the methods directly apply with little modification. Lead time, component cost, and non-homogenous work are three of the main differences between software and hardware development We developed PLAYBOOK specifically to account for the differences in hardware projects. Besides the Agile Values and Principles mentioned here, we also embedded principles from Lean and Theory of Constraints. If you would like to see these in action, watch the demo video. More detail? Read our complete series on Applying Agile to Hardware Development Ready to learn more about PLAYBOOK? Watch the Demo Video 12