collaboration between hardware and software teams
September 12, 2017

3 Steps to Better Collaboration Between Hardware and Software Teams

Backlog Management
Agile

Your car, cellphone, refrigerator, garage door, and your air conditioner. All are examples of products you use regularly. Increasingly, all are made with combinations of hardware and software. To get products to market faster, companies that make them are trying to bring their hardware and software teams closer together.

When we meet with customers working to combine hardware and software development, it's obvious there is a big gap in mindsets between the groups. On one hand, the hardware teams tend to prefer a Waterfall approach of working. There tend to be hard dependencies between deliverables, a development process with few unknowns, and inherently high R&D costs. On the other hand, software teams with a more Agile mindset manage a shorter planning horizon with softer dependencies and constant changes. Let us look at three steps to closing this gap:

Step 1 – Share One Product Backlog

For better collaboration, there must be a master location for the features you want to develop. This location is typically referred to as the product backlog. You may call it a feature list, activity list, or to-do list. But, at the end of the day, it is the list of things that you wish to get done.

shared backlog

 

 

 

 

A shared backlog and size estimation makes it easier to manage scope.

Several benefits exist for hardware and software teams that have one centralized place to work:

  • Alignment. With one shared view of the roadmap/vision, it's easier for the product owner (and others) to prioritize, align the roadmap, and use comparable metrics, such as size estimations.
  • Transparency. It creates transparency between the teams, which is a basic foundation for trust and collaboration.
  • Efficiency. It enables aggregation at the queue/scope level to provide for an efficient product development organization. This allows for teams to deliver on time and in-line with what Reinertsen points out related to flow.

In the figure above, hardware and software are two separate top-level containers. This is a real representation of both the structure of the product and the organization in many cases, which can make it an ideal structure for a shared backlog. However, I always recommend exploring whether an integrated, goal-oriented backlog would be more suitable. Look here for an inspiring product backlog example.
 

Step 2 – Work in Parallel

hybrid planning view

A hybrid planning view with software and hardware teams working toward the same releases and milestones helps visualize bottlenecks and shorten time to market.

The traditional view for product development has been,“Let’s make the hardware first, then develop the software, then get it to work well.” Unfortunately, this removes an opportunity for teams to work together to optimize the combined product. It also prolongs time to market unnecessarily.

To shorten time to market, the organization should focus instead on enabling hardware and software teams to work in parallel. This kind of arrangement can improve throughput and increase output. It typically involves avoiding dependencies and becoming more modular.

A hardware team that focuses on getting one block ready that can be tested together with software (sometimes combined with simulation techniques for remaining hardware) is a good example.

An Agile tool like Hansoft, with a hybrid view of the plan (see figure above), can help teams work towards joint releases. In such cases, it's important to spend more time on an in-depth common release plan to make sure dependencies are discussed and managed as early as possible. Add internal milestones during the process to meet unavoidable dependencies, or to manage strictly defined process models found in regulated industries, such as automotive and aerospace. Use burndowns then — for both hardware and software teams — to make sure progress is on track and aligned with real-time expectations.

schedule variance

 

 

 

 

feature burndown server

 

 

 

 

feature burndown for server

 

 

 

 

Real-time metrics from both the hardware and software teams in one view, makes decision making easier and more accurate.
 

Step 3 – Collaborate Quickly

Some dependencies cannot be avoided. These must be actively managed by teams involved. Collaboration is critical. Use tools available to communicate and resolve dependencies and impediments as soon as possible. The business impact of a quick resolution can be huge. If you can resolve right away, without a meeting, that's best. (A tool like Hansoft can help.) In doing so, you'll reduce the overhead generated by unecessary meetings.

news feed signaling blocked item

A news feed signaling that an item has been blocked as it happens.

Overcoming the gap between adaptive and predictive work is challenging. This challenge is made even more difficult when teams are not located in the same offices. A common tool can create a common language that emphasizes a collaboration around the issues that matter.
 

Bringing It All Together

Aligning hardware and software teams is a very complex challenge for today's development organization. These three steps are not a complete solution, but hopefully act as stepping stones in your path to bringing hardware and software teams closer together.

Learn more about Hansoft, the backlog management tool for better collaboration.