ScrumMaster Tales – The Story of a Rogue Developer

By: Mark Levison, CST

This sprint, the team has finished planning and has committed to delivering five stories, totaling 25 story points (sized 8, 8, 5, 2 and 2). Based on their velocity from the past few sprints, this seems like a reasonable commitment.

Shortly after the beginning of the Sprint, without talking to anyone else, Doug goes and talks to Product Owner Sue about a great idea he has. He’s come up with a way to find the user’s location via IP address, turn that into a street address and pre-populate the shipping address when they buy a book. (We will ignore the shocking privacy implications). He pushes hard and convinces Sue that this will be great addition for the product and promises her it will only take a week to do. Sue says “sure, go for it”. At this stage neither Sue nor Doug has said anything to the rest of the team.

During the next few days, Doug doesn’t attend the Daily Scrum, nor does he appear to have committed to any tasks on the tasks wall. Four days into this, he comes to the Daily Scrum but when he answers the question about “What did you complete yesterday?” he’s evasive. Nobody can really understand what he says he’s working on. ScrumMaster John is confused. After standup he digs through the Source Code Control logs to see if Doug has checked anything in since he disappeared. Then he asks Martin and Ian if they know what Doug is working on. Everyone draws a blank.

John asks Doug if they could have a chat saying: “I can’t see from the story board what you’re working on right now can you help me understand?”. Doug says I’m working on something important right now and I’m really too busy to talk.

What are John’s options?

Analysis

At its heart, Scrum helps to build collaborative high performance teams. While he’s well intentioned, Doug is not modeling the Scrum values. He’s not being open/transparent nor is really focused on business value.

Doug’s actions have several affects:

  • Commitment – By doing unplanned work, he makes less likely that the team will meet their commitment for the sprint

  • By doing work that wasn’t part of the Product Backlog, we don’t really know if this feature has value to the business

  • Estimates – The estimation wasn’t done with his teammates so no one was there to question his assumptions

  • Quality/Fit – We’ve no idea of what he’s working on is a good fit for the rest of the product, both in terms of the UI and also the shape of the code

  • Code review – his code has not been peer reviewed (either pair programming or code review)

  • Trust – By hiding from his teammates, he has effectively said he doesn’t trust them

  • He signals that being closed is ok on this team

  • Regulatory risk – if team has to comply with SOX or other regulatory framework, this code can’t be tied back to meaningful requirement

Doug has become a cowboy or rogue.

What options does John have?

  • Confront Doug right away

  • Invite him out for coffee and ask him what’s going on

  • Find a way to bring the issue up with the whole team right away, without turning it into a blame and shame

  • Let the rest of sprint take its course and let the team struggle to make the commitment – then discuss in the retrospective.

Side note: My Reccomendations

I never find confrontation solves any problems and as Doug has already said that he doesn’t have time to talk, I prefer the last option – let the team discover the problem on their own. We want to grow their self-organizing muscle. This is a good way to start.

I think the key for John is to have a good retrospective agenda ready so the team can delve into the issue without making it personal. This would be one of those occasions I would ask a team member to read and remind us of what the Retrospective Prime Directive says: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”. I would have several activities available to me and choose which one to use depending on what the team is discovering. In situations where we have things to discover, I find the Retrospective Timeline a good start: Patrick Kua has a great summary and Simon Baker has another example. In this case the activity seems like a good fit because it will not only reveal what Doug did, but also what happened with the rest of the Sprint. This way it won’t seem like Doug is being picked on.

Back to the Story

John decides to let it ride until the end of the Sprint and see what happens.

Doug hardly engages for the remainder of the Sprints and the team gets visibly more frustrated. The 2nd to last day of the Sprint, Doug checks in a large batch of code for his “feature”. However the code lacks unit tests, hasn’t been peer reviewed nor is it well tested. During the Sprint Review Doug demonstrates his feature and its clear it has some bugs. The rest of the team has struggled and just missed the original Sprint commitment delivering 21 of the 25 points.

Before the Sprint Review, John has surveyed team members to see if they would be comfortable with Product Owner Sue attending the Retrospective. Everyone said yes. John started with the EVSP (Explorer, Shopper, Vacationer & Prisoner) warm up activity and then launched into the timeline. Populating the timeline, Doug added his work on the location feature. When it came time to label emotions Doug put lots happy marks for the times corresponding to his feature while the rest of the team noted either surprise or sadness. This lead to a discussion about why team members had made the notes they did and Doug started to realize how the rest of the team perceived his actions. By the end of the Retrospective the team had agreed that in future if special projects were warranted, they had to be discussed with the team first and placed on the Storyboard so they would always be aware of what the others were working on.

What other options do you see John as having? How would you have handled it?

Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.