Cass,
Thanks for the reply.
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]Do you and your teammates get a sense of accomplishment at the end of
the sprint?
Very much so. That is not usually a problem. In our current team, a
few of the guys felt really pressured in the first sprint to get all the
stories done. But they noted that they felt the pressure go away when
they realized that I wasn't going to condemn them for not hitting
the commitment. I feel that those types of issues can be managed if you
are really stressing the whole team approach (i.e. Whole scrum team
including PO and SM). To me it feels weird to "fix" the feeling of "not
good enough" by committing to less instead of helping the team
understand that the commitments are for them and not form management.
Maybe I'm blessed with PMs that don't micro-manage that way. If a
team can't see past a percent complete to see the amount of actual work
that they accomplished, then I think they are still on the wrong side of
Individuals and Interactions over Processes and Tools (the burndown
chart is just another tool).
I wasn't worried about micromanagement (though if you had that, I would
be). Instead, I was worried about losing the sense of accomplishment
that comes from crossing off the last item in a list of things you set
out to do. That can be a big psychological boost. It shouldn't be the
only or even primary goal, but it's something to consider.
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]I think it's the discussion about WIP that I'm after. I definitely get
the fact that inexperienced teams need to get better at things like
testing and refactoring and that often when they think they're done
they're not really done. But I would think that after a while, when a
team think's its done with all the stories, they really are done with
the stories. In other words, that inexperience will (hopefully) go
away. Maybe I'm just optimistic. But if the team commits to 20 points
and is really done with 20 points and has a day or two left in the
sprint, what do you do? Ending the sprint early seems wrong because
part of what I like about Scrum is the rhythm. You could let the team
free play and do things like fix issues, but that seems counter to most
of the user value focus of agile. You could let them do more demo prep,
but that feels like falling into a mini-waterfall where the team starts
relying on having a "clean up" day.
I think picking up the next story is OK, especially if you check with
the PO to see if it's really still the next one. There are other things
I might consider doing first.
- reviewing the current sprint's work for things that weren't as
finished as they might be
- discussing the design and the tests
- attending to a small bit of cleanup for something that's been
annoying, but you haven't felt you had enough time to address
All of these could be questionable, as well, but they're examples of
things I often find getting too-little attention. If they're addressing
current weak points, and chosen by the team as a whole (including PO),
they'll pay dividends.
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]I wouldn't have said that I'm not trying to observe sprint boundaries.
Ah, I misunderstood you to say you were routinely picking more than
would fit in the sprint, thinking it didn't matter if it went over the
boundary.
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]I would have said that I don't want the sprint demo to become so
important that the event becomes more important than value generation of
the rest of the sprint. I feel like if you have to allocate time at the
end of a sprint to clean things up, then that implies a deficiency in
your adherence to DoD as you complete stories. I feel that choosing to
tidy up existing work for the purpose of making a smoother demo instead
of looking at new work can become a crutch that the team will start to
rely on where they will defer implementing everything right about a
story because they can always clean it up before the demo. It's just
that type of crutch that fuels the "Scrum is dumb" fire from the likes
of Frank D'Andrea
(http://igniteshow.com/videos/ignite-tao-v4-may-162013-frank-dandrea).
Consider taking time at the end of a sprint to clean things up and
identify what sorts of uncleanness is being generated in the sprint, and
how you could do that clean up on-the-fly in the next sprint.
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]So maybe I want Kanban more than I think I do. But I like the rhythm of
Scrum. I like the whole team oscillation between focused analysis and
focused execution. I know I said I don't want mini-waterfall,
but deferring integration to the end of sprint is different than the
mental oscillation between the analysis of the planning session or
backlog grooming and the focused execution of the bulk of the sprint.
That oscillation gives people new to agile a defined feedback cycle in
which to learn to apply the empirical part of agile. That opportunity
for the entire team to step back and think about things for a moment is
very important when you're trying to undo traditional habits and
mindsets and when you're trying to show how emergent design actually
gets you better results.
I think there are advantages to the rhythm of time-boxed development.
Those that adopt a flow system without maintaining a pronounced cadence
seem to struggle. Similarly, those that adopt a time-boxed development
cycle without keeping WIP low also seem to struggle. Scrum and Kanban
differ in which they specify, and which people find good to add in practice.
Karl Scotland and I (with some others) explored this area in 2010:
http://availagility.co.uk/2010/10/04/a-root-cause-analysis-of-agile-practices/
- George
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]__
Hi, Cass,
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]I don't know if it's the right answer, but we typically commit to
stretch goals in a sprint (a few more stories than the team
thinks they
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]can confidently achieve) in case the team over achieves. Every sprint
has a couple of stories that are in progress and the demo is
essentially
Do you and your teammates get a sense of accomplishment at the end of
the sprint?
That's a problem I've seen with teams that over-commit all the time.
They always feel a sense of "not good enough." And, as mentioned by
others, that usually leads to hurrying to do new functionality rather
than making sure what's done is done as well as they can. The nuisance
of working in a messy code base also contributes to the sense that they
need to hurry, since things take longer than imagined.
You may not have this problem, but I urge you to keep an eye open for it.
Also, if you're not trying to observe the sprint boundaries, why not
switch to a kanban approach? You can keep your current cadences for
planning, demonstrating, and retrospecting. The difference would be
that, instead of using getting things accomplished within the sprint
boundaries to limit WIP (which you're apparently not doing), you'd
explicitly limit WIP.
Just some thoughts to consider.
- George
[SCRUMDEVELOPMENT]
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]I am advising my clients to stop prefetching stores that they know
they can’t complete in the current sprint. They argue that they are
idle anyway. I argue that they should find something else to do like
read, innovate, speed up the build, add new tests, or play ping
pong. Part of the problem is their stories are too big and we are
addressing that. But I’d like some eloquence around as many
supporting arguments as I can develop. Suggestions?
Michael
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
------------------------------------
Posted by: George Dinwiddie <***@iDIAcomputing.com>
------------------------------------
To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com