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

Request for input

Expand Messages
  • Mike Dwyer
    I am using SCRUM and Agile to support IT Operations and the Management of Release Software and would be very interested in hearing from anyone who is in a
    Message 1 of 7 , Aug 2, 2004
    • 0 Attachment

      I am using SCRUM and Agile to support IT Operations and the Management of Release Software and would be very interested in hearing from anyone who is in a similar place or has thoughts on this area.

       

      At the present time we have an “endless backlog generator” and a corresponding “endless SCRUM” that overlay our problem tracking system and helpdesk technical support and escalation process.  This approach, along with some changes in workload allocation to support it, have given us the ability to average less than 120 open problems out of a total population of 8000+ problems reported – over the past year.

       

       

      -----------------------------------------

      Mike Dwyer

      Program Manager – Information Technology

      StatusOne Health Systems

      One Research Drive

      Suite 301

      WestboroMA    01581

      1 508 948 6018

      This message is a PRIVATE and CONFIDENTIAL communication.

      If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you.

       

    • Jeff Sutherland
      Over the past four years at PatientKeeper we have implemented Real Time Scrum which is in effect, an endless Scrum. It is an useful for IT management as
      Message 2 of 7 , Aug 2, 2004
      • 0 Attachment
        Over the past four years at PatientKeeper we have implemented "Real
        Time Scrum" which is in effect, an endless Scrum. It is an useful
        for IT management as product release cycles.

        An Open Source GNATS bug tracking system has been modified to
        include all development tasks as well as bugs. It works so well that
        in over four years, we have never had to identify anyone as
        a "project manager." We have Product Managers who package sprints
        and Scrum Masters who execute them.

        Milestones are packages of software for delivery to multiple
        customers which include enhancements and bug fixes managed by a
        Product Steering Committee. The system undergoes emergent evolution
        as packages move it one direction or another. Architecture is driven
        by refactoring which is scheduled as part of sprints, or may be run
        over an extended period until a set of changes are ready to be
        injected into a sprint.

        The Product Steering Committee is essentially a Scrum of Scrums that
        decides on a weekly basis what should be in the packages. It
        includes every key member of management (including the CEO) and
        every key technical leader. Since a milestone package is a sprint,
        we dyamically change sprints on a weekly basis. When sprints are
        changed, running sprints are effectively killed and a new sprint is
        created with a new date.

        Complete stats on backlog by person, project, etc. are automatically
        created on a daily basis. Burndown charts can be automatically
        generated in real time for any ongoing sprint. Everything is
        completely transparent for anyone to see.

        Our installations and support staff have implemented a parallel
        system for customer issues. We have automated links between customer
        issues GNATS and the primary development GNATS system so customer
        issues that need software changes can be packaged along with
        development issues in a sprint.

        Right now I am working on uploading autogenerated sprint data into
        Microsoft Project so the Product Steering Committee can see real
        time GANT charts that show the effect of their decisions. Everything
        will be bottoms up. Their are no project managers creating any GANT
        charts. It is simply a visualization tool to sort our a complex
        hierarchy of ongoing sprints run in parallel.

        My view is that "Real Time Scrum" is the next level of agility to be
        used only when people have the basics of Scrum operating well. It
        moves the organization up the CMM ladder because Scrum permeates the
        organization up through senior management and all decisions are
        driven by real time Scrum data.

        Once a company moves to this level, there are no more discussions of
        whether things should be agile or not. Pulling the plug on "Real
        Time Scrum" means the entire company crashes and has to reboot.

        Jeff Sutherland


        --- In scrumdevelopment@yahoogroups.com, Mike Dwyer <mdwyer@s...>
        wrote:
        > I am using SCRUM and Agile to support IT Operations and the
        Management of
        > Release Software and would be very interested in hearing from
        anyone who is
        > in a similar place or has thoughts on this area.
        >
        >
        >
        > At the present time we have an "endless backlog generator" and a
        > corresponding "endless SCRUM" that overlay our problem tracking
        system and
        > helpdesk technical support and escalation process. This approach,
        along
        > with some changes in workload allocation to support it, have given
        us the
        > ability to average less than 120 open problems out of a total
        population of
        > 8000+ problems reported - over the past year.
      • Mike Dwyer
        Jeff: That is impressive! We are moving in similar ways, but given the focus on keeping our users working we began putting everything in a single repository.
        Message 3 of 7 , Aug 2, 2004
        • 0 Attachment

          Jeff:

          That is impressive!

          We are moving in similar ways, but given the focus on keeping our users working we began putting everything in a single repository.  Because of this focus we redefined our level 1 and level 2 support rules to include the ‘problem solver’ or the person who can fix the code.  I know this sounds like the edge of Chaos but we have built into everyone’s burn a certain portion of time and resources that are devoted to keeping our customers working.

           

          Interesting thing pops out of that.  Annoying repeat customer service calls often point to emerging systemic problems.

          -----------------------------------------

          Mike Dwyer

          Program Manager – Information Technology

          One Research Drive

          Suite 301

          WestboroMA    01581

          1 508 948 6018

          This message is a PRIVATE and CONFIDENTIAL communication.

          If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you.

          -----Original Message-----
          From:
          Jeff Sutherland [mailto:jeff.sutherland@...]
          Sent: Monday, August 02, 2004 5:13 PM
          To:
          scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: Request for input

           

          Over the past four years at PatientKeeper we have implemented "Real
          Time Scrum" which is in effect, an endless Scrum. It is an useful
          for IT management as product release cycles.

          An Open Source GNATS bug tracking system has been modified to
          include all development tasks as well as bugs. It works so well that
          in over four years, we have never had to identify anyone as
          a "project manager." We have Product Managers who package sprints
          and Scrum Masters who execute them.

          Milestones are packages of software for delivery to multiple
          customers which include enhancements and bug fixes managed by a
          Product Steering Committee. The system undergoes emergent evolution
          as packages move it one direction or another. Architecture is driven
          by refactoring which is scheduled as part of sprints, or may be run
          over an extended period until a set of changes are ready to be
          injected into a sprint.

          The Product Steering Committee is essentially a Scrum of Scrums that
          decides on a weekly basis what should be in the packages. It
          includes every key member of management (including the CEO) and
          every key technical leader. Since a milestone package is a sprint,
          we dyamically change sprints on a weekly basis. When sprints are
          changed, running sprints are effectively killed and a new sprint is
          created with a new date.

          Complete stats on backlog by person, project, etc. are automatically
          created on a daily basis. Burndown charts can be automatically
          generated in real time for any ongoing sprint. Everything is
          completely transparent for anyone to see.

          Our installations and support staff have implemented a parallel
          system for customer issues. We have automated links between customer
          issues GNATS and the primary development GNATS system so customer
          issues that need software changes can be packaged along with
          development issues in a sprint.

          Right now I am working on uploading autogenerated sprint data into
          Microsoft Project so the Product Steering Committee can see real
          time GANT charts that show the effect of their decisions. Everything
          will be bottoms up. Their are no project managers creating any GANT
          charts. It is simply a visualization tool to sort our a complex
          hierarchy of ongoing sprints run in parallel.

          My view is that "Real Time Scrum" is the next level of agility to be
          used only when people have the basics of Scrum operating well. It
          moves the organization up the CMM ladder because Scrum permeates the
          organization up through senior management and all decisions are
          driven by real time Scrum data.

          Once a company moves to this level, there are no more discussions of
          whether things should be agile or not. Pulling the plug on "Real
          Time Scrum" means the entire company crashes and has to reboot.

          Jeff Sutherland


          --- In scrumdevelopment@yahoogroups.com, Mike Dwyer <mdwyer@s...>
          wrote:
          > I am using SCRUM and Agile to support IT Operations and the
          Management of
          > Release Software and would be very interested in hearing from
          anyone who is
          > in a similar place or has thoughts on this area.
          >

          >
          > At the present time we have an "endless backlog generator" and a
          > corresponding "endless SCRUM" that overlay our problem tracking
          system and
          > helpdesk technical support and escalation process.  This approach,
          along
          > with some changes in workload allocation to support it, have given
          us the
          > ability to average less than 120 open problems out of a total
          population of
          > 8000+ problems reported - over the past year.




          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




        • Jens Østergaard
          Thank you Jeff, what a story. That was most interesting to read. I do however wonder how the members of the sprint teams feel? Peer pressure must be extremely
          Message 4 of 7 , Aug 3, 2004
          • 0 Attachment
            Thank you Jeff, what a story.
            That was most interesting to read.

            I do however wonder how the members of the sprint teams feel? Peer
            pressure must be extremely high.
            How much overtime do you have?
            I would wotty about sprint members burning out unless management
            respected the 40 hour week.

            Jens


            --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
            <jeff.sutherland@c...> wrote:
            > Over the past four years at PatientKeeper we have implemented "Real
            > Time Scrum" which is in effect, an endless Scrum. It is an useful
            > for IT management as product release cycles.
            >
            > An Open Source GNATS bug tracking system has been modified to
            > include all development tasks as well as bugs. It works so well
            that
            > in over four years, we have never had to identify anyone as
            > a "project manager." We have Product Managers who package sprints
            > and Scrum Masters who execute them.
            >
            > Milestones are packages of software for delivery to multiple
            > customers which include enhancements and bug fixes managed by a
            > Product Steering Committee. The system undergoes emergent evolution
            > as packages move it one direction or another. Architecture is
            driven
            > by refactoring which is scheduled as part of sprints, or may be run
            > over an extended period until a set of changes are ready to be
            > injected into a sprint.
            >
            > The Product Steering Committee is essentially a Scrum of Scrums
            that
            > decides on a weekly basis what should be in the packages. It
            > includes every key member of management (including the CEO) and
            > every key technical leader. Since a milestone package is a sprint,
            > we dyamically change sprints on a weekly basis. When sprints are
            > changed, running sprints are effectively killed and a new sprint is
            > created with a new date.
            >
            > Complete stats on backlog by person, project, etc. are
            automatically
            > created on a daily basis. Burndown charts can be automatically
            > generated in real time for any ongoing sprint. Everything is
            > completely transparent for anyone to see.
            >
            > Our installations and support staff have implemented a parallel
            > system for customer issues. We have automated links between
            customer
            > issues GNATS and the primary development GNATS system so customer
            > issues that need software changes can be packaged along with
            > development issues in a sprint.
            >
            > Right now I am working on uploading autogenerated sprint data into
            > Microsoft Project so the Product Steering Committee can see real
            > time GANT charts that show the effect of their decisions.
            Everything
            > will be bottoms up. Their are no project managers creating any GANT
            > charts. It is simply a visualization tool to sort our a complex
            > hierarchy of ongoing sprints run in parallel.
            >
            > My view is that "Real Time Scrum" is the next level of agility to
            be
            > used only when people have the basics of Scrum operating well. It
            > moves the organization up the CMM ladder because Scrum permeates
            the
            > organization up through senior management and all decisions are
            > driven by real time Scrum data.
            >
            > Once a company moves to this level, there are no more discussions
            of
            > whether things should be agile or not. Pulling the plug on "Real
            > Time Scrum" means the entire company crashes and has to reboot.
            >
            > Jeff Sutherland
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, Mike Dwyer <mdwyer@s...>
            > wrote:
            > > I am using SCRUM and Agile to support IT Operations and the
            > Management of
            > > Release Software and would be very interested in hearing from
            > anyone who is
            > > in a similar place or has thoughts on this area.
            > >
            > >
            > >
            > > At the present time we have an "endless backlog generator" and a
            > > corresponding "endless SCRUM" that overlay our problem tracking
            > system and
            > > helpdesk technical support and escalation process. This
            approach,
            > along
            > > with some changes in workload allocation to support it, have
            given
            > us the
            > > ability to average less than 120 open problems out of a total
            > population of
            > > 8000+ problems reported - over the past year.
          • Victor Szalvay
            ... Everything ... be ... the ... Fascinating ideas Jeff. This is essentially the context in which we use UML diagrams. UML is used to temporarily describe
            Message 5 of 7 , Aug 3, 2004
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
              <jeff.sutherland@c...> wrote:
              > ... snip ....
              >
              > Right now I am working on uploading autogenerated sprint data into
              > Microsoft Project so the Product Steering Committee can see real
              > time GANT charts that show the effect of their decisions.
              Everything
              > will be bottoms up. Their are no project managers creating any GANT
              > charts. It is simply a visualization tool to sort our a complex
              > hierarchy of ongoing sprints run in parallel.
              >
              > My view is that "Real Time Scrum" is the next level of agility to
              be
              > used only when people have the basics of Scrum operating well. It
              > moves the organization up the CMM ladder because Scrum permeates
              the
              > organization up through senior management and all decisions are
              > driven by real time Scrum data.
              >
              Fascinating ideas Jeff. This is essentially the context in which we
              use UML diagrams. UML is used to temporarily describe design ideas in
              flux systems that are too dynamic to "document" in a final sense. The
              empirical nature of (agile) software development drives the documents,
              not the other way around.

              -- Victor Szalvay
            • Boris Gloger
              Hi Victor, can you explain a bit more in which way you use the UML diagrams in flux way? I will be faced with the fact that I will need to architect a whole
              Message 6 of 7 , Aug 4, 2004
              • 0 Attachment
                Hi Victor, can you explain a bit more in which way you use the UML
                diagrams in flux way? I will be faced with the fact that I will need to
                architect a whole new application and I want to work as iterative as
                possible AND using UML diagrams. And I do not want to use FDD.

                cheers
                boris

                On 04.08.2004, at 02:02, Victor Szalvay wrote:

                > --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
                > <jeff.sutherland@c...> wrote:
                >> ... snip ....
                >>
                >> Right now I am working on uploading autogenerated sprint data into
                >> Microsoft Project so the Product Steering Committee can see real
                >> time GANT charts that show the effect of their decisions.
                > Everything
                >> will be bottoms up. Their are no project managers creating any GANT
                >> charts. It is simply a visualization tool to sort our a complex
                >> hierarchy of ongoing sprints run in parallel.
                >>
                >> My view is that "Real Time Scrum" is the next level of agility to
                > be
                >> used only when people have the basics of Scrum operating well. It
                >> moves the organization up the CMM ladder because Scrum permeates
                > the
                >> organization up through senior management and all decisions are
                >> driven by real time Scrum data.
                >>
                > Fascinating ideas Jeff. This is essentially the context in which we
                > use UML diagrams. UML is used to temporarily describe design ideas in
                > flux systems that are too dynamic to "document" in a final sense. The
                > empirical nature of (agile) software development drives the documents,
                > not the other way around.
                >
                > -- Victor Szalvay
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >

                ---------------------------------------------------
                Mag. Boris Gloger
                m.: +43.664.500.3436  
                Certified Scrum Master Practitioner and Trainer

                Visit my Scrum Tutorial @ euroCMG Vienna:
                http://www.cmg-ae.at/data/downloads/euroCMG2004.pdf
                Next Scrum Certification Class: 4. and 5.10.2004, Vienna
              • Victor Szalvay
                Sure Boris, but if your customer wants you to architect/design the entire app upfront I cannot be of any help. What I mean is that we never sit down and design
                Message 7 of 7 , Aug 4, 2004
                • 0 Attachment
                  Sure Boris, but if your customer wants you to architect/design the
                  entire app upfront I cannot be of any help.

                  What I mean is that we never sit down and design entire applications
                  upfront. Nor do we design entire iterations worth of features in one
                  sitting. Instead, when a pair needs to do some design they might use
                  UML to sketch out some ideas on a whiteboard, and as Jeff said they
                  can make decisions about those design ideas in real time and in light
                  of the true state of the code base. But designing is often closely
                  coupled to coding, so those diagrams almost never make it into some
                  "design document" because they are implemented and modified almost
                  immediately. The next day might bring some entirely new design ideas.

                  I do think the UML "back generation" tools are consistent with agile
                  though. We are often asked to deliver UML and "design docs" with our
                  work, so right before we have to deliver we take a "snapshot" of the
                  design using UML back generation (try a cheap(er) tool like Enterprise
                  Architect), and perhaps we add some notes to clarify things. But the
                  neat thing is that the empirical reality of the code is what drives
                  back generated diagrams, it wasn't some upfront diagrams that drove us
                  to code a certain way. Of course, as soon as we start working on the
                  code again the diagrams we delivered get stale, but at least the
                  delivered code was fairly well documented.

                  Hopefully this makes sense.
                  Best regards,

                  -- Victor Szalvay
                  Danube Technologies, Inc.
                  www.danube.com

                  --- In scrumdevelopment@yahoogroups.com, Boris Gloger <boris@g...> wrote:
                  > Hi Victor, can you explain a bit more in which way you use the UML
                  > diagrams in flux way? I will be faced with the fact that I will need to
                  > architect a whole new application and I want to work as iterative as
                  > possible AND using UML diagrams. And I do not want to use FDD.
                  >
                  > cheers
                  > boris
                  >
                  > On 04.08.2004, at 02:02, Victor Szalvay wrote:
                  > > Fascinating ideas Jeff. This is essentially the context in which we
                  > > use UML diagrams. UML is used to temporarily describe design ideas in
                  > > flux systems that are too dynamic to "document" in a final sense. The
                  > > empirical nature of (agile) software development drives the documents,
                  > > not the other way around.
                Your message has been successfully submitted and would be delivered to recipients shortly.