Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (2014)

Chapter 9. Managing the Managers

Even though the Scrum framework doesn’t explicitly call out the specific involvement and contribution of senior stakeholders, project sponsors, and other managers, it certainly doesn’t imply that these roles don’t exist or that they’re not integral to the success of our projects.

The following three shortcuts offer a range of options for integrating these senior, high-level roles into the Scrum landscape.

Shortcut 25: Perception Is Reality focuses on managing the perceptions of project sponsors who may be unfamiliar with Scrum. Shortcut 26: Our Lords and Masters suggests an option for aligning multiple ScrumMasters in larger organizations through the proposed Chief ScrumMaster role. Finally, Shortcut 27: Morphing Managers in the Matrix details the efficacy of creating and maintaining a team-centric organizational structure and discusses how project managers and functional managers can still work with Scrum teams.

Shortcut 25: Perception Is Reality

We play card games during our estimation sessions, we decorate our areas with colorful sticky notes, we don’t rush around like panicked turkeys at Christmas, we get together in a daily huddle and have a laugh at some poor developer wearing the broken-build cowboy hat (see Shortcut 20)—hmm, sounds a lot like . . . oh, don’t say it . . . FUN!

Now, although Scrum officially prescribes only three roles—the ScrumMaster, product owner, and development team—if you want your Scrum projects to succeed, you had best learn fast how to get on with another important role that is financially critical to most projects—the project sponsor.

Sadly, many of you will have worked with project sponsors (especially from a non-software background) who are convinced that an axiom of office life is that productivity is mutually exclusive to having some fun.

Without wishing to overgeneralize, if one (or more) of your sponsors has a background in an industry synonymous with a command-control culture they will likely feel that working 18-hour days is a cultural norm and that if you don’t look like you’re about to have your fourth coronary, then you’re simply not focused enough! Based on that premise, imagine how they feel about seeing people leave work at a reasonable and consistent time, hearing constant chit-chat between previously disparate teams, and watching teams spend time on so-called non-functional work, such asunit testing and refactoring. I’ll tell you what they will be feeling—discomfort at best and fury at worst!

Even though the product owner should be the primary interface between the Scrum team and the more senior project sponsor, you have a role as the ScrumMaster to keep the sponsor from blowing a gasket. You must use your powers of persuasion to constantly align expectations by understanding the sponsor’s perspective and reconciling it with that of the team.

Build a Relationship

Don’t just wait for the more official sprint review or worse, an emergency, to meet with the sponsor. Instead, be proactive and set up a regular update session irrespective of what is happening—perhaps catch up for lunch or set up a regular coffee outing with the sponsor. During these regular sessions, you can reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going.

Corporate politics can be one of the trickiest and most persistent impediments facing your teams, so having a strong relationship with the sponsor offers you a chance to potentially obtain both direct and indirect clues regarding any politics that might be a hurdle down the track. With this insight, you can start planning how to deal with it if or when the time comes.

Reference Point

It is always a good idea to have a firm and unambiguous understanding of the overall goal of the project. Sure, as far as Scrum is concerned, this perception is the product owner’s responsibility; however, it is wise to ensure that the sponsor has plenty of input into the product’s high-level overview that forms the guiding beacon from beginning to end.

To create the high-level overview, I recommend the use of a simple product “one-pager.” Table 9.1 presents an example (inspired by Jim Highsmith and Pete Deemer).

Table 9.1. A Simple One-Page Product Overview

While the sponsor may be unfamiliar with the details of the emerging product backlog, he or she should be completely comfortable with the overview presented in the one-pager. Contention that potentially arises down the track with any of the specific requirements should ultimately be resolved by the solution that best aligns with what has been captured in this artifact.

Involve Them

I find that sponsors become less upset when confronted with problems if they are involved in the resolution. So, be proactive when an issue arises—approach them with a range of options and make them feel involved in determining the remedial course of action.

Also, I like to occasionally send out a special guest invite to a Planning Poker session (see Shortcut 14). These estimation workshops are dynamic, collaborative, and informative and, if facilitated well, will leave the sponsor feeling that the team certainly knows what it’s talking about!

Finally, it goes without saying that you should invite and involve the sponsors in the regular sprint review during which they get an opportunity to give the team feedback and offer encouragement (see Shortcut 22).

Keep Them in the Loop

Sponsors hate to be kept in the dark. Thanks to Scrum’s strong emphasis on transparency and visibility, there should no longer be any deep, dark secrets. Embrace this facet of Scrum by filling up your monthly calendar (see Figure 9.1) with a selection of the following options:

Figure 9.1. Maintain multiple touch points with your project sponsors to keep them in the loop.

Take the sponsor on a “Tour of the Task Boards” now and again. Explain what all the colorful sticky-notes mean and why you had that strange little spike in the burndown chart earlier in the week (see Shortcut 21).

Conduct regular presentations or “brown-bag” sessions that delve into specific Scrum practices, such as Explaining Relative Estimation or Understanding User Stories.

Circulate books and articles to reinforce the popularity of Scrum. Conservative organizations often don’t like feeling that they are pioneering new ways of working, so emphasizing that Scrum is fast becoming more mainstream is often very reassuring to them.

Promote your successes by circulating a monthly Scrum Success Stories update. It doesn’t need to simply focus on quantitative measures, such as reduced bug counts or faster deployment times; it should also be used to promote the more qualitative benefits. Achievements, such as the breaking down of walls between previously siloed-off groups are certainly causes for celebration.

I’m a big fan of sharing experiential war stories. Mike Cohn (2009) refers to these as “internal experience report presentations” and correctly points out that “nothing beats hearing from someone who is already doing it.”

Maintain Diplomatic Discipline

Never say no is a lesson that I have learned over time. No one likes being told no, so we often need to play some games to disguise this message.

Suddenly behaving like an aggressive rottweiler that feels empowered to push back and say no under the “protection” of the Scrum rules is never a good idea. Even if the sponsor understands and appreciates the principles behind the pushback, human nature dictates that no one likes to be told a categorical NO. The sponsors will push back if they feel that they have been curtly disregarded.

I personally like to use a simple approach when saying no. This is how it goes:

Sponsor: “I know that we’re now well into the sprint, but can we please briefly postpone user story ABC and implement user story XYZ instead?”

Me: “Sure thing, Mr. Stakeholder, we can do anything. However, please take into account the implications of enacting this change. Some of these implications include disrupting our strong momentum, calling for a sprint cancellation, and worst of all, undermining our Scrum process and damaging the faith that the developers have in the new and positive way that we’re working.

Would you agree with me that the implications at this point outweigh the benefits? So, how about we tackle user story XYZ first thing in the next sprint, which starts in a few short days?”

I find that more often than not, this approach works wonders and really generates a win-win situation: everyone goes away getting what they want while also feeling that they have been magnanimous and reasonable.

You also have potential for pushback when you start discussing the fact that time should be dedicated to pure technical tasks (as opposed to functional tasks), such as unit testing and refactoring. I find the easiest way to tackle these issues is to use statistics and precedents from other well-known and highly successful companies. For example, when I explain the need to pay off accruing technical debt, I like to talk the sponsor’s language and quote from a Wall Street Journal article about eBay:

eBay’s system, which involved 25 million lines of inflexible code, soon became a liability. . . .The benefits are fuzzy and the risks are very real. Yet you have to do it. If you don’t, you fall behind and you go out of business. (Fowler and Morrison 2010)

While the sponsor may not truly understand what technical debt and refactoring is, I have found the “If it’s good enough for eBay and it’s in the Wall Street Journal, then we should probably do it as well” attitude to be prevalent and that suits me just fine.

Remember Who Pays the Bills

Remember the expression, He (or she) who has the gold, makes the rules? So, the sponsors—the ones paying for what the Scrum team is developing—have the right and ability to run things however they like. Beware, that perception is reality. The last thing that you want is to revert to the dark old days simply because the sponsor doesn’t understand Scrum.

If there is a perception that Scrum is creating teams of ill-disciplined cowboys, then your job, should you choose to accept it, is to work with the sponsor to foster a stronger, deeper understanding of why Scrum is beneficial and how it offers the best possible chance of getting them the best bang for their buck.

Shortcut 26: Our Lords and Masters

When one ScrumMaster turns into two, then three, then four, life begins to gets more exciting. Scrum has clearly taken a stronghold in your organization and is settling in for the long haul.

Although this is a great situation, care must be taken to erect strong scaffolding to help guide the positive surge as well as to maintain a level of consistency and discipline across the expanding groups.

To ensure that problems don’t arise, consider the creation of a new position complete with a fresh remit to maintain standards and consistency. The Scrum equivalent of a PMO (project management office) would be ideal. However, setting up a PMO is no easy feat, and because this book is about identifying effective shortcuts, I recommend a simpler alternative (at least to start with): the creation of the Chief ScrumMaster position.

ScrumMaster versus Chief ScrumMaster

Although Scrum doesn’t prescribe any functional lead roles, the reality is that there needs to be a person who handles the responsibilities, such as HR, career progression, and technical mentoring, for the various functions. Simply put, the Chief ScrumMaster performs this role for a group of ScrumMasters and also acts as the organization-wide strategic Scrum coach (see Figure 9.2). If you prefer a looser structure, then you could instead view the Chief ScrumMaster as the facilitator of the ScrumMaster Community of Practice (see Shortcut 27).

Figure 9.2. While the roles are different, they share important commonalities.

Now that the general relationship between the two roles has been established, let’s explore the specific functions of each, starting with the new Chief ScrumMaster role.

Core Functions of the Chief ScrumMaster

Cohn’s Succeeding with Agile (2009) provides an excellent basis for the core functions of a Scrum-based PMO, and I’m going to start with a selection of these functions for our Chief ScrumMaster position description. I have put my own spin on these descriptions, so for Cohn’s original descriptions, please refer to his book.

Training and Coaching

Novice ScrumMasters need to learn how to become good ScrumMasters, and maturing ScrumMasters need to learn how to become great ScrumMasters. Programs need to be created to facilitate this education process.

Challenge Existing Behaviors

Cohn (2009) talks about challenging the teams “who are falling back into old habits.” This is obviously important, but in the case of the Chief ScrumMaster, it is also critical to continually challenge the organization (on a whole) if it slips back into its more systemic bad habits.

Provide and Maintain Tools

Whether the business decides to use high-tech or low-tech tools (or a combination of both), the various artifact templates need to be defined, adapted, and version controlled.

Define and Refine Metrics

Metrics should be used carefully for good rather than evil purposes (see Shortcut 19). The Chief ScrumMaster needs to ensure that relevant metrics have been formulated and are being utilized for the correct purpose.

Help Establish Communities of Practice

Function-specific communities of practice should ideally form organically from the grassroots (Cohn 2009). However, they will often need the initial kick-start and occasional shot-in-the-arm to keep them running effectively.

Ensure Consistency

Ensuring consistency across teams is possibly the most important function of the Chief ScrumMaster. It is important that consistency and discipline are maintained, especially when there are multiple teams and ScrumMasters. If certain teams need or would like to apply varying approaches (for whatever reason), then these variations should be adopted in a systematic and purposeful fashion with guidance from the Chief ScrumMaster.

Coordinate Teams

With multiple interdependent teams working on the same product backlog, processes need to be defined and maintained to ensure coordination occurs as seamlessly as possible.

In Addition . . .

The following are some additional functions that I feel can be added to Cohn’s list.

Ongoing Scrum Promotion

Promoting Scrum should occur not only in the early stages of the adoption but also as the organization evolves. New stakeholders will be regularly coming on board, and they will need to understand the incumbent Scrum environment.

Developing the Approach

Remember that Scrum is a framework and not a prescribed method (see Shortcut 2). Therefore, the specific, fit-for-purpose approach for an organization should be initially defined by the Chief ScrumMaster.

Company-Level Education

As each new Scrum initiative or practice gets introduced for the first time, the business needs ongoing education to ensure that the proposed benefits are understood.

Aligning the Teams’ Definitions of Done

Coordinating the defining and evolution of a consistent definition of done across all teams is important to ensure that expectations are aligned, especially during key integration periods.

Continual Process Improvement via Collective Retrospectives

Many useful suggestions will bubble up from the various team sprint retrospectives, and it is important that any golden ideas that Team X comes up with (that other teams may also find helpful) are leveraged across all groups.

Impediment Escalation

Not all impediments that disrupt an individual team can be resolved by the individual ScrumMaster, especially issues relating to organizational constraints, such as the physical working environment and/or incentive schemes. The Chief ScrumMaster should be the first escalation point for such impediments.

HR for the ScrumMasters

Just like everyone else in the organization, ScrumMasters have HR requirements that need to be managed, such as career planning, remuneration reviews, training, and mentoring.

Creating a Physical Environment Conducive to Scrum

To work successfully, Scrum needs to exist in a collaborative and comfortable team environment with minimal disruptions from the outside world (see Shortcut 3). Ensuring a close working relationship with the facilities department who can assist to modify the workplace where and when required is integral to Scrum’s success.

Core Functions of the ScrumMaster Role

When the ScrumMaster is a lone wolf in a small organization, then the Chief ScrumMaster functions listed earlier will also need to be taken on by the ScrumMaster. However, when there is the luxury of a Chief ScrumMaster, the ScrumMaster should then be free to focus primarily on the following roles and responsibilities.

Process Improvement

Identifying key improvement points with help from quantitative metrics (see Shortcut 19) as well as through the more qualitative sprint retrospectives (see Shortcut 23) is a fundamental responsibility of the ScrumMaster.

Impediment Management

One of the most publicized of all ScrumMaster functions is the controlling of impediments to ensure that project speed bumps don’t turn into brick walls (see Shortcut 9).

Diplomacy

Especially in the early days, silos will likely exist between the various groups who are required to work together in a new Scrum team. Bringing these groups together around the campfire is one of the more subtle, yet critical, responsibilities of the ScrumMaster.

Coaching

It is imperative that the ScrumMaster comprehensively understands the broader Scrum framework, and more specifically, he or she needs to be highly proficient with the approaches adopted among the teams. This includes being an expert with the various tools and techniques being used.

Managing Change

Regular changes will be made to overall product scope as well as individual product backlog items. Controlling these changes and guiding the various parties in managing the changes is extremely important.

Maintaining the Definition of Done

Once the definition of done has been defined by the Scrum team (see Shortcut 11), the ScrumMaster needs to work hand in glove with the product owner and developers to ensure that it is maintained.

Maintaining Effective Communication

Scrum relies on positive human interaction; therefore, the ScrumMaster needs to actively encourage a culture that allows such interaction to occur.

Updating Artifacts

The ScrumMaster needs to work with the developers to ensure that sprint artifacts are regularly updated (which often requires perfecting the art of chasing without nagging).

Facilitating Workshops

Prior to a project kicking off, the ScrumMaster needs to work with the product owner to facilitate the creation of the product backlog by conducting user story workshops and estimation sessions (see Shortcut 14).

Facilitating Scrum Activities

Several activities occur throughout the sprint iteration, and the ScrumMaster is responsible for their running smoothly. This includes managing the logistics and facilitation of the following:

Daily scrums (see Shortcut 20)

Sprint planning (see Shortcut 8)

Sprint reviews (see Shortcut 22)

Sprint retrospectives (see Shortcut 23)

A motivated ScrumMaster will also make efforts to constantly spice up these sessions by introducing various formats and locations to keep life interesting.

A Consistent Ecosystem

Phew! When you read these lists of functions, you can begin to really appreciate that maintaining a successful Scrum ecosystem is no trivial matter.

I believe that the key to success, especially as the broader Scrum rollout gains momentum, is maintaining a level of consistency, discipline, and continual education. A centralized Chief ScrumMaster, supported by dedicated ScrumMasters, will ensure that these critical success factors are achieved.

Shortcut 27: Morphing Managers in the Matrix

It’s no secret why it took electric-powered cars so long to come about. Powerful incumbents, satisfied with the status quo, are more than willing to completely repress any movement for overall positive change and efficiency. You can’t really blame them—it’s a survival game whereby one industry becomes obsolete to establish a newer and more efficient one. This is the same difficult battle that we face when trying to introduce Scrum broadly across a large organization that is not receptive to change. Many Scrum adoptions (particularly in larger, more traditional companies) require the typical hierarchical power centers to evolve (or potentially even disappear), and to accomplish this evolution requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics.

This shortcut explores some possible options to help organizations that are stuck in their traditional structural backwaters. This is obviously a big, deep topic to cover in a shortcut, but let’s be ambitious! Specifically, we will focus on three key areas: (1) options for the general organizational structure; (2) options for the traditional project manager, and (3) options for the functional managers.

Evolving Out of the Matrix

With increasing emphasis on project-related work, organizational structures have had to adapt. The most recent mainstream evolution was the movement in many organizations toward more project-centric structures, such as the balanced matrix. The question, though, is whether they have evolved enough to generate a sustainable, conducive environment for Scrum projects to successfully operate. Before answering that, let’s briefly recap some of the basic characteristics of typical organizational structures.

Functional Organizations

Characteristics of functional organizations include the following:

Made up of specialized departments.

Functional managers have ultimate authority (see Figure 9.3).

Figure 9.3. A typical functional organization chart.

Projectized Organizations

Characteristics of projectized organizations include the following:

Made up of dynamically generated project teams.

Project managers have ultimate authority (see Figure 9.4).

Figure 9.4. A typical projectized organization chart.

Balanced Matrix Organizations

Characteristics of balanced matrix organizations include the following:

Made up of vertical specialized departments and horizontal project teams.

Authority (supposedly) balanced between project managers and functional managers (see Figure 9.5).

Figure 9.5. A typical balanced matrix organization chart.

Alignment with the balanced matrix structure is becoming increasingly common in large organizations. In this structure, projects are run by project managers who are temporarily assigned people (and other resources) from the various functional managers for the duration of the project. Once the project is done and dusted, the project team disbands and everyone returns to their functional, operational roles or moves onto another project team. To many nonagilists, this setup is the perfect happy medium.

Team-Centric Organizations

So why is the balanced matrix structure still far away from where we need it to be? Well, although Scrum is a framework for effectively facilitating software projects, the project itself should not be considered the central component (and obviously the functional departments certainly shouldn’t be). So what is the central component that the next-generation organizational structure should be built around? I’m hoping that the answer is obvious to you; however, if not, your answer should be . . . wait for it . . . the Scrum team! In a team-centric organization (see Figure 9.6), teams are assigned projects rather than projects being assigned people (typically based on availability). Agile coach Rob Maher points out the key benefit of using a team-centric approach:

Teams go through a proven lifecycle—Forming, Storming, Norming, and Performing (Tuckman, 2010). This maturation process takes time, often months. Team members know their strengths and weaknesses and have learned how to communicate, collaborate and resolve conflict with each other. Why break up what has become a high performing team? There is published evidence that short-lived groups of people brought together for a project are correlated with lower productivity. (Maher 2011)

Figure 9.6. The most Scrum conducive organizational structure.

Apart from the fundamental benefit of higher productivity, there are other advantages to the team-centric approach, such as the ability to provide more accurate forecasts because of the longer-running historical velocity data that a jelled Scrum team has managed to accumulate (see Shortcut 19).

Think about a team-centric structure as similar to the cross-functional commando units in the military. Instead of forming new units when a mission arises, the most suitable preexisting units get assigned the missions that they are best able to take on. Sure, there may be the odd situation where the commando unit needs to add another type of specialist, but the vast bulk of the unit always stays together because of their strong cohesiveness, trust, and operational familiarity.

Project Managers Aren’t Disappearing

Scrum describes only three roles: the ScrumMaster, the product owner, and the development team. This seemingly simplistic breakdown inevitably leads to the same awkward questions from incumbent project managers time after time: “Umm, so what happens to us project managers?” The tough love response is offered by Cohn (2009) when he states, “In Scrum we recognize the untenable role of the project manager and eliminate it.” This leads to the next question (usually asked in panicked tones): “So what happens to all of the crucial project management functions, such as scheduling, budgeting, and planning?” I answer this question with something like, “Well, actually, those responsibilities are split among the three different Scrum roles to varying degrees.” The project manager, now reaching for a respirator, continues with, “So . . . what does that mean for me?” I’ll then respond sensitively with, “Well, it means that if you want to play in the Scrum world, then you’ll have to transition to become either a ScrumMaster, product owner, or developer—it’s pretty simple.” Now despondent, the project manager will often sigh and offer a final claim along the lines of, “I like the sound of Scrum, but I love being a project manager and don’t think that I want to give it up, so I guess no Scrum for me.”

I’ve seen this happen and I don’t much like it. Throwing the baby out with the bathwater is wasteful, so is there another option to involve more traditional project managers in Scrum projects? My opinion is yes (with a big but). The but is that I totally agree that there is no place for a traditional project manager in a single Scrum team. Where I see the potential for the reintroduction of project managers is when the development efforts utilizing Scrum are considered to be part of a larger multidepartment project. Let’s explore this further.

The Project Big Picture

More often than not, Scrum development projects don’t just operate in an organizational vacuum. At the tail end of development, there is typically a flurry of activity occurring in other parts of the organization. The marketing team is trying to understand how to best position the new product, the sales team is trying to understand the product for demonstrations, the customer service team is skilling up to handle customer queries, and the finance team needs to integrate the new pricing and revenue models based on the new offering (Figure 9.7). Wow! There sure is a lot to coordinate and manage here. I personally feel that the intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager.

Figure 9.7. The project manager can be an important interface between the Scrum team(s) and the other departments.

Third Parties

Kenneth Rubin (2012) offers another suggestion as to where the project manager can add value—the coordination of efforts between the Scrum team(s) and contractors who might not be using Scrum.

A project manager can also be helpful on development efforts where using Scrum represents just one small part of a much greater product or services development. For example, there might be subcontractors, internal non-Scrum teams, and other internal organizations associated with delivering the product.

The Future of Functional Managers

Now that we’ve looked at some options for the project manager, let’s change paths and focus on what opportunities there are for functional managers as Scrum enters the fold.

Here’s the problem: a great developer has been promoted to the role of functional manager. This position bestows hierarchical privilege that the new manager comes to enjoy and value. Sure, they may no longer be working hands-on in the code as much as they would like and instead are spending more time in boring meetings, delegating tasks, and fiddling with administrative paperwork, but hey, being able to tell their mom that they’re now in a management role is pretty cool, right?

The issue is that in Scrum, there is no prescribed functional manager who needs to delegate work to the self-organizing teams. These functional managers are then left wondering what becomes of them. Do they now get stripped of their title thanks to Scrum?

Well, I don’t believe so. My solution to the problem is to simply help them redefine what it means to be a functional manager. The first thing that I typically say to them is similar to what Scrum trainer and Stormglass CEO Pete Deemer (2011) recommends when he suggests, “In simplest terms, the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform.” Usually no arguments so far from the incumbent functional manager.

Next, I talk about the fact that with multiple Scrum teams, there is a strong need to help ensure that technical standards have been defined and that someone is able to guide the team to resolve technical impediments both intra- and inter-team. Our functional manager is still happy.

Moving on, I discuss the need for someone to be able to identify the knowledge gaps so that the applicable learning and development programs can be evolved—on both the technical and domain levels. No objections yet.

I continue by mentioning that we also need someone capable and qualified to help recruit new developer talent when we form new teams or need to replace someone. Still no objections.

Finally, I tell the functional managers that they can throw those painful delegation tasks that they are “forced” to do out the window so that they can get back to focusing on what they really love to do! Typical response to this redefinition: “Sounds super sweet! When do we start?”

I see this structural shift as a move away from hierarchical commanding and a step toward “community of practice” facilitation. If this transition occurs successfully, then I really don’t mind if they wish to hang on to their functional manager titles.

Let’s Be Realistic

Just because Scrum describes only three roles, it shouldn’t mean that all others are rendered superfluous or redundant. The changing of organizational structure and the wholesale removal of traditional functions, such as the project manager, is not only unrealistic but in many cases unnecessary. Thinking with an open mind can uncover options whereby these traditional roles may be repurposed without corrupting the true Scrum model.

By embracing existing functions, such as higher-level project management, we may be able to knock down a considerable barrier blocking the introduction of Scrum, especially in larger, more traditional organizations.

Wrap Up

The three shortcuts included in this chapter focused on a selection of tactics, tools, and tips to integrate senior stakeholders into the Scrum landscape. Let’s recap what was covered:

Shortcut 25: Perception Is Reality

The importance of establishing a fluid working relationship with the project sponsor(s)

A helpful approach for generating the product vision: the one-pager

Tips for ensuring that project sponsors continue to feel included and kept in the loop

Shortcut 26: Our Lords and Masters

Differentiating between the role of the ScrumMaster and that of the Chief ScrumMaster

Understanding the core functions of the Chief ScrumMaster

Understanding the core functions of the ScrumMaster

Shortcut 27: Morphing Managers in the Matrix

Why a team-centric organizational structure is preferable to the typical balanced matrix or functional models

Potential options for traditional project managers who don’t wish to transition into one of the core Scrum roles

The evolution of the functional manager role