Not long ago, I had a happenstance conversation with a mechanical engineering manager whose team had just adopted some agile practices for design. It was a fascinating conversation, for me, as he walked through some of the challenges they encountered along the way. They overcame them. They realized some big benefits. But the discussion was so intriguing to me because it cut right to the old-school core of engineering.
I’ll get to the story, but first, we need some context.
Old School Personal Responsibility
The first context is the responsibility of design in engineering organizations. I’ve written about this a number of times in blog posts and eBooks, so let me reuse some of that here.
An engineer’s prime responsibility has traditionally been to design products for the three Fs: form, fit and function. But that wasn’t a responsibility without consequences. It carried personal accountability. Engineers placed their signature on drawings to signify their personal approval of a design. If products failed, drawing signatures identified responsible engineers so they could justify their decisions. In summary, more so than any other group, engineering has had a strong culture of accountability.
This quote, taken from the Reference The Expanding Role of the Modern Engineer, focused on the fact that this reality is changing a bit in modern times because of the democratic nature of design. The point there was that engineering design reviews, where you have a quorum, is often where the most important decisions are made in product development. The idea of a lone engineer, often very tenured, making design decisions at their desk alone is fading for many companies.
However, the fact is that most engineers still work on a design from cradle to grave. Even if they don’t make all of the design decisions on their own, they will work on that design until the 3D model or the drawing is completed and integrated into a system. That is true today. However, agile has some serious implications for that reality.
The Dynamic Nature of Scrum
Our second context comes from a practice that is often adopted as part of agile called scrum. Here’s the textbook definition from the Scrum (software development) entry in Wikipedia.
Scrum is an agile framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within timeboxed iterations, called sprints (typically two-weeks) and track progress and re-plan in 15-minute stand-up meetings, called daily scrums.
Now, at the beginning of sprints, you’ll often have a wall of sticky notes on which there are short to medium level tasks. During these daily scrums, someone will often step forward to take one of those sticky note tasks for the day. If it isn’t completed, that sticky note might still be active. Most interestingly, that sticky note task might get assigned to someone else.
Yes. You read that correctly. One developer might be coding one piece of software only to turn it over to someone the next day. That’s part of the whole concept: it’s agile from an organizational perspective.
Applying Scrum to Mechanical Design
By now, I’m sure you see where I’m going with this.
When you apply scrum to mechanical design, the same thing can happen. You might be working on one part in an assembly one day. The next? Someone else is working on it.
No joke. No kidding. Obviously, that fundamentally undercuts the whole idea of one mechanical engineer working on one design from cradle to grave.
Implications of Agile Mechanical Engineering
OK. Well. So what?
Heh. There are some serious cultural challenges to this reality. Mechanical engineers tend to claim ownership of such designs. Sometimes, they have a tough time letting go of such efforts. So there will need to be some modifications to your team’s mentality while adopting this practice.
More practically, there are also some serious implications for requirements management and design intent. If someone else is going to be taking over your design work the next day, you need to seriously document what you are doing. You need to somehow capture your approach to satisfying the requirements, which requirements have been fulfilled at your stopping point, and your design intent. That is another significant cultural challenge that needs to be addressed.
My friend, who shared this story with me? How did they fare? After a few months of an adjustment period, they became comfortable with it. But more importantly, they saw some significant benefits. Facing a shortage of engineers, they knew they could ill-afford to have one engineer dedicated to one design for a long period of time. They needed to be more flexible. More agile.
They made the change. The organization realized the benefit.
Do you have experience with adopting agile methods to mechanical engineering? I, along with many others, would like to hear your perspective. Share your take in the comments.
Take care. Talk soon.