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

SCRUM Project Tracking

Expand Messages
  • Jeff Sutherland
    I ve looked at at many different approaches to documenting and tracking a SCRUM project in five companies. The most difficult problem is getting 100% developer
    Message 1 of 7 , Jul 23, 2002

      I've looked at at many different approaches to documenting and tracking a SCRUM project in five companies. The most difficult problem is getting 100% developer adoption of a tracking system that totally automates the process. Some basic principles have evolved:

       

      1. Developers must use an application they already use anyway. They will not readily adopt a new user interface or a new task.
      2. Update of the backlog must take less than 60 seconds per day per developer.
      3. Reporting on project status (project administration) must take less than 10 minutes a day.

       

      For the first time, I have gotten this to work by adding a few fields to our bug tracking system. My view is that you must use whatever bug tracking system the developers are already using.

       

      At PatientKeeper we use open source GNATS. We added only a few fields - milestone (typically a sprint), type of task (development change as opposed to bug), days of initial estimate, time invested, estimate percent complete.

       

      We have thousands of tasks with hundreds active on any one day. The system automatically calculates estimate updates in real time based on latest entry to the system. Developers cannot change the original estimate (we want to track how good they are at estimating). So we can get real time project status.

       

      In the morning I have emailed to me summaries for key milestones that show longtitudinal data in a *.cvs file. I open it with Excel and print out a burndown chart.

       

      I can also access the complete database from Excel and can do a pivot table on any attributes, i.e. can slice and dice whatever anyone wants to know. Typically, it takes me about 10 minutes to make up a high level chart and then a table breakdown by developer with days remaining for each developer (along with task details if needed). I send these out to the entire development team so everyone sees everyday the global picture. The team then self organizes to shift work around to balance the backlog to drive the burndown chart to zero on the target date.

       

      This is a huge win for the organization and I would not want to live without it. We can do it for any number of projects and any number of tasks in real time so a single person can easily manage multiple projects in his or her spare time.

       

      I use the same charts and graphs at code complete when the code moves into QA, except then all tracking is by bug count, rather than days remaining. Code moves through a development cycle like shifting gears in a sports car with this approach.

       

      Jeff Sutherland

    • Laurent Bossavit
      ... I d gotten the impression that there was a teensy bit more to managing than that.
      Message 2 of 7 , Jul 23, 2002
        > We can do it for any number of projects and any number of tasks in
        > real time so a single person can easily manage multiple projects in his
        > or her spare time.

        I'd gotten the impression that there was a teensy bit more to managing than
        that.
      • jsutherland
        This comment is a great foil for posing the question, What does a manager do who is responsible for multiple SCRUMS? Project management I view as unnecessary
        Message 3 of 7 , Jul 24, 2002
          This comment is a great foil for posing the question, "What does a
          manager do who is responsible for multiple SCRUMS?"

          Project management I view as unnecessary overhead. We don't want any
          people dedicated to this task. However, project tracking is a
          necessary evil. The executive team must know the state of all
          projects at all times, and resource needs must be addressed, and
          resource bottlenecks visible from the project tracking system must be
          eliminated quickly. So SCRUM project tracking should be like CISCO's
          financial system (actually better). Books can be closed in real time
          any time.

          Managers are responsible for selecting the SCRUM leader, setting the
          boundaries, providing the resources, and eliminating roadblocks. The
          SCRUM is a self-managing team if it functions properly. It will
          deliver roadblocks to the manager and expect the manager to perform
          his assigned taaks - get rid of the roadblocks! If a manager is not
          able to do that, s/he is typically not very welcome at a SCRUM
          meeting.

          In my current company, I sit in two SCRUMS which meet daily but do
          not run them. They are run by the SCRUM leaders picked for the task.
          The development SCRUM has given me the project adminstration job
          (since they felt I was the expert, not because I was the manager)
          which I do in my spare time. For this task, the SCRUM manages me.
          They have insisted it be extremely efficient and the the user
          interface be effortless. I have made it so.

          I run two longer term SCRUMS that meet less frequently - the security
          team, and the performance benchmark team. I ensure a weekly product
          management SCRUM is on track which includes all company directors. I
          spend an inordinate amount of time in executive meetings. And as much
          as I am able, I am on the road helping the sales guys do a technical
          close on major accounts.

          These are all "management tasks" that take a lot of time. Project
          management in the traditional sense I do out of my back pocket. If it
          is not cutting code, guiding company technical strategy, or closing
          deals, I don't want to spend time on it.

          This is a radically different notion of management and one of the
          revolutionary features of SCRUM that enables the process to generate
          functioning teams every time (on rare occassions, it is necessary to
          quickly dissolve a team that is obviously not going to work), and
          high performance teams at a much higher rate than anything else I
          have seen.

          It takes a lot of education of management teams at a company for them
          to understand SCRUM because they must give up some of their power in
          return for getting guaranteed delivery of a product in a reasonable
          time frame.

          Jeff Sutherland

          --- In scrumdevelopment@y..., "Laurent Bossavit" <laurent@b...> wrote:
          > > We can do it for any number of projects and any number of tasks in
          > > real time so a single person can easily manage multiple projects
          in his
          > > or her spare time.
          >
          > I'd gotten the impression that there was a teensy bit more to
          managing than
          > that.
        • Laurent Bossavit
          ... Thanks for clearing that up. I have one colleague who s inordinately attached to his skills with Excel, charting et coetera - and whom I ve never known to
          Message 4 of 7 , Jul 24, 2002
            > These are all "management tasks" that take a lot of time. Project
            > management in the traditional sense I do out of my back pocket.

            :)

            Thanks for clearing that up. I have one colleague who's inordinately
            attached to his skills with Excel, charting et coetera - and whom
            I've never known to be other than "too busy" for more than one
            tracking meeting every two weeks. Which doesn't keep him from
            assigning tasks at the meetings.

            He's the guy who was assigned to replace me as project lead on a
            project where I'd disrupted the normal routine by encouraging people
            to raise "roadblock" issues with management. No risk of that
            afterwards - he was already "managing" four other projects.

            If we ever work together again after the bankruptcy proceedings are
            over and done with, I think some of the perspective gained from the
            Scrum will come in handy in our discussions. Mike & Ken's book was in
            my last Amazon shipment.

            Cheers,

            -[Morendil]-
            Press Ctrl-Alt-Del to continue
          • Mike Cohn
            Great points, Jeff. I think you ve pretty well covered the normal project management tasks that still exist on Scrum projects but I actually think there are a
            Message 5 of 7 , Jul 24, 2002

              Great points, Jeff.  I think you’ve pretty well covered the normal project management tasks that still exist on Scrum projects but I actually think there are a few other ways that a project manager contributes, some of which take time. For example:

               

              --Scrum teams work best when working toward a shared vision. Given time and some direction the team will evolve toward a shared vision; however, without some occasional taps in the right direction from someone more in touch with broader company goals this shared vision isn’t always the right shared vision. I have seen teams go off on visions where they make wrong decisions about speed vs. quality or choose incorrectly between sex-appeal features and under-the-covers performance, etc. Frequently the project manager has insights into the rest of the company that the team members don’t. This may the “guiding technical strategy” you refer to but I think it’s a bit broader.

               

              --I’ve never been part of a Scrum team where the team could actually take disciplinary action or hire or fire. The team can ostracize people but that usually leaves them on the payroll but with nothing to do. You mentioned to me once about your teams (I suspect at IDX) and how a team could banish a team member and he had a month or so to find himself a new team. I thought that was a great idea and one I plan to use. But everywhere I’m familiar with still has some HR-related hassles involved with actually firing someone: document the poor performance, warn the person, give him 38 more chances to improve, etc. Teams aren’t really comfortable with that and I don’t really think that type of dirty work should be done by the team for their sake and that of the poor performing employee.

               

              --I find that management time still gets spent on budgeting and forecasting. When I need to prepare a budget for an organization I always do the first draft and then send it by at least a few on the various teams but their involvement may be 1-2 hours. For complicated budgets (I’m thinking of a Fortune 40 company here) I probably spent 100 hours on the operating and capital budgets. That’s a big chunk of time.

               

              --Most companies of any size still have some politics and the project manager is the best person to insulate the team from that. I’ve seen teams that were doing well (not necessarily using Scrum but the projects were moving along as well as if they had been) have their projects cancelled out from them for political reasons. If the project manager pays attention to how his project is perceived and perhaps does some PR in the group about the upcoming benefits to make sure everyone remembers them then projects are less likely to be cancelled. I’d hesitate to say I’m advocating that a project manager “play politics” but there is usually some time well-spent making sure the team’s efforts are understood. As an example, I’m thinking of a reporting group that I shifted to Scrum. They had a horrible reputation as being slow and unresponsive at generating ad hoc reports various people in the company requested. As part of the status reporting I had them prepare a single page that went to the CEO weekly and then later monthly that showed their average response time and the number of reports they were running daily. The numbers were phenomenal. They were killing trees by the hour and were pretty responsive. Perception of the group turned around over a few months. If I hadn’t publicized what they were doing and how well (and in some areas how poorly) they were doing the group or at least its key people would have almost certainly been axed.

               

              So—I completely agree with your premise that much of traditional project management goes away. And I find that Scrum leaves me more time to do other things (I’ll pass on the customer sales calls and stick to the coding whenever possible myself, though!). But, there are still some things that require a project manager.

               

              --Mike

               

              -----Original Message-----
              From: jsutherland [mailto:jeff.sutherland@...]
              Sent: Wednesday, July 24, 2002 5:59 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Re: SCRUM Project Tracking

               

              This comment is a great foil for posing the question, "What does a
              manager do who is responsible for multiple SCRUMS?"

              Project management I view as unnecessary overhead. We don't want any
              people dedicated to this task. However, project tracking is a
              necessary evil. The executive team must know the state of all
              projects at all times, and resource needs must be addressed, and
              resource bottlenecks visible from the project tracking system must be
              eliminated quickly. So SCRUM project tracking should be like CISCO's
              financial system (actually better). Books can be closed in real time
              any time.

              Managers are responsible for selecting the SCRUM leader, setting the
              boundaries, providing the resources, and eliminating roadblocks. The
              SCRUM is a self-managing team if it functions properly. It will
              deliver roadblocks to the manager and expect the manager to perform
              his assigned taaks - get rid of the roadblocks! If a manager is not
              able to do that, s/he is typically not very welcome at a SCRUM
              meeting.

              In my current company, I sit in two SCRUMS which meet daily but do
              not run them. They are run by the SCRUM leaders picked for the task.
              The development SCRUM has given me the project adminstration job
              (since they felt I was the expert, not because I was the manager)
              which I do in my spare time. For this task, the SCRUM manages me.
              They have insisted it be extremely efficient and the the user
              interface be effortless. I have made it so.

              I run two longer term SCRUMS that meet less frequently - the security
              team, and the performance benchmark team. I ensure a weekly product
              management SCRUM is on track which includes all company directors. I
              spend an inordinate amount of time in executive meetings. And as much
              as I am able, I am on the road helping the sales guys do a technical
              close on major accounts.

              These are all "management tasks" that take a lot of time. Project
              management in the traditional sense I do out of my back pocket. If it
              is not cutting code, guiding company technical strategy, or closing
              deals, I don't want to spend time on it.

              This is a radically different notion of management and one of the
              revolutionary features of SCRUM that enables the process to generate
              functioning teams every time (on rare occassions, it is necessary to
              quickly dissolve a team that is obviously not going to work), and
              high performance teams at a much higher rate than anything else I
              have seen.

              It takes a lot of education of management teams at a company for them
              to understand SCRUM because they must give up some of their power in
              return for getting guaranteed delivery of a product in a reasonable
              time frame.

              Jeff Sutherland
               

            • Jeff Sutherland
              Mike, Good points. Comments are below. Jeff Sutherland ... Message: 4 Date: Wed, 24 Jul 2002 19:50:35 -0600 From: Mike Cohn
              Message 6 of 7 , Jul 25, 2002

                Mike,

                Good points. Comments are below.

                 

                Jeff Sutherland

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

                Message: 4

                   Date: Wed, 24 Jul 2002 19:50:35 -0600

                   From: "Mike Cohn" <mike@...>

                Subject: RE: Re: SCRUM Project Tracking

                 

                Great points, Jeff.  I think you've pretty well covered the normal project management tasks that still exist on Scrum projects but I actually think there are a few other ways that a project manager contributes, some of which take time. For example:

                 

                --Scrum teams work best when working toward a shared vision. Given time and some direction the team will evolve toward a shared vision; however, without some occasional taps in the right direction from someone more in touch with broader company goals this shared vision isn't always the right shared vision. I have seen teams go off on visions where they make wrong decisions about speed vs. quality or choose incorrectly between sex-appeal features and under-the-covers performance, etc. Frequently the project manager has insights into the rest of the company that the team members don't. This may the "guiding technical strategy" you refer to but I think it's a bit broader.

                 

                 (js) This is one of the reasons I sit in the SCRUM. "Taps in the right direction" is the way to describe it.

                 

                --I've never been part of a Scrum team where the team could actually take disciplinary action or hire or fire. The team can ostracize people but that usually leaves them on the payroll but with nothing to do. You mentioned to me once about your teams (I suspect at IDX) and how a team could banish a team member and he had a month or so to find himself a new team. I thought that was a great idea and one I plan to use. But everywhere I'm familiar with still has some HR-related hassles involved with actually firing someone: document the poor performance, warn the person, give him 38 more chances to improve, etc. Teams aren't really comfortable with that and I don't really think that type of dirty work should be done by the team for their sake and that of the poor performing employee.

                 

                 (js) The main development SCRUM is led by my Director of Engineering. He has hiring and firing authority. He codes half the time and manages half time. I agree this is not the usual case.

                 

                --I find that management time still gets spent on budgeting and forecasting. When I need to prepare a budget for an organization I always do the first draft and then send it by at least a few on the various teams but their involvement may be 1-2 hours. For complicated budgets (I'm thinking of a Fortune 40 company here) I probably spent 100 hours on the operating and capital budgets. That's a big chunk of time.

                 

                (js) I had to do the same in a big company. In a startup, I drive that into the hands of the product managers. They develop the business plan, the requirements, and work with the developers to estimate the pieces. When they have the pieces, they prioritize the backlog for releases. This then is submitted to the senior management team as the plan. I strongly believe this would make a big company far more effective if they could do this. Usually, the inordinate beaurocracy and political maneuvering make this impossible. Dell seems to work more product management driven and that is why they kick butt everywhere.

                 

                --Most companies of any size still have some politics and the project manager is the best person to insulate the team from that. I've seen teams that were doing well (not necessarily using Scrum but the projects were moving along as well as if they had been) have their projects cancelled out from them for political reasons. If the project manager pays attention to how his project is perceived and perhaps does some PR in the group about the upcoming benefits to make sure everyone remembers them then projects are less likely to be cancelled. I'd hesitate to say I'm advocating that a project manager "play politics" but there is usually some time well-spent making sure the team's efforts are understood. As an example, I'm thinking of a reporting group that I shifted to Scrum. They had a horrible reputation as being slow and unresponsive at generating ad hoc reports various people in the company requested. As part of the status reporting I had them prepare a single page that went to the CEO weekly and then later monthly that showed their average response time and the number of reports they were running daily. The numbers were phenomenal. They were killing trees by the hour and were pretty responsive. Perception of the group turned around over a few months. If I hadn't publicized what they were doing and how well (and in some areas how poorly) they were doing the group or at least its key people would have almost certainly been axed.

                 

                (js) Managing the politics and keeping it out of the SCRUM is a top priority management task. I view this as a key roadblock to be removed by management. A well functioning SCRUM will insist that managers take care of this properly and keep them advised. The SCRUM would do well to manage the manager is this regard. Occassionally the SCRUM will start generating their own politics and if the SCRUM leader cannot eliminate it, the manager needs to step in.

                 

                So-I completely agree with your premise that much of traditional project management goes away. And I find that Scrum leaves me more time to do other things (I'll pass on the customer sales calls and stick to the coding whenever possible myself, though!). But, there are still some things that require a project manager.

                 

                 

                 

                --Mike

                 

                 

              • Ulrich Winter
                Jeff, ... I found that this is one of the hardest jobs if you want to switch to scrum. Furthermore if you are doing projects for customers, convincing them to
                Message 7 of 7 , Jul 26, 2002
                  Jeff,

                  > It takes a lot of education of management teams at a company for them
                  > to understand SCRUM because they must give up some of their power in
                  > return for getting guaranteed delivery of a product in a reasonable
                  > time frame.

                  I found that this is one of the hardest jobs if you want to switch to scrum.
                  Furthermore if you are doing projects for customers, convincing them
                  to let the team manage itself is almost impossible especially if the
                  customer is from the public sector.

                  Uli Winter
                Your message has been successfully submitted and would be delivered to recipients shortly.