Throw It On the Backlog
A familiar scenario played out today on one of our Scrum projects. The customer had been thinking about one of the administration screens and how it could be enhanced. The requirements for it had already been baselined for the Sprint, but they were really interested in the new functionality.
On this particular project the last few times the developer has decided well, OK that isn’t too big a change, I’m sure we can get it done in the Sprint anyway. I’ve had several conversations asking questions about whether that made the most sense and shouldn’t we put it on the backlog, but they always felt they could get it done, and it wasn’t that big of a change. Much of this is probably attributable to trying to serve the customer, the product owner in this case.
Over the last two Sprints that scenario played out in predictable pattern. The developer simply wasn’t able to get all the changes in within the Sprint, or they delivered a day or two before the end of the Sprint to QA and so it wasn’t tested within the Sprint. Looks like the third time the lesson has sunk in.
I debated being hard-nosed and forcing the issue to be put on the backlog, but it’s really up to the team and the Scrum Master on the project didn’t balk, so I think it ended up as a much more valuable lesson learned. They might not have understood had I simply forced the issue onto the backlog. As Scrum Master I might have thought differently, but as a manager I think it’s better to let people make their own choices.
I think from now on we’ll see a lot more pushed onto the backlog and not forced into the current Sprint.
Ed Gibbs @ November 30, 2006
Nice story. I’ve found one of the challenges of being a manager of an agile team is what you described… resisting the temptation to dictate. A team can only become self-organizing, self-managing, and accountable/responsible to each other if they’re given the space to grow into it.
Very good way to handle the situation. I’m on the developer side of things, rather than management, but I’ve often said “we can get that done.” Usually it’s forced to be put on hold, but had I been able to attempt it a couple of times and realize that it’s not always as easy as it may seem, I wouldn’t feel like management doesn’t have confidence in me, but they’re just making good decisions. Good post - and @Luke: nice response.
I’ve always observed the developer optimism about rising to the challenge even among some of the grumpiest and cynical developers. Realizing that a simple change is rarely a simple change takes a long time to sink in.
“As Scrum Master I might have thought differently, but as a manager I think it’s better to let people make their own choices.”
This statement raises an interesting question : can the scrummaster and the manager be the same person?
Nothing prohibits a manager from being the ScrumMaster, but there are obviously some sub-optimizations as Ken Schwaber would say. There is a real danger that the team will feel extra pressure to conform to the wishes of their manager, so that can be a dangerous trend. And generally the manager is going to represent the interests of development over say QA which is also a danger.
The big plus is mangers typically have some inherent power to remove impediments directly. I know I’m often able to clear roadblocks quickly for a team where a typical Scrum Master would have to rely more on influence. Simple matter of hierarchical organizations.
I really don’t know how typical manager as Scrum Master is, but it’s been a pretty common occurrence in my corner of the world.