Loading ...
Sorry, an error occurred while loading the content.

49464RE: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • Roy Morien
    Dec 1, 2010
      I did follow my 'so what?' comment with the suggestion that, if all is made transparent and explained to everyone, then in all probability the (temporary) fall in velocity would be known and understood by all concerned. So, given only an implication of reasonableness by stakeholders, the Momma would understand and not be too unhappy. Of course, this must be taken in the context that this is not a regular and frequent situation that has caused the customers to lose confidence in the team, no matter how open and transparent they are.
       
      The impression I got from the original posting was that there were clearly some technical matters that really needed attention, and the poster of the message was rather agonising over how to get it done, in a 'Scrum' way. My feeling was that there should not really have been such a concern ... if it didn't fit under Scrum's process regime, then that still shouldn't be a problem ... get it done, whatever had to be done.
       
      I think this notion of only ever doing things that have value to the customer has been somewhat misunderstood, or misapplied. There are most certainly things that need to be done that do not have an immediate, direct, or even obvious value to a customer ... but they still must be done. So what if user stories are not written for them, and so what if they really don't fit the notion of user stories (however defined). Being afraid to get it done because Scrum doesn't seem to cover that situation just leads to development paralysis.
       
      Regards,
      Roy Morien
       
      > To: scrumdevelopment@yahoogroups.com
      > From: ronjeffries@...
      > Date: Tue, 30 Nov 2010 09:57:26 -0500
      > Subject: Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)
      >
      > Hello, Roy. On Tuesday, November 30, 2010, at 12:37:53 AM, you
      > wrote:
      >
      > > Do you really have such a difficult choice to make? I would think
      > > that if your 'technical' development requirements are so important
      > > and so big, or so many, isn't it a practical thing to do to call a
      > > timeout on user-facing development, and get those technical
      > > matters squared away and off the table?
      >
      > I have not seen this approach work often on the ground, unless the
      > time involved is very short. Especially if the time involved is
      > short, interleaving improvement with features works better in my
      > experience.
      >
      > > Or, is it possible to reassign some developers to get these
      > > technical matters done, while the rest of the team continues on
      > > the user-oriented stuff? This may affect team velocity, but so what?
      >
      > "So what" equals: the product owner and other business-side people
      > become unhappy. And when Momma's unhappy, everyone's unhappy.
      >
      > Assigning developers is likely to leave both efforts weak, unless
      > the team is rolling in talent. And if they were rolling in talent,
      > they wouldn't be in this mess.
      >
      > Working on the "technical matters" works best when it is driven by
      > stories. The code base is probably in need of work everywhere, but
      > the payoff will be received only where the code is going to be
      > worked on for user-facing reasons. If no stories are going to pass
      > through some crufty area, working on it is largely wasted.
      >
      > Therefore, I prefer the approach of taking stories as usual (but
      > probably fewer of them), and following the "boy scout rule" of
      > leaving the campground better than you found it. In other words,
      > wherever the stories lead us, let's write more tests, let's refactor
      > more aggressively.
      >
      > This approach has at least these advantages:
      > maintains "best sensible" flow of stories;
      > provides help from all team talent;
      > provides for whole team to learn how to keep code clean;
      > focuses improvement exactly where it is needed;
      > does not waste improvement that "may be needed;
      >
      > ... and probably more.
      >
      > Regards,
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Know what I pray for? The strength to change what I can, the inability to
      > accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > <*> Your email settings:
      > Individual Email | Traditional
      >
      > <*> To change settings online go to:
      > http://groups.yahoo.com/group/scrumdevelopment/join
      > (Yahoo! ID required)
      >
      > <*> To change settings via email:
      > scrumdevelopment-digest@yahoogroups.com
      > scrumdevelopment-fullfeatured@yahoogroups.com
      >
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >
    • Show all 28 messages in this topic