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

Re: Command and control to start

Expand Messages
  • Alan Shalloway
    ... One of the practices and strengths of scrum is the mandate to find and eliminate impediments. Basically, it s an eliminate waste approach and is very
    Message 1 of 31 , Aug 2, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...>
      wrote:
      >

      One of the practices and strengths of scrum is the mandate to find
      and eliminate impediments. Basically, it's an eliminate waste
      approach and is very good. One waste that most teams have is delay
      from when some error occurred until it is discovered. Here are a few
      common ones that Scrum is designed to eliminate:
      * time from misundertanding customer until it is discovered
      * time from writing code bug until it is discovered

      Another form of counterproductive delay is when you need informaiton
      and have to wait for someone who has it. It's easier for people to
      see what is slowing them down than it is to know how to be more agile.

      The Scrum Master's role is help elminate these impediments. I suspect
      if you focus on eliminating waste (and particularly in the form of
      delay) you'll find that you will need more Scrum practices. People
      may be more motivated to follow these because these delays are making
      their life more difficult.

      Be careful when you focus on delays that you also keep a third
      principle in mind ("optimize the whole"). In other words, the
      principles of "deliver fast", "eliminate waste" and "optimize the
      whole" are very powerful and help move Scrum forward. BTW: One way
      to achieve all three of these is to "build quality in" Notice where
      delays are due to quality issues - loopbacks due to bugs or
      misunderstandings.

      Alan Shalloway
      CEO, Net Objectives
      Achieving Enterprise and Team Agility

      > -----BEGIN PGP SIGNED MESSAGE-----
      > Hash: SHA1
      >
      > Cory Foy wrote:
      > |
      > | What makes you think they need more? Maybe the practices they have
      > | adopted have gotten them as agile as they need to be.
      >
      > The team is productive and was before the beginning of our Scrum
      > adoption efforts. However we are not even half way to execution of
      the
      > Scrum framework. No estimated product backlog, no team created
      sprint
      > backlog and many other pieces are not part of the team practice yet.
      >
      > We could decide that they are as agile as they need to be but we
      cannot
      > yet state that we have even tried Scrum.
      >
      > | Or do you see specific things that could possibly be helped by
      other
      > | agile practices?
      >
      > I see things! Oh yes, I see things that would be helped. This
      team and
      > the company could be so much more productive with all Scrum
      practices in
      > place. We are not done adopting yet.
      >
      > Alan
      >
      > -----BEGIN PGP SIGNATURE-----
      > Version: GnuPG v1.4.6 (GNU/Linux)
      > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
      >
      > iD8DBQFIlJ2IDQw/VSQuFZYRAnabAJ9JyB4FsjaT/sQ1BZEhgQRf2ciijwCdFLfR
      > tmDgzGO/aXIFp3SBisCwBiQ=
      > =A9Ia
      > -----END PGP SIGNATURE-----
      >
    • david.hicks_radtac
      Not sure if this will help but I have often found that people are less than enthusiastic about changing the way they work using an approach suggested by
      Message 31 of 31 , Aug 4, 2008
      • 0 Attachment
        Not sure if this will help but I have often found that people are
        less than enthusiastic about changing the way they work using an
        approach suggested by someone else - whether it be Scrum or any other
        new practice.

        In all circumstances I have tried to identify that person's goals -
        what they are truly trying to acheive in thier work, and what
        motivates them - and then help them to see how the new working
        practices can help them acheive those goals. If I can do this (and it
        is often difficult), then it always helps.

        --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...>
        wrote:
        >
        > -----BEGIN PGP SIGNED MESSAGE-----
        > Hash: SHA1
        >
        > Writing about this topic in my Scrum adoption journal, I seem to
        have
        > arrived at a conclusion that should work for me. However, the
        great and
        > MUCH more experienced minds here can help solidify my confidence.
        If I
        > may indulge, let me describe my thought train.
        >
        > Our Scrum adoption is going slowly but positively. I have
        attempted to
        > teach the team about Scrum and agile principles to allow them to
        select
        > which pieces they want to adopt as we go. This has worked well with
        our
        > starting adoption of minimizing team effort interruptions and
        meeting
        > interruptions.
        >
        > But we have stopped adopting and the team has not asked for
        anything more.
        >
        > They only have a single, one-hour presentation on the Scrum
        framework
        > and some written materials in their knowledge bank. I am confident
        that
        > they either don't know what to ask for or don't see the practical
        value
        > of specific practices.
        >
        > We still very much have a Team Lead providing command and control
        in the
        > most positive way possible. (Another place where a self-directed
        team
        > is not yet realized.) The Lead has stated two things the pushed me
        to
        > my conclusion, paraphrasing: "We don't need training. We already
        know
        > how to get the job done," and "Just tell us a practice to do and
        we'll
        > do it."
        >
        > Overcoming the lack of desire to receive instruction is a slightly
        > different topic that I'll choose to ignore at present. Focusing on
        the
        > second point, I did not want "command and control" the team in their
        > adoption of Scrum.
        >
        > Then I remembered an question and answer exchange during ScrumMaster
        > training. The question was "What is the usual way to introduce
        Scrum in
        > an organization?" Trainer Michael described a two-day kick off
        going
        > through introduction, exercises, creating a real backlog, sprint
        > planning and go.
        >
        > And it hit me. The described introduction process is "command and
        > control," of a sort. And that makes sense to me now. When
        learning a
        > new technique, the student must be told what to do and the real
        learning
        > is in the doing. Especially when learning Scrum, the learning, and
        > proving value, is definitely in the doing.
        >
        > I know, based on team desires and management reluctance to surrender
        > time for training, a multi-hour "immersion" or an attempt to change
        > everything all at once will not work in my situation. But, I think,
        > based on the Team Lead's desire to be told and an initial
        > "teacher/student" relationship, it safe for me as ScrumMaster to
        pick
        > practices that the team can learn by doing. Command in the most
        > self-directed team manner possible.
        >
        > Any thoughts or insights for me about my thinking here?
        >
        > Alan
        > -----BEGIN PGP SIGNATURE-----
        > Version: GnuPG v1.4.6 (GNU/Linux)
        > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
        >
        > iD8DBQFIk/PzDQw/VSQuFZYRAn67AJ9i8Cy9ZUH/0+KVNnhGLCWP2kAicgCfVC13
        > HY+uqIR/0xs8QcKz6Gs3RQI=
        > =33gh
        > -----END PGP SIGNATURE-----
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.