How to be Agile in a Waterfall Environment
There has been a lot of talk lately about combining Agile and Waterfall in a sort of hybrid mix. I think most people refer to it as, "Agilefall". I just started working in a new team and they work in a waterfall environment, however, they want to be more agile. My boss has recently tasked me with coming up with what elements of Agile can be applied to a Waterfall environment. At first I thought that would be easy, but the more I think about it, one methodology sort of offsets the other. Does anyone have experience implementing this sort of a strategy? I'd love to hear about how it went and what worked and what did not work.
Thanks
Maybe try a step by step strategy.
What is easy enough to test tomorrow and can make some difference ?
Focus on the Agile Manifesto instead of a particular framework.
I've heard people in this predicament have used kanban as a gentle approach/ warm up. I haven't personally tried this, but can see the potential.
Another alternative is to do a small, couple day to week long iteration with the "dive head first" approach. Be up front that you're trading actually delivering anything during this intro time, or possibly something extremely small, for the sake of relearning how to work.
It's a completely different world. Are they more open to easing into it, or diving right in? Pros and cons of both, all depends on the teams.
Your boss is asking the wrong question.
The question is not, how agile elements can be applied to waterfall without disturbing anyone.
The question is, what problems arise in your waterfall environment, which of these are the most risky to your business, and which rule of the Scrum framework can help to make these problems more transparent, i.e. appear earlier and more often, so your organization can learn faster and adapt.
What I have seen working is starting with incremental / iterative development and delivery. If you say something like: Hey, these are our absolute top priorities. I suggest we put our efforts in delivering them somewhere begin of next month. We show the results and take our mission from there.
People understand what you are proposing. If people get used to incremental / iterative development you have a starting point for a Scrum Sprint.
I have seen this working in a niagara fall type company. The context was favorable though: for legal reasons they had to deliver within 3 months. And it was a small independent team.
> My boss has recently tasked me with coming up with what elements of Agile can be applied to a Waterfall environment
One and one only, which is the minimisation of waste in its various forms. If your boss understands and values that, and is prepared to sponsor a remedy, then this may lead to a more agile and leaner way of working. He should be prepared, however, for deep and pervasive change.
The fundamental conflict between agile and waterfall is whether there is a commitment to deliver specific detailed scope items by a specific date. There is NO WAY around that. Waterfall is predictive; agile is adaptive. Waterfall is designed for projects without design work -- it makes sense if a new release to a business system requires a staged global roll-out with classroom-based training for 10,000 employees over a six-month period, including printing manuals, arranging classrooms, instructors' visas, etc.... Waterfall is only a bad fit if you're designing something new.
The trick is to recognize that you can be a little waterfall-ish before your start building (as long as your charter focuses on success criteria and outer boundaries rather than detailed scope items), and you can be a little waterfall (more likely iterative, most people don't know the difference) on the back end, around the release and support, while being totally agile in developing the product.
Imagine you were hired to sustain a released product: you start your first sprint with an increment in production, with a solution architecture, dev and QA environments, a product backlog, a team.... At that point, does it matter what kind of project built the existing increment?* Extend that thought to the first sprint -- does it matter what kind of project set up the environment, selected the platform, built up a product backlog, as long as you don't have a fixed plan?
Scrum delivers "an increment of potentially releasable product." In a large enterprise business systems organization, the work to take that product to production release might be waterfall-ish, as might the activity to close the project itself...while the life of the product continues in other projects or in production support.
*I'll answer my own question: sometimes it matters, because waterfall projects sometimes don't design for sustainability. Sigh.
I agree with Ian's reply, elimination of waste is the key. As a more lean approach I guess that starting with Kanban will be less painful in this case, as it can be initially applied on top of any waterfall to focus on continues improvement. If you do it right, you will start to gradually move towards a more agile environment and will probably end up with something very similar to Scrum. The other alternative will be to start with Scrum, but it can be more stressful if you try to blend it with waterfall, since Scrum requires much more dedication and organizational alignment to get it right.
In Waterfall, each phase is a project in itself, where one has to manage scope, quality, and time to achieve the goals of that phase. For e.g. in requirements phase, the goal is to receive sign-offs on functional (BRDs, FRS) and non-functional (NFRs, Tech specs) requirements through respective documentation. Each phase in a waterfall model is few weeks to months. This can be managed better by taking an Agile approach to each phase. For instance, the requirements phase can be broken down into manageable EPICs to User Stories like sizes and worked in 2-3 week sprints. Further, a Sprint team can be identified and assigned for each of the waterfall phases. At the end of each phase (or each sprint), the team can have Sprint review meetings and retrospection meetings to ensure subsequent phases are optimally assigned and worked on. This is how you would then use the Agile approach in a traditional waterfall model.
Regards,
Viral Sodha
Perhaps it is simply my experience, but I have yet to see or hear of an effective approach to combining Waterfall and Agile.
There is simply so much that is "glossed over" with these attempts, in the interest of keeping intact a methodology (Waterfall) that is inherently inefficient and cumbersome.
Why are we even considering "managing" scope, quality, and time? Agile shows us that these attributes cannot be managed.
How does keeping a phased approach (i.e. - requirements phase) promote agility? Are we producing working software anytime soon? Are we promoting collaboration between roles in the organization, or are we reinforcing inefficient silos?
How do unstable, specialized teams promote agility? And why would we entertain such a poor practice like epics and user stories morphing into task retainers to support each isolated and non-agile waterfall phase?
Outside of the discipline of continuous improvement, I do not see where else Agile can be applied to traditional project management methods.
Apologies. Scope certainly can be managed in an Agile environment. In fact, in Scrum, it is the ONLY project constraint (time, cost, scope, quality) that should be changed based on feedback and direction.
Agile is a mindset than a template. In that sense, the mindset can be applied to a waterfall model.
@ Viral
Agreed that Agile is not a template or methodology, but a change in mindset.
I would strongly argue however, that an honest application of Agile to a waterfall model would inevitably change that waterfall model, since so much of the waterfall practice directly contradicts Agile.
I would be curious to hear your thoughts on the following, using your experience in applying Agile to Waterfall:
1) Where in your example do you providing early, frequent, and continuous working software to the business?
2) How do you manage changing requirements that surface well after your "requirements" phase? How do you respond to change?
3) How do you facilitate continuous improvement and retrospective discussions across different teams assigned to different phases of a traditional Waterfall project? How would your "testing" team benefit from your "requirements" team discussions?
4) What "planning" and estimation do you continue to implement in your Waterfall/Agile hybrid approach?
5) Where in your example does frequent customer collaboration take place?
I think it will be suitable if I recommend you to read this article What is Agile methodology, the easiest explanation with real life solutions There's a plenty information about Agile and some real life solutions.
I think Agile methodology is not always relevant and is not suitable for every project and developer.
in some cases, other methodologies are more suitable, especially since there are so many of them.
Sometimes even DevOps or Kanban
I want to recommend an article DevOps for Startups: Agile is not Enough for App Development
i think maybe this will help you
@Scrum.orgSupport, can you please remove the above two comments that bring absolutely nothing valuable to the community but are aimed at generating authority for the linked URLs?
Every few weeks we see such comments popping up and it's a pitty they are allowed to show up.
Scrum Support Ryan Eastabrook (SDO) FYI ^
[thought I don't think you have an internal tracking system to alert when your get called out]
Hi Eugene,
Happy New Year, and thank you for all your helpful contributions on the community forums!
Unfortunately, we're currently unable to remove older posts after they've been moderated. We do make efforts to ensure our forums aren't used as a marketing platform. We will continue to do our best to validate that new comments are in line with the spirit of the thread.
Thank you for your feedback and suggestions, and have a great day!
You can combine using Extreme programming and Scrum. Read this article, it may be helpful Scrum vs Extreme Programming: What's the Difference?
Of course, you can and should approach your code base intelligently, adhering to its modularity, weak connectivity, and so on, to help with re - factoring efforts, but re-factoring efforts are something that should exist throughout the entire process. This continues. This is iterative. It's about making things better. But you also have to demand forecasting. Don't worry that the theorizing is done, look at the lag element and let it determine what is done.
My boss has recently tasked me with coming up with what elements of Agile can be applied to a Waterfall environment
**This is just my opinion and my thoughts...
Look at the waterfall model, stack the different phases one on top of the other.
Then, ask the people doing the work, "How can we look at what we need to deliver, and do a small piece of that which incorporates all the stacked waterfall phases?" - Individuals and interactions over processes and tools
When that small piece of work is done (integrated, tested etc), does it work? - Working software over comprehensive documentation
Once that small piece of work is done, can we ask our stakeholders for feedback, is it still the same direction we want to continue in? - Customer collaboration over contract negotiation
If the direction has changed, or if the scope has changed, or if something needs to be changed, then can we strive to implement that feedback and repeat these steps all over again? - Responding to change over following a plan
If we can think in this manner, what thoughts come to your mind regarding how to execute it?
P.S. I'm open to feedback.
I have a similar scenario. The business I work for considers the installation of an AV solution such as an LED screen a project. With this in mind there are realistically a few projects considered as one: -
- LED screen manufacture
- Groundworks and physical installation
- Content Solution - software based (with inclusive hardware)
The LED manufacture side of things takes care of itself in a factory in China, but the physical installation side of things and the software product side of things are almost run as two separate projects. As the installation side is using externals as well as internals and a waterfall approach, does it seem valid to let this continue in this manner and potentially place key dates along side sprint ends of the software side of the project?
In an agile methodology, a large amount of work is divided into smaller chunks called ‘sprints’. A sprint is developed and tested in a parallel fashion. This means that testing is not a separate phase but an integral part of the development process. The main aim of the testing team is to ensure early identification of bugs, issues and defects.
The main benefit of agile methodology is that the product is delivered to client in a shorter span of time.
Follow step by step strategy.
Agile also have design, build, test, deploy cycle, in iterative manner, to deliver small incremental/iterative products to end customer.
Identify MVP, work on delivering MVP in small iterations agreed with stakeholders.
Follow Shu-Ha-Ri
Start with scrum, later integrate others Agile methodologies as per the need.
Use Scrum with Kanban - ScrumBan (popular now a days). This will help in streamlining deliveries, deliverables, deployments using Kanban boards, Swimlanes. Can help in limiting WIP.
CFD also be a great help for improvisation.
In an agile methodology, a large amount of work is divided into smaller chunks called ‘sprints’. A sprint is developed and tested in a parallel fashion. This means that testing is not a separate phase but an integral part of the development process. The main aim of the testing team is to ensure early identification of bugs, issues and defects.
If we can think in this manner, what thoughts come to your mind regarding how to execute it?
In an agile methodology, a large amount of work is divided into smaller chunks called ‘sprints’. A sprint is developed and tested in a parallel fashion. This means that testing is not a separate phase but an integral part of the development process. The main aim of the testing team is to ensure early identification of bugs, issues and defects.
In an agile methodology, a large amount of work is divided into smaller chunks called ‘sprints’.
I disagree with that statement. For example, Kanban does not use sprints. And there is nothing to say that sprints have to be used. Sprints are part of Scrum but Scrum is not a methodology, it is a framework.
I will agree that testing has to be included in the work to produce something that is "done". If you do not vet that the work produces the behavior/result expected by the stakeholders, you are setting yourself up to fail and a lot of rework.