In the beginning I was a coder. Then, suddenly one day, I found myself a Project Manager. Our PM had left unexpectedly and the call went out for a temporary replacement. I was the last one to bolt for the door, and so there I was: temporary Project Manager.
Several years and a project-management diploma later, temporary had become permanent. I was qualified. I had the diploma to prove it, and I had certifications, too. But there was one small problem: My projects never came out on time or on budget. As a relatively new and inexperienced project manager, I assumed the problem was me. I resolved to take more care with my schedules. Track progress more carefully. Make sure the team did its estimates correctly. Ensure requirements were locked down. Track my dependencies precisely. I followed the best-practice guidelines in the PMBOK (Guide to the Project Management Body of Knowledge) to the letter.
I spent hours crafting highly detailed schedules, analyzing estimates, and compiling huge lists of detailed requirements. The result? My projects still never finished on time or on budget. And I was spending my whole life fighting with requirements tracking tools and Gantt charts. I had some successes (or I wouldn't have had a job), but I couldn't produce results consistently. The harder I tried to follow best practice, the harder I worked, and the worse things seemed to get.
It was around then that I began to notice it wasn't just me. None of the other PMs I worked with could produce consistent results either. We were all using "best practice" but couldn't produce consistent results. Could it be that there was something wrong with "best practice"?
I went looking and found that there were project managers who did produce consistent results. On budget, on time, every time. How did they do it? I studied what these successful PMs did and learned from them. I learned that the key to success as a project manager is not schedule, or requirements, or estimates, or any of the things the PMBOK lists as important. What is important is people.
Successful project managers didn't worry about schedules. They worried about people. They set a clear vision for the project team and provided inspirational leadership to make sure the team was focused on the goal. They mentored and looked after their people. They made sure the team was protected from interruptions and that obstacles were cleared as quickly as possible. They made sure that lines of communication were open and that information flowed. I tried it, and it worked. I started to achieve results. I put aside my detailed schedules, my requirements tracking tools and estimation sheets. I focused on people.
Sound familiar? Sure enough, at around this point I discovered Agile and Scrum. Some reading and a CSM course later, and my transition from PM to ScrumMaster was complete. (On the inside, anyway; my business cards still said "Project Manager.")
One of the things I was told during my CSM course was that a project manager should not be the ScrumMaster. But here I was. The business called me a project manager, but the team called me ScrumMaster. Was this a problem?
Several reasons are given for why the PM should not be the ScrumMaster. The first is usually that the ScrumMaster isn't "the boss." This person should be a peer of the team, not above it. Project managers are bosses; ScrumMasters are peers.
Is this true, though? Normally, a project manager isn't the boss. Full responsibility with zero authority is usually the role of the PM. A good one works through influence, not command. This is similar to a good ScrumMaster.
The second reason project managers aren't supposed to be ScrumMasters is usually that the PM has a hierarchical, command-and-control mentality (in spite of his or her complete lack of real authority), while the ScrumMaster works with or for the team. For the majority of PMs I've worked with, and for myself early in my career, I agree. A project manager is focused on control, or the illusion of control — schedules, estimates, reports — and not on what makes a ScrumMaster a ScrumMaster. The mindset is completely different.
But is this really a problem with project managers? Should they automatically be excluded from being ScrumMasters? Project managers are taught to focus on hierarchy and control. It's a problem with their training, not necessarily with the project managers themselves. Remember those exceptional project managers I mentioned before? The inspirational leaders, the mentors, the communicators, the influencers? A truly successful project manager does everything a ScrumMaster does. What's on someone's business card doesn't matter. You can call them "Project Manager," "ScrumMaster," "Team Lead," "Person who gets stuff done," or whatever you like. What matters is what they do. Do they focus on control or collaboration? Do they focus on process or people? A ScrumMaster who focuses only on the Scrum process, at the expense of people (something I have been guilty of myself), is just as unlikely to succeed as a project manager who focuses on process over people.
Nowadays, my business card says things like "Agile Coach," and my job is to help companies improve their project delivery through Agile practices. Most of the time, the people who step forward as potential ScrumMasters are the current project managers. Do I consider that a problem? No. Not if they focus, or can learn to focus, on the right things. If they're already great project managers, they're already more than halfway there.
Editor's Note: Also see Tatyana Yanush's recent article, "Implementing Scrum: How Does the Project Manager Fit In?"