VIDEO TRANSCRIPTION
Scrum Master In Black
‼️Scrum Is Not An Iterative Mini-waterfall Project Management Method
Description generated by Skrybot
No description has been generated for this video.
Transcription generated by Skrybot
So let me get this straight, Scrum is not an iterative mini waterfall project management method in disguise. So I just came back from travel and during my trip I had conversations with several Scrum practitioners. The common theme that I'm getting from those conversations is, some people still think that Scrum is just a big long up from water polp plants chopped into multiple sprints. And the scope for every sprint is fixed because the scope for every sprint is derived from the overall water polp plant which is already fixed. And this is what I meant by iterative mini waterfall in many of my other videos on this channel.
Some people at our workplace may still perceive Scrum as an iterative mini waterfall. Perceiving Scrum as an iterative mini waterfall creates harm, not only for the Scrum team who will be involved in delivering the product, but also for the high level management and the customer who hires the team. And I will explain to you later why Scrum is not an iterative mini waterfall, and why perceiving Scrum as an iterative mini waterfall creates more harm than good, right after this one. Hey, what's good this week awesome people? I hope you're having an awesome week. Joshua Pertwege here, back again in my home studio in Brisbane, delivering another content for you.
So folks, as I mentioned earlier, Scrum is not an iterative mini waterfall project management method. Even though it's easy to perceive it that way, using Scrum under this perception is harmful for the company who are implementing it, and it is one of the reasons why companies are not getting maximum value out of their Scrum implementation. So first, we have to understand that Scrum is meant for a context where there are more unknowns than knowns. When we read the Scrum Guide, the definition of Scrum is a framework for developing complex products. So, in a complex context, there is more information that we don't know today than that we know.
When we are innovating or creating an innovative product, there is more information or knowledge that we don't know today. After all, in many cases, an innovative product is a product that has not been created before. To get the most value out of our Scrum implementation, instead of using Scrum with project management perspective, we should be using Scrum with product perspective. Now, I've already made a video that explains the differences between project perspective and product perspective. Go find that video on this channel, or you can just click the link up here if you haven't already watched the video.
So now that we know that Scrum is intended for a context where there are more unknowns than knowns, instead of creating a big, long, detailed up-front plan, when we're using Scrum, we deliver a small, releasable product increment every sprint based on the information and the knowledge that we have today. Now, by delivering a releasable product increment every sprint, we will uncover more of those unknowns. This is what empiricism is about. In a context where there are more unknowns than knowns, creating a fixed detailed scope up front and then locking those scope up front is a form of waste. Because in a context where there are more unknowns than knowns, the scope and the detail implementation will likely change.
In Scrum, rather than starting with a fixed scope of requirements, we start with defining the goal of the product first. The product goal is not the fixed scope of work that the Scrum team needs to do. Instead, it is the business outcome that the company would like to see from the resulting product. I've already created a video that elaborates how the product goal is the business outcome rather than a list of output. Go check out that video on this channel, or you can just click the link up here if you haven't already watched that video. Because we start Scrum with defining the business outcome, the scope of work towards achieving that product goal should be negotiable.
After the Scrum team has collaboratively defined the product goal, they will collaboratively create the initial product backlog. Now, unlike in Waterfall or in Project Management, not every item in this product backlog is detailed to a granular level. There is a possibility that some items in the product backlog are not delivered. And let me say it once again, this is because Scrum is meant for a context where there are more unknowns than knowns. The success criteria of Scrum is also different to Project Management. It is not to deliver fixed scope on time and on budget. It is to deliver business outcomes. And yes, it is possible to deliver business outcomes with less scope than originally planned.
The product backlog that the Scrum team initially created is based on their current understanding about the product, their customer, and also about the current market situation. In Waterfall project, people commit to big upfront plans when they have the least understanding about the customer, the product, and also the market situation. We don't do it like that in Scrum because, once again, Scrum is based on empiricism. In Scrum, quite often the team only refine the product backlog items that they will most likely do in the next two or three sprints. The Scrum team does not just leave every other items unrefined though.
Great teams will continuously refine the product backlog items from sprint to sprint as they gain better understanding about the customer, the product, and also the market situation. Go check out my video on product backlog refinement if you haven't watched it already. For the Scrum team to improve their understanding, they need to release the product and also ask their customer to use the product as early as possible. Because without any release and without any customer using their product, the Scrum team will have so many unvalidated assumptions. And these unvalidated assumptions can be very expensive for the company because delivering the product that the customer don't want to use is very expensive.
In Scrum, the items in the product backlog are dynamic and fluid. Some items that were initially placed in the product backlog can be discarded because the Scrum team, along with the product owner, may have found out that those items are no longer needed. Maybe because the customer have changed their mind, or maybe because the market landscape has changed, or maybe the regulation around the product have already changed, or maybe because the competition in the market have become stiffer. The sprint in Scrum is not a shorter waterfall. And here's what I mean by that.
During sprint planning, the Scrum team starts with creating the goal of the sprint and just like the product goal, the sprint goal is also not the amount of product backlog items the Scrum team need to complete this sprint. I've also already made a video about the sprint goal and how the sprint goal should be outcome oriented. Otherwise, the team will end up becoming a feature factory. You can find out that video on this channel, or you can just click the link up here to watch that video. After the Scrum team has created the sprint goal, they will collaboratively make a forecast on how many items they likely can complete this sprint.
And the Scrum team will use several information when creating the sprint forecast, such as their performance from the previous sprints, the amount of check boxes in their definition of done, the amount of team members who are currently available in this sprint, the retrospective commitments from the previous sprints, etc. I've already made a detailed video about the flow of sprint planning. Go check out that video on this channel if you haven't already watched it. Now, this sprint forecast is not the sprint commitment, because in Scrum, the team commits to the goal rather than the scope of work.
A lot of people think that the amount of items that the team forecasted during sprint planning becomes the sprint commitment or the fixed scope for the sprint. In some companies, I've also seen that the Scrum team is blamed when they don't deliver according to their sprint plan. And I personally think this misperception is caused by a very popular tool that is widely used by many teams. And this misperception is how a lot of teams end up in running their sprint as a mini waterfall. The forecasted product backlog item for the sprint can also change throughout the sprint. The Scrum team can negotiate the forecasted product backlog items with the product owner throughout the sprint.
The detailed implementation can also change during the sprint. And in fact, new items that weren't originally discussed during sprint planning can also emerge in the middle of the sprint, as long as it helps the Scrum team to achieve the outcome-driven sprint goal. The amount of product backlog items the Scrum team delivered at the end of the sprint may also not match with the amount of items they forecasted during the sprint planning. In Scrum, as long as the Scrum team can achieve the sprint goal or the business outcomes that they have collaboratively defined during sprint planning, the Scrum team is considered as having a successful sprint.
As the purpose of sprint review and the sprint retrospectives is to get feedback so that we can deliver the best product possible for the customer as defined in the product goal, this feedback can also change the content and the order of the items in the product backlog. Now, again, as long as the Scrum team can achieve the product goal, they have succeeded in their product delivery. Because Scrum is not a fixed scope, fixed timeline-driven project management method, Scrum is a goal-driven product development framework. And all of this that I have explained to you are the reason why Scrum is not an iterative mini waterfall project management method.
Even though there are so many institutions and individuals out there who like to sell Scrum as an iterative mini waterfall project management method, because it's more sellable if it's marketed that way to the upper management, but selling Scrum as an iterative mini waterfall project management method actually creates more harm than good. The upper management will only ask others in the company to change, and they will think that there's nothing that needs to change from their side. Iterative mini waterfall will put the management under the illusion that the company can have agile transformation just by changing the labels.
But the party that will get more harm from this misperception about Scrum are the people who will be involved in or with the Scrum team. People will be disengaged because in some cases, iterative mini waterfall leads to people having burnout. And burnout may lead to low quality products and many technical debts in the product. Some people will be disengaged because they perceive Scrum as a micro management tool. Some people may also feel unfairness because they need to change while the upper management does not need to change. Engagement from people is very important when using Scrum because Scrum emphasizes empowered self-managing teams. So that is all for me today folks.
I hope after watching today's video you gain a better understanding about Scrum and I really hope you can avoid implementing iterative mini waterfall at your workplace. If you want to implement Scrum and get the most value out of Scrum implementation, I've already made a video that explains a simple step by step of studying Scrum in the company. You can click the link up here if you haven't already watched that video. Subscribe to this channel if you haven't already folks and click that like button down below if you think this video helps you correct that misperception about Scrum.
And don't forget to share this video to your colleagues if you are currently working in a company who implements iterative mini waterfall and call it as Scrum. I will see you in my next video folks. Enjoy the rest of your day. Bye now!.
S K R Y B O T
Skrybot. 2023, Video transcriptions from YouTube
By visiting or using our website, you agree that our website or the websites of our partners may use cookies to store information for the purpose of delivering better, faster, and more secure services, as well as for marketing purposes.