Interestingly, R&R does not always mean Rest and Relaxation! In
some cases, it can mean roles and responsibilities. And recently, I had a
chance to visit this concept in the most interesting way. You see, when you are
trying to change a system, you have to take into account the “built in” biases
that the current system has in place. Sometimes, even with the best intentions,
we forget that there ARE boundaries that can lead our analysis. I was reminded
about a very sad meeting I once attended…
A long time ago, in a client far far away, I was brought in
as the Scrum Master for a consulting team. The client needed a solution
delivered with solid practices, high quality, short timeline and “no budget
restrictions”. So, they brought “us” in. And, initially, they agreed to provide
a PM to support us with their process so we could “do” our Scrum –maybe teach
them a thing or two along the way.
Sadly, as is often the case, things started to immediately
change. Our project was high priority, but cost started to become an issue. The
USERS were in love with the team, particularly the UX part of the team, but IT
started to have a problem with our “execution”. This was because we were asking
hard questions, some that had not been asked for months. This, along with our
delivery to commitment started to make people uncomfortable. In addition to
this, throw in layoffs and a massive change in direction in IT, and well – you
have all the ingredients for a recipe that does not end well.
In the midst of this chaos, our team continued on, and we
were able to deliver a healthy first demo. By this time, the project had just
been pared down by IT – to the chagrin of the business users. It made us all
awkward, and was rapidly followed by the request that we provide our own PM
support for the project. It just so happened that I had a few years experience
as a PM, and was able to jump on and start providing what they needed. Within
this framework, and because the liked what I was doing (getting a PM as a
bonus) they decided to invite me to their PMO sessions. As a special guest and
Agile adviser.
This was a solid milestone for me, because I already knew
that PM work is not well appreciated in most organizations. In addition, I knew
some of the structural issues they had to deal with – including the budget. I
also knew that every PM had more than one project under their responsibility.
This was a special meeting, the CIO was to show up and “rally the troops”. What
he did was awesome – in every measure of the word.
The new CIO introduced himself to the team, and mentioned
how important project management was to the organization. He asked for
feedback, which the entire group was hesitant to provide. Finally, one of their
best PM’s spoke up – and asked for help with all the challenges they were
having. His response was measured and calculated. In a nutshell, he listened
attentively and told them something like this: “In my neighborhood, I have a
person that picks up the trash twice a week. I live in a nice neighborhood, and
things are expected to be clean and tidy. We pay our dues and have a reasonable
expectation that we do not notice our trash service. If I have to talk to the
garbage man, you can bet something has gone terribly wrong. Project Management
is like this to an organization. When I do not have to speak to you, I know
things are going well. And as you can see, I am having to speak to you today”
The silence was stunning. Grown men were twitching, women were squirming – they
all got the message loud and clear. He then insisted that the goal of the PMO
was to reduce all projects by cost and timeline with a positive change of 10%.
And he asked what they thought.
The PM who spoke up was crying – in rage. She basically
asked if he had any ideas of the load that they and the teams were carrying,
and if he could suggest ways that his goal could be accomplished. At this, I
checked out.
To me, this was brutally horrible. I do not think I could
muster the guts or idiocy to address a team the way this man did. But it was
done. And I was reminded recently of this horrible exchange with something much
less insidious. At a recent meeting, another leader wanted to show how this new
organization was supporting the PM community. The presentation was positive,
pleasant really. When the value of the PM role was brought up the feeling
ceased to be innocuous. In their assessment PM’s, in a best case analysis are
considered “overhead” because in terms of delivery, they are not in the “front
line” of the actual development team. The leader who brought this up did so
almost apologetically, but still – the weight of the message certainly felt the
same.
I have been a good PM. And I have been a good SM. I think I
may have posted about the developer who asked me “why he should buy into this
agile thing”. The answer to him that mattered was that in Scrum, he had a voice
– a place – within the project and the delivery. For him, that was enough,
because in his entire career he had always felt like a cog in the wheel. We all
want to matter; we all desire to be a part of the solution. And I often get the
question (especially by my PM and ex Dev Scrum Masters) about the differences
between being a PM and being an SM. This is an interesting question, and I
answer to the best of my ability and experience. But the answer is not really
that relevant – because the question belies the real issue. We all want to
MATTER, we all want to FIT. And many of our organizational structures work
against this. Sometimes without leaders even being aware of it.
