Why Agile Development Misses the Boat
If you’re in the software industry, you’ve probably heard a lot of buzzwords about making software fast, good and error free. for a long time, people have been solving problems using some pretty standard techniques. One of these has manifested itself in Software as “Waterfall” development. Waterfall is basically the same idea that everything else in the world is developed by – first, you figure out what the problem is, then you figure out how to solve it, then you write the program that solves it, then you test it, then you deploy it. Seems like a pretty sensible approach – for every dollar you spend in each step, you can expect to spend 10x that on the next step. so if you spend ten dollars to make a design decision, making that same decision after deployment could cost many thousands of dollars. It’s really just like in construction – moving a line on a blue print is a lot cheaper than moving a wall in a building.
But software isn’t really like everything else. Partially completed software can actually be used. A bridge with a few feet missing is entirely useless. But a program with a few features missing tends to be pretty useful. Because of this, people figured out that they could do other development methodologies with software. And so was born the agile development methnodologies. Lean, Scrum, XP – all sorts of different names were given to them. They compressed the time from analysis to production down from what could sometimes be years to months. Were they a good thing? Sure, to an extent. They’ve been criticized for various things by the Waterfallers – missing requirements, not able to address all concerns, etc. But that’s not my approach.
Agile Software methodologies fail not because they are too lean, but because they are not lean enough. That is to say, they absolutely not lean at all. They’re just a name given to short waterfall cycle. “Lean” manufacturing was invented by Toyota. The idea of lean is to eliminate waste. Waste from everywhere, but notably in inventory. But software doesn’t have inventory, you say. Of course it does – inventory is any piece of functionality that is not delivered to the customer.
Reread that – that’s the crux of S3′s Production System. Inventory is any requirement functionality that is not delivered to the customer. If you have a requirement that is sitting in a queue anywhere, that’s inventory. Have software designed but not coded? Inventory. Have software coded but not tested? Inventory. Software tested but not deployed? Inventory.
Agile (like waterfall) groups features together. Sometimes related, sometimes not. But it groups features into releases. Why? because that’s how it’s always been done. Nobody deploys a single feature. It’s always grouped. Which means there’s always inventory. If a software methodology is going to claim to be lean, truly lean, it has to get rid of the inventory. Why do you have three developers working on three different features, then that whole package goes to a QA department (possibly overseas)? S3 does true one piece flow. One piece of functionality – from inception to production with no wait points. No inventory. Design, Development, QA, production in the same room – a piece of functionality never has a chance to be wrong. Quality suffers? No way – just like Toyota, by having everything there together, quality skyrockets. Reworks disappear. Bugs are caught before they are even written.
There is a lot more to come on how S3 truly adapted lean manufacturing to software – this is just something to get you started thinking. Challenge me, please. We’re always looking for better ways. But if it’s something that exists today, we’ve already determined that it’s too slow.
I’ve practiced practical Agile/Scrum for the last two years to deliver packaged software product.
In my experience Agile/Scrum deliverables do not have states of software designed but not coded, software coded but not tested, and/or software tested but not deployed. It’s either in backlog, in progress, or built. Software is a built/verified feature, and anything not completed within span of the current Sprint is not a delivered feature. Sprints are adjustable too, depending on the speed you need.
Features are not groupings of functionality, but as atomic as possible, and must provide enough functionality to deliver some benefit to the customer. If you are not prioritizing functionality to benefit the customer you are destine to fail, and not following proper Agile methods.
Nothing is considered a completed feature unless it is designed, built, tested, and documented. I would also assert that it’s not really Agile if the engineer, tester, and tech-writer are not all on the same team, or maybe even one team member who could be wearing one or more hats. You just can’t have a successful remote rugby player and that is the same on an Agile/Scrum team (IMO).
I’ll assume features being built and in backlog is what you are referring to as inventory? The best thing about backlog is that it is easily adjustable to re-prioritize, based on ever changing customer needs. Even features being worked on in the current Sprint can come to a halt, be thrown in backlog and substituted by a feature deemed more important. That’s why it’s called Agile after all.
Regardless nothing is ever completely bug free, even with Agile. But the bugs reside more in improper feature outcome rather than system crashing nonsense.
We used a lot of build and testing automation, such that every 4 hours a complete build/test was run and the outcome was an installable software package that could be sent to any customer for implementation.
It sounds to me like you are on the right track with S3 deliverables and closer to the Agile/Scrum methodologies we practiced than you think.
I say, keep doing what you’re doing! The direction you’ve taken sounds like a good formula for a successful outcome. – Cheers