Following article got published on Techwell
All of you have probably heard the news involving the recent ban on larger soda sizes in New York and the subsequent un-banning. There are people who are arguing against the soda size ban, and they are challenging government not to micro-manage their lives. On the other hand, there are people with views who vouch that this ban would help improve the health of overall society as well as reduce the tax burden.
These conflicts in thinking that occur in societies in which a group of people resist an unpopular decision are nothing new and not restricted to large societies at all. We see these things in our day-to-day life—even in our work places.
Have you come across situations where project teams have resisted changes suggested by their leader? To add another twist, what if the teams were self-organizing, as in the agile world?
Self-organizing teams are supposed to have clear goals and manage their own priorities to achieve them. This does not mean that they are leaderless. Let me clarify at the outset that self-organizing teams have leaders and someone to monitor and support them.
As author and developer Jim Highsmith says, they need light-touch leadership. Leadership needs to step in if the self-organizing team are treading in the wrong direction, thus moving away from the goal.
I heard a story from the trenches about a particular self-organizing team going through this journey. This new agile team felt it was a waste of time to do Scrum rituals and collectively decided to skip the daily stand ups and retrospectives.
As expected, the ScrumMaster stepped in, did the root-cause analysis, and found no reason to skip the rituals. The ScrumMaster then tried coaching the team about the importance of rituals and why team members should not ignore them.
However, the team members decided to escalate further to senior management to get support for their cause. Let’s say you are part of senior management. Would you be supporting the ScrumMaster or the team? I am sure most people would agree to support the ScrumMaster since the daily stands ups and retrospectives help agile projects, teams, and their own bottom-line in the long run.
However, what if management supported the team's skipping the rituals? Supporting the ScrumMaster would have caused more agitation by the team, which would result in a loss of team morale. Tying this story about self organization back to the New York soda ban, I see that Mayor Michael Bloomberg (ScrumMaster) had all the good intentions to save lives by bringing this change; however, he didn’t get support from the citizens (self-organized teams).
How would a ScrumMaster bring about change in the above situation? What kind of management practice could help team members change their minds?
1 comment:
If i would have been in scrum master's position I would not have stopped the team from doing what they want to do. However, as a coach, I would have definitely challenged them and "make them think" about how & when would they reflect on their learnings, how & where would they capture those learnings and action items, how and when would they communicate it to the entire team, how would they measure their change etc... These questions are the essence of retro. If the team has thought through these questions, if they do have a concrete & better plan, if the entire team agrees and is willing to experiment, then by all means I would not stop them.
You said scrum master would coach the team to follow the rituals. Or to follow the "rules". Thats the issue I have with your post and thoughts.
There is a difference between coaching and mentoring or being a watch dog. Coaching is about asking solution-focused powerful questions that helps an individual or a team to step back and think through, have a different perspective, have a broader vision. Coaching is all about helping someone "think for themselves and not to think for them instead".
There is also a difference between being agile and agility. You must have heard of ShuHaRi. The three stages of learning. Someone new to agile or scrum might start by following "rules by book". But once they start understanding why they are doing what they are doing, it is scrum master's job (and company overall) to make a fail-safe environment for team and let them loose; to experiment. By fail-safe I mean 'it is ok to fail. it was an experiment after all'. That is your Ha state.
From your post it seems you do want your team to move beyond Shu state. You do want your team to experiment, to fail and to learn from failure.
Observe and reflect closely and frequently to the team as a scrum master and coach so that they do not fail too much too often. But by all means let them decide and self-organize and fail and learn from it. Most of the times, they would not fail (with a good coach / scrum master who would help them think through it thoroughly)
For example; when I was working with ThoughtWorks, our team decided not to do any sprint planning. In fact remove the concept of sprinting. They wanted more of Kanban pull flow in place in between of the project. But the team had a plan for how to reasonably predict release dates, when and how to give feedbacks and when and how to retro. We experimented and it was a huge success. To give you an idea (though I am against measuring team success using velocity) our velocity went up from 6 to 8 SP to 12 to 16 SP per 2 weeks. Somewhere team sought freedom from their past performance (velocity) by not doing doing sprint planning, though scrum says "do sprint planning".
Post a Comment