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

Re: [scrumdevelopment] Tackling Agile lean change in a large org

Expand Messages
  • Thomasjeffreyandersontwin@Gmail.com
    Agreed All numbers are 1/4 the number 3/4 using your brain to interpret the numbers. Jeff Anderson agileconsulting.blogspot.com On Jan 30, 2010, at 6:17 AM,
    Message 1 of 7 , Jan 30, 2010
      Agreed
      All numbers are 1/4 the number 3/4 using your brain to interpret the numbers.

      Jeff Anderson


      On Jan 30, 2010, at 6:17 AM, Alexander Kriegisch <Kriegisch@...> wrote:

       

      Thomasjeffreyanders ontwin@Gmail. com, 29.01.2010 04:59:
      >> Whatever you do, be aware that in the beginning you get quite a lot
      >> of freedom to advocate and implement change. While you do this and
      >> create transparency, resistance will grow in certain parts of the
      >> company, because transparency can be unpleasant. This will slow you
      >> down. A few months later, somebody might kill the whole agile
      >> approach if there are no tangible benefits. So you better think
      >> about how to measure progress. That the teams might like working
      >> with lean/agile, will not be enough.
      >
      > Yes agreed, we are big on getting measurments in place, thinking of
      > a bunch of metrics, some examples...
      >
      > Work to build over work to fix per feature
      > Trouble tickets at help desk per release
      > Cycle per t- shirt sized feature
      > Defects over time
      > Cycle time
      >
      > Of course these are all IT metrics we need to tie in business
      > metrics as well, but sometimes the usual suspects can be hard to get
      > at (roi, roe, etc)
      >
      > If you have any ideas on metrics I'm all ears...

      I am not suggesting any specific metrics, but trying to point out a
      bootstrapping problem: Even though you might introduce simple metrics
      such as velocity in an environment where there did not exist any useful
      metrics before Scrum introduction, you might have a hard time proving
      that anything has improved because you have no pre-Scrum metrics which
      you can compare the new and hopefully improved situation with. You might
      be able to compare stuff one release cycle from now, but I am not sure
      if you get enough time from your management. They are usually impatient,
      unwise though that may be. So try to record the status quo *before* you
      start 'scrumming' and be able to use it as a benchmark.

      As for defect rates, be careful: A new feature such as automated crash
      reporting or a bug report wizard in your software might trigger a flood
      of new trouble tickets which will help you improve the product but make
      'bug rates' skyrocket if you merely compare the numbers.

      >> Record the status quo and concentrae on making improvements,
      >> however small they might be. Document them and be able to report
      >> them whenever asked. Try not to focus on eliminating problems,
      >> because everyone will think you are a smart-a**. Try a
      >> solution-focused approach and try to motivate people not just to
      >> make fewer mistakes and produce fewer waste, but tell them: "There
      >> is a considerable amount of good stuff here. How can we make more
      >> of it?"
      >>
      >> I told you this because I was a smart-ass too often, just because
      >> I wanted to help people and solve problems. It turned out they did
      >> not want me to solve problems, even though they said so. What they
      >> really wanted was to improve their situation.
      >
      > Interesting but I think I would need a more concrete example,
      > anything to keep me from falling in the same trap :)

      Let me tell you a little story about a Scrum coach who started his
      carreer as a software developer because he *loves* to solve problems,
      sometimes just for the sake of it. So whenever he saw a problem, he felt
      tempted to point it out to others and offer his help and good advice
      about how to solve it. He was very constructive, not just mentioning
      problems but also possible solutions. Anyway, while he thought that he
      was a particularly nice guy because he tried to help others, they
      thought he was rude because he kept laying his finger into their wounds,
      showing them what was wrong - or worse, what they were doing wrong.
      Sometimes they did not even agree with him that a problem existed at
      all, because it had always been like that. In the same instant the Scrum
      coach was seen as a smart-ass, especially because he was rather blunt
      than diplomatic in nature because he thought (and actually still does)
      that the truth is always the best thing to say. Unfortunately, not
      everybody thinks like he does...

      So, if you are anything like this guy, try to resist the urge to talk
      about problems all the time. Talk about how to improve the current
      situation. Focus on solutions [1] rather than problems, and try to find
      out how to make people want those improvements. If they don't, even the
      best improvement idea will be useless.

      [1] Solution focus: http://www.sfwork. com/jsp/index. jsp?mnk=c10

      Bottom line: An impediment list is an important and helpful tool, but
      try not to rub impediments into people's faces all the time.

      Probably I am disappointing you once again, giving general rather than
      concrete advice, but I think it would be charlatanry to offer concrete
      advice about something I do not know much about: your concrete situation
      and the people involved. I try not to do 'remote diagnosis' like that.
      --
      Alexander Kriegisch
      http://scrum- master.de

      <Kriegisch.vcf>
    Your message has been successfully submitted and would be delivered to recipients shortly.