Thanks for the forward lunatech!
Defining a "project manager" role on a Scrum-based effort is a classic
superimposition of waterfall, process-heavy methods onto an Agile
methodology. Numerous problems ensue when that happens.
One of the leading tenets of Scrum is the concept of self-managing teams.
The Scrum master is charged as a facilitator bringing and maintaining
structure to the project and performing certain functions that a traditional
project manager would - such as conducting the daily Scrum, measuring and
reporting progress on the iteration and its backlog, current/next iteration
planning, and removing (or attempting to remove) external roadblocks getting
in the team's way. While these are also functions of a "traditional" PM, the
Scrum master is not charged with day-to-day management of the project team -
the team itself is.
The concept of self-managed-and-directed teams makes certain assumptions
about the team's composition, direction, and support:
- Since there is great emphasis regarding team communication and
collaboration, extreme personalities (i.e. self-righteous prima donnas and
the very timid or passive/aggressive) are usually not good fits on Scrum
teams.
- The continuous presence and direction of the product owner is critical.
This position is, generally speaking, not part-time.
- The team is dedicated to the project 100% or as close to that as possible.
In most cases where I've seen Scrum efforts fail to deliver, the team
members' time was too fragmented to get the worked scoped for an iteration
completed.
As I mentioned above, a major problem with the introduction of any Agile
method in an organization is the temptation, usually based on well-founded
previous experience, to superimpose traditional PM techniques or to
rationalize and graft them onto an Agile method. For example, I have
routinely stopped "traditional" PMs from attempts to plan all iterations and
activities in advance and convince them that in an Agile world, only the
current and next iterations are the ones that matter. This also flies in the
face of strategic planning and budgeting principles, but if the organization
wants the flexibility that Agile promises, they're going to have to come to
grips with a different way of managing the uncertainties. Some can, and some
can't - its a mixed bag so far.
Bob McIlree
I am a project manager. I informally introduced a few Scrum/Agile
concepts at my workplace without trying to introduce the whole concept
all at once. I've taken this approach for three reasons. First, not all
development projects are best served by this approach and I wanted to be
careful to pick projects where Agile fit the bill. Second, management in
my shop grew up under the waterfall model and wasn't about to give up
their comfortable methodology without one hell of a fight. Lastly, it's
easier to apologize later than it is to ask permission up front so I
pulled a Nike and "just did it."
On a short, time-boxed project with a small team that had a history of
working well together I did away with weekly status meetings and reports
in favor of the daily 3 question status call. I made the commitment that
we would deliver the product on time (in this case, 9 weeks from that
commitment) and actually managed to get away without offering delivery
dates on other waterfall deliverables (formal tech design docs, for
example). Then I pulled the bulk of the team together in a conference
room, explained that this was a "black" project plan, we were all going
to collaborate the way we knew was possible and we weren't going to let
our various managers get in our way.
The team loved the concept and got right to work. I published a schedule
in Microsoft Project with about 20 tasks comprising 4 deliverables
(developed software, tested software, relevent documentation and
software in production). I got lucky in that nobody questioned why the
first three were all to be delivered on the same date. It seems that as
long as there was a published plan and we me the date at the end of the
plan, few cared what was actually in the plan. Shows how many people
actually read project schedules, doesn't it?
My sponsor loved the daily status calls. My team loved the feeling that
we all knew what was going on at all times. I loved not having to
explain either why we were behind schedule or why, since we were on
schedule we couldn't accelerate the schedule some more. We had two
sprints (being very careful not to call them that in public) with one
adjustment (called "scope adjustment day," the only day where anyone was
allowed to alter the project scope, even the sponsor). We delivered the
finished product on the day we promised. We delivered all the required
elements and 2 of 3 "nice to have" items. The product has been in
production 4 months now. It cost us about $85,000 to build and implement
and has already demonstrated savings of over $400,000.
Nobody knew we weren't doing it "by the book" until after we were done.
There was a lot of squawking when I started spreading the word about the
new way of doing development, but when I could show that I knew what the
strengths and weaknesses of these techniques were and that I knew how to
apply them successfully, the noise died down quickly.
Nothing succeeds like success, and I now have carte blanche to use all
the agile techniques I want on future projects. It may not work for
everyone, but it worked for me. Paul Neuhardt