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

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

Expand Messages
  • 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 1 of 5 , Oct 12, 2003
      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.
      -----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.