Product teams for hardware products

Already in 1986 Ikujiro Nonaka und Hirotaka Takeuchi identified cross functional teams as a success factor for the development of new products. In their HBR article „The New New Product Development Game" they described six characteristics of successfully designing products:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Not only simple teams but cross functional ones are a key factor for successful development.

What is a cross functional team exactly?

Cross functional teams are a way of working together more cohesively, across the silos of the organizational chart, reducing hand-overs and achieving a smoother and more efficient workflow. For our clients, we usually build autonomous teams with all or the maximum of competencies needed to develop solutions valuable to the customer. It shows that it is a key success factor. Scrum is a team-based management framework. It fosters interdisciplinary and collaborative work within the organization. It’s no coincidence that the first of the four statements of the agile manifesto says: "Individuals and interactions over processes and tools.“

Some companies starting with Scrum in hardware development are not willing to build cross-functional teams across organizational silos right from the beginning. Within a short time one can observe the following consequences:

• A single team cannot deliver value on its own
• Difficulties to deliver value with all teams on a sprint basis
• Time consuming coordination and synchronization between different teams
• No transparency about real product readiness
• Integration phases are slowing down the delivery process
• Lack of commitment to the entire product
• No ownership on product level - shipping of responsibility: „We“ vs. "the others“

We recommend to be especially careful as far as the team setup is concerned. To be able to deliver value the team’s setup and responsibility should ideally mirror your product architecture based on independent modules. Means each team should be responsible for a functional module. In this case you have one team for each module of your product and you can deliver value on the entire product level at the end of each iteration.

What are the main challenges of interdisciplinary work in a cross functional team?

Responsibility and decision makingGive the team the authority it needs to get things done and move forward. Progress will slow down if the teams have to ask the management for approval at every step. As head of mechanical engineering, system engineering or electrical engineering you have to let down taking single decisions. Instead, support the team in understanding or defining transparent decision criteria. As such a stakeholder you can still challenge the team at least at the end of every sprint! If your project is not doing as well as you desire, try to figure out how you can strengthen the team. Look for solutions within the team before you start looking for solutions outside the team, without the team!Find a common languageTeamwork is an individual skill, interdisciplinary work is another one. Team members have to learn respecting each single competence and input. As a Product Owner you encourage the team to deliver valuable results and features together. Never define single delivery where only one competence is requested. It will help the team to know each other, understand the single contribution to the whole product development. As a ScrumMaster you can support the team finding a common language by using visualization and encouraging pairing.

Team decision versus level of influence

Depending on the company's culture or history, different functional silos might have different levels of influence. The ScrumMaster and the manager have to be careful not to transfer these power biases into scrum teams. Be careful that decisions are not a „mechanical decision“ or a „science“ decision but a team decision regarding to the product vision.

Collocation

The best way to lower barriers to team communication is collocation. Without sending the whole team in the desert for the duration of the project like engineering legend Kelly Johnson of Lockheed Martin did in 1943 (see Skunk Works) you should support a maximum of collocated time. It has to be simple for the team members to meet if they want/need it.Use a War Room or project room (Obeya in lean equivalent) to make the project visible in one place. A place for collecting all the Information and project artifacts will create a magnet for team members as well as for supporting resources and stakeholders. This place can be seen as a working room as well as a show room. Choose a room spacious enough to host your prototype or which is very close to your laboratory or prototyping facilities. In all our projects, we have at least a dedicated team room for scheduled meetings (Planning, Review, Workshops) where we gather all the main Artifacts (Vision, Backlog, Workshop results, etc.). Especially for design, architecture and interface specification invest colocated time instead of other kinds of communication. Like Donald Reinertsen said: „Never place an organization or a geographic boundary on top of a poorly characterized architectural interface.“ (Don Reinertsen: Managing the Design Factory. A Product Developers Tool Kit. Free Press, 1997)

Focus

You wish your team members to be committed, to share a sense of ownership, taking responsibility and making decisions? Strive for dedicated team members! 1 Person= 1 Team = 100%Even with best intentions, bystanders trying to "help" the team often just create more work for it. Those who are doing the work should be making most of the decisions.  Although you probably cannot afford to have every member assigned to only one team each, the more often you can do this, the better your project is likely to perform. Be sure you have people almost temporarily (some Sprints ) in the team if their field of competence and their decision are strongly needed in this phase. Invite people to join at least the Scrum Meetings, especially the Dailys or Review Meetings. For example when you are in a phase in which you have to negotiate with suppliers and submit orders, ask the colleague of the purchasing department to join the team for a few sprints.I made the experience how dedicated staffing greatly improved accountability and commitment because:

• If the project is not working, team members cannot hide somewhere else!
• Each team member is informed, always up to date (compared to part-timers constantly out of date, and others wasting time updating them.)
• Each team member understands and was involved in the decision process.

Although you cannot afford to have every member assigned to only one team, the more you can do this, the better your scrum team is likely to perform.I am deeply convinced that cross-functional teams are the key to delivering value faster by reducing transaction costs, accelerating decision processes and fostering a real sense of ownership for the entire product: before losing yourself in coordination and integration activities, give it a chance from the beginning!