Skip to content 
The time has come to de-mystify Agile. Our research and client work show that even those software firms that boast about being Agile do not necessarily follow every point in the Agile Manifesto. They do not follow even half of them. They apply only a very small portion of Agile practices – and they’re having remarkable success with this approach. Development teams of tangible products, be they consumer electronics, medical equipment, or pharmaceuticals, can also benefit from applying select practices from the Agile body of knowledge to speed products to market. Two of the most effective and beneficial of these practices are sprints and demos. Powered by these twin aspects of Agile, development teams of all manner of products can increase accountability and make programs faster and more predictable.
Applying Sprints to Tangible Products
A sprint is nothing more than a small, time-bound portion of a longer product development program focused on achieving a pre-defined goal. Whether the goal is to test a portion of a product, create a detailed interface design, or prove the concept of a key functionality, each sprint must have a definite deliverable or prototype demonstration, presented to some customer, external or internal. This deliverable must be specific, observable, and tangible.
Planned in this manner, sprints are a forcing function that moves the product development program ahead in a rapid fashion, holding teams accountable for some measurable result on a regular basis. They also provide early and rich feedback from those outside the agile team that dramatically increases the probability the new product will satisfy, if not delight, customers. The diagram below shows the range and priority of benefits reported by practitioners who have modified Agile for tangible products.
Have a Clear-cut Goal
We have found that most teams that use sprints plan them relatively informally. After deciding on a duration, the essentials of planning a sprint include defining 1) its goal and 2) the audience and deliverable for the prototype
Every sprint needs a clear-cut goal. The goals will vary depending on where the entire team is currently located within the phase-gate or milestone process. Early in the program, the goal of a sprint might be to create a sketch, a simulation, a paper prototype, a screen shot, or a vignette. As the program moves from the Concept to the Prototyping Phase the deliverable may be a sub-assembly or a component of the overall product.
Plan the Demo
Define the deliverable and audience for the demo by reasoning backward from the goal the team plans to deliver. What aspect of functionality is the team planning to demonstrate? What form will the deliverable take? Will it be screen shots? Will it be 3D printed? What are the day-to-day steps to be completed and by whom, in order to reach the finish line within the allotted time? Finally, ask how the team will measure success.
Product development is an activity with many stakeholders and any number of them may form an audience for a demo. Given that the proper non-disclosure agreements are in place, actual or potential customers could be an audience for a sprint demo. However, the audience is more often customer proxies that include members of the Sales organization, Customer Service, Marketing, or Field Engineers. Another potential audience may be senior leaders with a stake in the product’s success or owners of the agile process or product. Adjacent stakeholders such as operations managers, marketing managers or even folks from Purchasing or Legal or any other function that has a stake in a portion of the complete product development effort, may also be an audience for a demo. Demos for adjacent functions can enhance the collaborative event between the team and these cross-functions.
Often the purpose of the demo is to reinforce confidence in the do-ability and desirability of the program, as well as to eliminate risk. The stakeholder that most needs this confidence boost may determine the right audience for a given demo. The nature of the demo will often have a looser definition toward the earlier phases of a program, increasing in specificity and concreteness as the team continues its work. What is most important in defining the audience and the nature of the demo is that the sprint possess an unambiguous target that is clearly defined. It must be easy to ascertain if the team has achieved its goal or not.
The Value of Sprints and Demos
Sprints and demos act as beacons of accountability for your teams. Focusing on the short term can prevent the team from getting stuck in the weeds, with the concomitant waste and churn. Sprints and demos also inspire the team to meet incremental, achievable goals that give team members clear indications as to when they hit their targets, within the allotted time. Sprints and demos keep the team on task and moving forward in a steady, consistent fashion toward the overall goals of the program.
Teams become accountable to the senior managers and internal customers who see clear results early in the program. Demos also increase confidence in the major stakeholders. Customer proxies, senior leaders and adjacent functional leaders see the risk wrung out of the program and see concrete evidence of success at regular intervals. If the team runs into issues during the sprint, then these challenges are identified quickly as they arise and may be managed just as quickly before they fester.
Adapting a software process to tangible products requires creativity and flexibility. In tangible product development, teams may need to make changes late in a program, or a component manufactured overseas may be delayed, which can throw a wrench into the works, sprints or no sprints. Yet, our research with clients show that successful firms are using a very small number of select practices from the Agile approach, including sprints and demos, to manage product development programs to market success. There’s no magic in Agile. Just know-how, consistency and planning.