Latest questions:
Trending questions:
Hot questions:
Agile or Waterfall ?
Is waterfall not suitable for modern product development practices? I am especially talking about IT, Software and Digital. When do you prefer waterfall over agile ?
9 answers
Waterfall is not necessarily a slow, fat document-heavy process, and, if mismanaged, Agile can be a slow expensive process too. Waterfall simply means a linear pass through the development process (and in actual practice it almost always has iterations); Agile means letting the requirements evolve as the project goes along and getting partial products into place early so as to begin delivering some value as early as possible. So, ironically, if you are running very small, quick projects to produce a low-cost item, you won't have the time or the money for Agile: you'll just have to get it done and get it pretty close to right the first time. Another question would be whether it is possible to sell/deliver the product in increments. If not, or if about 85% right is the minimum acceptable, then you're into one-pass territory again. Having said that, note that at the task level, producers should be checking their work and should not be releasing material that doesn't meet the standard, so you will see iterations within a task if needed.
If you look closely at Agile/Scrum then you see mini or micro waterfalls.
The notion of trying to determine ALL requirements in once step and then building it entirely over a course of months/years has proven to be flawed because business requirements aren't ever complete, there are unforeseen changes that impact requirements, some element of trial-and-error needs to be judiciously used during the course of the project, etc.
As such think of Agile/Scrum as a technique to break a project into many smaller phases and constructing each of them as a micro-waterfall. This allows for regularly scheduled priority reviews to allow reality to creep into the product development process.
Waterfall, especially for bigger projects, has a lot of flaws. It assumes that you can guess all of the twists & turns that will occur during the course of the project which is never the case. As more information becomes available the team needs the flexibility to make those course changes quickly instead of going through a laborious Change Request process.
The main challenge in Agile is that leadership is stuck in a Waterfall mindset. They want to know exactly how the project will play out and the correct answer is "I don't know", but that is never acceptable so I have to make some wild assumptions based on almost no information and leadership takes that as a commitment. It puts the Project Manager in a terrible position.
An agile like approach is always preferred -- but many go overboard with agile ... agile without some form of longer term direction is chaos :-)
Waterfall really is a structured, documented and heavy process. Agile is not only a way of working (it is not a “techniqiue” or “methodology”), that shifts an organization and its cultural to a more inclusive, team-inclusive approach.
Waterfall is more suited to a project with very specific expectations for final outcome and when there is a hard and fast deadline.
Agile is more appropriate when there is room for a collaborative contribution to the outcome, and flexibility for the end product is a given.
i suggest starting with the Agile Manifesto and the affiliated 12 Principles to gain additional perspective on the differences, to then better envision other instances where Waterfall might be more appropriate.
Best of luck in your research!
There are more things to consider here. For example, waterfall does not really require planning things out for the 1-2 years. Waterfall does not say have all the requirements up front, though many have interpreted it as thus. The word progressive elaboration applies here, plan what you know, learn from that in the development work, adapt and adjust, then plan the next section of work. Beware the false choice and of those that deride one solution though seldom have done it or done it correctly. Any approach, poorly executed will lead to poor results.
- What is your organization's management philosophy - command and control or push decisions down to the talent executing?
- Are there legal and regulatory structures for your industry?
- What is the level of risk associated with the product? What risk does this pose for the company?
- What about trace-ability of the work and potential product litigation?
- What is the level of competence of your staff? Considerable new people? Mostly long term and well trained?
- What level of product management skill (technical) is within your organization?
- What level of customer knowledge is available within your company?
- What are the communications channels like (distributed team or co-located)?
These questions are better to ask when considering which approach in my humble opinion. Nobody says waterfall requires all of the requirements, nor must plan out the entire project as if you know everything. It is better to consider the attributes of your organization and of your project rather than berate one poorly executed over another approach which, if poorly executed will deliver the same unsatisfactory results.
I think the optimum approach is a hybrid - depending on compexity
- Force the domain expert to create a Complete Vision. This is an typical attribute of Waterfall.
- Force the domain team supporting the export to create a Complete Functional UX. This is an typical attribute of Waterfall.
- Force the Product Marketing team to write the Press rRelease that describes the new product: what is it, what does it do, why is it better, and what are its benefits.This is an typical attribute of Waterfall.
- Acknowledge that it is completely acceptable to break up the effort into small task chunks with MVP (very small part of the Complete Vision/Function/PR) as the initial deliver goal. (Agile)
- It is also completely acceptable to change the Complete Vision/Function/PR as the feedback loop becomes operational - but they must be changed not abandoned. (Agile and Waterfall)
- The entire development team understands the Complete Vision/Function/PR and leverages it to create a flexible domain driven model framework can be drastically changed while en-route. (DDD)
Agile Wins
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
It advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement, and it encourages rapid and flexible response to change.
63 months ago
I think now most of the projects are turning into agile only. Also, with new approches like Microservices, DevOps and CI-CD ( Again I am only talking about software development industry) there is no role left for SDLC. SDLC can still be used at program level.
Do you agree ?