Product Owner in Scrum = Project Manager!

I became a CSM last week: Certified ScrumMaster after taking a thoroughly enjoyable course over the weekend. I read my first book on Agile and scrum back in 2007 and have taken a number of courses since then. I also got a PMP along the way. However, this was simply the best course ever! Check out www.beardedeagle.com for their excellent training.

One of the things the trainer said that got me immediately stirred up was that in many cases the closest analogy for the Product Owner in scrum is the project manager in traditional style of project management. (There is no role of project manager in scrum). This got me really thinking as I always believed that the product owner would be someone from the business side (bringing this into the Wall Street Banking IT arena). I could not for the life of me envision a senior manager in Product Control, Front Office, Operations, etc taking Scrum training and playing by the rules of Scrum (Perhaps I shouldn't be so pessimistic about it, but if you work in Investment Banking IT, you'll probably see my point). So I had determined that Scrum wouldn't really work well in my environment and that I would have to continue to act as traditional project manager and use a modified scrum-like methodology.

But lo and behold, the Product Owner = Project Manager solved the problem for me! And it makes perfect sense. The traditional project manager is the one that has to manage the stakeholders, assess the priorities, etc. That makes for a perfect product owner! And now under this light, it all seems work-able now. Of course, in some instances I'll have to play dual role of Product Owner & Scrum Master (which is dangerous as it's a bit too powerful) but I have some room now to empower my colleagues in running our projects. I can give the role of Scrum Master to one of my Analysts and have him work with the Dev team to accomplish our goals while I can step back and concentrate on other things.

Tools, tools and more tools

I've been having some thoughts about tools in the project management biz. I actually embarked on writing a specification for a new project management tool: one that would be the 'right' way to manage projects. I was even trying it out on a live project I am doing. The first few 'rules' I was using to manage the project (rules that would eventually become requirements in the software implementation of the tool) seemed to work well.
I became so enamored with the idea that I called an MBA friend of mine and told him of my idea and how this tool would revolutionize project management and that we should do a startup!

Shortly afterwards, I happened to look up project management tools online and discovered that they were a dime a dozen! There's just so many tools out there it's unbelievable. It would be extremely difficult to differentiate my tool from one of the many that already exist. But this wasn't a dealbreaker. Perhaps my tool would just be so incredible that it would out-shine the competition.

But as the project moved forward, I had to keep developing more intricate rules to take care of each case. It went well at first but after a while, it became cumbersome. In fact it became downright unwieldy. It dawned on me at some point that what I was developing when I was creating these rules was actually a philosophy or style of project management, not a tool. The tool didn't matter; in fact, I could use any tool (even MS Project as it's so darn customizable) and adapt it to my needs.

The over-reliance of tools to 'get the job done' is a joke. A tool can't get any job done. It's just a tool. There needs to be an intelligence behind the tool and how it's used. Namely, that's you or me: a sentient human being who is actually using the tool for a purpose.

That's one of the reasons many agile methodologies don't prescribe tools; Whiteboards are the favored means of communication. One level from that is Excel, which happens to be my favorite tool (also Word & Outlook). In the Project Management biz, communication is king and these tools all do the job quite handily.

In fact, I constantly create & abandon tools all the time! For example, I created a spreadsheet to track my own projects back in 2012. When new management came in 2013, and the style of reporting was changed, I realized my internal spreadsheet I was using wasn't fit for purpose. I wholesale abandoned it and created another one that would enable me to report on the relevant state of my projects. The lesson is: Don't get married to your tools and force-fit them. The need to *communicate* first and foremost is paramount.

I won over a difficult stakeholder across the pond by abandoning tools. When a fresh year started, he wanted me to represent my projects in a spreadsheet he liked (even though the group as a whole mandated another way, which led me to maintain two spreadsheets representing similar information). It got cumbersome and eventually I wasn't able to complete these in a timely manner. I then resorted to straight updates on e-mail: these were very focused and to the point and *relevant*. I figured I needed to get him the information one way or another and b/c of bandwidth limitations, plain bullet items in e-mail was fastest. He thanked me for the great updates and I knew I had a winner. I completely stopped filling out a spreadsheet for him (which I doubt he looked at anyway) and continued with bi-weekly updates over email. He even spoke about what a great job I was doing to my own managers!

A key point here is: What was important one week may not be as important the next week. Blindly filling in spreadsheet templates with boring, non-relevant details (just to get it over with) every week will make your stakeholders deaf, dumb and blind to your needs. [This harks back to my previous point about a sentient human being actually using the tool for a purpose]. You need to focus attention on what is important in that reporting time period. A rule of thumb: if you don't know what is important, then if it's important to YOU, that makes it important. And then of course there's listening: people will tell you what is important. Note it down, capture it in the actions, put someone down as owner and track it. And of course deliver on your actions.

Another tool that I've found quite useful is the depiction of scheduling of projects. It has been previously difficult to look ahead to see when projects will end and when others can start. Typically, people might use a Gantt chart for this (and I did) but I stumbled on quite a nice way to represent on-going projects that are being run in parallel across my group and show this to the exact number of weeks. It looks quite nice and I can share it with stakeholders to easily grasp where we are. [I roll off past weeks simply by deleting rows on top]. The flexibility of Excel makes it easy to play around with the best ways to deliver information (not just data!) and give a picture. If you rely on one prescribed tool (like say, a big portfolio management tool your company may have purchased) and only use that, you'll put your stakeholders to sleep!