Making the leap from Project Manager to Scrum Master

So you've gotten your certification from PMI as a certified Project Management Professional (PMP) but the world starts to change around you. Something new is on the horizon called agile software development and it's moving fast. Everywhere around you people are talking about it, it routinely shows up in job descriptions, and you feel woefully unprepared. First, don't panic. Today agile SDLC is gaining mind share among software professionals but in practice you still find waterfall SDLC deeply rooted. Even organizations that say they are doing agile are trying XP, Lean, or Scrum on a trial basis and often with a heavy overtone of waterfall processes.

Whew, you've still got time to prepare. So you ask yourself, how do I prepare myself for Agile SDLC. Fortunately there are courses you can take, books and blogs to read to get you better acquainted with this process. I recommend you start by reading blogs and books, it's by far the cheapest way to get an introduction. Attending a local meeting of an agile SIG can also introduce you to the terminology and ideas. I attend a local group that meets monthly to discuss a variety of agile topics. Everyone is welcome and there are no dumb questions.

One thing you need to be prepared for are some of the bigger differences between Waterfall and Agile. In Waterfall you don't do anything until all of the preparation is complete (MRD, PRD, Functional Specs, Technical Specs, Design Documents, Test Plans, Release Plans, and finally a schedule); in Agile (Scrum in this example) you follow the agile manifesto principles which value conversation over documentation and working software over a well written plan. I've heard agile documentation referred to as "Just in time documentation", meaning you don't write it unless it's absolutely needed. On my teams we often do this on a wiki to keep the information easy to access and easy to update by anyone on the team.

I've just scratched the surface on some of the differences between Project Manager and Scrum Master. More later.

Scrum with an absent Product Owner

What is scrum? Scrum is a set of principles/activities that allows a group to coordinate actions and deliverables so that something useful is delivered (has business value) when finished. It's also an agile process for delivering software.

Scrum to many is just a word that can conjure images either of complete anarchy or nirvana depending on your understanding of it. Scrum is successful when all involved coordinate based on roles on the team. You have your pigs and chickens as roles; you have your team member, scrum master and product owner roles as well. As team member on the team my role is to produce output that in it's entirety has business value. As a scrum master my role is to ensure the team meets daily, identify and remove impediments, and act as the liaison to the Product Owner. As the Product Owner I'm the one ultimately responsible for delivering business value to my stakeholders.

What happens to the team if the product owner role isn't filled or even worse has someone who only takes that responsibility semi seriously? For many teams they will overcome and in the short term be successful. Unfortunately in the long term they fail; mainly because they are focused on the sprint or next couple of sprints. There is no overall strategy or vision. A product owner who rarely shows up at daily standups or decides that attending the end of sprint review is optional for them is doing a dis-service to the team and ultimately to the company.

If you find yourself with an absent product owner I recommend taking action by talking to the product owner and letting them know the value that they add by being an active member of the team.