More with LeSS: Who's on the Scrum Development Team?

In the first two posts in this series, we explored how to identify the product and how to identify the Product Owner. If you missed these tips, check them out HERE.

Now let’s say you have effectively identified both the Product and the Product Owner. How do you identify the Development Team? Or in the case of BIG products, which this series is focused on, how do you identify multiple Development Teams?

Regardless of the development type - Product Development, Internal Product Development or Project Development - with Scrum, the Development Team characteristics as described in the Scrum Guide remain the same:

• Are self-organizing. No one (not even the Scrum Master) tells the Development Team hot to turn a Product Backlog into increments of potentially releasable functionality

• Are cross-functional, with all the skills as a team necessary to create a product increment

• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole

If Identifying Product was Skipped:

Scrum adoptions are rarely effective if identifying the Product was skipped and what is happening is an attempt to make Scrum fit into existing structure or the status quo.  Scrum is about changing the status quo. It potentially requires structure change in order to effectively optimize for delivery of working product.

As an example, if the structure of the organization has people segregated by specialized, singular activities such as analysis, building, testing, architecture, etc. those are component teams. The component team structure not only requires hand offs, late integration which increases risk, it structurally does not enable delivery of value to the customer the way a cross-functional feature team can. If the organization is still using project management with component teams, it’s rare that any members of component teams are 100% dedicated to one project. Typically, people are assigned to multiple projects to execute the one, specialized skill so that instead, they appear to be 100% “utilized”. This divides their attention, is less productive due to context-switching between projects and is a cost drain.

Like Scrum, Large Scale Scrum or LeSS, requires the teams to be cross-functional possessing all of the necessary skills to deliver a customer-centric feature or features in any given sprint (analysis, programming, testing, database work, etc.). Team members are 100% dedicated so there is focus on value and no loss of productivity due to time-slicing. Although people may initially have a special skill, Scrum and LeSS teams are multi-learning teams. People are willing to learn other skills and work together to deliver value.  An illustration from https://less.works/ comparing component teams to feature teams:

Because there’s always new features, maintenance or items that come back to the team via feedback loops, these teams are also long-lived. Customer centric features from the Product Backlog are broken down into items on the Sprint Backlog that the cross-functional, self-organizing feature team delivers in a sprint. Identifying Product at the beginning of the adoption makes it pretty simple to identify all of the skills that will be needed in order to achieve this. Each of these feature teams is made up of a minimum of 3 people with a maximum of 9 people per team.

How many cross functional feature teams are needed may be determined based on the needs of the Product itself or budget. In a LeSS adoption, the upper limit for the number of teams is 8. In really BIG product scenarios, LeSS Huge may be adopted which involved more than 8 teams. For more information on LeSS Huge teams please visit:  https://less.works/

To learn more from Large Scale Scrum (LeSS) co-creator, Craig Larman, and to earn a Certified LeSS Practitioner credential register HERE.

What is a ScrumMaster?

In a recent Certified ScrumMaster (CSM) course, a student new to Scrum was a bit confused by the repeated reference to the ScrumMaster as a “coach”.  “What do you mean coaching or when does this coaching happen?” was the question raised. Caught a bit off guard, or more importantly caught up in my own internal dialog of, “Well, doesn’t everyone who comes to a CSM already know this?” For a moment I was a bit dumbfounded. Then I realized that this is the very question that we need to spend more time answering.

Let’s just start with coaching. What do you think of when you think of coaching? Do you think of a sports team that has a coach? Do you think of losing weight and maybe hiring a personal trainer as a fitness coach? Do you think of accomplishing personal goals through engaging a life coach to help you stay focused? In any of these instances, the person that is in the coaching position does not do the work for the person being coached. The coach’s role is to:

·       Ask all kinds of questions – the obvious question, the dumb question, the hard question, etc

·       Make observations and play back what they are seeing, what they are hearing, what they are observing

·       Make recommendations, suggestions, provide alternative view points

·       Listen

·       Remind the coachee of the very goals that were set out to be accomplished and take stock of reality – is the goal being met or not with the actions the coachee is taking

Scrum is a different way to do work. It may sound simple to change to a new way of doing work, but many find the practice of Scrum difficult to accomplish. The official Scrum Guide is free to all and is available here.

The Scrum Guide is clear that a ScrumMaster does not only coach the team of people doing work or developing the product that will be used by customers, but they also have the responsibility of coaching the Product Owner and the Organization. The Product Owner gives direction about the product, and the greater Organization is comprised of other experts, users, customers and stakeholders about interacting with the Scrum Team.

That may sound like a big job, and it is!  This is why a ScrumMaster is a full-time job and not one that can be done effectively as part time. It’s not administrative at all. It’s about people. It’s about individuals and interactions. It’s about setting goals, accomplishing goals and more importantly, what needs to change if goals are not accomplished.

Think back to sports teams you may be a part of that had a coach. Or any sports teams that you watch. How many are successful without an effective coach? How many Olympic athletes achieve a medal without a coach? This idea is critical to a successful Scrum adoption. The ScrumMaster is the coach to the Development Team, the Product Owner and the Organization regarding making this change and when things get tough, not back-sliding into old habits or unsuccessful approaches that detract from the goal.

If you would like to learn more about Scrum or the ScrumMaster, refer to the free Scrum Guide. You can also join me for a Certified ScrumMaster course hosted by Hollstadt Consulting on Oct 2.

Author: Christian Antonie

ScrumMaster Certification: Answering Crucial Questions – Isn't a ScrumMaster just a Project Manager by Another Name?

---

In prior posts in this series, we have examined a number of crucial questions regarding the Scrum Framework and the role that a ScrumMaster plays in addressing them.  We conclude this series with an overview of how the role of ScrumMaster differs from that of a traditional Project Manager.

Before highlighting these differences and answering the question,”Isn’t a ScrumMaster just a Project Manager by Another Name?”, it is important to note that Project Managers have value.  Most are good and decent people who are trying to add value wherever they can in the pursuit of a project objective.  With that said, the goals of a project manager differ remarkably from those of a ScrumMaster.

A project manager is charged with ensuring the project goal is achieved within the scope, schedule, cost and quality parameters set by the project sponsor or project steering committee.  While they may discuss customer value or the team in pursuit of this goal, both of these topics are secondary to it.  The team is often seen as a means to end, a method of accomplishing the project.

In contrast, a ScrumMaster views the team as a source of creative, innovative energy that, when set loose in a self-organizing environment and served by an educated Product Owner and ScrumMaster, can achieve amazing results.  While this may sound a little new age, it is a crucial distinction between the two roles.  While a Project Manager is concerned with plans, controlling change and reporting the status of the effort to the various project stakeholders, the ScrumMaster trusts the Team and the Product Owner to work through the framework to address planning, changes and the reporting of status to stakeholders.  While these items look different in Scrum, they achieve the same objective: freeing the ScrumMaster to focus on things like Team dynamics, event facilitation, and impediment removal.

A ScrumMaster is also concerned with the technical practices of the Team.  While items such as the Team’s automation approach to continuous product integration are of minimal interest to most Project Managers, they fall clearly within the purview of the ScrumMaster.  A ScrumMaster is a strong advocate for the Team adopting these practices and is continually educating the Team on their benefits and pushing them to continually search for, and stretch, the technical excellence of their product.  Project managers might inquire as to whether the project team is controlling their source code or is regularly testing the application, but rarely will a traditional project manager push beyond this cursory inquiry.

In short, a Project Manager exists to serve the project stakeholders by providing them with an idea of the project’s progress through indirect means – how much money has been spent, how time has expired in a flawed plan, etc.  A ScrumMaster instead does anything that will help the Team be a better version of itself, to, in the words of Jeff McKenna, the coach of the first Scrum Team ever, “help the Team be awesome”.

Click here to view our upcoming classes and register for our next CSM or CSPO course.

Author: Collaborative Leadership Team. Learn more about our coaches and offerings here. 

ScrumMaster Certification: Answering Crucial Questions – What's A Self-Organizing Team?

---

In the first two parts of this four-part series, we addressed the broad question of “Why Get Certified?” and how a Certified Scrum Master (CSM) can help an organization transition from a project-based to a product-based organization.  In this post, we examine a unique aspect of the Scrum Framework – a self-organizing team and the role that a ScrumMaster can play in helping the team become self-organizing.

Before outlining the ScrumMaster’s responsibilities in this regard, it’s important to establish what “self-organization” means or more importantly what it does not mean.  Self-organization is providing the team with a goal to achieve, constraints to which they must adhere and then getting out of their way as they determine the best way to achieve this goal.  Note that this definition does not state the team gets to decide the goal, change the goal or generally decide on a day-to-day basis what work it would like to do or not do.  A team that follows this approach is practicing Scrum or any other Framework, it is engaging in a method known as “Chaos”.

This is the first responsibility that a ScrumMaster has in regards to self-organization – teach its definition and highlight to both the team and the organization’s broader leadership the implication of this definition.

Beyond teaching this definition, the ScrumMaster must also encourage the team to practice self-organization.  This means not letting the team wait for direction from management before taking action.  Whether it’s something as simple as gaining access to a server or something as complicated as identifying the source of an intermittent defect, the onus needs to be on the team to take action.  In organizations with a high-degree of “command and control” leadership, a ScrumMaster’s needs to be both persistent and patient with the team.  Part of this patience involves the ScrumMaster advocating for action, but not taking that action on the team’s behalf.  If the ScrumMaster becomes impatient and acts on the team’s behalf, they have simply replaced management in their former role and the next time the team needs to take action they will wait for the ScrumMaster to act.

Of course, the ScrumMaster also has to protect the team while it learns what it means to be self-organizing.  Often times, management will understand the definition of self-organization and will give the team the opportunity to self-organize only to quickly become impatient and fall back to a “command and control” mentality when the team struggles to put the principle into action.  A ScrumMaster in this situation needs to coach management regarding the time it takes for a team to adopt a new way of working and preach patience as the team works through this timeline.

In our next post, we will address another crucial question related to the ScrumMaster role – “Isn’t a ScrumMaster just a project manager by another name?”  If you are interested in learning more and becoming a Certified Scrum Master (CSM)., click here to view our upcoming classes and register for our next CSM or CSPO course.

Author: Collaborative Leadership Team. Learn more about our coaches and offerings here.