In the good old days (1990s and before), they used to have something called waterfall model for software development. There were several variations...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Two other points:
The reason XP and DevOps (it's not a job title) exist is due to the pain of experienced Devs and Ops who lived through the 90's and early 2000's and know they weren't "good old days". They were nightmares of instability, unhappy customers, missed deliverables, and sleeping under desks. We'd much rather have lives.
Professional developers don't depend on external test teams for testing.
Yet another article, by yet another person who has never actually implemented an agile framework correctly with their team or been part of a team using an agile framework correctly.
"Easy to understand. Difficult to master".
I even doubt that he has even tried to do some research on agile/scrum.
see also