Skip to content

Paul Bae #Leadershipweek

November 3, 2009

This post was written by my friend Paul Bae for #leadershipweek. I want to thank Paul for taking the time to participate in this event. Paul’s website is under construction so follow him on Twitter here.

Fresh Perspectives for Project Management

Ever heard the term “Scrum”? It’s a formation used in the sport of rugby to restart play. But since I know absolutely nothing about rugby, I’d like to talk about another type of Scrum – this one from the software development world (they borrowed the name from rugby). Scrum is a team-based product development framework, or process-management methodology. It relies on strict guidelines and patterns to maximize cooperation and productivity, improve trust and teamwork, aid in time/resource management, and reduce conflict and confusion. Scrum is somewhat complex (or at least multi-faceted) so I’ll just focus on a few different aspects of it here. Why? Because organizations and team leaders can gain fresh perspective by looking at strategies and methodologies from industries that are vastly different from their own.


As a user-experience producer (and wannabe programmer), I’ve worked within the Scrum framework before and was pretty impressed with how it helped bring increased efficiency and focus to the product/project development team. Scrum can really streamline a complicated (and potentially chaotic) product development process by managing expectations, goals/timelines, and most importantly, roles. This post will focus on the roles, although the process definitions are fascinating — “sprints”, daily stand-ups, backlogs, sprint retrospectives, etc. (Sprints are predefined, repeatable iterations or work cycles that are typically 2-4 weeks each and highly specific to a set of goals. Once a sprint starts, you can’t add new tasks or change the scope. Isn’t that awesome?!?!)

So, back to those Scrum-defined roles… All 3 roles are essential to the process:

The TEAM is a small group of people who do the actual work, including analysis, design, implementation, testing, etc. Generally, you’re talking about 3-7 people. They can be from different departments, but each person brings the skills and knowledge to do the actual work (design, develop, test, etc) and accomplish whatever the project needs may be.

The PRODUCT OWNER represents the stakeholders (customers) and shapes and communicates the overall vision for the project to the team. The Product Owner defines the features of the product and sets the priorities according the customer’s needs/desires. They are usually the person that makes the budgetary and final go/no-go decisions.

The SCRUM MASTER is a “servant leader” to the team and it is this person’s job to facilitate scrum. The Scrum Master can be (but is often not) the leader of the team, but works outside of that team to help them deliver their goals. They are responsible for eliminating distractions to the Team, enforcing the Scrum rules, shielding the Team from external interferences, and making sure that they have what they need to succeed in each “sprint”. Think of this person as a “buffer” and process evangelist. (Think about that for a sec… “Process Evangelist” — so important, yet so many organizations lack them)

Your organization probably has individuals or roles that match up in many ways to these Scrum roles. But the interesting thing about Scrum that makes it unique, and arguably more effective, is that the roles are (for the most part) mutually exclusive. In fact, it’s almost MORE important what each role does NOT do. This aspect of Scrum really helps to reduce conflict and confusion. For example:
* The Product Owner does not do any actual development work – that’s the Teams’ job.
* The Team carries out the actual work, but can NOT change the focus of the project or the specific goal(s) of each sprint — that’s been laid out by the Product Owner.
* Only the members of the Team are empowered to make the daily decisions regarding how the work will be carried out.
* The Product Owner or Scrum Master cannot make any daily decisions regarding how the work will be carried out. The Team is entrusted with those daily decisions and tasks.
* The Scrum Master focuses on eliminating outside distractions and whatever impediments that may arise.
* The Team is not allowed to focus on impediments that arise from changing conditions, customer requirements, etc.

Now, those points may seem really obvious. After all, that’s why each job has a specific job-description in your organization, right? But how many times has the “Product Owner” in your organization micromanaged a particular facet of a team’s work sprint? How many of your “Team” members have been distracted by the changing needs of a “customer” and attempted to directly address them? If there is a role in your organization akin to a “Scrum Master,” has that person ever misinterpreted or augmented the vision, albeit ever-so-slightly?

The beauty of Scrum is that strict adherence to these roles limits conflict, increases trust, forces better communication, requires thorough evaluation, and demands realistic goals and expectations. For software development, Scrum is almost crucial for teams to stay focused in the midst of potential conflict, distractions and chaos created by rapidly changing circumstances and evolving market/customer needs.

Even if your “customers” are not as demanding as Apple’s iPhone users awaiting the next software update or bug fix, having guidelines or a team-based methodology that better define roles and processes may be helpful.

* If your project life cycles are long and constantly changing, try adhering to short “sprints” that have hyper-focused goals/tasks.

* If your organization already has well defined roles in place, trust each role and then give each person the freedom to do what they do best.

* If you are the type of person that has many talents and consequently gets involved in every aspect of a project, try setting limits for yourself (within any one particular project) and allow other people to blossom in their roles.  Just make sure that the expectations are laid out clearly beforehand.

Sometimes the best way to support other team members is to set really specific guidelines and then stay out of their way!

2 Comments leave one →
  1. November 3, 2009 8:10 pm

    I have to say that I LOVE the connection between Scrum Master and Servant Leader. I think that whole concept really nails what a servant leader can truly be to an organization, especially since they are so rare.

  2. Benjamin Davis permalink*
    November 4, 2009 1:25 am

    Good stuff Paul! I have never thought of a team working like this before.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: