Scrum/Waterfall
So I have inherited a team that already does scrum or at least what they believe is scrum. When it comes to the basics they are great. They attend the ceremonies have a team charter that they regular update and exhibit the behaviors that a high performing team would. The only issue is their product development is lacking. It’s literally like they are fitting a waterfall project plan into sprints. For example. Instead of DEV, INT, QA and PROD and outputting an increment at the end of a sprint it’s more like… One sprint is for DEV the next is for INT then QA and so on. So to deliver a potentially shippable/releasable increment actually takes 2 months. I have been candid with the team and told them straight up that this is not scrum and instead its just waterfall masked as scrum. I just told them they need to outline features (I know this is mostly the PO/PM's role) that they can deliver in 4-12 sprints and identify a standalone functionality that can be delivered as an increment that could be delivered in 2 weeks sprints. If part of the features cannot be delivered in two weeks then we may need to increase our sprint cadence to three or four weeks. I attempted to work with the product owner and team to compromise/collaborate on a solution and got massive push back as she feels that this works for the team. I’m kind of lost at where I should start but I know what I need to do. I would just like to receive some suggestions before I make a move. Is there anything that I’m missing here?
Hi John,
Is the fact that they (can) release an increment every two months a problem for them?
You're perfectly right in saying they aren't really doing scrum, but if real scrum doesn't bring them any additional benefit, It would only cause overhead while attempting these changes.
It might be that they are experiencing some downsides, but just don't know that they relate to this longer release cycle. You could keep an eye out for any "symptoms" that a long time to market could give. Like slow customer feedback loops or distractions by getting feedback from topics that you worked on months ago. With this information you could start a discussion on how much pain it brings them and if that is enough for them to try and change there ways.
and got massive push back as she feels that this works for the team
If waterfall is genuinely working and there is no need to innovate, why even bother faking Scrum?
It sounds like transparency has been deliberately reduced over two things:
- what Scrum means, thereby inhibiting empiricism in other, more genuinely complex work
- the success a waterfall model has apparently brought in this non-complex and relatively predictive situation
Why mess either of these things up? Who wins by these shenanigans?
I’m kind of lost at where I should start
To start with, you may want to back up and find out why the team chose Scrum and what challenges they thought Scrum would help with before you joined, and bring transparency to what is still missing in this Zombie Scrum way of working. A good servant leader will help the team get to the "why" behind the elements of Scrum.
You've already identified a key missing piece, in that the Scrum Team does not have a valuable, useful product Increment every Sprint? Help them understand why that is the game changer when it comes to Scrum. As an example, was/is rework a problem? Did Tech Debt build up? Were issues found late in the waterfall and now cost more to fix late in the process?
So I have inherited a team that already does scrum or at least what they believe is scrum.
The point of Scrum isn't to do Scrum, it is to deliver value to your customers. Help them understand that.
So I have inherited a team that already does scrum or at least what they believe is scrum. When it comes to the basics they are great. They attend the ceremonies have a team charter that they regular update and exhibit the behaviors that a high performing team would.
Just because they use some of the terminology does not mean that they are using the Scrum framework. There are no ceremonies in the Scrum framework but there are events. A team charter is not mentioned at all in the Scrum Guide. So your indicators are not indicative of the Scrum framework.
The only issue is their product development is lacking.
Based upon what empirical evidence? Have customers voiced concern about the products being delivered? Has anyone in the company voiced concern that what is being delivered is not of quality or that it is being delivered late?
Scrum is not for all companies or all situations. As the Scrum Guide states
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Not all problems are complex. You mention nothing about the complexity of the work or why you feel that the current process is flawed. While I applaud your desire to see more agility and help others see the benefit of Scrum, you might not be in a situation where that is going to be appreciated. Are any other teams in the organization using processes that are more inline with the Scrum framework? If so, what is different in their product area than the one you are mentioning? How does the organization support them differently than how it supports this team?
Hi John,
One option for you might be gradually improve the credibitliy among the team memebers and in the organization towards yourself. At this moment it is more important for you teaching/explaining Scrum than proposing the process changes. You may even need to distance from Scrum and focus on the empiricism, agility, continues improvements and their benefits. Gradually intorudce/improve certain elements of Scrum to trigger self-improvement. The crucial element is well facilliatet retrospectives, which should naturally bring to the surface potential problems. Those retrospectives do not even need to be in the prescribed Scrum cadance, it more important for them to happen. This all needs to be done carefully, keeping in mind the importance of preserving/building trust.