From the course: Agile Foundations

Jump off the waterfall

From the course: Agile Foundations

Start my 1-month free trial

Jump off the waterfall

“

- If you work for a large organization, then you might hear the term waterfall or stage-gate release. The waterfall model is a step-by-step approach that was used in engineering. Each step falls into the next like a waterfall. In the 1970s, a computer scientist named Winston Royce took this waterfall model and reworked it to make it work with software. The first stage was gather requirements, then analyze the requirements, design the system, code the software, test the software, and deploy. For 30 years, this was the most popular way to develop software. In fact, many organizations are still using this approach. Business analysts will work on analyzing the requirements. The software architects will design the system. Software developers will then code the software, and a separate quality assurance team will run all the tests. Often, there's a separate infrastructure team that's responsible for deployment. Chances are your organization still has several of these people working on your team. Many Agile coaches feel that waterfall and an Agile mindset are complete opposites, but the truth is a little trickier. Remember that Agile is a mindset. It's a way to think about your work. While waterfall is a concrete process. It's strict guidelines for how you should do your work. Many large organizations prefer strict guidelines over a new way of thinking, so you almost certainly bump into times when waterfall practices are inconsistent with your Agile mindset. You see this a lot when organizations want Agile teams to create detailed requirements, but your Agile team will still spend plenty of time planning, designing, analyzing, and testing. It's just that instead of working on these things in sequential phases, you'll have the whole team working on these things all at the same time within a sprint. If you think about it, it would be nearly impossible to deliver every few weeks if you were using a waterfall-style approach. If the business analysts got stuck waiting to hear from the customer, then the rest of the team would just sit idly as they wait to start development for the handoff. Remember that the "Agile Manifesto" says in principles four, five, and 11, that Agile teams should be motivated and self-organized. They should also work closely with business people when delivering the product. That's why many Agile teams strive to be cross-functional. So, instead of having business analysts, testers and developers, you'll have generalized team members that try to do a little bit of everything. When you work as a cross-functional team, you're not as vulnerable to these backups. The product owner on the team will give you all the user stories you need to keep working. So, just think of an Agile team as accomplishing many of the same things as you do in waterfall, but they're just doing it in a cross-functional way, and compressing all the phases into a few weeks.

Contents