One of the things I’ve witnessed first-hand over the years working as a software developer in hardware manufacturers – is that electronics, telecoms and hardware manufacturing firms struggle with understanding what software engineering truly means. From my early days when I worked for Motorola in telecoms, I saw software engineers working in classic waterfall – receiving a spec (often helping to write it), creating a design doc, getting that signed off before writing any code, writing test specs.
Software is not a predictable process. Estimation, creation, testing, delivery and maintenance are all different concepts when it comes to software than for hardware.
Firstly software is hardly ever ‘done’ – it’s rarely complete. Requirements changes, dependencies change, software needs to be rewritten or adapted to accommodate. There is no complete ‘specification’ for software.
Second – testing can’t wait until something is ‘complete’ if something is never complete. Make testing a part of your everyday software work.
Third – the delivery of software is highly dependency on context. You can’t install software on any platform at any time, dependencies play a huge part in not only the deployment of that software but also that it runs according to your ‘specification’ (which as we now know doesn’t truly exist).
For those from the world of creating physical products, it can seem like a waterfall approach will bring reliability and quality when in fact all it brings is the opposite. It brings uncertainty because software doesn’t sleep. It keeps changing.
SAFe mimics Manufacturing
Implementing the SAFe framework (Scaled Agile) can feel like the appropriate choice for manufacturing businesses. It keeps enough of the ‘command and control’ waterfall flow of hardware delivery to feel comfortable but introduces a lot of Agile-sounding processes which make it feel modern and reactive.
SAFe is marketed to precisely hit this perceived gap. Through implementing this framework you will feel like you’re creating modern software (and increasingly modern software infrastructure too), when in reality all you’re doing is trying to mimic what feels comfortable to you in a domain where it has no right to exist.
The original Agile Manifesto’s authors have strong opinions about SAFe, and I’ve borrowed a few quotes from that article:
“SAFe’s insistence on rigid planning and up-front design is counterproductive in a rapidly changing business environment.”Arie van Bennekum
“SAFe’s attempt to codify and standardize Agile practices is misguided; Agile is about adapting to the unique needs and context of each project.”Martin Fowler
“SAFe’s attempt to scale Agile by adding more layers of management and control is misguided; Agile is about removing barriers, not adding them.”Ron Jeffries
With more of the world becoming software dependent, implementing an effective way of working with software within your business is crucial to the impact your business has on the world. With your key infrastructure also increasingly becoming defined by software (through either public cloud infrastructure or via Infrastructure as Code) you can quickly find that any decisions you make about the future of your business’s production, marketing, sales or administration implies a software change.
If you implement a rigid software change process using inappropriate methodologies it can have significant implications for your company’s ability to stay agile in the market because your way of working (in many departments throughout the business) is affected by the ability to make easy and secure software changes.
Therefore, before you implement any sweeping changes to the way you work or attempt a ‘digital transformation’ incorporating cloud and agile ways of working, consider what it will mean to your business’ future prospects. You don’t necessarily need a big bang to your way of working, you may just need a plan.