Embedded Files
Comparing Theoretical Waterfall and Scrum Agile
Comparing Theoretical Waterfall and Scrum Agile
As noted in the previous section: Agile Overview, product management usually has the following stages.
Requirements: Get them from customers and stakeholders
Design: Perform technical designs and planning
Build: Execution / product development
Test
Deploy
For software development, the most common agile methodology used is Scrum Agile. You can read up more on Scrum at Wikipedia here and at Scrum.org. In general, it's a framework that's designed for 10 or less people and goals are broken down so that they can be completed within a set timeframe, usually two weeks.
The following section contains two figures that you can use to compare theoretical waterfall and scrum-agile methodologies.
Here are some key takeaways:
In the traditional Waterfall timeline, the stages are completed sequentially one after another (do you get the waterfall comparison?).
In waterfall, you build one working product at the end. The drawback is you can't test if this product is what your stakeholders and customer want.
In Scrum, you develop a working product after every single sprint. This means, the first versions of your product are pretty poor, but the purpose is to get feedback from your stakeholders immediately.
Both figures show processes that are too simplified: they are great as teaching tools, but I've seen firms who follow these simplified processes to their detriment.
Traditional phase-gate waterfall has evolved into a new phase-gate process that now includes feedback loops to account for changing requirements.
Theoretical Scrum-Agile (as shown in the figure) does not account for product roadmaps and is impossible at scale. You'd think this is obvious, but I've seen product managers stop their long-term planning because they are "Agile".
So, what's the reality? See the next section.
Scrum-Agile Development: The Reality
Scrum-Agile Development: The Reality
The reality of choosing Scrum-Agile or Waterfall is a bit more complex; you end up doing a sort of hybrid approach. In this case, you really need to consider the headspaces of your stakeholders and customers (see my writeup "Your Headspace"). Then you need to create a series of feedback loop processes to keep everyone informed and to account for changes. The following figure shows what it's like to run Scrum-Agile with multiple developer teams (Scrum at scale).
Here are the key takeaways:
The figure show a process that assumes that the product leader has a product vision, has completed customer co-creation, has validation that the product is needed, and has released prototypes to test. YOU'VE BEEN WARNED!
A product leader needs to prioritize product features by 3, 12, and 24+ month priorities (see my writeup "Your Headspace" to find out why.)
A product leader needs to create a feedback loop every month that includes the sponsoring executives (or board of directors) in regard to the 3-month and 12-month requirements.
The product leader needs to create a feedback loop every sprint that communicates with the product managers, designers, and development team what the current 3-month requirements are AND if they are valid (see my writeup "Sprint Cadence").
IF there are multiple development teams for one product line, THEN the 3-month requirements are crucial for dependency planning; one feedback loop is needed to align the product managers and designers for 3-month requirements and designs.
The junior and intermediate product managers are expected to communicate with their development teams the product's 3 month and 12 month requirements every sprint.
A sprint is itself a feedback loop upon sprint close; the goal of every sprint is to deploy a working product: "working" doesn't mean it's valuable - you have to test the value of the new features with the customer.
The product leader needs to create a feedback loop with the customers to test the product; I suggest every sprint if it makes sense.
The requirements and designs should be completed 2-3 sprints ahead; notice in the figure below that the development team is 2-3 sprints behind on Sprint 10 while the requirements and design are being completed for Sprint 13.
The requirements and designs should never be completed ahead by more than 3 sprints from the development team; you want to prevent your designers and PMs from working too far ahead of the development team. You want to minimize the risk of working on features that could get deprioritized or eliminated.
The requirements and designs should avoid being just-in-time or only 1 sprint ahead; this places too much stress on the designers and product managers (this is unavoidable in Sprint 1).
It is possible to build, test, and deploy working products every sprint. If you can't, then your team needs some discipline.
All these feedback loops require a lot of discipline by the entire team.
The Biggest Takeaway
The Biggest Takeaway
Create a series of timeboxed processes that lets you get feedback from your customers and stakeholders so that you know if you're on the right path. Base this on what headspace they have.
Page updated
Report abuse