RIP Scrum, Agile and Test-driven Development
This post has been on my mind for a long while, and even as I start writing it I know that this post won’t even allow me to dump a tenth of what I’ve had on my mind for a while now.
I’ve been doing or managing software projects for year now. Saw the rise of AGILE programming, saw people getting crazy about Test-Driven-Development… and yet I’ve rarely seen so much crappy software and such long development cycles in companies. Why ? Because Agile has become a method for hiding your responsibilities as a developer over a roadmap, a new way of crumpling the whole development process where developers are empowered with everything while not given any responsibilities over the deliveries, a new way to fail project without consequencies.
AGILE is actually the less agile method I’ve ever experienced, where sprints are blind development tunnels where outside of the developers nobody can really evaluate how the project is progressing. With sprints lasting up to 2 months (I’ve seen it), and with no real ability o get anything delivered in-between, this is definitely the worst approach of all should you be a small-to-medium size company willing to deliver fast and iterate fast.
What are the real objectives for software ? In my opinion those points are a must and should always be granted
- The master branch has the current production code, and can be updated fast (after testing) should a bug be found. This is critical in my opinion : when a bug is found by a user in production : you must be able to correct it immediately ! And most of the time current methodologies just disable that from ever happening…
- No software goes to production before having been tested. An NO-UNITESTS ! Unitests are only good for testing complicated algorithms. You should focus on designing usage-based tests with scenarios following the most common user action suites. On the web, selenium is the way to go. And this is only going to enable you to limit regressions by highlighting potential side-effects of a latest code update that as a developer you may have missed.
- Deploy often. Why wait the end of a sprint to see a service update ? Some stories are fast to deliver and have limited impact on the codebase and can de done in a few hours… some require weeks of headaches… why choose your deployment speed to match the longest task development time ? Put each feature in a dedicated branch, merge them into testing when completed (for testing) and then into master for a final test run.






