At a recent class a student asked me which role I would personally prefer to fill: product owner, ScrumMaster, or development team member. I have held each of these roles in the past, so that question gave me pause to consider how I really felt.
After some consideration I realized that although I have enjoyed and learned much in each of those roles, I do have a preference. I want to walk you through my thought process, explaining the appeal of each role for me, with the hope that it might help you in considering which role fits you best.
Development Team Member
I began my career in the 1980s as a software developer.
From the time when I gave up on the hope that I would be a professional baseball player (my original life plan) I was certain I wanted to be a software engineer.
At age 13, I was the first person in my high school to own a computer (TRS-80 Model I). From the day I got it I was hooked, and I knew this is what I wanted to do. All through high school I developed software, including the inventory management system for the Heathkit Electronics store where I worked in Plantation, Florida. I still remember the Corvis 10MB hard drive (the size of a large desktop scanner) walking down the table every time a long sort operation was executing. I learned a year later that bubble sort was not a good choice for this operation!
After high school I attended Georgia Tech, where I earned a BS in Computer Science, then I moved to Stanford, where I earned a MS in Computer Science. At this time I was working for ParcPlace Systems (a startup company spun off from the Xerox Palo Alto Research Center) to commercialize the Smalltalk development environment. At ParcPlace I was actively involved in development (1988 to 1992) using now-commonplace technical practices like code refactoring, continuous integration, unit testing, pair programming, and so on.
I really enjoyed those days. I can remember showing up first thing in the morning and next thing I knew it was 7pm. No meetings, no interruptions, just the pure joy of focusing on great technical work done in collaboration with some very smart colleagues.
At times I long to be back full time on a development team, but I don’t believe I’ll be filling that role until nearer to the end of my career. In the meantime, I’ll have to make do with the occasional stint as a developer of my own websites and mobile apps.
ScrumMaster
As I progressed in my career, I started to move into leadership roles, which over time moved me away from most of the hands-on development work. In these roles, I began to develop coaching skills. So it was natural for me to become a coach, and later a ScrumMaster, for numerous teams.
I personally find the ScrumMaster role fulfilling. Helping people solve their own problems brings me a lot of satisfaction. Coaching a team to embrace core agile principles and come up with their own approaches to the Scrum practices gives me a personal high. I get a thrill out of working with a group of people that slowly gel into a high-performance team. I am excited by the dynamics of the group work.
I realize, however, I still have more work to do before I truly become a world-class ScrumMaster (coach). A recent non-software example illustrated this to me. At my mother-in-law’s recent birthday event we decided to do a team (family) puzzle building activity. The puzzle we chose was a 1,000-piece puzzle of American Lighthouses. In hindsight, I realized that this was the most difficult puzzle I have ever worked on.
We started by dumping all of the pieces onto the table. I asked how we should start (good ScrumMasters ask questions), even though everyone knows that you do the borders first! A few people said they wanted to work on the borders and the others wanted to start creating islands of connected pieces to fill out the interior (there were eight people in total). So we self organized into sub-groups. So far, so good.
Then I lost my ScrumMaster mojo when I said, “Okay, we can’t get dinner until we finish the border.” Nobody complained about that; it seemed like other people felt getting the border done before dinner was also a good idea. However, as a ScrumMaster I shouldn’t have issued an edict. It would have been better to have said, “How important do you think it is for us to finish the border before we have dinner?” and then let the conversation among the team members evolve until they arrived at a decision. If I had done this, perhaps the team would have chosen a different outcome, e.g., the border people stay focused on the border and the island people go get dinner.
The good news is, we finally finished the puzzle at midnight, memorialized the moment with a picture (see below), and took our exhausted selves to bed.
The next day, though, as we were all discussing the puzzle exercise, my wife pointed out that I took a very “demanding” attitude during the activity!
The way I remember it, I did say several times: “Hey if you see any pieces that have numbers or location names, please give them to me so I can locate them in the picture and get them placed.” Apparently, however, I said it more like “Look for any pieces with a number or location name and give them to me.” My wife pointed out that I had not acted in a very ScrumMaster-like way. And I agreed. Ah, the good and the bad of having taught my family Scrum!
I often play the ScrumMaster (coach) role in many contexts. In fact, this might be the most frequent of the three Scrum roles that I have played over the past 10 years. A fair percentage of the work I do for companies is in a coaching capacity (both Scrum teams and executive teams) and I try very hard to apply effective ScrumMaster skills with them. But just because I tend to fill a coaching role most frequently doesn’t necessarily mean it’s the best-fit role for me, or the one that I prefer above all others.
Product Owner
That brings me to product owner. In many contexts this is my favorite role because it often can have the greatest impact on outcome measures. I enjoy being a developer and coach, but I love the broad financial impact I can make in the role of product owner.
Day to day I am the product owner of the several companies that I own and operate. I just love creating and refining a product backlog. I love interacting with stakeholders. I love trying to solve the right problem. I love to make a meaningful impact.
When I worked for IBM in the mid-1990s, my group of 130 people did about $25 million in revenue a year. One night I recall having a conversation with my wife when I had the epiphany that since my revenue number was included in IBM Global Services revenue (a number measured in billions), that I could double my group’s revenue and I would still be a rounding error to IBM. $25 million is nothing to sneeze at, but my group’s relative impact on the IBM bottom line was nil.
So, I am not talking about absolute impact, but relative impact. When I left IBM I worked with seven different startup companies (usually as an executive, e.g., CEO, COO, VP Strategy, VP Product Development, VP Marketing). I knew in those companies that after every day’s work I made a difference to that company. That is the type of energy I get from being in a product owner-type position!
Conclusion
So, I’ve enjoyed being a developer and I still do development, but I will not likely operate in a full-time developer role anytime soon. I frequently play the ScrumMaster role in many different contexts. I really like this role and it is a key piece of the services that I provide to companies. But, I am most fond of the product owner role because of its ability to have a real effect on the outcome measures of the group or company.
How about you? Do you have a preference for one role over the other? If so, leave a comment so we can discuss it!