“We don’t have enough engineers.”

That’s was the takeaway headline, according to a Computerworld article, from Obama’s speech back in the middle of June. For anyone that’s been tracking the STEM shortfall issue, that might not come as a terrible surprise. Yet there was one other issue I came across in this summary that did surprise me. Here it is.

“The U.S. had just over 1.9 million engineers in 2010, according to Labor Department data. Software engineers make up nearly half of that total.”

Of course, today’s products not only include embedded software, most of the innovation and investment of any product development venture is in the embedded software. In the end, however, the ultimate task is to get systems of mechanical items, electrical components and embedded software to work together. While the mechanical and electrical design processes may not have changed all that much in the past few decades, software development has. And the question on my mind is this: could those advances be applied to mechanical, electrical or system design processes?

What is Agile Development and SCRUM?

I don’t think the concepts of Agile Development need too much introduction, but just to set a proper baseline, here’s some short excerpts from wikipedia that summarize some of the main points. I’ve clipped these together for brevity. To get the full scoop, head on over to the entire wikipedia entry on Agile Development.

Agile Software Development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The Agile Manifesto introduced the term in 2001.

The main emphasis of the Agile Software Development method are the following.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Here are some of the major characteristics I think are most important.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders…

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members…

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication…

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions…

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are…

Compared to the traditional processes and procedures associated with mechanical, electrical or system design, these characteristics sound dramatically different. But it’s hard to argue with the popularity of these processes. Agile development and it’s offshoots like SCRUM, paired programming and the like are widespread in the software application industry. Furthermore, they’re increasingly widespread in traditional product industries like high tech, automotive, aerospace and defense and others. I guess the last and most important point here is that this process is effective. It enables organizations to stay on schedule, control scope creeping, control costs and solve problems at an incredible rate.

Analogies to Mechanical, Electrical and System Engineering?

So what would it look like if we applied these concepts to mechatronic products or systems? Let’s take a look.

Going Old School?

When thinking about Agile in the context of broader mechatronic products, the concept of working software as the end game is equivalent to working sub-systems or systems. This would almost necessitate integrated teams of mechanical, electrical, software and system engineers. But this isn’t just about getting those individuals together, but getting a working prototype of the subsystem or system actually functioning. Lots of companies have processes and procedures for NPDI and the like but that equivalent doesn’t necessarily have to be brought down to the lower levels of product development. In fact, from my impression of Agile Software Development, the attitude should be more like let the chaos ensue and solve problems as they arise. Ultimately, this actually reminds me of old school design. Back in the day, engineers and designers weren’t locked to their desk. They were most likely to be found on the shop floor or test lab, tinkering and experimenting with physical parts in their hands.

But does that mean less actual design time? Does that mean less time in front of CAD and CAE? Ultimately I’m not sure how it would play out in terms of exact amounts of time, but I do think the activities would change. The urgency would be on getting the subsystem or system in the test lab as soon as possible to enable fast failures, fast changes and fast experimentation.

There’s No ‘I’ in Team

Another major emphasis with Agile Software Development is on face-to-face interaction and a de-emphasis on documentation. The whole idea of capturing and documenting everything that was said or how decisions were made aren’t at the forefront. What I find most interesting about that is how it cuts across the traditional accountability culture of engineering. In the old days, when an engineer signed off on a drawing, their reputation was on the line. If something went wrong, managers and executives would come to that individual. Of course this led to a lot of conservative decisions over the years, but that was engineering for you. The Agile way ignores that individual accountability approach for the sake of a more team-based and consensus building approach. I guess the team could be held accountable but I think that’s besides the point. The idea here is adaptability and speed.

We Don’t Need No Stinking Schedule!

That title is a little bit in jest. But again, it’s all about where the emphasis is placed. Tasks are broken into minimal tasks with little emphasis on long term planning. I think I can hear many an executive’s blood pressure rising right now. And I have to admit, I am unsure how this might apply to broader product development myself.

In the software application world, conceptually there is an infinite list of enhancements and bugs to be addressed over an infinite number of releases. Software applications are almost like living things that grow over time. That strikes quite a juxtaposed image compared to traditional products like cars, planes and industrial machines. Sure, you can enable all of those things with internet connectivity and update them wirelessly. But for you to ship those products you have to have at least one formally working configuration. And while the same applies to the first release of a software application, with traditional products the hardware in the first shipping product might never change. So there is at least some part of that configuration that as an engineer you assume it is locked.

Summary and Conclusions

Embedded software is a major piece of traditional products. A lot of resources and budget are now being dumped into the hiring and support of software engineers. There are a lot of intriguing characteristics of Agile Software Development. It seems like some of them apply to mechanical, electrical and system engineering. But there are others that may not translate very well.

Time for you to weigh in. Has your company tried to adapt Agile methodologies to other engineering areas? What worked? What didn’t? Weigh in and let us know what you think.

Take care. Talk soon. And thanks for reading.