RE: [scrumdevelopment] Program/Project Office - Roadblocks to Agile
- 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
Subject: RE: [scrumdevelopment] Program/Project Office - Roadblocks to AgileMy 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-----When I first arrive to a consulting engagement and I'm introduced to
From: rwaltersiii [mailto:rusty.walters@...]
Sent: Thursday, October 09, 2003 12:09 PM
Subject: [scrumdevelopment] Program/Project Office - Roadblocks to Agile
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?
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.