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!

Complex Systems

I'm reading Michael Crichton's last novel called Micro and I love the introduction. I'd like to post some of it here:

Perhaps the single most important lesson to be learned by direct experience is that the natural world, with all its elements and interconnections, represents a complex system and therefore we cannot understand it and we cannot predict its behavior. It is delusional to behave as if we can, as it would be delusional to behave as if we could predict the stock market, another complex system. If someone claims to predict what a stock will do in the coming days, we know that person is either a crook or a charlatan. If an environmentalist makes similar claims about the environment, or an ecosystem, we have not yet learned to see him as a false prophet or a fool.

Human beings interact with complex systems very successfully. We do it all the time. But we do it by managing them, not by claiming to understand them. Managers interact with the system: they do something, watch for the response, and then do something else in an effort to get the result they want. There is an endless iterative interaction that acknowledges we don't know for sure what the system will do--we have to wait and see. We may have a hunch we know what will happen. We may be right much of the time. But we are never certain. Interacting with the natural world, we are denied certainty. And always will be.

Legacy Software

Working at an investment bank is challenging. There's constant pressure to deliver, not screw up, reduce operational risk (which is the new buzzword that represents the same concepts that we've always been wanting less of), reduce TCO (another buzzword), etc. and of course to produce new software that helps the business do deals or reduce their manual workload.

Here are a few of the challenges:

• Maintaining Legacy Software and/or trying to Decomm Legacy software
• Satisfying audit & internal regulatory requirements that have little impact
• Hiring button pushers rather than smart people who can actually debug issues

I will address the first two points in this post & leave the last for another day.

We have tons of old, legacy software whose original developers have moved on. I'm talking about software that just runs and that is mostly a black box. We feed them (i.e., keep the lights on, reboot the servers on a routine basis, monitor them) so they keep running but occasionally they fail. That means I need to pull a developer who is working on a new project to resuscitate the old software. This is painful because the developer is not very familiar with this software and it takes time to figure things out. Users may be impacted and thus screaming and escalating to senior managers, so this adds to the pressure. Note that most if not all of this software was not constructed with the latest agile practices like TDD so there are no unit or integration tests to speak of, and the documents (if they even exist) are yellow & crusty.

Of course, making changes to this software is risky, because the developer could make a change that impacts another part of the software and break something else. And without a good suite of tests, how will you ever know? Given the time pressure to get this working again in production, we can't do adequate testing. So we release into production and hope for the best. And we document what we learned in a wiki or FAQ, so we can at least build our knowledge base (hopefully). Then we all context-switch back to our new software development.

This is an oft-repeated pattern in my group and I would not be surprised if this is universal. (or I would be surprised if this was NOT universal!) Additionally, morale slips because we lose time fixing old software, we disappoint both the users of the legacy software and the new users who are expecting their new software on time, etc. Developers become disappointed because they can't seem to get traction on the new software as well.

So as a general rule of thumb, we should try to minimize modifications to the legacy code-base. If you need to do it, then do it. But let's look at one 'need' in more detail; this brings me to the 2nd bullet point above: Satisfying audit & internal regulatory requirements that have little impact

I'm currently on a project to satisfy an internal audit point (not a government regulatory item) that requires me to modify a legacy piece of software (which by the way we are trying to decommission). This change, I'm finding is incredibly risky. One, it touches at least a dozen files across the board and the software is responsible for getting all kinds of data intra-day and End of day. Two, the developer is in Singapore whereas the rest of the team is in NY and so we can't even talk real-time about the changes. Three, there are other, new components that the legacy software will need to make use of and so may require a 3rd party to be available on stand-by. Taken all together, it would have been wiser to get an exemption for this.

Unfortunately, this comes back to the way I presented the problem to my manager. I hadn't thought through all the ramifications of the change. I only knew I didn't think it was in our best interests. But I went to my manager and all I said was "Look, we have this audit point but we want to decomm this software so do we really want to do this?" and he said, "Yes, we need to". So off, I marched.

My point is that I didn't have a strong enough view on the situation. At that moment in time, I only had a 'leaning' but not a clear enough picture of what the whole thing would entail. If I did, I could have possibly persuaded him that this wasn't in our best interests to do.

So what's the lesson here? When modifying legacy software, (1) get the scope of the change (how long it will take, impact assessment, how many files/modifications need to be made, etc), (2) assess overall risk, (3) if too risky, push back and make the case as persuasively as possible.

Audit points, regulatory risk, operational risk are big buzzwords that make people jump and immediately act but wait! not so fast...  (1) there could be abuse of those terms and they can be inappropriately applied, especially if there are other agendas involved like politics & (2) they should not all be treated equally. Some audit points just aren't as important as others and we need to really understand what's important and what's not. It's similar to taking something in the spirit of the law and not just going by verbiage. So if the risk to satisfy this point is riskier than not satisfying it, well, that should be taken into account. We shouldn't just blindly do it because that's what the audit point says. Let's have a conversation about it and negotiate.

So in writing this point and thinking further about this, what I will do is: re-examine the exact scope of the change, and if warranted, re-have the same conversation with my manager asking for an exemption. I'll fill him in on the exact risks and have him sign off on email if he still wants to proceed. That way, if there are issues, he can't say he didn't know about them. And I'll have done my due diligence.