In this video, the instructor compares an agile mindset to project phases.
- 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 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 the 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 the 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.
- Recognize inhibitors that have a significant impact when managing an agile team.
- Define the “agile manifesto.”
- Recall the structure of a cross-functional team.
- Determine what should be included in user stories.
- Apply the 80/20 rule to determine the priority of highest value items.
- List two agile principles that guide the team to stay within time structures while remaining flexible enough to adapt to change.
- Name a disadvantage of the waterfall approach.