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

36343RE: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]

Expand Messages
  • Anthony Principato
    Feb 2, 2009



      My company is in the process of figuring out how we can better leverage Scrum techniques, disciplines and principles within our Data Center and Infrastructure groups to better support Scrum/Agile Development teams. Can anyone please share their experiences, approaches with aligning the planning of Data Center and Infrastructure new and updated build outs of all environments up and through Disaster Recovery in preparation of Sprint Development efforts.  

      What we are trying to do is align accordingly the timing of Infrastructure and Data Center build outs in direct relation with Development Sprint efforts so we can be better prepared for Sprint Development.


      Questions we are asking ourselves:  


      Do we time-box work effort processes by server type, number of servers so we can strive for velocity levels to communicate back to the business and development for release planning?

      Do we create a Scrum Service Level Model so we can maintain a plug and play of Virtual Machine resources for all project release initiatives?


      Any help would be appreciative.






      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mitch Lacey
      Sent: Monday, February 02, 2009 4:05 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]


      Hello Adam,


      Sorry to chime in a little late, but the topic of fixing defects into a Sprint is a bit of a perplexing one.


      I’ve wrestled with this and have a chapter on it for my upcoming book.


      One of the rules we have on the list is no spamming of blog posts or URL’s to drive traffic to our websites, but I talked to Ken about it and he’s OK with me sharing.


      You can check out the draft chapter here:

      http://tinyurl. com/chghy5


      Please provide feedback on the chapter, it’s fresh off the press.




      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Adam Sroka
      Sent: Friday, January 30, 2009 3:26 PM
      To: scrumdevelopment@ yahoogroups. com
      Subject: Re: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]


      On Fri, Jan 30, 2009 at 5:39 AM, Joseph Little <jhlittle@mindspring .com> wrote:

      > Hi Kane,
      > I would certainly agree. And thanks for raising the issue. And
      > apologies if I deflate the interest of some readers by changing the
      > subject line to a different metaphor.

      Hehe. You said "deflate".

      > I think it is a feature (not a bug) that Scrum does not *require
      > specific* engineering practices. But not continuously improving
      > Engineering practices is a form of ScrumButt ("we do Scrum, but...we
      > don't have any engineering practices"). Doing Scrum absolutely means
      > that you must improve engineering practices. Continuously! !!
      > You and Martin (apparently) don't define what "a mess" means.
      > suggest two things to start with that might clean it up:
      > (1) A story is not done until all bugs are fixed (very soon this
      > almost always means you must have more automated testing).
      > (2) Somewhere in every story we must do some refactoring of the code.
      > Should be part of the definition of done. That DoD is *very* important.

      Yes, but, having been there myself:

      1) We can't possibly fix all of the existing (production) bugs in a
      single iteration. Would it be okay if we increased the length of our
      iterations? Add an "iteration 0" so that we can assess the impact to
      existing production code of every new effort?

      2) I don't know what is going to break if I refactor this stuff,
      because there are no tests. Can we create "technical stories" so that
      we can go on refactoring crusades? Can we greatly inflate our
      estimates, because we don't know what is going to break?

      And, I'll add another "but" to the pile:

      What do we do if some parts of the team are willing to adopt
      "engineering practices" and others resist? In my experience (And I'm
      an "XP guy") "engineering practices" only work team wide. If most of
      the team are doing TDD, continuous integration, pairing, etc, and one
      or two guys are sneaking in untested code, velocity will grind to a
      standstill while the "good guys" attempt to clean up after the bad.

      > One more thing, somewhat different to what Martin was getting at:
      > * we must also have continuous improvement in Business Value Engineering.
      > If we can't provide evidence that we are getting better and better at
      > delivering BV, then what are we doing? Of course, many specific
      > practices in this. More in another post.

      What is the "business value" of cleaning up the huge mess of horrible
      legacy code we've created over the past umpteen years? Does business
      understand the value of adding tests? Does business understand the
      value of eliminating bugs that don't have an immediate (known) impact
      on the customer? Adding testing and refactoring to every story will
      greatly reduce velocity (at least initially.) Will the business accept

    • Show all 30 messages in this topic