« Understanding Backlogs| Main | Puppy #2 Identified »
Agile Warrior: Breaking up is Hard to do
The projector painted a screen from Microsoft Access on the wall as the team voices all droned into a low hum. It was Showcase and Retrospective time, and I was visiting a team to try to figure out why one of my star teams had lost 80% of their velocity this past iteration.
“How about story 174,” the project facilitator asked, “what’s the status on that?”
“Let’s see,” a voice from the back of the room said, “This is ‘research Groovy’”
“Well?”
“Well, I finished researching Groovy. It’s great.”
“So the story is done?”
The Product Owner speaks up.
“Not exactly. There should be ‘install Groovy in the dev environment.’ on that story too.”
The facilitator starts adding to the story.
She looks up – “Well how many hours are left to do that?”
The developer shrugs. “I don’t know. Say around 20?”
“Okay then. We’ll carry that over to the next iteration. How many points were there?”
“It was a 21-point story.”
“So you think you did about 7 points worth this time?”
“Beats me. Sure. All I did was spend some time Googling. Is Google around 1 point?”
“We’ll call it seven points. So you have 14 points remaining for the next iteration.”
The developer shrugged. “Sure”
Somewhere deep in the back of my mind a silent scream called out, and then was silenced. It was as if a million coaches rose up their voices in fear and anger and were suddenly quieted.
There was a major disturbance in the force.
At the end of the meeting, the team’s velocity had improved – they delivered about 80% of what they had planned – if you counted points. If you counted stories, they completed 3 stories out of 12.
Just from the back of the napkin, around seventy percent of agile projects end up with severe velocity problems during their timeline. This phase can be transitory, or it can be fatal to the project, depending on how it is handled.
I asked the Product Owner after the meeting how he thought the iteration was going.
“It’s going fine,” he said, “we have a good team.”
Does the decreasing velocity bother you?
“What’s a velocity?”
Stepping back, I couldn't help but feel amazed at where we were. This was a sharp team -- one of the best in the small company that I was working with. Most of the team members , on their own, went out and got their CSMs. Over previous iterations they had consistently delivered quality work, and were highly respected by their peers.
But looking at that backlog, nobody had any idea or control at all over when things were going to be completed.
Something had to change.
I took the PM aside after the meeting and spoke with him in the hall.
"The real problem we have here is the team. They just don’t understand Agile development. Sure, I’ve lectured them many times on “pure” agile development and how if we were really pure we wouldn’t have all of these problems, but for some reason my lectures go unheeded. I have a three-part lecture series scheduled for next week where I go over how I was involved at the very start of the agile movement with (mentions a couple of names) and how they would handle things if they were here. Did I mention that I just got all the latest scrum certifications? CSPO and CSP. I’m thinking about getting my CST."
"What about the decreasing velocity?"
"Well obviously the team is not working in a self-directed manner. If they were, we’d be working with lots more small stories instead of these big ones. I keep telling them, but for some reason they have a really bad attitude. Beats me why."
This didn't seem to help any, so I made an appointment with the Product Owner for the next day. He was in a fine mood as I stepped into his office.
"Good to see you! What a great group we have there. I’m proud as heck of ‘em."
"Do you think it is a good idea to be adding onto the stories at the end of the iteration – effectively adding a bunch more stuff for the developers to do?"
"Sure I do. After all, I need the work done, no matter how we slice it. And have you seen what a pain it is to put all of that stuff into Access? I tell you, I’m not going through all of that again. We’ll just add the new stuff on and we can finish it the next iteration."
"But don’t you have stories that have gone for 4 iterations like this – each time at the end you add more stuff on? How can we ever finish a story like that?"
"Let’s not get caught up in all the details, son. After all, this agile stuff is all about the team performing, becoming self-directed. We’re just self-organizing the stories as we learn more about them. That’s agile, right? We’re taking ownership of the stories. We own them, so we can do what we want with them. And it’s not like it’s anything new – heck, we’d have to do all of this anyway. What difference does it make whether we do it in one story or seven?"
The more I interviewed the team, the more I became convinced that the project manager had poisoned the well. He was so excited about Scrum and Agile that instead of exciting the team, he had turned off the entire team to continuing to improve their work. Worse yet, the ones not turned off, like the Product Owner, had a distorted idea of what Scrum or Agile is. Interviewing him further revealed that he was getting his idea of what true agile was by taking some things from the Project Manager and some things from the CSMs on the team, mixing them up into something that made sense to him.
During the next stand-up, I asked for ten minutes of time. I told the team that they were working very hard and that the entire organization was proud of them. Agile is a simple thing, but you can screw it up if you try hard enough. At it's heart, you must be able to describe what you’re going to do, commit to doing it, execute, and then demonstrate that you’ve done it. This feedback loop is critical to agile.
They took it well. The audience was polite and agreeable. But I couldn't help but think that everybody was just going through the motions. Even when it came to improving their work habits, they'd rather have the pain they knew than change. In their minds they had changed enough.
Never heard much from them after that. I reviewed some of their work from time-to-time as requested, and found them still giving partial credit and struggling with "done". They were happy that they knew everything they needed to know about agile and I was happy their Product Owner was happy.
Breaking stories up can be hard to do. But you still gotta do it.
You Agile people (meaning you and my own Agile boss/coach/whatever) should get over yourselves. Andy Hunt, one of the original signers, says that Agile isn't right for all situations. If zero Agile is thinkable, perhaps partial Agile is also thinkable. But no, you converts are rigid, as converts are.