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

RE: [scrumdevelopment] Program/Project Office - Roadblocks to Agi le

Expand Messages
  • Tony Homer
    My group has been developing an Office of Project Management for a year or so now. A common reaction to ongoing delayed, over-budget or failed projects is to
    Message 1 of 5 , Oct 9, 2003
    • 0 Attachment
      My group has been developing an Office of Project Management for a year or so now.  A common reaction to ongoing delayed, over-budget or failed projects is to decide that whatever we're doing now must be failing because we aren't trying hard enough, so we need to try harder.  At least in my case, I believe that was the thinking...
       
      I think that the problem here is that in a traditional hierarchical business structure, there is always a chain of accountability.  In other words, SOMEONE is responsible to review all the work that is being done.  In software development, this frequently results in a loss of productivity due to the project lead/software manager/project manager becoming a bottleneck for the rest of the team, for a number of reasons.  First and foremost, that person frequently performs some degree of business analysis.  Consequently, they are less available to the team (because a significant amount of their time is consumed with attending meetings) due to an operational practice that required the team to have more access to them in order to gain the information required to be productive.  This is sometimes referred to as "shielding the team from unnecessary administrative tasks."  Second, how can one person possibly review all the work that a whole team of developers is doing?  In many cases, the development team takes the specification from the manager and fleshes out the details significantly.  This is the nature of the work: the stakeholders generally have an intuitive grasp of the required processes/hopes/dreams/whatever, but are not able to fully articulate them in a requirements gathering meeting.  The developers are burdened with filling in the details (often incorrectly) and the manager is accountable for the "mistakes" the development team made.  Obviously the problem here is that the team lead needs more time to get involved in the work of the team and ensure that they are not deviating from the specification.  How can we make that happen?  Free up the team lead's time by removing some of the tedious administrative responsibilities that are consuming his time.  After all, maintaining gantt charts is a very time-consuming process.  Adjusting schedules based on poor estimates (estimates that are made based on incomplete specs, in this case) is a time-consuming process.  Anyway, I think that if you consider the necessary dynamics of a traditional hierarchical business organization or especially a small organization that has grown into a larger one without evolving it's operational practices, the emergence of a group whose purpose is to increase the resource management bandwidth is almost a given.  This group gives executives an objective reference for how resources are being expended, something that the team lead(s) can't really provide due to time contraints.
       
      Anyway, I've been considering this issue of how PMOs seem almost emergent from a traditional waterfall approach to software development, but obviously my thoughts are still not clearly defined.
       
      As to what to do about them, you could try to educate them about alternatives to waterfall.  I bought multiple copies of the Scrum book and handed it out to the PMs and Directors in my organization.  I've been sending them introductory articles on Scrum and XP.  Involve them in daily scrums and sprint planning sessions.  Expose them to an iterative process that is low ceremony and high productivity.  Maybe you'll be able to win their hearts and minds.
       
      Tony Homer
       
      -----Original Message-----
      From: rwaltersiii [mailto:rusty.walters@...]
      Sent: Thursday, October 09, 2003 12:09 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Program/Project Office - Roadblocks to Agile

      When I first arrive to a consulting engagement and I'm introduced to
      the leaders of the Program and/or Project Office organization, I
      immediately hear the "sproing" sound of red flags going up.  In my
      experience, the existence of either of these groups is an indication
      of a long, hard struggle with helping an organization change to agile
      methods, or even if it is possible.

      I'm always amazed at the number of companies, which are usually large
      organizations, who have one or both of these departments.  I have no
      idea the origin of these concepts, but they must of done a great job
      in selling them, because so many organizations seem to have bought
      into the concept.  My guess is Management so desperately wants to
      hear the sales pitch on how the departments will define how programs
      and projects are defined and managed in a predictable fashion....blah
      blah...blah that they jump on the band-wagon.

      I'm curious as to the experiences others have had with companies who
      have either of these departments in trying to assist in the
      transition to agile methods.  Do you recommend disolving these
      departments?  Leave them intact, but try to change what they
      profess?  Work on a pilot project that by-passes the departments and
      let the results speak for themselves?

      Rusty Walters
    • ross_w_taylor
      This is an interesting topic to me because I have recently moved to a PMO inside our internal IS organization. To put this in perspective, my responsibilities
      Message 2 of 5 , Oct 9, 2003
      • 0 Attachment
        This is an interesting topic to me because I have recently moved to a
        PMO inside our internal IS organization. To put this in perspective,
        my responsibilities for the last year and a half have included
        introducing agile delivery practice into our internal application-
        development projects (this is over 20 projects of various sizes).

        My new responsibilities include continuing that work but I now have
        an extended mandate that includes the delivery approach used in IT
        infrastructure projects. I am fairly certain that the IT
        infrastructure projects will be able to benefit from the empirical
        process perspective of scrum and, potentially, from lean development
        (or at least lean thinking) though I do not have personally
        experience with lean, yet.

        So, if I can kick in my two bits worth, I would say I don't
        understand the immediate connection made between a project office and
        ineffective delivery methods. The leaders in my IS organization
        value the success we have had with Agile and they want to see this
        success extended to other none-app-development projects.

        Here is an interesting finding. According to CIO magazine the top
        reasons to establish a PMO are improved project success rates,
        standard practices and lower cost. The impact of "standard
        methodology" in terms of strategic impact is second only to "projects
        linked to company strategic and operating plans" (I am never going to
        argue with that being most important!). In terms of financial
        impact, "standard methodology" is number 1, by 56%, in the financial
        impact category.

        So you might ask why am I bringing up CIO magazine results on
        standard methodology?. Well because nothing says a PMO has to
        promote a bad method. In my organization we have had success using
        Scrum / XP hybrids. We will continue to promote agile delivery as
        long as we get success from the use of the approach.

        So, it may be that you have had bad experiences with IS PMOs in other
        organizations, but I would say it is not necessarily that PMOs are
        bad.

        Cheers,
        Ross Taylor

        --- In scrumdevelopment@yahoogroups.com, Tony Homer <tony_homer@s...>
        wrote:
        > My group has been developing an Office of Project Management for a
        year or so now. ...

        > -----Original Message-----
        > From: rwaltersiii [mailto:rusty.walters@e...]
        > Sent: Thursday, October 09, 2003 12:09 PM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] Program/Project Office - Roadblocks to
        Agile
        >
        > When I first arrive to a consulting engagement and I'm introduced
        to the leaders of the Program and/or Project Office organization,
        I ...
      • rwaltersiii
        Good point, I m glad to hear of your success. My experience has been that most organizationations with PMOs are still using and pushing heavy, sequential
        Message 3 of 5 , Oct 9, 2003
        • 0 Attachment
          Good point, I'm glad to hear of your success. My experience has been
          that most organizationations with PMOs are still using and pushing
          heavy, sequential methods.

          It sounds as though your success is based on adopting agile methods
          one project at a time, and letting the results speak for themselves.
          And thus, the organization requesting you become a member of the PMO
          so that your influence can be spread throughout the organization.

          Do you think the change in the organization could have been
          accomplished any-other way?

          Rusty Walters


          --- In scrumdevelopment@yahoogroups.com, "ross_w_taylor"
          <ross_taylor@t...> wrote:
          > This is an interesting topic to me because I have recently moved to a
          > PMO inside our internal IS organization. To put this in perspective,
          > my responsibilities for the last year and a half have included
          > introducing agile delivery practice into our internal application-
          > development projects (this is over 20 projects of various sizes).
          >
          > My new responsibilities include continuing that work but I now have
          > an extended mandate that includes the delivery approach used in IT
          > infrastructure projects. I am fairly certain that the IT
          > infrastructure projects will be able to benefit from the empirical
          > process perspective of scrum and, potentially, from lean development
          > (or at least lean thinking) though I do not have personally
          > experience with lean, yet.
          >
          > So, if I can kick in my two bits worth, I would say I don't
          > understand the immediate connection made between a project office and
          > ineffective delivery methods. The leaders in my IS organization
          > value the success we have had with Agile and they want to see this
          > success extended to other none-app-development projects.
          >
          > Here is an interesting finding. According to CIO magazine the top
          > reasons to establish a PMO are improved project success rates,
          > standard practices and lower cost. The impact of "standard
          > methodology" in terms of strategic impact is second only to "projects
          > linked to company strategic and operating plans" (I am never going to
          > argue with that being most important!). In terms of financial
          > impact, "standard methodology" is number 1, by 56%, in the financial
          > impact category.
          >
          > So you might ask why am I bringing up CIO magazine results on
          > standard methodology?. Well because nothing says a PMO has to
          > promote a bad method. In my organization we have had success using
          > Scrum / XP hybrids. We will continue to promote agile delivery as
          > long as we get success from the use of the approach.
          >
          > So, it may be that you have had bad experiences with IS PMOs in other
          > organizations, but I would say it is not necessarily that PMOs are
          > bad.
          >
          > Cheers,
          > Ross Taylor
          >
          > --- In scrumdevelopment@yahoogroups.com, Tony Homer <tony_homer@s...>
          > wrote:
          > > My group has been developing an Office of Project Management for a
          > year or so now. ...
          >
          > > -----Original Message-----
          > > From: rwaltersiii [mailto:rusty.walters@e...]
          > > Sent: Thursday, October 09, 2003 12:09 PM
          > > To: scrumdevelopment@yahoogroups.com
          > > Subject: [scrumdevelopment] Program/Project Office - Roadblocks to
          > Agile
          > >
          > > When I first arrive to a consulting engagement and I'm introduced
          > to the leaders of the Program and/or Project Office organization,
          > I ...
        • rwaltersiii
          few more things...could you elaborate on how you were able to utilize agile methods when you started to get the first projects going? What where the selling
          Message 4 of 5 , Oct 9, 2003
          • 0 Attachment
            few more things...could you elaborate on how you were able to utilize
            agile methods when you started to get the first projects going? What
            where the selling points to management to allow it? Did you run up
            against stiff resistance from the PMO initially? I'm assuming the
            existing practices, and the ones the PMO were advocating did not work
            well, and thus the reason you were evangalizing agile?

            Thanks,

            Rusty Walters

            --- In scrumdevelopment@yahoogroups.com, "ross_w_taylor"
            <ross_taylor@t...> wrote:
            > This is an interesting topic to me because I have recently moved to a
            > PMO inside our internal IS organization. To put this in perspective,
            > my responsibilities for the last year and a half have included
            > introducing agile delivery practice into our internal application-
            > development projects (this is over 20 projects of various sizes).
            >
            > My new responsibilities include continuing that work but I now have
            > an extended mandate that includes the delivery approach used in IT
            > infrastructure projects. I am fairly certain that the IT
            > infrastructure projects will be able to benefit from the empirical
            > process perspective of scrum and, potentially, from lean development
            > (or at least lean thinking) though I do not have personally
            > experience with lean, yet.
            >
            > So, if I can kick in my two bits worth, I would say I don't
            > understand the immediate connection made between a project office and
            > ineffective delivery methods. The leaders in my IS organization
            > value the success we have had with Agile and they want to see this
            > success extended to other none-app-development projects.
            >
            > Here is an interesting finding. According to CIO magazine the top
            > reasons to establish a PMO are improved project success rates,
            > standard practices and lower cost. The impact of "standard
            > methodology" in terms of strategic impact is second only to "projects
            > linked to company strategic and operating plans" (I am never going to
            > argue with that being most important!). In terms of financial
            > impact, "standard methodology" is number 1, by 56%, in the financial
            > impact category.
            >
            > So you might ask why am I bringing up CIO magazine results on
            > standard methodology?. Well because nothing says a PMO has to
            > promote a bad method. In my organization we have had success using
            > Scrum / XP hybrids. We will continue to promote agile delivery as
            > long as we get success from the use of the approach.
            >
            > So, it may be that you have had bad experiences with IS PMOs in other
            > organizations, but I would say it is not necessarily that PMOs are
            > bad.
            >
            > Cheers,
            > Ross Taylor
            >
            > --- In scrumdevelopment@yahoogroups.com, Tony Homer <tony_homer@s...>
            > wrote:
            > > My group has been developing an Office of Project Management for a
            > year or so now. ...
            >
            > > -----Original Message-----
            > > From: rwaltersiii [mailto:rusty.walters@e...]
            > > Sent: Thursday, October 09, 2003 12:09 PM
            > > To: scrumdevelopment@yahoogroups.com
            > > Subject: [scrumdevelopment] Program/Project Office - Roadblocks to
            > Agile
            > >
            > > When I first arrive to a consulting engagement and I'm introduced
            > to the leaders of the Program and/or Project Office organization,
            > I ...
          • Ken Schwaber
            Yes, Scrum certainly throws a wrench in these gearworks by saying that the Product Owner is responsible for reviewing the work and the Team is responsible for
            Message 5 of 5 , Oct 12, 2003
            • 0 Attachment
              Yes, Scrum certainly throws a wrench in these gearworks by saying that the Product Owner is responsible for reviewing the work and the Team is responsible for the quality and quantity of it. A difficult implementation issue for those using Scrum is what to do with the rest of these managers who until this date have added cost but not value.
              Ken
              -----Original Message-----
              From: Tony Homer [mailto:tony_homer@...]
              Sent: Thursday, October 09, 2003 2:24 PM
              To: 'scrumdevelopment@yahoogroups.com'
              Subject: RE: [scrumdevelopment] Program/Project Office - Roadblocks to Agile

              My group has been developing an Office of Project Management for a year or so now.  A common reaction to ongoing delayed, over-budget or failed projects is to decide that whatever we're doing now must be failing because we aren't trying hard enough, so we need to try harder.  At least in my case, I believe that was the thinking...
               
              I think that the problem here is that in a traditional hierarchical business structure, there is always a chain of accountability.  In other words, SOMEONE is responsible to review all the work that is being done.  In software development, this frequently results in a loss of productivity due to the project lead/software manager/project manager becoming a bottleneck for the rest of the team, for a number of reasons.  First and foremost, that person frequently performs some degree of business analysis.  Consequently, they are less available to the team (because a significant amount of their time is consumed with attending meetings) due to an operational practice that required the team to have more access to them in order to gain the information required to be productive.  This is sometimes referred to as "shielding the team from unnecessary administrative tasks."  Second, how can one person possibly review all the work that a whole team of developers is doing?  In many cases, the development team takes the specification from the manager and fleshes out the details significantly.  This is the nature of the work: the stakeholders generally have an intuitive grasp of the required processes/hopes/dreams/whatever, but are not able to fully articulate them in a requirements gathering meeting.  The developers are burdened with filling in the details (often incorrectly) and the manager is accountable for the "mistakes" the development team made.  Obviously the problem here is that the team lead needs more time to get involved in the work of the team and ensure that they are not deviating from the specification.  How can we make that happen?  Free up the team lead's time by removing some of the tedious administrative responsibilities that are consuming his time.  After all, maintaining gantt charts is a very time-consuming process.  Adjusting schedules based on poor estimates (estimates that are made based on incomplete specs, in this case) is a time-consuming process.  Anyway, I think that if you consider the necessary dynamics of a traditional hierarchical business organization or especially a small organization that has grown into a larger one without evolving it's operational practices, the emergence of a group whose purpose is to increase the resource management bandwidth is almost a given.  This group gives executives an objective reference for how resources are being expended, something that the team lead(s) can't really provide due to time contraints.
               
              Anyway, I've been considering this issue of how PMOs seem almost emergent from a traditional waterfall approach to software development, but obviously my thoughts are still not clearly defined.
               
              As to what to do about them, you could try to educate them about alternatives to waterfall.  I bought multiple copies of the Scrum book and handed it out to the PMs and Directors in my organization.  I've been sending them introductory articles on Scrum and XP.  Involve them in daily scrums and sprint planning sessions.  Expose them to an iterative process that is low ceremony and high productivity.  Maybe you'll be able to win their hearts and minds.
               
              Tony Homer
               
              -----Original Message-----
              From: rwaltersiii [mailto:rusty.walters@...]
              Sent: Thursday, October 09, 2003 12:09 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Program/Project Office - Roadblocks to Agile

              When I first arrive to a consulting engagement and I'm introduced to
              the leaders of the Program and/or Project Office organization, I
              immediately hear the "sproing" sound of red flags going up.  In my
              experience, the existence of either of these groups is an indication
              of a long, hard struggle with helping an organization change to agile
              methods, or even if it is possible.

              I'm always amazed at the number of companies, which are usually large
              organizations, who have one or both of these departments.  I have no
              idea the origin of these concepts, but they must of done a great job
              in selling them, because so many organizations seem to have bought
              into the concept.  My guess is Management so desperately wants to
              hear the sales pitch on how the departments will define how programs
              and projects are defined and managed in a predictable fashion....blah
              blah...blah that they jump on the band-wagon.

              I'm curious as to the experiences others have had with companies who
              have either of these departments in trying to assist in the
              transition to agile methods.  Do you recommend disolving these
              departments?  Leave them intact, but try to change what they
              profess?  Work on a pilot project that by-passes the departments and
              let the results speak for themselves?

              Rusty Walters


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


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            Your message has been successfully submitted and would be delivered to recipients shortly.