Waterfall + Agile for Hardware Product Development
Most consumer devices combine hardware and software. Cross functional development teams need to manage both hardware and software efforts in the most effectively way possible.
Hardware, or the physical manifestation of the product, includes industrial design, mechanical design and electronic system design. These three design disciplines are highly dependent on each other and require tight coordination in each design iteration, and may involve a number of outside vendors to complete. The Waterfall management approach is best suited to manage the complex dependencies between activities of hardware processes.
Product software may be in the form of device firmware, a mobile or PC based application, or driver software. In addition, there is likely software development effort required to build device programming and testing tools for design validation or implementation at the production site. Traditional Waterfall project management methods have become passé in the last few years, with most software developers adopting various Agile methods instead, to limit and set scope in clear and digestible work items that can be tested and released at a regular cadence.
So how do you bridge the preferred project management paradigms for a cross functional team working to design, develop and release a hardware product? You use both and create an interface between the two.
Step 1 - Hardware Project Plan
Along with stakeholders, the engineers and designers working on the physical aspects of the design need to define the goal of the current design iteration. Iterations may have goals such as prototyping a new design or refining a design in preparation for mass production, and each will have their own set of tasks, timelines and dependencies that need to be mapped out. Traditionally this is done with a Gantt chart, which shows a list of tasks and a timeline with task start date, task length and dependencies illustrated graphically.
Step 2 - Identify Software Milestones and Requirements
Stakeholders and engineers should then sit down with the software development teams and create and milestones that represent software deliveries that are required. These milestones should be linked, with dependencies to tasks in the project plan. Examples of software milestones include device firmware, with sufficient code to test basic PCBA functionality, or test software required to validate various assembly processes. Minimum requirements for each software milestone need to be discussed and listed. These requirements will be used to define the work items in the next steps.
Step 3 - Convert Software Requirements into Work Items in Backlog
The software team then will convert the requirements for each release into work items and place in the backlog. All items should have an initial estimate of effort required in order to get a gut check on whether the delivery timeframe is reasonable.
For instance if the lead time on the project plan from the current date to the next software milestone is 8 weeks, and the software team is running 2 week sprints, then the software team must be able to pull the full set of work items across 4 sprints. If the effort level is deemed too high to deliver in the requested time frame, then either the milestone needs to slip and push items in the project plan out, or additional software resources need to be brought in to complete the work items.
Step 4 - Plan and run the Sprint
During sprint planning, software and hardware teams can prioritize and pull the most critical software work items into the next sprint for execution.
At daily Stand Up meetings hardware engineers will discuss progress along the project plan and software developers will relay their progress in executing the work items in the Sprint.
Blockage of software tasks due to hardware dependencies should be highlighted, during the Stand Up meeting, and hardware engineers should work to unblock the software developers.
It is not necessary for the hardware engineers to have work items in the Sprint, but it can be helpful for engineers to have their own backlog of tasks, which can be pulled forward during periods where external processes are running through their lead times.
Step 5 - Review the Sprint and adjust the Plan
At the end of each Sprint the whole development team should review work items completed and determine if the estimates for remaining work items towards the software milestones need to be adjusted. If items are still left incomplete in the Sprint or estimates on work effort increase then the hardware team and stakeholders will need to adjust, or add slippage to the software milestone. The overall project plan should be reviewed to see the overall impact to the project schedule.
If on the other hand work items are being completed ahead of the milestone, or the hardware schedule has slipped, then it is up to the discretion of the whole team whether to release the minimum spec and move on to the next milestone, or to attempt to fold in less critical, but possibly useful features into the release.
Step 6 - Release and repeat
When the requirements for the software milestone are complete the software should be packaged and released to the hardware team.
Sprint retrospectives and velocity mapping should be used to derive the accuracy of a team's effort estimates and calculate a team's throughput. This will help increase confidence in estimating if scope of work for milestone release is achievable or if adjustments need to be made to scope or schedule for future work.
By combining the Waterfall and Agile project management methods in an intelligent and coordinated way cross functional hardware and software teams can operate in the modes that best suit them. Through identification of major software deliveries through milestones and constant communication between teams through Sprint Planning, Stand Up meetings and Sprint Reviews, tight coordination can be achieved.