When I was teaching software engineering almost a decade ago, I always liked to compare building software to building a house. It was this mindset that differentiated a “programmer” from a “software engineer”, and explains why it’s best to catch a bug early (even before any code is written) as it gets incrementally expensive as you go along the process. It was a beautiful analogy that seemed to drive the point.
Except for one thing – it wasn’t really accurate.
In my defense, this was the line of thinking that was prevalent at the time. It was the foundation of why the waterfall model was widely accepted then.
But these days, we’ve recognized that building software isn’t really like building a house. While it’s a fundamental truth that the later you fix something, the more expensive it is to do so, there’s really not much you can do about this in the case of a house. With software though, you can design it to be flexible to change. And since software creates value almost out of nothing, do-overs and refactors are not really as expensive as they sound.
What this means is that while engineering is, in fact, a mindset we share with civil construction, it may not be helpful to limit the possibilities within that analogy.
The “magic” of Agile
Agile has in recent times been generally accepted as the way to build software. It’s a huge paradigm shift from the linear, waterfall model of old. It acknowledges the nature of software to change, and that instead of resisting or even groaning over these changes, we should embrace them.
The principle of the minimum viable product was groundbreaking in this regard. It encouraged you to build something halfway through and get people to use what you’ve built so you get a better idea how to move forward. (Going back to the house reference – imagine building a basement and a kitchen, and asking someone to live there for a week, just so you can figure out how to best build the bedrooms. Doesn’t really make sense in that context.)
This concept consequently led to the idea that software can and should be a service, rather than a product. The idea is so widely accepted, there’s an entire industry around it now (“Software as a service” or “SaaS”). As compared to a product, improving a service is continuous and granular, and agile positions software as being in the same vein.
Does the model work?
It personally took me a long while to get used to the idea of using an agile process model. In the department I managed at my last job, some of the teams adopted it, but I never really saw the difference it made as compared to those that approached development in the traditional waterfall.
I realized later that this was mainly due to what we were building, and not a matter of the process. The software we built was part of the production line, and if there’s a worse position to be in than being a product, it’s being a part of its production. You get even stricter deadlines, less flexibility on features, and a much higher expectation of quality.
No silver bullet…
Could we have done better with our development process? Of course, we could. After all, continuous improvement is something that transcends development life cycles. Could we have fixed it with agile? I don’t think so.
The fact is, agile is no silver bullet. You need to use it thoughtfully or you could end up in a worse situation than you started with.
Here are a few things to look out for that might indicate that agile isn’t for you.
You don’t have a way to continuously deliver your software.
My department specifically was in charge of building the DVD (yes, a bit outdated but who understands the hardware market these days) containing PC software that went into the box of every printer & MFP in production. And once that DVD is out, there’s pretty much no way to replace it without costing significant amounts of money.
Yes, there’s website downloads and auto-updates, but that’s something a very select few users actually do (and it’s generally bad form to ask them to). You have to accept the reality that once they install your software, every line of code built into and excluded from it will likely stay that way until they buy a new device.
Continuous delivery is key to why agile works so well, and why SaaS became such a dominant business model. Without continuous delivery, there’s really no option to release an MVP and hope to fix it later.
You don’t do unit tests (and probably never will).
In theory, every engineer can (and should) learn how to do unit tests. In reality though, not everyone has the liberty to do so. This is especially true when you’re working with a lot of legacy code. I’ve seen 2,000-line functions in my lifetime, and I’ll be damned if I ever need to unit test those.
The test harness is a key component that allows developers to freely and fearlessly refactor source code. It allows you to make changes on the fly (sometimes but hopefully not too often in production). With some legacy code, changing how a single input field works can sometimes have disastrous side effects, as was my experience. If you’re in this situation, you best have a QA phase in your process before your release.
You’re part of a bigger process.
In our particular case, that was the manufacturing process. It’s not a very good place to be if you want to be creative with your development process. In manufacturing, a delay to a planned production line can cause a big dent on the bottom line. You don’t want your “agility” to be the cause of that.
When you’re part of a bigger process, you’re bound to abide by deadlines and management controls that may not be 100% in your scope of influence. In most cases, an agile process model is not easily compatible with this situation and in the interest of the greater good and releasing a product to your customer, you will need to find a process that better fits in.
When any of these things sound familiar, you should reconsider whether an agile approach will work best for your project. In most projects I’ve personally seen that attempted to use an agile process in the above conditions, the project team ends up using it as just an easy excuse to defer work to the next release cycle.
If you’re feeling like a hero, you could work to fix those conditions – build a continuous delivery system, code those unit tests, or tear the whole thing down and start over with the right mindset. It’s a boatload of effort to begin with, but it may well be worth it if it paves the way towards a better software culture for your team.
In the end though, “agile” is more than a process model, it’s basically a culture. There’s a lot of agile practices that can be healthy to incorporate even into linear process models. Stand-ups and retrospectives are helpful tools to consistently align everyone’s understanding of the situation. Even breaking down work into sprints can do wonders in a linear model – you probably just need to plan much, much further ahead.