Lessons from Lean Manufacturing

I talk about Agile development with anyone who'll listen. It's especially interesting to me to talk with non-game developers, because other development projects have concerns that I've often never considered. Recently I was talking with a couple of guys who I play in a band with about their day jobs, which are in manufacturing.

The topic of Lean Manufacturing came up. Wow, were there some opinions there. Terms were thrown around like Black Belt and Six Sigma and other things that I googled at the time, but generally the whole affair was pretty well derided by these compadres of mine.

As their story went, to comply with the Lean Manufacturing rules, one needed to have some number of people to fill various titular roles. Ostensibly, these folks are there to provide support for the needs of the rest of the staff, support that was never there before but which was always needed. Theoretically you could convert or otherwise transition some of your existing staff into these roles, but "full compliance" demands certification for these roles and, as it was explained to me, their employer desired an "out of the box" solution so chose the route of hiring a number of consultants to fill these roles.

In my head I compared this to the agile "methodology" with which I am most familiar, Scrum. Scrum "creates" a number of roles in the scrum master and product owner, among others, although in my opinion and experience, it is highly desirable to take these people from the team. Insofar as compliance goes, by-the-book Scrum doesn't require anything of the participants outside of an understanding of what it is they're doing. Over the past few years there's even been a growing drive on the certification front, with Scrum certification courses happening around the world.

My question is, is this really necessary? This came up because of the Lean Manufacturing talk, actually. These friends of mine asserted that these new people in their manufactured roles added nothing but bureaucracy to their jobs. That tickled an itch of mine, because the whole point of Agile Development is to make it easier for the team to make the software. For any given participant, the amount of new bureaucracy should be easily offset by a reduction in other non-productive tasks that get done, overall yielding more productive time per hour worked.

As the story goes, in this implementation of Lean Manufacturing, there was only overhead added and no new efficiencies. A checkbox for the corporate certification but no actual tangible benefit.

I fear that this is where a blindered approach to agile practices could lead, as well. Already I know of some in my industry who get all of their people "certified" for various of the practices, but to what actual tangible benefit? (Disregarding that it's nice for a company to send you to a conference, because I could think of a number of other conferences more relevant to what we do.) Especially when the "certification" is of the "give us money and we'll certify you" variety; how can someone claim "master"-level command of a subject if no sort of examination was given to test that skillset and knowledge base?

This brings me back around (in my mind, anyway) to one of my earliest posts here, and that is the single most important takeaway for me from all of the agile learning I've done over the past five years. That is, simply, that it's not the process that matters. Devotion to a book or a method or a procedure is only suitable as long as it's applicable to the group that's using it, and it's only applicable to the group if it actually helps that group to accomplish what they're working toward.

Clearly I'm not a fan of certification. In general, I'm not a fan of the "institutionalization" of anything that we do as game developers, because there is no silver bullet. There is no one-size-fits-all. We've got a million problems before us (ok, only 750kloc in my current project but lets assume for the sake of argument that there is more than one bug per line), and no game is the same as any other. This is great! There is huge variety in the teams out there, different teams doing different games with different development strategies, and it would be foolish to think that any one method of doing things would apply across the board. Sure, certain aspects of Scrum, for example, could be useful across a number of teams. Certain bits of XP will work out of the box for a broad range of developers. We can, and probably should, figure this out through experimentation with our own teams, though. We shouldn't, and will probably fail if we try to, go to a conference, hear about ProcessX and say, "this is what our team will use."

...and that is what was bothering my friends in the Lean Manufacturing shop. All show, no go. The "Black Belts" were (or at least, appeared to be) there to ensure compliance, rather than being the thoughtful senseis that the people behind Lean Manufacturing likely intended. But then that's why I thought of this comparison, because I know plenty of folks who are in "agile" shops who swear up and down that it ain't making their lives any easier, it's just bullet points on the marketing brochures.

Agile helps development as much as it's allowed to help. It is empowered by the flexibility that it is given. As much as the team is a living organism, so the processes that the team uses needs to breathe. Inhaling and exhaling, in with the reflections on the process, out with the bits that aren't ineffective. An open mind is all that is required. I would imagine that Lean Manufacturing is intended to make better products faster, fairly obviously since otherwise it wouldn't even be considered for implementation. It's too bad, and I feel sorry for my friends there that the people running the joint don't "get" it. A manager has got to truly grok agility to be able to pull it off, but it is sadly clear that many do not.