Let’s start by stating some facts. Scrum was formalized as a framework in 1995, and the ‘new development game’ in 1986 first mentioned the term Scrum in this context. The Agile manifesto has been drafted in 2001. In short, it is not new. Since this time the Agile mindset and associated approaches and have gained much ground. According to the Project Management Institute, almost three-quarters (71%) of organizations report using Agile approaches sometimes, often, or always. I think it is safe to say that an Agile way of working is the modus operandi in software development nowadays.
Even though this way of working has been around for years, there still are many challenges to overcome in adopting an Agile mindset and transforming to an Agile organization. We have come to realize that it is more than just an IT-party. It is more than just following a different process, adopting some new rules and practices and placing some new roles within our organizations. It requires organizational change to truly revolve around customers, deliver the highest possible value and be able to react to the fast-pace of change.
So in that sense, still many organizations in this field struggle with those changes, and are continuously learning and developing to become more Agile. But they do understand that the empirical approach is the way to go.
When we talk about when we need an Agile or empirical approach, the simple answer is ‘to deal with complexity.’ Software development in a fast-changing world inherently is full of uncertainties, therefore we need transparency and real feedback to inspect and adapt. We generally accept this notion and the world is full of great examples that this way of working is the most effective way to deliver real value.
What strikes me as strange is that ‘complexity’ at the same time is the primary reason that many high-tech product development organizations say that ‘Agile is not for them’. Companies delivering hardware or embedded software see this as a boundary and an obstacle instead of the driver for an empirical approach.
Agile won’t work here; our environments are way too complex, we have too many uncertainties, we need too many skills to deliver a product, our systems are way too complex to oversee by a single team, a product owner cannot fully comprehend our product, or we cannot deliver MVPs because we need a complete working machine.
Instead of focusing on business value in real products, we focus on technical value in building components. Instead of talking to and understanding our customers, we rely on writing requirements, specifications and designs. We try to mitigate the uncertainties, risks and unknowns by elaborative planning and documentation. We look for certainty in analysis and depend on specialists to do the heavy thinking and managers to coordinate all the efforts. At the end, we then roll out our initial plan in one big bang.
Software development is inherently complex, and hardware and embedded software is inherently more complex. The higher cost and longer lead-times of such development and the necessary skills involved to deliver a working product are all factors to take into account. Therefore, I understand that it might be difficult to see how to apply Scrum or any other Agile framework in this context. I understand there are obstacles in adopting an empirical approach in this domain. However most of these obstacles were also perceived within ‘regular’ software development. By incrementally changing and continuous learning we have overcome these challenges. What is key, is that we start to acknowledge that we do need to change. Focus on the positives, the opportunities and steps you can take, before thinking in limitations and problems. The additional complexity in hardware or embedded software development should not be seen as an obstacle to an Agile approach but as main reason for needing it.