Tenet #2: Think in sprints
In my last blog, “Tenet #1: Align the organization”, I discussed the need to align the organization in two ways:
- Align with information to motivate for the needed change, and
- Align with structural changes, reporting, roles, responsibilities and metrics to make your pipeline faster.
Alignment of the organization in both information/motivation and structure is critical to moving faster. Don’t make the mistake of false economics that has hurt so many companies, that a lower cost product development engine with higher utilization of all resources is best for the company. In the end, this choice will slow you down, and slower projects will cost you far more in lifetime gross profit than a so-called efficient and highly utilized organization will save you in project cost.
In this blog I would like to talk about the value of breaking down the work in small pieces and driving the work in sprints.
Sprints are discussed a great detail in the literature pertaining to agile software development. The idea of a sprint is to have a short term goal with a firm ending point in time, and (in agile software development) at the end of this period to have a customer-usable prototype. In this manner, the team is focused on moving step-by-step toward the longer goal of project completion through bursts of energy that sum together to make the whole product. This process has been shown across many industries to have the following advantages for software projects:
- It is faster because everyone is motivated toward a clear, short term goal and everyone’s role in accomplishing that goal is very visible and highly monitored.
- It will deliver higher quality because testing at the end of every sprint gives very rapid feedback and frequent opportunities to fix issues along the way.
- It will produce higher levels of innovation because sprints allow for short learning loops (small learning batches and discovery with each sprint) and the ability to take risks early and iterate often in a low cost environment.
- It will gain sponsorship buy-in through communication because at the end of each sprint you have the opportunity for a demonstration of the product to those sponsors. This frequent communication is relatively low impact to the team compared to the deflection of large gate/checkpoint presentations.
- It will fulfill the customer needs better because sprints allow for frequent touch-points with the customer to assure that your product will hit the mark when it comes to fulfilling the needs of the customer.
The above advantages are well proven for pure software projects. But when your innovation processes is designed to produce products having a complex combination of hardware and software, this sprint philosophy can still be applied, though it will look a little different than sprints on a pure software development project. In the case of a hardware/software project, sprints for the software aspect of the project can be handled in much the same way as with pure agile software techniques. But the parallel running sprints in hardware may be as shown in Figure 2-1 below.
Figure 2-1: Schematic of Parallel Sprints for Software and Hardware
For example, HW Module 1 Sprint 1 may be the design of a local oscillator for a down-convertor chain. HW Module 1 Sprint 2 may be the first breadboard of this oscillator, using the full force of Rapid Circuit Prototyping (RCP, see “Tenet #3: Focus on the Risk”). HW Module Sprint 3 may then be a refinement of this design for better temperature stability. Organizing the program into sprints and coordinating the integration in intermediate sprints will keep designers and managers focused with a sense of urgency toward the near-term goal; including both the hardware teams and the software teams on a given project.
Projects with a mix of hardware and software present some noteworthy differences in comparison to pure agile software projects:
- Hardware Sprints are longer: Although recent advances in rapid prototyping and simulation technologies have shortened the time to build electronic circuits and mechanical models, it is usually the case that development of a working physical prototype requires more time than developing a useful software module.
- Integrations are less frequent: System integrations with hardware and software will occur at a cadence slower than the pure software sprints. And it is unlikely that you will have a customer-usable version or perhaps even a version for internal demonstration at the end of each sprint.
- Hardware development is more expensive: Software development generally requires only software engineering labor, whereas hardware development usually requires significant additional investment in parts, materials, forming or machining, stocking & handling, and shipping & receiving. Building hardware prototypes also requires specialists of multiple disciplines. In addition, expensive and long lead-time tooling is often needed for prototyping, for manufacturing, and for testing. In fact, integrated hardware/software product development is really four separate projects happening in parallel: 1) the product itself, 2) the supply chain for physical parts, 3) the manufacturing process, and 4) the testing and quality assurance process.
- Hardware product definition is less flexible: A true agile process includes an agile product definition, where specifications and content for the product are still flexible to some degree throughout the project. In essence, for a software project until a feature is pulled out of backlog and work begins on it, the definition is floating and marketing can change it. The software becomes more defined throughout the project around a solidifying base structure. Nevertheless, agile definitions for hardware are still possible, but to a limited degree as compared to software. Since the impact of a change in hardware definition is greater in both cost and time, it is essential to carefully narrow what flexibility can be allowed. For instance, you may be able to make a change to the output power specification for the final stage amplifier for a signal source without major impact, but it’s very costly to change the distortion specification since this is driven from every block in the system.
- Rapid prototyping tools are needed: In hardware, special tools are necessary to accomplish the speed expected in a sprint-based product development process. Old methods of printed circuit board design may have taken 3-4 months from design to results. Today the problem should be broken down into blocks where the risk is in the block and not in the interface, and tools must be provided to iterate on these risks many times faster than in the past. See Tenet 3: Focus on the Risk, for more information on rapid prototyping.
- Platform management is critical: Because of the cost of rework in hardware, building on a well-designed platform is essential to deliver the speed and quality you need from your projects. This need has two aspects:
- Hardware – Forward looking platform management is vital. This is different than looking to the past for technology blocks that have been used in previous products and pulling them forward for leverage. Forward looking platform management is a conscious effort to plan on the needs of a given product area and build in the flexibility and commonality that will allow for faster projects, lower cost from shared parts, and higher quality from proven designs.
- Test-bed software - Some level of software is often necessary to light up certain circuit boards and test them for functionality. This requires some investment in generic test-bed software ahead of time in order to gain the fastest prototyping capabilities.
- Quality checking is less complete: Quality for hardware will include some aspects that are not shared in software, and are too costly to test at the completion of every sprint. Examples include environmental tests (temp cycling and shock, vibration, EMI, etc.) and regulatory tests (FCC, FDA, ITAR, etc.).
Having discussed the differences of hardware/software project sprints compared to pure software sprints, it’s important to remember that most of the advantages listed above for sprints used in agile software development are available to projects with a mix of hardware and software, including faster projects and greater innovation. Learning to drive your organization through sprints, both in hardware and software, will deliver better cycle times and produce products more aligned with customer needs.
In my next blog, “Tenet #3: Focus on the risk”, I will discuss the need to focus heavily on risk, both market risk and implementation risk, and how this risk can be managed to produce better project speed.
See for instance “Scrum: A Breathtakingly Brief and Agile Introduction” at http://www.agilelearninglabs.com/resources/scrum-introduction/.
I make a distinction here between a stage-gate and a phase-checkpoint process. In the former, the gate meetings are held to ask permission to move forward. This is important when the risks and costs are very high and top management must hold the team back until they make a decision. In many industries, a phase-checkpoint process is more rational, allowing the team to proceed quickly, taking some risks on their own and potentially spending some money ahead of the checkpoint meeting in order keep the project from slowing, to get long lead-time parts in place to keep the project on track and fast. For speed, a team should fly-by a checkpoint and “check in” with management. I will use “checkpoint” in place of “gate” for the rest of this blog.
 Often this flexibility is the last principle of agile software employed by a given firm, since it is much more difficult, and a large portion of the value of agile software development can be gained even before employing this level of definition flexibility.