Lucine, his wife, smiled and finished chewing her strawberry before asking "What now?"
"Trying to keep my team on track is like herding cats."
"Why?" asked Lucine, before popping a bite of waffle in her mouth.
"They don't do what I tell them to do." Frank heaved a sigh and added, "They don't get it."
Embarrassed that her strategy hadn't worked, Lucine asked "Don't get what?" around her mouthful of waffles.
"They are my Scrum team. I am their Scrum Master. They just can't seem to get that through their heads."
"It does sound like they should be doing what you tell them to do."
Later, Frank went to work - something he dreaded every morning and the night before. He sat with his team and tried to keep them on track.
In the course of the day, he noticed they were doing their best to follow his orders. They each came to him and asked for permission to do something at least five times a day, but they weren't meeting their goals.
It seemed like they asked him about the little things and made their own decisions about the big things.
Obviously, Frank needed more control. So he got more involved in the details. After all, the aggregate is just an accumulation of details.
Frank inserted himself into every decision. He made sure he was in every meeting. He asked for status reports four times a day. Gradually and consistently, he insinuated himself into every aspect of his team's work.
After a few months, Frank noticed that the more control he took, the more out of control the project he was managing seemed to get. Something about that insight nagged at the corner of his mind but he set aside the concern to really focus on the problem.
He decided he would try an experiment. He would go back to only answering requests for permission.
For a few days, the team basically did nothing. They were afraid to move without Frank's sayso. Then the team began inviting Frank to pair with them and to their design sessions.
After another few days, Frank called a short meeting where he made a brief announcement.
"It seems like my old style of leadership was getting you to do the right thing more often than this, so I'm not going to involve myself in any of the little things, for a while."
The team seemed skeptical but they tried it the old way, making some of the decisions themselves and asking his permission in other cases. Frank stayed true to his word.
A few weeks later, Frank was at a bar with a friend and he said "It's weird. When I help them more, they do worse. When I help them less, they do better?"
His friend didn't really want to talk about work, so Frank filed the notion away for later.
The next morning, he was mulling over the idea. "Why would they do better with less help?" thought Frank.
Then he remembered something weird that he heard in the class he took to become the Scrum style of project manager - a master of a Scrum team. It didn't make sense at the time, but it crept into the forefront of his mind as a result of him thinking about how much he helped...
At least, that's how Frank remembered what was said.
Without really understanding what this agility thing was all about, Frank made the best interpretation he could: A scrum master's job isn't to make sure a team meets its commitments. It's to make sure they beat them.
As a result, he drove his resources hard and put them away wet every sprint for a year.
Yet, upon seeing empirical data that a team went faster when he interfered less, Frank began to wonder if his trainer had meant something else.
He dug through his old things and found the printout from the class. There was an email address in the back and he wrote the teacher to ask him his question:
The coach was surprisingly prompt in his reply.
Frank was perplexed by this and he didn't reply for days. Finally, he sent this:
Almost instantly, he got his reply.
It was like someone smacked Frank upside the head and knocked something loose. His job wasn't to be a taskmaster, making sure people were working hard enough or on the right things. His job was to make sure people had all the information they needed to make the right decisions on their own.
Frank worked diligently to change his habits. He replaced assertions with questions and elicited analysis whenever someone sought an answer. When he drew his own conclusions, he shared them as insights or, better yet, as questions that would help others make the same discoveries as he had.
Six months later, things had turned around completely. The team managed their own tasks. They improved on their own. People worked predictable days and made continuous, measurable progress toward their business goals.
Within a year, Frank found himself laying out his clothes for work the next day and thinking about how he was on the precipice of an "Alexander wept"-type scenario.
"Should I move on?" he asked himself.
Just before he concluded that he had worked himself out of a job, Frank realized that there was an entire enterprise full of teams that hadn't made this transition and an entire array of problems that weren't caused by the team but still affected them.
Frank smiled.
For the first time in a very long time, he was looking forward to going to work, the next day.
His friend didn't really want to talk about work, so Frank filed the notion away for later.
The next morning, he was mulling over the idea. "Why would they do better with less help?" thought Frank.
Then he remembered something weird that he heard in the class he took to become the Scrum style of project manager - a master of a Scrum team. It didn't make sense at the time, but it crept into the forefront of his mind as a result of him thinking about how much he helped...
You're job isn't to make sure the team hits its deadlines. It's to make sure the team can keep going faster by helping them see and remove impediments.
At least, that's how Frank remembered what was said.
Without really understanding what this agility thing was all about, Frank made the best interpretation he could: A scrum master's job isn't to make sure a team meets its commitments. It's to make sure they beat them.
As a result, he drove his resources hard and put them away wet every sprint for a year.
Yet, upon seeing empirical data that a team went faster when he interfered less, Frank began to wonder if his trainer had meant something else.
He dug through his old things and found the printout from the class. There was an email address in the back and he wrote the teacher to ask him his question:
I got my team working as hard as I could but they kept slowing down. I tried to help them make better decisions and keep them from doing things that weren't approved and they kept slowing down. The only time they sped up in just over a year is during this last sprint, when I stopped helping them as much. How am I supposed to make a team go faster if helping them makes them go more slowly?
The coach was surprisingly prompt in his reply.
I knew this might be a problem. I've seen it before. It's part of a natural transition for big organizations - especially ones that make the mistake of trying to translate the project manager role into being SMs.
I'm glad you are noticing the problem, yourself. You don't make the team go faster. The team makes itself go faster and you help by facilitating the identification and erradication of impediments.
Frank was perplexed by this and he didn't reply for days. Finally, he sent this:
So who tells them which tasks are okay and which are not? Who says how long it should take?
Almost instantly, he got his reply.
They make all the decisions - except for a few reserved for business. You make sure everyone has all the information they need.
It was like someone smacked Frank upside the head and knocked something loose. His job wasn't to be a taskmaster, making sure people were working hard enough or on the right things. His job was to make sure people had all the information they needed to make the right decisions on their own.
Frank worked diligently to change his habits. He replaced assertions with questions and elicited analysis whenever someone sought an answer. When he drew his own conclusions, he shared them as insights or, better yet, as questions that would help others make the same discoveries as he had.
Six months later, things had turned around completely. The team managed their own tasks. They improved on their own. People worked predictable days and made continuous, measurable progress toward their business goals.
Within a year, Frank found himself laying out his clothes for work the next day and thinking about how he was on the precipice of an "Alexander wept"-type scenario.
"Should I move on?" he asked himself.
Just before he concluded that he had worked himself out of a job, Frank realized that there was an entire enterprise full of teams that hadn't made this transition and an entire array of problems that weren't caused by the team but still affected them.
Frank smiled.
For the first time in a very long time, he was looking forward to going to work, the next day.
