57932Re: [SCRUMDEVELOPMENT] Stop Prefetching Stories
- Aug 4, 2014On Mon, Aug 4, 2014 at 3:32 PM, George Dinwiddie lists@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
Thanks for the reply.
On 8/4/14, 12:07 PM, Cass Dalton cassdalton73@...[SCRUMDEVELOPMENT] wrote:>> I think it's the discussion about WIP that I'm after. I definitely getI think picking up the next story is OK, especially if you check with
> 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.
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.Our developers tend to overengineer. In an effort to highlight agile's focus on only engineering what's needed for direct customer value, we have been asserting that all the work in the sprint needs to be tied to customer value. For example, one of the developers wanted to write something like "As a developer, I want a debugging framework..." I refused to let that story into the backlog and there was a lengthy discussion about how you build solid software without "As a developer" stories. I guess part of my fear is that they will see the end of a sprint as an opportunity to hide developer stories and that will be no different than just writing developer stories except that I don't have any say in prioritizing the work.
> I wouldn't have said that I'm not trying to observe sprint boundaries.
would fit in the sprint, thinking it didn't matter if it went over the
boundary.>I think there are advantages to the rhythm of time-boxed development.
> 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.
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.
Hmm.. described that way it does sound like I'm not trying to observe sprint boundaries. And you're saying that one purpose of said boundaries is limitation of WIP?Karl Scotland and I (with some others) explored this area in 2010:
- George> <mailto:lists@...> [SCRUMDEVELOPMENT]
> On Mon, Aug 4, 2014 at 9:07 AM, George Dinwiddie lists@...
> <mailto:SCRUMDEVELOPMENT@yahoogroups.com>> wrote:
> __> <mailto:cassdalton73@...>
> Hi, Cass,
> On 7/24/14, 12:54 PM, Cass Dalton cassdalton73@...> > <mailto:yahoo@... <mailto:yahoo@...>>
> [SCRUMDEVELOPMENT] wrote:
> > 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
> > can confidently achieve) in case the team over achieves. Every sprint
> > has a couple of stories that are in progress and the demo is
> > the snapshot of what is done and ready on that day.
> 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
> > On Thu, Jul 24, 2014 at 12:30 PM, Michael Wollin
> yahoo@... <mailto:yahoo@...>
> > <SCRUMDEVELOPMENT@yahoogroups.com
> > <mailto:SCRUMDEVELOPMENT@yahoogroups.com
> <mailto:SCRUMDEVELOPMENT@yahoogroups.com>>> wrote:
> > 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
- << Previous post in topic