From: James S. Fosdick,
PMP, CSP
If I had to pick one thing I’ve observed to create the
greatest
impediment to a successful application of agile principles it is the
failure of middle and senior management to grasp the idea of servant
leadership and/or accept it as a valid means to achieve success. The
following conversation actually occurred when I was coaching a company
and a new project manager was brought in to "whip things into shape"
(although they were in fine shape to begin with):
PM: How do you know what the developers are doing?
Me: They tell me and if I have a particular question I ask them.
That’s why I sit in an empty cube over on their side of the building
with them instead of in the PMO area.
PM: You don’t tell them what to do?
Me: No.
PM: Well then what the hell do you do all day?
Me: I remove any obstacles they encounter, enforce the process,
protect them from outside distraction, communicate to stakeholders and
senior management and basically do whatever the team needs me to do.
PM: [exasperated] Do you work for them or do they work for you?!?!?!?
Me: I work for them.
PM: [more exasperated] And you think that’s a good management
strategy?!?!?!?!?
Me: I know it is.
PM: [angry/condescending] Well you clearly don’t understand [this
company’s particular business]. This "agile" thing stops today…
After that conversation what ensued over the next several weeks was a
treat to watch. The PM came in and created a Microsoft Project Plan
detailed down to the hour which allocated each resource on the team to
a specific task. That "plan" was accurate for all of 5 minutes (as
such plans usually are) and development essentially came to a
screeching halt after more than a month of steady progress before the
PM "came to the rescue". The PM proceeded to run around browbeating
the development team members until the development manager basically
had her removed. At the end of it she never realized what she had done
and said that she was coming off the project because she was too busy.
Fortunately it was a fairly experienced team that was used to project
management derailing projects so they took it in stride and once she
was gone they got things going again.
I have seen that attitude throughout my career. I had difficulty
understanding it even when I was ostensibly a command and control PM
in a waterfall environment. I’ve always felt leaders should be serving
the people they lead and not the other way around. It’s one of the
first things I tell managers when implementing Scrum and yet a
majority, in my experience, don’t get it (or don’t want to get it).
From: Roy Morien
I’d like to add a couple of ‘amusing’ anecdotes to this discussion.
On an occasion, when I was a development contractor, I finished my
designated task about 2pm … instead of the planned 5pm that the
project manager had stipulated. Because I was being paid by the hour, I
decided not to go home early, but to get going on another programming
task, which I finished about 4pm. At that time, the project manager saw
me and asked me about the original task. When I said that I had
finished it, she said that I could go home, and tomorrow I could start
on the next task (which she had estimated a full day of development).
When I told her that I had also finished that too, she was actually
quite upset, and made it clear that this was not in her plan, and I
shouldn’t have done it, because her plan said I would do it tomorrow.
When I said, semi-jokingly, that I hadn’t wanted to lose 3 hours
contract pay, she made it plain, in no uncertain terms, that her plan,
and its effective implementation, was more important than my income
earning. Needless to say, I didn’t take any further tasks on on my own
initiative. I also didn’t stay with them very long after that.
Well, I must admit that I was also under a bit of a cloud there because
of another ‘unauthorised’ act. I was specialising in writing reports
using a particular report writer. A business area manager had been
sitting with me and watching me work on a couple of his reports.
He said that it seemed reasonably simple to use the report writer, and
asked if people in his business area could use it, and create their own
reports. When I said Yes, after some discussion I sold them a copy of
the r/writer. When the IT Department manager heard about this, he was
furious. He asked me, amongst other angry questions, if I had any idea
of the damage that I had now caused. When I said No, he was even more
angry. He demanded that I withdraw my invoice, retrieve the software
package, and never talk to the users directly again. He clearly saw
that putting any type of development ability in the hands of users was
highly damaging to the role of the IT Department. (Remember, the
r/writer could not update data, only retrieve data and present it).
And finally, an interesting little story from my university. A
colleague said "I don’t understand about this agile development; it
seems too simple".
