‼️Scrum Is Not An Iterative Mini-waterfall Project Management Method

Scrum is gaining a lot of traction in the industry. There are quite a growing misperception that Scrum is just an iterative mini-waterfall project management method. Perceiving Scrum as an iterative mini-waterfall can damage people in the company. In this video I also elaborate why Scrum is not just an iterative shorter waterfall as perceived by many people in the industry. #scrum #projectmanagement #agile

[@wrecktanglin5126]

It would be great if you made a playlist of all the videos referenced in this video for mobile users

[@damianrybinski7386]

Thanks for this video Joshua! :)

[@scrummasterinblack]

You’re welcome. Thanks for watching 🙏

[@ardianpramanta704]

Hi Joshua, Greeting from Indonesia. Excellent video!! Wish that this video reach high managements and create better world. How we can do agile, if developers are different entity (outsourced, contracted), they develop their own product and may have different goal than us?

[@ashleydickson62]

Excellent!!

[@scrummasterinblack]

Thanks Ashley 🙏

[@hendragunawan9615]

Hi Joshua,
Greeting from Indonesia. Could you please make a video about how a good workflow is, the example of a good one, example of a bad one, in related to implementing kanban in scrum and not making our workflow as mini-waterfall? Thanks and scrum on

[@krod16]

This is exactly how my organization uses Scrum like a mini waterfall to micromanage and satisfy management that does not change. And it's been this way for 10+ years. I don't think that's going to change any time soon unless people like you are consulted which is never going to happen. The Scrum Masters used are either past project managers or internal developers who continue using it as a management tool.

[@scrummasterinblack]

10 years and nothing has changed ? 😟

[@krod16]

@@scrummasterinblack It now got worse because SAFe started being used. Instead of fixing the impediments like dependencies, tools, etc. even more process, fake agile, and focus on fixed time, scope, budget.
I tried explaining the issues and exactly the same thing that we are doing mini waterfalls and not fixing the actual problems rather making it worse by adding process overheads. But management is not interested in that and it continues.
The formality of following processes, using labels and getting the tag of being agile is more important than actually achieving agility.
Management wants development teams to be agile. Rest of the organisation continues as it is.
Higher management wants statistics like how much is the velocity of the teams and how many story points are completed per sprint.
Each team member has his own sprint goal to complete the tasks per sprint.

[@lifeafterforty]

Hey Joshua,
What are your thoughts about the Change Request process?
It has been suggested that every scope change, requirement change goes through a Change Request process and there is a recurring meeting for discussing and approving such changes.
Is it common in Agile projects or is it more of a traditional waterfall approach? Thanks

[@scrummasterinblack]

I can’t speak for Agile as it’s definition is vague and too broad. Each person you talk to has different definition of Agile.
Scrum itself as you already know is not about projects. In Scrum, any so called “change request” is just a Product Backlog item. The Product Owner decides whether that Product Backlog item adds value to the product and decides when it will be done by the team and released to the customer.

[@lifeafterforty]

@@scrummasterinblack Thanks Joshua.
The issue as you have mentioned in the video is when the project with tight deadlines is broken down into sprints Then every change in scope and requirements is expected to go through a CR process.
Agile transformation is a journey I guess. And definitely not an easy one 😊

[@scrummasterinblack]

Indeed is not easy. We need to continuously challenge the status quo.

[@gorboman]

I want to get your opinion on this case, please. If a backlog item faced many issues during development, had to be stretched from the agreed 1 sprint to 6 sprints, and eventually it's no longer relevant, should we just release it in whatever state it is and disable / hide it? Or should we just stop the development and scrap the backlog altogether?

[@scrummasterinblack]

You should ask your Product Owner first over me. At the end of the day we're using Scrum for business purposes. If the Product Owner think it is no longer relevant in the market, then there is no point in releasing it. But before you spend extra 5 Sprints, the team could've try releasing it at the current state as an experiment and see how does the customer react to it. If there is traction, then continue building it based on the customer feedback.

[@gorboman]

@@scrummasterinblack thanks. releasing as an experiment is something that we didn't think about.