In the good old days (1990s and before), they used to have something called waterfall model for software development. There were several variations but in general, there used to be four major steps:
- Design (Devs and Testers understand what the requirement is from the user)
- Coding (Devs code their stuff and make it testable)
- Testing (Testers test what devs have delivered, catch bugs, go back to step-2 if any found)
- Deployment and Maintenance (DevOps team takes the deliverable and installs it on user's production server). If any bugs or issues are caught, back to step-1/2.
Appears quite simple and straightforward, isn't it? But Alas! Those wizened managers sitting in Silicon Valley IT firms decided that this simple development model ain't making no money for them! They need something more magical and mysterious, something they could shove down their clients' throats which neither them nor the clients can understand (for only when they're confused and feel overwhelmed do they shell out lots of monies).
Thus, some astonishing buzzwords were born in the industry such as Agile, Scrum and Kanban. The marketing dudes were taught all the ticks of the trade, "Oh, we use the proven Kanban technique for software development, sir. And our great methods like TDD and BDD (will turn into some other XDD in a few years!) will ensure that your product will be delivered within deadline, sir".
All those buzzwords are in fact needed to justify the millions that the firms rake from their gullible clients. If the firm simply says, "Got your requirements sir, we'll deliver this within 30 days more or less, here are the estimates and task breakdown", it doesn't convey the seriousness of their software business and their ambitions.
The people throwing around buzzwords like TDD and BDD should take a pause and consider it for a moment, do coders doing software development before them didn't test their work? Are things like unit testing and debugging rocket sciences which never happened before?
If things like Kanban and Agile actually worked, then software of similar quality would be tested and delivered much faster today than before, don't you think? But does it really happen?
Our predecessors worked with woebegone code editors like turboc, vim, emacs and even notepad. Then came the era of Foxpro, Visual Basic and Visual C++, and they still churned out some great software using them.
One would think that today's modern software infrastructure like improved packaging systems (npm/pip/composer), wonderful IDEs (Intellij, PHPStorm, VSCode, Atom), etc. might hasten the development speed, but that doesn't happen at all.
The recent debacle of Accenture vs Hertz proves that all is not well with this Agile/Kanban/TDD model of development. Accenture is a top IT firm which is typical of having all the modern processes I just mentioned but even then they failed to deliver a straightforward web development project to Hertz.
I'm not saying that the waterfall model is perfect but what's happening right now isn't any good either. There might be some good things hidden in Agile and TDD too but facts should be separated from mystery and magic, Agile/Kanban/TDD should be brought down to a level where they could be applied to software development effortlessly rather than being abstract buzzwords or mantras which have no use on their own.
On a closing note, I'd like to share with you this excellent meme I recently came across on Toggl which portrays the spirit and gist of this article:
Top comments (28)
Looking for the humour in this.
Waterfall is famous for projects failing to deliver anything at all. Been on a few projects that, after months of analysis work, failed to even reach the coding stage.
Waterfall can work well when requirements are static and the process to fulfill them is consistent with previous projects.
Agile is about embracing change, delivering (or failing) something fast, and learning from feedback. Can't complain about about that.
Agile doesn't promise to complete faster than waterfall but incremental delivery does at least result in you devivering something.
In waterfall, you fix the requirements and keep going until completion. Choose Scrum as an alternative and you can choose fix time instead and give incremental deliveries of features in priority order until the time runs out.
Requirements can be made clear and precise if you do a thorough investigation of user's workflow before jumping on to coding the solution. In the waterfall model, the user "signs off" saying "these are my required features and functionality", so there remains little doubt about what is to be developed.
In the agile way, many times the coder may jump on to programming directly with unclear or only half understanding of what to develop. This isn't the problem of "changing requirements" but that of half-baked understanding of the project. Why do you think the Accenture's project failed recently?
Its not as if the nature of work or the user's workflow changes each day during the course of the project, what changes is the dev's understanding which improves as one gets closer to the final product. Even with the waterfall model, there are variants called "prototype" or "iterative development" models where the whole process (design, coding, testing, deployment) is repeated in multiple cycles and each developed prototype is an evolved successor of its predecessor. This used to happen since decades before agile and scrum became buzzwords.
The mystery and magic surrounding these buzzwords isn't good, they are creating an elitist attitude in certain managers who are starting to think that others are inferior to them.
The point is that development isn't agile Vs waterfall. It is about choosing the correct tool for the job.
Waterfall works well when requirements are clearly known and reasonably fixed.
Agile is about adapting your processes, learning from feedback, and accepting that requirements may change as development progresses.
Mass production of a single car model as an example can work with a waterfall style approach (but keep in mind that Kanban and some other agile concepts came from Toyota). A formula one car on the other hand would never work in waterfall.
I don't think you'd pick Agile to write a complex accountancy package. If it were done in Agile, it would be like:
User: "OK, we'll need to post to the office ledger, so code for that."
Developer:
User, later: "Right, so now we need to take care of the nominal ledders"
Developer: "So there's more than one type of ledger?"
Funnily enough that's actually what I do and have been doing successful via some form of Agile for 15 years now, seems to work fine.
I'd be interested in discussing that further, particularly how large-scale, multi-release features are planned in, using the example of multiple types of ledgers, perhaps. Thank you.
Happy to discuss further @greigtaylor on twitter.
beza1e1.tuxen.de/waterfall.html
Good read. Thank you.
Please read that link BK Lau posted. I believe the original article here made quite a few presumptions and was poorly researched unfortunately.
All I have to say is that you clearly need to learn about Agile. First to be able to properly articulate your words as you are mixing up things by calling "Agile, Scrum and Kanban" the same thing. Second, the way you described how agile is supposed to work (e.g.: when you say things like "jump directly into coding) also clearly demonstrates your lack of understanding of what the Agile Mindset is about and how it's supposed to be translated into practice. Article like yours provides a very poor service to the community.
Exactly my thoughts
I think you are over simplify things a bit. If you have worked with software and hardware development, you will see they are two different beasts. Hardware requires almost perfection because you can't easily roll out updates and bug fixes on hardware minus firmware upstates which is why waterfall normally works well for hardware. As for software, things can be done iteratively and should be done as such hence Agile and Kanban. You shouldn't compare software development vs hardware development.
Agile, Scrum, and Kanban are not buzz words. The problem is when they are used as buzz words. As with any new technology or approach, people need to actually learn them and not just cherry pick practice and cargo cult implementation.
The other issue with your infographic is starting with something relatively well know, a car. Make the ask something new and never done before and the infographic’s point does not hold water. Waterfall has its place, but when there is high unknown and variability in delivering what the customer wants, waterfall is not a good choice.
They are not buzzwords and they were NOT thought up by managers. I think every developer learns quickly that an iterative approach is the most effective. Agile just brings the rest of the organization on board with that approach.
I'm apparently one of your predecessors, having spent the better part of two decades developing C using vi. I've worked using ad hoc process, Waterfall, bad "Agile" frameworks, and true iterative development. You've obviously never been exposed to either large Waterfall projects or competent iterative development. There's a reason Google and Amazon don't spend month in requirements gathering followed by months generating technical design documents to hand off to coders who then hand off to testers. By the time it delivers, and statistically not on time or at all, it's no longer relevant.
Yep, you are right to some extent. At some organizations where I've worked, agile was mostly a matter of parading and show off by the managers. They used to call us devs for a stand up scrum call but hardly anything happened in those except people standing up! Agile had also become a political tool in some projects for some team members to wage proxy wars with others.
On the other hand, the orgs I worked where waterfall was practiced, they did it diligently and honestly and never failed to disappoint the client. Maybe, that's a bias from where I'm looking at things.
It is. Place blame where it belongs, the people. Delivering with agility means you are delivering value constantly. If that's not happening, it doesn't matter how many stand-ups you have.
However, if you think that TDD, BDD, DDD, & CDD have no value, I would challenge you to study your craft. Even in a waterfall project, those should be happening.
I've worked in both environments and have seen projects succeed and fail in both methodologies. As techies we tend to be think in deterministic way and often forget about the human factor. Code development is a dance between us and our clients. We may know and execute the waterfall or agile perfectly, but for many clients, this is their first time.
If we fail to teach or they fail to learn how a process (any process) works, the project will stumble, be delayed, or even bomb.
For a savvy client that has an established, known, agreed upon, and working process, waterfall is perfect. You gather the requirements. They sign off. You code, test, and deliver. Boom! Happy client.
But then take a not so savvy client with an evolving process, no clear product owner, discord within the ranks, endless change orders; Agile is your only hope of delivering.....something.
If you can't communicate to your client, if you can't establish a human connection, no method in the world is going help you. Methodologies don't deliver solutions, people do.
imho
Delivering against predefined requirements and walking on water are equally easy. Assuming they are both frozen. But we know that is rarely the case. You argue people push Agile to charge big bucks in consulting fees, but I would say you push waterfall so you are not accountable for delivering a working solution and can bill your customers forever.
I liked your ability to call a spade a spade. Development and business in general is lost in buzzwords which ensure all sight is lost of the most important thing - understand the real rationale behind a development request.
Well, I think using any tool we have to remember that it's not always perfect. Knowing the tool's limitations is what differs a begginer from a senior, I guess.
I totally agree with @Alistair: 'The point is that development isn't agile Vs waterfall. It is about choosing the correct tool for the job.'. One of the articles that opened my eyes when trying to apply Agile and Kanban to everything was kanbantool.com/kanban-library/kanb... , the one showing me that: yes, great software may be used wrong.
Still, it is great that you discuss this topic, @Prahlad, I think we need to analyze more the tools and attitudes we use when doing projects.
Scrum, kanban, lean and many more make up the agile methodologies.
I have gone through waterfall methodology for more than 10 years and scrum for 2 years and I can personally say that scrum, or any agile methodology done right, can be empowering. The iterative nature of scrum helps us discover what the user really needs. In most cases, what the user say they need doesn't map to what they actually need. In waterfall, you can't proceed to coding without completing the design and the bigger the requirements, the longer it takes to complete the design phase.
Agile methodology allows the process to be changed to adapt to changing world. In typical waterfall, you can't.
Now, I mentioned I referred to agile done right. When I say done right, I refer to methodologies that follow by heart the agile manifesto. Some company claim to be agile but people are not empowered to change the process to improve the development. Agile thinks that the developer can organize themselves to best deliver the product.