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

Re: Questions re Scrum, please help.

Expand Messages
  • Alan Shalloway
    ... model ... have a ... (otherwise it ... features ... with ... Hi Bas: Very nice point. ... overproduction ... It s a ... You are correct, I should not have
    Message 1 of 7 , Aug 21, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Bas Vodde <basv@...> wrote:
      > In practice, people tend to execute scrum in an annoying mental
      model
      > called "project". The thing with "project" is that it tends to
      have a
      > definite start, end, goal and thus some kind of content.
      (otherwise it
      > wouldn't be "project" anymore). IMHO this often leads to extra
      features
      > and much other waste. It often leads to product owners to continue
      with
      > stuff in the product backlog because it "is part of the project".

      Hi Bas:
      Very nice point.

      > Related: in lean production, I wouldn't call eliminating
      overproduction
      > a principle though. Eliminating waste is and overproduction is
      > identified as the mother of all waste. Same with minimizing WIP.
      It's a
      > result of removing the waste.
      >

      You are correct, I should not have called those principles. They
      are more results you want to achieve. I incorrectly called them
      principles because one of the most pragmatic advice I have seen work
      for people is to give them a goal and then see how the team is doing
      for achieving the goal. Sometimes this is easy, but more often
      there are impediments to the goal. Seeing the difference between
      where they are and what they want helps them see the impediment and
      remove it. Otherwise they sometimes just think - this is as good as
      I can do. I think of principles as things to follow and doing what
      I just described is a "thing to follow" (but not a principle).

      In this case, I was thinking part of our Scrum retrospection should
      always be to see if we delivered some code that wasn't needed or
      code that superceded prior code (making the earlier code
      unnecessary). In an ideal world this shouldn't happen. But I have
      seen teams not quite recognize the need for a full-time available
      product owner make some customer decisions themselves on the basis
      that the customer wasn't available. I've also seen developers put
      in extra features with the claim - "well I was in there anyway and
      it didn't cost anything" (forgetting the several times more price
      they are going to pay in maintenance). In both cases, seeing that
      they have wasted their time may eventually convince them that
      following the Scrum practice of the product owner deciding the
      priorities is a good idea. One of my favorite quotes is from Jeff
      Sutherland:

      "The task then is to refine the code base to better meet customer
      need. If that is not clear, the programmers should not write a line
      of code. Every line of code costs money to write and more money to
      support. It is better for the developers to be surfing than writing
      code that won't be needed. If they write code that ultimately is not
      used, I will be paying for that code for the life of the system,
      which is typically longer than my professional life. If they went
      surfing, they would have fun, and I would have a less expensive
      system and fewer headaches to maintain."

      Few programmers truly embrace this.

      This makes me realize the difference between an agile transition and
      an agile transformation. When I first started coaching teams in
      Scrum it was something they wanted to do. It was more of a
      transition. It was often very small teams and isolated at that.
      Getting them to apply Scrum practices was relatively straight
      forward and easy. As we now are transforming companies to agile
      with Scrum I would say the task is different. Most of the
      difficulty is actually getting people to understand why they should
      be doing what they should be doing. People only do things that:
      1) make them right
      2) are in their best interest

      Aligning the teams with management in order to transform the
      enterprise requires unifying principles.

      Alan Shalloway
      CEO, Net Objectives
    Your message has been successfully submitted and would be delivered to recipients shortly.