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

Week One : Relief & Panic (Long)

Expand Messages
  • Greg Akins
    So as of yesterday we re a week into our use of Scrum The start of the first Sprint was rocky for some of the reasons mentioned before. This is a long post
    Message 1 of 1 , Feb 28, 2007
    • 0 Attachment
      So as of yesterday we're a week into our use of Scrum

      The start of the first Sprint was rocky for some of the reasons
      mentioned before. This is a long post and I mostly describe what
      we've done so far. The one question I have (and more detail is
      towards the end of the post) is how to get the team to realize what
      project mgmt can fix; and what needs to be fixed by other departments
      (ie., bad planning because sales doesn't maintain predictions, or a
      sales pipeline).

      =========================================================

      1. The Sprint Backlog was not accurate

      We were able to substitute better backlog items and keep our Sprint
      size the same. The Sprint items that had to change hadn't been
      started yet, so I think this is OK; and the decision was made with the
      whole team present and in agreement.

      2. The "True" product owner didn't have enough input

      The product owner is now on the team. Though he says he doesn't think
      he'll be able to make all the daily meetings. I think this is still
      a problem, but at least the psuedo product owner and the true product
      owner have a better idea of what is involved. I think that they can
      work together to create better single "proxy" of product ownership.

      One concern that came up as a result of this is that the Product Owner
      is a little too high level. He is supposed to be a product manager,
      but really isn't that interested in details. When he and the proxy
      worked on the backlog they didn't come up with that much work.. And I
      think the Product Owner is still expecting a way to "interrupt" us if
      really important stuff happens.

      3. The team, in general, wasn't well educated on the use of Timeboxed
      iterations.

      This is getting better. I'm doing a lot of "Coaching" to try and
      explain the context of what we're doing and the alternatives for doing
      things differently that still yield the benefits of Scrum.

      4. No "experienced" Scrum people

      I mentioned hiring a ScrumMaster but didn't get a postive response.
      I'll keep mentioning this especially as we run into problems that
      could have been avoided if we had more experience.

      Regarding the willingness to "Interrupt". In the past, with no
      process, and no planning; it was perfectly acceptable to stop
      development at any given point to work on emergency issues.

      In our business these are "Pilots" where a new customer is promised
      some changes to support their specific business needs. We've
      committed to this level of support since we're a new company and are
      trying to get a customer base built up.

      However, instead of trying to predict these events, or plan for them
      better (using intelligence from the sales and customer service
      departments) we're "adapting" our process to allow interruptions

      The CEO, COO and the product owner have said that no matter what we do
      in development we have to respond to Pilots. I agree with that; but
      think that we can do that in the context of a relatively short sprints
      (we're at 3 weeks now).

      Sorry for such a long post.

      --
      ==============
      Greg Akins
      http://www.pghcodingdojo.org
      http://www.insomnia-consulting.org/monologue
    Your message has been successfully submitted and would be delivered to recipients shortly.