Lex Larson, who asked.
I'm a new scrum master. Hooray. We're building BI solutions.
The team is largely in south america. That is, everyone more technical than me is down South. We've got a half dozen DBAs, who have a manager.
Up here is me and the PO. The PO is my boss, and the boss of the DBA's manager.
We've got the following problems that I may need help in how to resolve:
1. Our last spring planning session was two weeks ago. It was chaotic, as the PO kept demanding that we take on more work. I told her it was too much a couple of times, as did some of the engineers. She insisted. Additionally, she said our estimates were wrong. It was ... not good. I knew what was going to happen: the sprint was going to fail.
2. It got worse. The DSM's became explanation and micromanagement from the PO, instead of the simple "what did you do yesterday/today/blocks" that it should be. One of them went an hour, and I was unable to successfully intercede.
3. At those DSMs, she was assigning new and different work than had been agreed to. Work assignments for the engineers also changed through the day. It was chaos.
I've done the following:
-- Talked to the manager down South, who called me concerned. She knew as I did that we weren't going to hit any of the goals for the sprint.
-- Talked to the PO, who insisted priorities would continue to change. I've told her that if this happens, we won't be able to deliver.
So ... my dearest internet: What, other than having a backbone, am I to do?
Subscribe to:
Post Comments (Atom)
Okay, so who does your PO report to? Who is she answerable to? Are those leaders on board with actually doing an agile/Scrum methodology, or just paying lip service?
ReplyDeleteBecause what you're doing is crunch/cowboy development, not Scrum. The PO needs to hold the sprint commits sacred in order to reap the benefits of predictable velocity and regularly released working code... which is the whole dang point of Scrum.
What does the PO say when you explain that you cannot commit to the extra work she's trying to introduce?
(I have other questions about where her priorities are coming from, and how she's delegating work, but we can start here...)
Lex Larson "For two weeks? Come on, you can all do more".
ReplyDeleteMe, bemused look: That's not really how this works....
Her: I know how scrum works.
... So, yeah. It's problematic. I've said pretty much exactly that: That with shifting sand, we won't be able to make progress, that we won't have a good product. That she needs to trust the developers, and that the commitments need to be held as sacred.
She's also talked to the dev manager about it, who I think said something similar. We're having a planning session tomorrow, which I am hopeful will go better.
I continue to be open for advice and suggestions, though I know the above didn't have direct questions.
Oh, and happy coincidence: I am on the mailing list for Mike Cohn of Mountain Goat Software (and a Name in the Scrum community). He was writing about POs with 'shiny object syndrome' which leads to behavior like your PO:
ReplyDeleteHere's the article:
Does your boss ever tell the team to develop a feature and then a few days later ask for a completely different feature? Have you ever had a manager who participated in a debate over two possible approaches but then a week later couldn't remember which approach was chosen?
That happened to me a lot when I was a programmer. And it infuriated me.
And then as I moved up the corporate ladder, I realized I was the one occasionally doing this to my teams.
But then I learned why I was behaving that way. And I learned how to stop. Today, I want to share with you what I learned.
First, let's give a name to this type of behavior: shiny object syndrome. Someone asks for a feature and then before that feature is delivered, the person's attention is captured by the next shiny object.
Dug, the talking dog from the movie Up, suffered from shiny object syndrome. Whenever Dug saw a squirrel, he became completely distracted.
I learned that I suffered from shiny object syndrome because once I'd asked a team to build something and they confirmed they would, that feature was out of my mind. As far as I was concerned, it was done.
I'd asked for it. They said they'd build it. Done.
And so my brain moved on to thinking about the next thing, and then I'd ask the team for it. And they'd get as frustrated at me as I did at my bosses when I was in their situation.
OK, I don't want to just tell you why your boss suffers from shiny object syndrome, I want to help you fix it.
To do that, you need to make sure your boss, or whoever is behaving this way, remains mentally engaged in the feature.
This type of boss needs more frequent updates. They don't need to be formal or even written. But you need to be sure that your boss remains aware "that thing isn't done yet."
This can be as simple as casual updates when you walk past the boss's desk or see him or her in the hallway. Comments like
• Hey, I want to let you know we're making good progress on the feature you asked for. Earlier today, Ashwin show me that he got the such-and-such working.
• Oh, hey, we're having a meeting this afternoon to discuss design options for that feature you requested. Stop by the team room at 2 if you want to see them. (Or simply, I can tell you more after the meeting if you'd like.)
• Hey, we got stalled a bit on that feature because the vendor took two days to get back to us on something. But they finally sent us the new drivers this morning. We should be able to make progress again.
Those aren't formal or even detailed, but they are just enough to keep someone's brain mentally engaged with the feature they asked for.
And that should be enough to help your team succeed with--squirrel!--agile,
Mike
William Nichols First: She doesn't know how Scrum works. You are correct, and she's out of line to demand the team do more.
ReplyDeleteIf you think a logical approach will work with her, you can outline the following in a 1:1 discussion:
a) Trusting the team to do their work with care and quality is vital to team success. The team needs her trust and support to deliver. Without it, quality will suffer, and features won't get done, because she's setting an unsustainable pace for the team... which leads to burn out, which leads to staff turnover, which leads to project implosion.
b) Each work day is never a full 8 hours of hands-on-keyboard coding time. There's meetings, there's collaboration, there's research... so 6 hours/day is a more likely workday for a developer, and 2-4 hours of coding time for a lead dev who is coordinating their team is pretty typical.
c) While scrum discourages equating story points to elapsed time, you can calculate how many story points the team can deliver per sprint, and how many points a given dev can deliver per sprint. In my experience, I see something like 1 point per day per developer (so 10 points per sprint for each dev) is pretty common. A team of 5 devs + 1 dev lead? That's going to be about 55 points, assuming your dev lead is coding about half of the time. YMMV, but once you have some sprint delivery data at your disposal, you can run the numbers.
d) The sprint commit is like a contract. It needs to be locked in for two weeks for the team to work on. If there's a change to the terms, then that contract is no longer valid. It can be amended, and a new commitment established... but it rarely benefits anyone to spend time to renegotiate while devs sit idle waiting for their priorities to shift.
e) Any new ideas are always welcome into the backlog, but the door is closed while in-sprint. Sprint boundaries is where reprioritized (and sprint-ready) stories can be introduced.
I personally use a two-pronged persuasion tactic: I do the logic thing above, PLUS add on an emotional appeal for trust. She cannot know how scrum works until she's tried it. It's kinda radical thinking to trust your team is professional enough to get their work done on time with high quality, but it's a necessary component to successful teams.
ReplyDeleteIn standups where POs have a bunch of ideas for what should be getting done, I use a parking lot sheet on the wall to record the idea so it gets in the backlog. This lets the PO feel heard, but puts their request into the context of the entire backlog, so they are forced to keep looking at all the competing ideas they have.
The backlog should be continuously groomed (meaning epics broken down to stories, stories detailed until they meet the team's Definition of Ready, prioritized/stack ranked according to business, technical, consumer factors), and sized by the dev team. Do you have BAs writing stories, or is the PO doing that? If the PO is writing stories, I can't see how she's got time to keep introducing new work...
In addition to the backlog-as-parking-lot approach, I give POs some 'tough love' and let them know that we want to help and take all their ideas and make them real, but it has to happen in sequence, by priority, and only for work that's ready for development.
Is the PO supposed to be at the standups? I didn't think they were? That seems like the easiest way to at least keep them from annoying the devs? For the sprint planning I might try "well then we'll deliver early, but right now we're still gathering data" or somesuch. I think a lot of the stuff (points, velocity, etc) seems more like an excuse to tell management no, so use it :)
ReplyDeleteIt sounds like she doesn't trust the team enough for scrum.
ReplyDeleteSome people are genuinely freaked out by an apparent lack of direction and control. She's acting as if she believes the team will do the wrong thing (or nothing) unless she's constantly on them.
She may feel threatened by the team coming up with its own internal dynamics. By keeping the team constantly reacting to her latest intervention, they can't come up with a coherent voice that might produce a dissenting opinion.
She may feel worried about the overall timeline. If all you're gonna do this sprint is "x", then we're going to miss a deadline. She may be under pressure from above/elsewhere, and her only tool is to use electric shocks to make up the difference. At least she tried, right? (Many driven people treat themselves this way.)
There's an HBR article that talks about how to deal with a micromanager; sadly it's soaked in advice that smells of codependency to me. The basic points are:
1. Micromanagement stems from anxiety
2. Attempting to wrest control from a micromanager or calling attention to their behavior will increase their anxiety
3. Empathy can help, finding out what their needs are might mean you can meet it some other way (or at least have a conversation about the actual issue). I've seen this happen once, my PM visible sighed and slumped in his seat when I figured out the source of his stress.
4. Overcommunicate, flatter
5. Find a new job
https://hbr.org/2011/09/stop-being-micromanaged
It actually looks like #2 might be happening - she's anxious, so she micro-manages, then you tell her the team won't deliver, so she has to double down (as she sees it).
I worked for years under a controlling, anxious manager, and it was an enormous source of stress for me. Leaving was the best thing I did.
Sometimes when you have a conflict, your own resistance, however unconscious that is, can exacerbate the conflict. I don't know if that's happening here. You might try a little judo on the PO by saying, sincerely and with a straight face, "That's a great user story! We should put it on the backlog! If we can get through this meeting fast enough, and we can take care of this week's sprint, we might be able to do that for the next sprint! In fact, let's give it a high priority." She gets what she wants... assurance that she was listened to and the product will be improved, even if it isn't improved the way she wants this week.
ReplyDeleteSounds like you are doing your job as SM by defending the team's time. Good luck.
Patty Kirsch In by-the-book scrum, the whole team (PO included) is supposed to attend daily standups.
ReplyDeleteIn reality, many POs attend a couplefew standups a week, often relying on other team members (the scrum master, or business analysts) to keep the lights on while they're otherwise occupied, like with their regular job.
In by the book scrum, the PO's job is to be the PO. I doubt that happens much.
ReplyDeleteMuch as being the SM for this team isn't my full time job. I've easily got two or three things that should be full time jobs, and the quality is suffering for it.