Monday, July 29, 2013
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.
Friday, July 12, 2013
I love fishing. And when I say this, different people understand it differently. Most assume I like to drink beer by a pier while reading a book. Some may think I like to go to the lake and spend some time in a boat. Others imagine I catch a lot of fish and cook them. But my friends that do go fishing usually ask a few more questions. Like, are you a cat or a bass man? Do you fly or bait cast? Have you tried noodling? These guys know that there is more to fishing than just what people imagine there is. And these guys know there is a huge difference between fishing and catching! More on that later…
Sunday, July 7, 2013
Last post, I was speaking to an old friend about the amount of work technical teams take on, and the negative impact to the overall effort. Our thoughts immediately went to leadership, but the reality is that most problems are complex and may need a separate approach. Just having experienced a painful team experience lesson, my thoughts went straight to how we see problems, and how as humans we try to solve them.