12

A fellow CSM approached me yesterday with a problem. They have been running Scrum for 6 months quite successfully and Management are happy however the development team have requested the CSM to take on a Project Manager role and instill waterfall practices.

Given the team are self-organising and they are deciding to organise away from Scrum he was at a loss as to how to proceed.

They articulated a number of concerns and regardless of the CSM explaining the benefits of Scrum they are committed to return to Gantt Charts, Project Management meetings and detailed documentation as well as time-sheeting.

Improve this question
3
  • 1
    ^^ I think this is EXACTLY the problem. They don't want to be accountable.
    – Venture2099
    Commented Mar 7, 2015 at 9:55
  • Great thoughts @jessehouwing. You should have put it in an answer.
    – Joel Bancroft-Connors
    Commented Mar 7, 2015 at 23:13
  • What is the problem that this change in process is meant to solve?
    – Todd A. Jacobs ♦
    Commented Mar 8, 2015 at 17:40

5 Answers 5

Reset to default
16

Well first thing is to remember that a retrospective, like a user story, is an invitation to a conversation. I wasn't there, so I can only take a guess as the meeting. It sounds like the retrospective may have ended up more focused on solution and not what the actual problem is.

The scrum master (CSM is a certification, not a role) should start with some powerful questions. "What is the benefit to a Gantt chart?", "How would you see the a week under waterfall?", "What does time-sheeting get you?".

If he has access to another scrum master or, better yet, a coach having that person come in might help. The problem could be the scrum master (we don't like to think it is us, but it happens) and by getting an outside person to ask the questions, you might get better answers.

Taking off the coach hat for a second and moving to mentor, my gut is saying there is an outside factor at play here. Working with software developers for 20+ years I've never met one that said "Please sir, can I have my time sheet back. Oh and can we do 100 page functional spec documents that no one reads?" I'd look to the management layer to see if some outside pressure is being put on them. It is not unheard of to have a functional manager threaten their people's reviews if they don't do things their way.

Improve this answer
1
  • 2
    +1 for outside factor. Who's asking them information that's hard to give or commitments that are unrealistic ;)?
    – jessehouwing
    Commented Mar 8, 2015 at 9:49
13

Hard problem; I've seen that as well in the past. Analyze deeply what it is they're trying to improve in the whole. Then ask them hard questions, trying to get to the deeper problems before jumping to solutions.

  • why you'd need Project Management meetings
  • how the Scrum Meetings are not supporting that
  • How creating a Gantt chart differs from creating a plan during the sprint planning meeting.
  • Are their planning meetings currently effective?
  • Who it would be helpful to if they did hour tracking?
  • etc.

You might find that the developers do not want to be accountable for the plan and the product and prefer to do as told, which is hard to break through. In that case, read into the dysfunctions of a team, before teams can be held accountable, they need trust, conflict, commitment before accountability. The Five Dysfunctions of a Team is a great book (and there are a lot of presentations available on this subject - e.g. a selection from SlideShare).

enter image description here

The final thought I have is that there is a (perceived) pressure to deliver. That the backlog only gets larger as they deliver new stuff and that the team needs motivation that they're doing their best and are delivering the right things. It can be very demotivational (and kill commitment) if you're constantly being told you need to be more productive, deliver more, faster and cheaper. It kills the drive to improve and it generally takes away the time that's needed to put these improvements in place.

Slow down to go faster

Improve this answer
1
  • You may consider taking the whole team through the PSD.NET Course to get them to appreciate the role of a Developer in Scrum a little more.
    – jessehouwing
    Commented Mar 8, 2015 at 17:39
8

"Self-organizing" does not mean uncontrolled

You said:

Given the team are self-organising and they are deciding to organise away from Scrum...

I believe your development team is grossly exceeding their bounds on the pretext of "Self-organizing". To cite a small example, the stakeholders now have to wait for, say, nine months to see the first demo of the project, instead of every two weeks.

Here are a few quotes from Mike Cohn's presentation on Leading a Self-Organizing Team:

It does not mean letting people do whatever they want to do.

[Management sets the] boundary within which self-organization occurs.

From the original 1986 article by Takeuchi and Nonaka that introduced the term "Scrum":

Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. Instead, the emphasis is on “self-control,” “control through peer pressure,” and “control by love,” which collectively we call “subtle control.”

However, it is not clear why the ScrumMaster, let these concerns pile up instead of addressing them as they arose:

They articulated a number of concerns...

If I were the ScrumMaster, instead of being on the defensive, I will try to drill down into these concerns and make a serious effort to understand the root causes and look for solutions.

Improve this answer
0
2

One option would be to make the move back to waterfall an experiment. Agree to make the change but say that you will measure how successful it is and compare it to the results the team was getting using the agile approach.

Improve this answer
2
  • How would you measure the success of the return to Waterfall? - what would be the criteria for either staying with waterfall, or returning to Scrum? Unless that is nailed down, you could end up with the team being divided in terms of their preference, and worse, I fear that you could end up flip-flopping between the two and getting no real buy-in to either methodology.
    – Iain9688
    Commented Mar 8, 2015 at 9:46
  • I would hope that criteria of success were set when the team originally moved to Scrum. Some metrics that spring to mind are customer satisfaction, time-to-market and numbers of production bugs. But the appropriate metrics would be those that encouraged the switch to Scrum.
    – Barnaby Golden
    Commented Mar 8, 2015 at 10:38
1

The team here, wants to go back to the waterfall model, that they have been working since long. A change (Here Scrum implementation) is difficult to inculcate within. A better solution here would be to coach the team, learn the difficulties they are currently facing and how switching back to the Waterfall model these problems could be removed. Plan a retrospective meeting with the team and take notes of the following points:

What the team should Continue doing? What the team should Start doing?
What the team should Stop doing?

Try to get solution to the problems the team has collectively come up in this meeting.

Above all try to energies the team with the core values of Scrum "FORCE", build this in the team. And help them out to strengthen as a team: F - Focus O - Openness R - Respect C - Courage E - Extreme Commitment

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.