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?
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
If the team is not "Mobb Programming" then they are doing design-dev-test-deployment in a serial manner with dedicated specialists in each position, which can be called "mini-waterfall" in that sense. You are correct in pointing to the OTHER agile practices that are different from traditional waterfall management. But in the sense of a serial-manner of value creation with specialists in each position, in such cases (99% of all implementations) then Scrum could be called mini waterfall in that sense.
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.
@@productleadership 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.
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?
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.
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
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.
@@productleadership 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 😊
Thanks for this video Joshua! :)
You’re welcome. Thanks for watching 🙏
Excellent!!
Thanks Ashley 🙏
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?
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
If the team is not "Mobb Programming" then they are doing design-dev-test-deployment in a serial manner with dedicated specialists in each position, which can be called "mini-waterfall" in that sense.
You are correct in pointing to the OTHER agile practices that are different from traditional waterfall management.
But in the sense of a serial-manner of value creation with specialists in each position, in such cases (99% of all implementations) then Scrum could be called mini waterfall in that sense.
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.
10 years and nothing has changed ? 😟
@@productleadership 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.
It would be great if you made a playlist of all the videos referenced in this video for mobile users
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?
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.
@@productleadership thanks. releasing as an experiment is something that we didn't think about.
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
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.
@@productleadership 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 😊
Indeed is not easy. We need to continuously challenge the status quo.