Lean Startup, Agile, SAFe and Silicon Valley’s impact on development…
A headhunter contacted me in my twelfth year as a design engineer. At the time, I was designing for Honda. He asked me if I knew anything about Lean Product Development and its principles of set-based concurrent engineering, chief engineer, trade-off curves and more. I honestly had no idea what he was talking about and told him so. He wasn’t convinced so he sent me a book, TheToyota Product Development System by James Morgan and Jeffrey Liker. After quickly digesting the book, I realized it described what I did on a daily basis. I had not realized that academia had conducted research and coined terms for our style of development, Lean Product Development.
Design for Six Sigma (DfSS) was an attempt to drive six sigma principles into the development arena. This methodology was accepted about as well as Lean was in design settings; in other words, not so much. There were, however, a couple of wins in both areas: Lean’s focus on flow and value creation and DfSS’ emphasis on the voice of the customer (VoC) and Design for X, where X could be anything other than technology that considered the impact on manufacturing, service, cost and more. That gave each of those practitioners a solid base from which they could build.
Agile wrote its Manifesto years before but exploded on the scene after 2010. Everybody was scurrying to mimic the software world. Lean met Agile when Eric Reis’ book The Lean Startup gained notoriety for its emphasis on infinitely small design/test cycles. It doesn’t take into account prototype creation time. It assumes an instantaneous build. Outside of publicly distributed software, there simply aren’t industries that can do instant prototypes and the requisite testing. Approaches require a short “waterfall” approach before writing User Stories.
Scaling Agile isn’t easy. A scrum of scrums and SAFe are one person’s take on Agile’s answer to portfolio management. Proceed with caution as I have yet to see a successful implementation of SAFe.
Development teams don’t want structure
Creative teams don’t like process. They bristle under micro-management. They embrace Agile because scrum teams are nearly autonomous in what they work on, what order and by whom. Classic waterfall project management opponents outright reject large Gantt charts, critical paths, associated resources and precise prototypes stages today, and for a good reason, it’s bureaucratic and burdensome.
However, Agile has its limitations too. Because of the brand equity associated with Agile now, executives have little ammunition to dig in and debate the innovation methodology and process. Results seem eerily familiar: projects remain stuck in development, schedules aren’t maintained, and it stretches people beyond their limits.
Development teams must have constraints. You must define the innovation process, while keeping it dynamic. You must also closely monitor autonomy and holacracy. Teams often hide poor performance behind industry accepted development methodologies. Be aware of the advantages and disadvantages of each approach if you are going to implement them. If not, you may create a confused, frustrated team.