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

Рет қаралды 2,744

Жыл бұрын

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

Пікірлер: 17

@damianrybinski7386 11 ай бұрын

Thanks for this video Joshua! :)

@scrummasterinblack 11 ай бұрын

You’re welcome. Thanks for watching 🙏

@ashleydickson62 Жыл бұрын

Excellent!!

@scrummasterinblack Жыл бұрын

Thanks Ashley 🙏

@ardianpramanta704 11 ай бұрын

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?

@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.

@wrecktanglin5126 Ай бұрын

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

@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

@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.