Agile and Scrum Certification

Scrum is a framework that allows for effective facilitation and management of more complex, dynamic, or undefined projects. The framework harnesses the knowledge of essential and cross-cutting project stakeholders. It keeps a team in continual communication, supporting iterative work and flexibility to address ongoing changes or new project discoveries. Scrum, which has become the de facto standard for helping teams find their own effective collaboration, was born out of the software development industry as an agile methodology to counter established waterfall-style project management processes. 

A Scrum approach works for all product and service industries. A Scrum team is led by a Product Owner who provides the vision and direction for a defined goal or outcome. A Scrum Master facilitates communication and Scrum team effectiveness. The development team (those responsible for actualizing parts of the project work) brings the work to life and gets things done. Process and product, service, and program work is reviewed regularly and incorporates improvements ongoing throughout the Scrum framework model. 

Every member of the Scrum Team plays the role of Team Member, but only one Team Member is held accountable to the Business for the Scrum Team’s success and the value of the Scrum Team’s results. That’s the Product Owner, or PO for short. And that accountability is a big thing, as it defines the PO as the formal leader of the team as far as the outside world is concerned. 

The PO is the Scrum Team’s eyes and ears to the outside world (the Stakeholders). They are the Scrum Team’s one point of formal contact, the conduit of information. Add to this that the PO has the Scrum Team’s back—which means that, in being held accountable for the Scrum Team’s results, the PO is consumed with making sure the Scrum Team is getting the proper feedback to make the right Product at the right pace. The PO spends a lot of time scoping the product, clarifying murky expectations, negotiating delivery dates, and making it all fit for the Scrum Team. 

We should also note that, although the word “owner” is in the title, the PO may not be the Product expert. The PO certainly has a lot of knowledge and skills, but the role is defined by accountability, not by product-specific skills. A good PO realizes there may be a wealth of smarts both inside and outside the Scrum Team—and they know how to leverage this for the good of both the Scrum Team and the product. 

While the PO is the eyes and ears toward the outside world, the Scrum Master’s eyes and ears are pointed decidedly inward in many ways. The Scrum Master (SM) is an informal leader worried about what’s going on internally within the Scrum Team and making sure that Scrum is being used correctly. 

The Scrum Master is a leader without managerial responsibilities as part facilitator, part influencer, and part expert. They are laser-focused on the health of the Scrum Team and the Scrum Team’s continuous improvement, especially when it comes to the Scrum Team’s use of Scrum. The Scrum Master does this by helping improve the Scrum Team behaviors and working relationships, removing stumbling blocks (called “impediments” in Scrum lingo), and dealing with constraints. 

Many people new to Scrum quickly understand getting to know their Scrum Master is essential to feeling grounded and productive. Because the Scrum Master is inward-looking, and the Product Owner is outward-facing, it is inappropriate for the same Team Member to play both the Product Owner and Scrum Master roles. 

The term “Development Team” represents the portion of the Scrum Team that is currently developing or creating the product—and this may, or may not, include the PO and SM. It is proper and often useful for the PO and SM to be on the Development Team, but they must always realize that their leadership roles come first. 

You can think of the Development Team a little like the Three Musketeers, operating by the motto, “all for one and one for all.” When Scrum is really working well, and Teams are performing at a high level, the Development Team acts in the Development Team’s best interest, with everyone doing their part to achieve a collective goal. Each member is held responsible for the Development Team’s Product Production. 

Unlike many work teams, Development Teams function on a level playing field. There are no specialized roles. It’s as straightforward as it sounds, and every Team Member is just that: a Team Member. Development Teams tend to be small, ideally around five people. However, at times a project may dictate a slightly larger group. Every Team Member shares the same primary goal of partnering with the other Team Members to deliver the right product to the best of their abilities. Every Team Member is invested in the same secondary goal to help avoid spinning its wheels and improve as a self-organizing, cross-functional group. 

• Business Owner: The three most critical external roles are a sort of triumvirate of Scrum. The external roles of Business Owner (BO), Stakeholder, and Subject Matter Expert (SME) maintain an important level of influence in the Scrum process through the PO. The BO also works with the PO to weigh in on the priority of future work in the Backlog, assist in altering the Release Plan if needed and help the PO better understand the needs of the Stakeholders. On an organizational level, the BO works closely with the Scrum Master to help alleviate organizational impediments that get in the way of the Scrum Team’s success. 
  
  
• Stakeholder: We can think about a Stakeholder as anyone who is invested in the project or the product. To this point, there are two types of Stakeholders: internal and external. Every Team member is an internal stakeholder but, for the sake of today’s journey, we will focus our attention on the external stakeholders (a.k.a. “The Big Kahunas”). 
  
  If it weren’t for the external Stakeholders, there wouldn’t be a Scrum Team producing a Product. There will always be many people interested in the Scrum Team’s Product; however, it’s only the Stakeholders who truly have a vested interest in the product. It’s important for the Scrum Team to recognize the Scrum “food chain” here and give the Stakeholders their props. It’s essential for the team to try their hardest to satisfy the Stakeholders’ needs and work with the PO and Scrum Master when things get in the way of realizing these needs. 
  
  
• Subject Matter Expert(s): As we’ve noted above, Scrum Teams are cross-functional groups who are knowledgeable about many things, but there may be times when the Scrum Team doesn’t know everything about everything it needs to know. And that’s why Scrum utilizes Subject Matter Experts (SMEs). SMEs bring something unique to the team that it doesn’t possess on their own. It could be technical knowledge, business knowledge, database expertise, or a host of other things that are needed to make the right product the right way. 
   
  A SME is a consultant in every sense of the word. They impart know-how to the Scrum Team and then walk away. There’s no accountability or responsibility, although there’s some risk associated with this. Despite the SME being full of critical expertise, they do not share the Scrum Team’s priorities and goals. Scrum Teams should follow some sage advice when using SMEs: try to treat them as part of your team, but remember and respect that they may have priorities that pull them in a different direction.