In a similar vein to my previous post Project Managers Bridge to Agility I have recently stumbled across another nice article – this one from Pete Deemer at www.scrumtraininginstitute.com.
These things always ring so true – yet in practice it’s so hard for a company to do let go and trust in their team’s ability, especially when under pressure.
You really need to have all players sold on the belief that agile development does work.
As Jeff Sutherland mentioned in a seminar of his I went to last night, these things are so simple, but not necessarily easy.
Excerpt from MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM below:
The traditional role of the manager in the corporate world is based on a model known as “command and control”. Here, the job of the manager is to identify what needs to be done, to issue detailed instructions to the employee, and then to ensure the employee completes the work according to the instructions. The role of the employee in this model is simply to follow the directions as given, trusting the judgment and wisdom of the manager to ensure that the right work is being done in the right way.
In complex, dynamic environments such as software development, this approach tends to break down. First, it is difficult and time--consuming for a manager to understand every requirement in full detail and issue precise instructions to guide the work of every employee. Within a software development Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a single manager to do all the basic thinking for his or her team is unrealistic, and it often constrains the team’s productivity to the manager’s ability to give instructions. In addition, this approach tends to be demoralizing for employees; their role is simply that of “order follower”, and they often feel little sense of ownership of their work. Accountability is limited to answering the simple question, “did I complete the orders I was given?” If the answer is “yes”, the job has been done – regardless of whether the right thing was built, built well, or built to satisfy the business goals of the customer.
Scrum is based on a different approach: The Self--Organizing Team.
The Galaxy Team had been doing Scrum for several months, and the Team was
well on its way to being truly self-organizing. Their motivation was high, they were
focused, and after a few Sprints of under-delivery, they were now showing a
pattern of making reasonable commitments and delivering them 100% each
Sprint. Morale was high, and there was a real sense of “flow” in the work they
were doing. The engineering manager Francis had come a long way – once a
habitual micromanager, he was now acting like much more of a mentor and coach
for the Team. Unfortunately, though, in the eighth Sprint, the Team encountered
some unexpected difficulties, and about halfway through the Sprint, they were
significantly behind in their progress. The VP of the group, Simon, had ventured
into the Team’s work area to see their Sprint Burndown Chart, and called Francis
to his office.
“Francis, it looks like this Sprint is a disaster. What’s going on?” he asked.
Francis responded, “Well, the Team hit some bumps along the way, and they’re
trying hard to get everything done that they committed to, but it’s a bit touch-andgo
right now.”
Simon grimaced.
“Francis, this project is critical, and we can’t let it fall behind. I’m counting on you
to make sure the Team finishes what they commit to, this Sprint and every Sprint.
As a manager, your job is to make sure the Team gets it done; if things are going
well, then you can back off a bit, but the minute the going gets tough, I want you in
there making sure that no time is being wasted, and everyone is doing exactly
what needs to be done.”
Francis was exasperated. Simon had been too busy to attend the in-house Scrum
trainings, but Francis had emailed him a Powerpoint presentation about selforganizing
Teams and the new role of the manager, and Simon hadn’t voiced any
disagreement. Francis spoke up:
“But what about the self-organizing Team, Simon? What about our shift away from
micromanagement?”
There was a glimmer of recognition, as Simon recalled a Powerpoint he’d seen a
few months before.
“Yes, the Team is responsible, but when they start to fail, I hold you responsible.
We want maximum accountability, so I’m holding them accountable and I’m
holding you accountable. In our department, everyone is accountable! Now make
it happen.”
At that, Simon spun his chair around and started typing. Francis took the hint and
left the office.
The next day, Francis showed up at the Daily Scrum Meeting.
“Guys, we’re going to do a different format for the meeting today. Due to the
criticality of this project, Simon has instructed me to more actively… uhhh…
‘facilitate’ your self-organization during the Sprint. So what I’d like to do this
morning is get a status update on each of the features you’ve committed to –
whose done what so far, and what’s left to be done – and I’m going to be giving
some more detailed feedback so hopefully we can get everything 100% finished
by the end of next week.”
The Team looked at each other. Philip, the ScrumMaster of the Team, spoke up.
“Francis… uhhh… does this mean that the Team is no longer responsible for
managing itself?”
Several Team members nodded in agreement.
Francis replied, “Guys, we’re all responsible. You’re responsible for managing
yourselves, and I’m responsible for making sure you get everything done. We’re
all responsible together!” Francis didn’t see the eyeballs subtly roll.
As the Sprint proceeded, Francis was more and more involved. The Daily Scrum
became an update meeting for the Team to tell Francis what they’d been able to
complete, and for him to assign them the next day’s tasks. The mood of the Team
shifted; motivation seemed to go down, and Team members seemed to be
reverting to their previous role, what they used to sarcastically call “servants-of-
Francis-the-Great”. By the end of the Sprint, the Team was fully back into “orderfollowing”
mode, and Francis was directing their efforts task-by-task.
At the Sprint Review, the Team was surprised when Simon joined the meeting just
as it was starting.
“So…” Simon announced, “Did we get our commitment done?”
The Team looked at each other. Francis answered.
“Simon, unfortunately there are a couple backlog items that weren’t finished.”
There was a flash of anger in Simon’s eyes.
“How did this happen? Who is responsible for this?”
The Team was silent, but their heads all turned slowly to Francis.
Simon continued. “Francis, I told you to get it done. Next Sprint, I don’t want to
see this happen again. If it does, there will be hell to pay…”
Upon hearing this, everyone on the Team made a mental note to think very
carefully about just how much to commit to in the next Sprint. The last thing they
wanted was to get shouted at again two weeks from now.
As the Sprints passed, Francis became more and more involved in directing the
Team at every stage of their work. Gone was any semblance of self-organization,
and with it disappeared the improved motivation, drive, and focus that the Team
had started to display. Morale had plummeted, and so too had productivity. Lunch
breaks were getting longer, coffee-breaks more frequent, and Francis felt like he
was spending more and more of his time just making sure people were at their
desks working. Those amazing few Sprints, when the Team was truly selforganizing,
and performing at the level they were really capable of, were
becoming more and more of a distant memory. The return to micromanagement
was made all the worse because they’d had a taste of the self-organization “good
life”.