Common demo mistakes
I was invited to the demo by the parallel team recently. They were quite well organized. Perhaps a little too organized for my tastes (they took a 45 min rehearsal before the demo), but it played quite well. What they did that was nice was to summarize the sprint objectives, in a printout, prior to each segment. We always came up short in that department. What they did that was bad was they demoed features that weren't finished.
So class, does anyone know why we shouldn't do that? Of course you all do, because we've all tried to pull this one off. You spend three weeks busting tail and get just within spitting distance of completion. Close enough so that part of it is showable, even though there's still another week or two of code cleanup before it's ready to go. Not wanting to look like a slouch who got nothing done for the entire cycle in front of the boss, you show it anyway.
So what's the problem? Now that item is crossed off the backlog and won't be taken into account when planning the next sprint. But you know there's at least two more weeks of work hiding in there. What happens? Either you try to overbid your next sprint goals, making up the missing code with your slack, or that feature winds up shipping (or making it to final testing) in an incomplete state. Or a combination of the two. Regardless, it's bad news and these problems build on each other and compound themselves until there's a big, explosive day of reckoning at what should have been the end of the product cycle, kind of like what happens in tradition SDLC development.
Q: So how do we avoid this? A: Every way you can.
This can be easy or hard, depending on your organizational environment.
#1. Developers must show courage and be ready to admit when they mis-judged. We too often fall into the arrogant mentality that we're the smartest people on the earth and somehow our brilliance will overcome all adversity. This leads to misrepresenting the status of a task in the standup in the hopes that we'll be able to overcome and no one will be the wiser.
#2. The scrum master must be truly aware of what is going on with the project. If you as the scrum master have a solid rapport with everyone and complete faith in what everyone tells you, I have a bridge for sale in Brooklyn. I don't mean to distrust, but if one of your devs is failing every sprint cycle, but says things are great every standup, you need to actively work with them and understand what is done and what is left. The buck stops with you, scrum master.
#3. Kill features early, kill features often. If something appears to jeopardize any aspect of the cycle, kill it immediately and rechannel your devs to working at a more methodical pace on fewer features and focus on quality. When you start rushing on anything, quality suffers across the board. Next planning meeting, evaluate why you had to kill it and reduce scope on the suspect features.
So class, does anyone know why we shouldn't do that? Of course you all do, because we've all tried to pull this one off. You spend three weeks busting tail and get just within spitting distance of completion. Close enough so that part of it is showable, even though there's still another week or two of code cleanup before it's ready to go. Not wanting to look like a slouch who got nothing done for the entire cycle in front of the boss, you show it anyway.
So what's the problem? Now that item is crossed off the backlog and won't be taken into account when planning the next sprint. But you know there's at least two more weeks of work hiding in there. What happens? Either you try to overbid your next sprint goals, making up the missing code with your slack, or that feature winds up shipping (or making it to final testing) in an incomplete state. Or a combination of the two. Regardless, it's bad news and these problems build on each other and compound themselves until there's a big, explosive day of reckoning at what should have been the end of the product cycle, kind of like what happens in tradition SDLC development.
Q: So how do we avoid this? A: Every way you can.
This can be easy or hard, depending on your organizational environment.
#1. Developers must show courage and be ready to admit when they mis-judged. We too often fall into the arrogant mentality that we're the smartest people on the earth and somehow our brilliance will overcome all adversity. This leads to misrepresenting the status of a task in the standup in the hopes that we'll be able to overcome and no one will be the wiser.
#2. The scrum master must be truly aware of what is going on with the project. If you as the scrum master have a solid rapport with everyone and complete faith in what everyone tells you, I have a bridge for sale in Brooklyn. I don't mean to distrust, but if one of your devs is failing every sprint cycle, but says things are great every standup, you need to actively work with them and understand what is done and what is left. The buck stops with you, scrum master.
#3. Kill features early, kill features often. If something appears to jeopardize any aspect of the cycle, kill it immediately and rechannel your devs to working at a more methodical pace on fewer features and focus on quality. When you start rushing on anything, quality suffers across the board. Next planning meeting, evaluate why you had to kill it and reduce scope on the suspect features.
posted by nitpickable at
9:45 AM
0 Comments:
Post a Comment
<< Home