We have a pretty good understanding of what it means to develop Software (SW) using the Agile techniques. What is more difficult is how Agile methods are applied to Hybrid (physical, or hybrid – combination of HW and SW) development efforts.
Based on research we recently performed, we discovered that there are three pillars that support the application of Agile methods to Hybrid development: Cultural (such as teaming), Hybrid specific processes (like multiple prototype builds), or Agile best practices, re-purposed from software development.
Since September 2013 we have been researching how companies are applying Agile techniques to HW development. This research, involving 20 companies from Silicon Valley, has been supplemented by academic research and further interviews. The techniques outlined below arise from our research and various other sources.
As many organizations have found, the only thing you can count on is change. The competitors are moving at ever more rapid speeds. Technologies and partners are also moving very quickly and ignoring this is not the way to success. Software organizations have found that Agile methodologies enable their fluidity but Hybrid organizations have been challenged by adopting Agile methods because they don’t know where to start. We plan to outline what we have discovered that can be applied to Hybrid organizations and enable them to see early benefits in significantly less than a year.
The Three Pillars of an Effective Hybrid Process
As we looked at the research we performed this last Fall, we discovered that the best practices were organized into three areas. The first area were mainly soft skills, teaming, and cultural. Frankly these are table-stakes for any organization that aspires to be effective in product development. Second, there are some best practices that are unique to Hardware and are not derived from the Agile Maniftesto nor Scrum practices. Third, there are some best practices that can be drawn from Scrum and slightly modified – and we call these “SW Derived”
As our survey repeated reinforced, you don’t have to be doing each and every Scrum practice element to reap the benefits of Agile development. Many organizations have adopted just a few best practices – Sprints, Sprint Planning, and Burn-down charts and have found that to be sufficient. This is true in Hybrid development as well. You don’t have to do 100% of the best practices to get some real benefits. Finally, we recommend an inch wide, mile deep approach where you select a few key best practices and adopt those. Work with them for a while. Optimize them. And then when ready, take on some more.
Cultural Pillar – Table Stakes
If we look at the Cultural area first, we need to recognize that these core elements around teaming, empowerment, trust are essential for any high performance team. In fact all of the elements from high performance teaming fully supports Agile development and you do not have to do anything different to implement them in a Hybrid environment.
The core elements are mainly values around the importance of teams and the fact that requirements will change. Int addition we also place other elements such as having a Customer Owner and having Daily Stand Up meetings in this category. We would recommend every Hardware or Hybrid organization start with the Cultural Pillar first, and don’t proceed until you have mastered this.
Hybrid Pillar – Unique to HW
The core elements surrounding the Hybrid Pillar are those best practices that are totally unique to Hardware. They do not come from the Agile Manifesto but rather are derived from our research as stand alone best practices that some companies use to become faster and more responsive. However, some of these don’t come without additional cost. So when evaluating these for your organization you may have to justify them based on time to market payback justification.
The most obvious elements are to have more Engineering Validation Test builds and more Development Validation Test builds. Typically this is done by building more variants at the time of the build when you can not fully simulate or anticipate the outcomes (Radio Frequency Interference, for example). You can also consider interleaving the builds so you start one build before testing of the prior build is completed. Although risky, when these two methods have been combined, firms have seen 40% reduction in time to market. Finally, if you have an Asian ODM or OEM building the product for you also employ a local firm (within an hour by car) to do prototype builds. Having local build capability is key.
A Non-obvious best practice is the use of a Boundary Condition representation of the key project attributes: Schedule, Product Cost, Program Cost, Performance, and Quality. It basically summarizes the contract between the team and management. If this is combined with a pre-agreed upon process when a boundary is projected to be broken, the team can be freed of micro-management and pursue their goals without management meddling. Also, if a change in the market causes a boundary break, the team as a response mechanism to change course quickly.
SW Derived Pillar – Not so different for Hybrid
Finally, there are many best practices that we call ‘SW Derived’. Those are best practices that are lifted from the Scrum methodology and suitably modified so it makes sense for Hybrid development. There are many such process elements that are transferrable, but we found that Sprint Intervals, Interval Planning, Burn-down Charts are some of the most impactful.
By looking at a typical Hybrid development program of one year in length, you can divide this into approximately six, eight week Intervals. Each one of these Intervals can have a planning aspect where the team sizes the deliverables and determines the total number of “Story Points” that is possible during a Sprint Interval. These are linearly placed over the eight weeks, unless the team has greater insight, and then progress is plotted in a visible way in the team workspace.
Other elements of the SW Derived Pillar include specialized and more technical and test driven aspects. For example Continuous Integration can be applied where the Hybrid builds are always kept up to date and in a whole system. TDD (Test Driven Development) is a methodology where you plan the interval with test completion in mind.
Finally, the notion of User Stories can be directly translated to Hardware development. In fact many in the research study indicated this is better than just passing on requirements because User Stories give greater insight via their use case approach, so the engineers have more freedom to provide an innovative solution rather than simply satisfying a dull requirement. Furthermore, we discovered that some teams actually integrate the HW and SW aspects of a User Story so that it is completely integrated.
If you have read this far, you might think that the application of Agile methods to Hybrid development is a lot of work! And yes, you are right it requires fundamental change in beliefs and behaviors. However, if you can make progress in implementing just a handful of best practices, you may see some quick wins in morale and productivity.
In the research findings, we found that most surveyed felt that using Agile methods, more code ended up being shipped in the final product and that the team had much less burnout. Although the daily standup meetings can be taxing, if efficiently run, they are a great way to focus the team and prevent surprises with often brings team members down.
Others reported significantly faster cycle times. In the case of internationalization one company reported going from 11 months down to 6 weeks! A more typical result was to reduce the time between releases from 11 months down to 2 months. One of the best examples was one organization that actually reduced apples to apples time to market by nearly 40%!
In all of these situations the respondents indicated that there was less waste and more fun. With results like that in Software, there is no reason at all we should not try for the same benefits in Hybrid.