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

Re: [scrumdevelopment] Re: Velocity change over time for stable teams

Expand Messages
  • George Dinwiddie
    Hi, Sten, ... If it s that time-critical, then there s all the more reason to make the scope flexible. Note that this /does not/ necessarily mean cutting
    Message 1 of 7 , Sep 9, 2010
    • 0 Attachment
      Hi, Sten,

      On 9/9/10 2:24 AM, Sten wrote:
      >>> We are at a point now where most - if not all identified key
      >>> competence areas are covered in most teams. The velocity is still not
      >>> at the level that satisfies a release of the product in april.
      >>
      >> Are you working toward a fixed scope?
      >
      > Yes. That is, there is a minimum feature set the project (PO
      > organization) feels is needed for a first release to production. The
      > product launch is really a very time-critical thing and a late
      > release might well put us out of business.

      If it's that time-critical, then there's all the more reason to make the
      scope flexible. Note that this /does not/ necessarily mean cutting
      features. Usually I find it better to slice the features into thinner
      user stories, as some of those this slices can generally be deferred.
      If they're not sliced thin enough, that's not possible. And slicing
      thinly is a learned skill, and one that most new scrum teams haven't
      mastered. Of course, this is a technical skill that's not really part
      of scrum, so that's not surprising.

      >> Besides the question of team size, Fred Brooks' "Mythical Man Month"
      >> pretty clearly documents that adding people will slow you down. Perhaps
      >> adding a new team can help, /if/ you can partition the work to minimize
      >> the need for interaction between teams. Too often I see orgs try to use
      >> multiple teams, but haven't figured out how to organize work so these
      >> teams can operate independently. In effect, they've got one big team
      >> with walls (and sometimes miles) between subsets.
      >
      > This is something we are struggelig with. We have 5 teams concerned
      > with the April release. We are constantly working on ways of
      > improving the interaction between them.

      Are they all in the same location?

      > We have just recently gotten to a stage where we have some historical
      > velocity data and although little statistical basis, this does not
      > look too good at the moment. We have stabilized the sprint length to
      > two weeks (used to be varying between 3-4 weeks, some teams actually
      > did a 6 week sprint this summer), gotten a better organized and
      > T-Shirt size estimated backlog and the team is now actually working
      > with tasks in the sprint backlog of less than a day in effort.

      That sounds like definite improvement.

      > I was thinking that rather than adding even more people to the force,
      > why not spend some resources on someone dedicated to helping teams
      > work better together?

      A very understandable strategy.

      >> Before hiring a coach or new team members, you might consider an
      >> assessment from a good Agile coach. An outside pair of eyes (or two
      >> pair--it can result in much more than twice the information) might
      >> reveal some things that you don't notice. We become used to our
      >> situation and filter out things.
      >
      > I don't think we have existed long enough to have had time to get
      > used to our situation. My team has had people added to it every month
      > since it was established in April/May and I got onboard as a scrum
      > master in June. Before that, the PO was acting as SM too. The lack of
      > team stability is very apparent to me right now.

      Yes, instability of the makeup of the team will inhibit the team from
      gelling. It could well be that some coaching in technical practices
      (for the developers, but also including story refinement with the PO)
      will help, also.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.