Agile Product Development with a Partner
Whether you are developing software products, some combination of software and hardware products, or even pure hardware products there are advantages to be gained by using some or all of the Agile Software Development principles in collaboration with your development partner. These principles are different from the traditional “waterfall” project management methods in that they:
- Empower the overall product development team
- Catalyze innovation (even by the partner)
- Embrace changes in the product definition throughout the development cycle
- Encourage frequent hardware and software prototype intervals
- Tighten the relationship between the developers and the end use cases
- Utilize predictive progress metrics
- Encourage mid-project retrospectives and process improvements
The principles involved in agile software development were first published as the Agile Manifesto in February of 2001. However, many of these principles hold well for any kind of electrical or mechanical product development process. In the twelve Agile Principles below, I have replaced the word software with either product or prototype or both (notice that I needed to make only 3 substitutions – underlined below):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable prototypes and products.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working prototypes frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working prototypes and products are the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Of course not all hardware projects can take advantage of short and frequent development cycles if long lead-time items are involved, but many of them can. Rapid prototyping techniques are increasingly available for many types of development, including 3D printing for hardware, fast-turn printed circuit boards for electronics, and even gate-arrays for quickly turning application-specific integrated circuits (ASICs). In addition, simulators and emulators for modeling the behavior of electronics and sensors and other hardware components are getting faster and more accurate all the time.
It is beyond the scope of this paper to cover in detail the methods and best practices of agile development processes such as Scrum methodology for software or for hardware/software systems, but we will write about how partners can work within these frameworks. We will not consider every type of partner, but instead focus upon what is perhaps the most common case wherein a partner company with multiple engineers is asked to develop a sub-component or subset of the prime company’s product. A typical example might be a “smart” appliance that connects through Bluetooth or Wi-Fi to the home network or internet. The prime company might develop the appliance and its control system, but contract with a partner to develop the electronic hardware and software needed to connect to the network. This communication subsystem will be an important, integral part of the product’s value proposition and there is a lot of interaction with the appliances control system; so the collaboration between the teams must be seamless.
In this kind of partnership, most companies have traditionally taken an “arm’s length” approach: They call on one or more development subcontracting companies with a set of specifications and say to them: “Here is the subsystem we need. How fast can you develop it, how much will the development cost, and how much will the completed subassembly cost to manufacture?” This kind of request causes the potential subcontracting company to “pad” their bid with significant extra time and money to cover major risks – both technical risk and risks that the specs will change or “creep”, which they know is the usual case. The people managing the partner don’t have the means or visibility to check the estimates upon which the contractor’s bid is based, so they just accept a bid and hope for the best. Communication may be minimal while both teams are doing their development, and by the time the units are brought together for integration, there are typically a lot of problems and bugs to work out – very often slipping the (padded) schedule and going over the (padded) budget significantly.
A much better approach that will lead to a better, lower-cost product in a faster time is to find a partner with whom you can follow the Agile Principles above; starting with principle number 5. Use a contractor who is willing to dedicate excellent, motivated people who can work as a team with their counterparts in the prime organization. Both the overall team and the contractor’s team should be given the environment and the support they need, and boundaries within which they can make their own decisions with little or no management meddling. Within those boundaries, the subcontracted partner team should be encouraged to innovate – adding to the value proposition of the overall product (principle #11).
Ideally these people would be collocated for best daily interaction (principle #6), but that situation is very often impractical. In collocated software Scrum groups, the daily communication is initiated with a short morning “stand-up” meeting wherein the members report their progress from the previous day and their plan for the new day. A good substitute in the case of remote teams is to have a short, daily web conference covering the same subjects. When the teams are separated by multiple time zones, it is usual for them to have these short, daily web conferences at a time when the working hours overlap.
The next point for this agile co-development is to build working prototypes (or at least simulators) in the shortest possible intervals and very frequently (principle #3), integrating these prototype subsystems at regular intervals. In the example above, the prime company might build an early “breadboard” of the appliance with simulators for the final sensors or physical elements, incorporating a similar early prototype of the communication module from the partner. A “breadboard” can be thought of as a bench or table with all of the functional elements laid-out on the surface to emulate how it will work, not yet paying attention to the final form factor. Subsequent prototypes will be closer and closer to the final form factor and functionality and use fewer and fewer simulators.
Frequent prototype cycles allows the teams to connect more closely with the dynamic needs of the end customer, usually by having a full-time product manager closely involved – or in some cases even actual end users (principle #4). The product manager’s job is to represent the real unmet needs of the end users and build the business case for the product. As subsequent prototypes are tested, it is common for development teams to find that the use case (or customer needs and stories) may change; so the improvement or changes can be incorporated in the next prototype build (principle #2). The progress in meeting the customer needs (and changing needs) can be measured with “Burn-Down Charts” and other Agile techniques; but the best metric is the number, quality and growing usefulness of the prototypes themselves (principle #7).
During the product development, the overall team including the subsystems contractor should conduct team self-reflection reviews; not reviews imposed by management, but retrospectives on how the team could work better together (principle #12). They should ask themselves: “What are we doing well? What could we do better?” And they should possibly do some root-cause analysis on any major disruptive events. These retrospectives will help the team grow and improve in principles 9, 10 and 11.