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

Re: [scrumdevelopment] Re: Team size question

Expand Messages
  • Keith Ray
    Note to the original poster: don t forget that scrum is based on empirical process control-- estimates are not the same as promises. Measure results, reflect
    Message 1 of 7 , Mar 23, 2009
    • 0 Attachment
      Note to the original poster: don't forget that scrum 
      is based on empirical process control--
      estimates are not the same as promises.
      Measure results, reflect on how they 
      got them. 

      C. Keith Ray
      Agile Coaching, training, eLearning 
      Sent from my iPhone

      On Mar 23, 2009, at 12:16 AM, Roy Morien <roymorien@...> wrote:

      What FAILed? Did the developers FAIL to work well, and to their level of competence? What happened during the sprint that leads you to believe that it was the in-Sprint activity that FAILED?
       
      Perhaps it was the initial guessology (sometimes called estimating) that FAILed! Perhaps that person who became ill didn't see it coming. You have actually stated two apparent areas of 'FAILURE'. The first is the pre-sprint activity, of estimating, planning, preparation. The second is the actual sprint period and activity. Putting it another way, if I say it will take 1 week to do something, and it in fact takes 2 weeks, then there are two very distinct possible areas where things 'FAILED'. My estimate may have been 50% shy of the mark, or I just didn't perform very well during the sprint, thereby confounding the estimate.
       
      Rather than talk about FAILed, put it another way ... OPPORTUNITY. You now have an opportunity to review, consider, learn ... whatever you want to call it ... about what to do differently, and presumably better, in the future. If you do not take on this opportunity, THEN you will have FAILed. If you learn nothing from your experience and from the problems that you have obviously already identified, THEN you will have FAILed. So far, you haven't FAILed, you have merely discovered some of the ways of not doing things.
       
      Regards,
      Roy
       

      To: scrumdevelopment@yahoogroups.com
      From: dnicolet@...
      Date: Fri, 20 Mar 2009 16:39:47 +0000
      Subject: [scrumdevelopment] Re: Team size question

      --- In scrumdevelopment@ yahoogroups. com, "jacobkarma@ ..." <j.ozolins@. ..> wrote:
      >
      > Hello. Lately we have done a couple of sprints with a team the same size as this and in my humble opinion - Scrum can work.
      >
      > The problems we faced were:
      > * lack of sharable knowledge during sprint
      > * lack of preparation due to lack of knowledge at preparation meeting
      > * a sick developer created a much larger impact on team velocity
      >
      > The result for us, from three such sprints was, 2/3 FAILED. Tasks were not completed before the deadline, although in one case we only just missed it. The first sprint we were completely off target, due to developers claiming to be able to push themselves, and not being able to.
      >

      Failed seems like a strong word, especially when written in capital letters.

      Impressions:

      1. In the first sprint it's normal for a team to accept work on a "commitment" basis because they don't yet have a historical velocity to use as a guideline. Management should not see this as a "target." It's just a reasonable guess to get things started.

      2. It's normal for developers to be optimistic initially about how much work they can complete.

      3. It usually takes 3-4 sprints for the team to get used to working together and to ramp up to their normal velocity. What happens before that isn't "failure," it's just normal ramping-up stuff.




      Let ninemsn property help. Need a new place to rent, share or buy?
    Your message has been successfully submitted and would be delivered to recipients shortly.