Most Agile software methods operate under the key assumption that resources (software developers and testers) are interchangeable, just as user stories are independent of each other. This is one area where Agile software experts run into real trouble when they push these ideas onto hardware teams.

A recently-published article on Agile for Hardware had two sentences that stunned me: “To achieve the most value at each iteration, Agile teams capitalize on cross-functional skills. A mechanical engineer may make simple firmware updates, or a software engineer may modify a CAD design and rerun analysis tests.”

Whoa!

Would you, as a project leader, let an ME anywhere near your firmware’s code base? Run the risk of a hard-to-find defect that derails the entire schedule for days to save a few hours? Would you, as the overloaded firmware engineer, relish the idea of training an ME on the minimum they need to know about your code to help you? Perhaps an electrical engineer might do it, but how much training would be required on the SW team’s tools and coding conventions? And even if you were willing as the project leader, would the ME/EE and FW managers go along? I’m doubtful.

Similarly, I doubt few software engineers would be able to modify a CAD design for a mechanical part unless it was literally “go here — enter these numbers — push this button to rerun the analysis test.” In fact, it would be difficult for an ME who wasn’t on the team to do much more than this, because hardware developers build knowledge in an area of specialization.

Development Teams Are Teams of Experts

In every team — hardware or software — members develop areas of specialization, even if they start out with the same backgrounds. Some people work with designers to code user interfaces; others dive deep into the guts of the database or train artificial intelligence systems. Some become experts in how plastics flow through a mold and others in how different metallic alloys affect aerodynamics. Some places have people who do nothing but design the packaging so that the product arrives at its destination intact.

Some areas of expertise are so core to the product that the engineers are permanent team members. They’re dedicated to the program because their work is central to the task at hand. They have plenty of work — more of it than they can do — within their own disciplines.

Others are like Frank, a master mechanical engineer who helped invent the technology behind the company’s core product. Frank is on every team, for at most a few hours a week. He spends his days going from one design review to another, providing useful feedback. He’s seen it all and done most of it already. A few hours with an expert like him can save weeks of time.

Most Experts Juggle Multiple Projects

An engineer can become known as the go-to person for a specific subsystem and then the engineer’s manager has to juggle commitments across all the projects that are modifying the subsystem. This is more typical, in fact, than being dedicated to a program from cradle-to-grave.

Even core team members usually get assigned to multiple programs at least some of the time, because the engineering process has points where individuals are waiting for something — a supplier response, test results, etc. — or because they may be in that time when one project is near the end as their next project is ramping up.

Resource Managers Need to Track Program Allocations

To stay on top of all this, resource managers need the ability to track project assignments and allocations across projects.

A program doesn’t need a packaging engineer for the duration of the program, unless there’s something about the product itself that will require a new type of package that the company doesn’t know how to create. The packaging engineering manager needs to know when packaging engineers will be needed.

If packaging engineers are scarce resources, we don’t want to hold up a project because this resource has become a bottleneck. This is a problem that Agile software teams don’t need to solve, because interchangeable resources can be reallocated to prevent these obstacles from forming.

Agile Resource Management for Hardware Teams

At the same time, the solution is not to revert back to detailed GANTT charts that map out every detailed activity from start to finish. Here’s what Agile Hardware Teams do instead:

• Avoid overload at the portfolio level, by ensuring that the organization as a whole is not taking on too many things at once. I admit this is simple but not easy, because most product development groups have more potentially good products than they have resources.
• Let floating experts govern their own time as long as no project is being ignored. Frank knows very well which teams he can help, which ones are ignoring his advice, and which ones are doing OK without him. He needs accountability and prioritization so that he doesn’t just work where it’s easy, fun and he’s seen as a god. But he doesn’t need a detailed allocation that breaks up his schedule into half hour increments.
• Have cross-functional teams work on clusters of related programs together. This way, they can work on multiple projects without having to work on multiple teams. This simplifies scheduling and allows the team as a whole to pivot quickly to new programs.
• Make sure that shared resources, like those packaging engineers, have enough visibility into project plans to know when they will be needed, while encouraging the core program teams to identify Knowledge Gaps and Key Decisions where their help and early feedback will be needed.

With these tactics in place, teams should be able to manage their work well enough to make progress on the overall portfolio even if localized bottlenecks slow things down within individual teams.

Who’s the right person to help that overloaded firmware engineer? A firmware engineer working on a related program that’s not as urgent.