Bad Meetings Are Boring and Ineffective

Every day, when my husband returns from work, I ask him “How was your day?”  Most of the time, he shrugs, and says something like, “Urrggghhh – so many meetings – I didn’t get ANY work done.” I’ve no idea what he does, but his LinkedIn profile tells me he “attends meetings and adds value.”

But meetings ARE work. They are an important part of the collaborative process, and one that the Scrum framework recognizes and formalized.

According to MeetingKing, 11 million meetings occur in the US every business day, and waste $37 billion in lost time each year. Maybe you are in a boring meeting right now, reading this.

Patrick Lencioni’s fable, “Death by Meeting,” hits the nail on the head:

“Bad meetings, and what they indicate and provoke in an organization, generate real human suffering in the form of anger, lethargy, and cynicism. We typically complain we have too many meetings, but the real issue is that the meetings normally aren't very effective.”

That doesn’t sound very agile, does it?

Lencioni cites the problem as twofold. Meetings generally lack:

Drama or conflict Contextual structure

Frustration is inevitable when “little is decided as participants have a hard time figuring out whether they are supposed to be debating, voting, brainstorming, weighing in or just listening.”

Why Are We So Bad at Meetings?

We are failing our Scrum Masters. They are our anointed servant leaders, coaches, and facilitators. How inspiring! However, we rarely tell them HOW to fulfill those roles. There is a general overemphasis on process and technology, and an under-emphasis on leadership skills.

I have a recurring daydream, where I decline every single meeting on my calendar. Eventually, if I’m really needed, I’ll be contacted again. Bliss! I’ve learned that this isn’t the most emotionally intelligent way of dealing with meeting overload.

David Grady’s humorous take on organically seeding good meeting etiquette is a great primer, especially when you have no idea what the meeting is about:

You don’t HAVE to accept every meeting you are invited to – use the “tentative button.” Talk to the organizer, and let them know you are excited to support their work. Ask what their goal is and how you can help. If you do this often and respectfully enough, maybe people will become more thoughtful about putting meetings together.

The Difference Between In-Person and Virtual Meetings

While I was attending an advanced agile scaling class a few years ago, the instructor stated, “at scale, Scrum won’t work if you have distributed teams – they must be co-located.” Always one that likes to debate, I sent out a “thought balloon” to see how it would be shot down. I was curious.

“Do you think that 16 years after the Agile Manifesto and its principles were written, technology has changed enough to update the idea that ‘the most efficient and effective method of conveying information to and within a development team is face-to-face conversation?’”

“NO!” was the emphatic response, followed by a couple of slick and funny YouTube videos highlighting the problems with conference, or worse, VIDEO conference calls.

I had to admit I agreed with him. Today’s modern communication software does not replace face-to-face conversation, but the reality is that the majority of teams are moving to this type of dispersed work. 

Whatever the latest technology du jour is, it will not replace the fact that you can learn how to facilitate better.

So what can we do to make the meetings suck less?

Have a Plan

I have great respect for the Grove Facilitation Model, which provides a robust, world-class way to lead a meeting.  It helps to provide the context for the following questions that every participant of a meeting needs to know:

Why am I here? Who are you people? What are we doing? How should I behave? When can I leave?

In my agile coaching practice, a common weak point I see is the retrospective being omitted. People don’t have time to do these meetings, and therefore they mistake the lack of effectiveness for false efficiency. This points to all kinds of juicy and dysfunctional problems, but meetings don’t HAVE to be a chore.

Make Your Virtual Meetings Shine

After training with The Grove on successful virtual meeting facilitation, I’d love to share their six main points to consider when planning a meeting. Make a template and fill it in so you have a proper plan you can add to your agendas. Scrum Masters, discuss it with your team to use as part of your working agreements.

Prepare Assign roles (such as tech support, scribe, timekeeper or facilitator). Don’t make the team lead a facilitator. Use a visual focal point for each agenda point. Humans are a visual species – this is how we remember and engage with things. Include a team portrait and graphic facilitation. Practice transitions. Determine how you will reach your outcome. How will time be used, who owns each topic, when do you make decisions, how will you make and document a decision? Make it engaging. I like to channel Sharon Bowman’s The 6 Trumps™ for any occasion. The person doing the most talking is doing the most learning, and if anything is longer than about 10 minutes, then you have lost your audience engagement. Design things well to maximize audience participation and use simple tools. Clarify Communication Channels Confirm meeting arrangements ahead of time. Audio is the most important element to get right. Include working norms. For example, always use a headset – no speakerphones permitted. How will you share working documents? Which ones does your company support? Which ones support the type of work you want to do? KISS (keep it simple, stupid)! Go Slow to Go Fast Expect a slow start. Include an icebreaker to allow people to get settled. It also serves as a subtle way to do a tech check and ensure that everyone can hear. Display the agenda often, especially at the beginning, transitions and the end. Virtual meetings often omit an agenda altogether. Create space right away for people to have their voices heard and get connected to content. Ask people to reframe the purpose of the meeting -- include a “2 breath” rule to allow for bottom-lining of context. Ensure Participation is Balanced Engage everyone by name, especially in blended meetings. Make space for quiet participants. Be sure to throw the quiet people a line. Structure an inclusive process (maybe write thoughts down first, then share). Keep Calm and Carry On Keep participants accountable to the agenda. Expect things to fall apart. Always have a lower-tech back up plan (phone or chat). Actually Follow Up Form crystal-clear agreements on next steps. Communicate with people after the meeting. Make the notes visual and ban the bullet point. It’s a snore fest. My list here is ironic. Document! List action items, owners and due dates, and add things to the backlog.

Poorly facilitated meetings are still poor meetings, irrespective of location. Virtual meetings just amplify facilitation problems. Facilitation as a skill is not often purposely honed--it’s something that most people “just do.” The evidence overwhelmingly tells us that it is not usually done well.

Now I know my husband does work by attending meetings and adding value, even though he feels like he attends every one of those 11 million meetings a day.

Bad meetings are boring and ineffective. But, if done well, they can be a time-saver.

Have you had positive or negative experiences with virtual meetings? Do you have any tips for improving their efficacy? Let me know in the comments below!

Find more information about different facilitation models here:

Grove Facilitation Model and OARRS

Agile Coaching Institute POWER


End the Scrum Revolution, Begin the Scrum Evolution

An organization is a network of complex dependencies. Because of this complexity, any change in any direction will face some resistance. The major difference between a waterfall project and a Scrum project is that the latter encourages and even welcomes change. How do you introduce Scrum to a non-agile organization without facing major resistance?

Unfortunately, in their efforts to apply Scrum, companies often take the head-first approach, seeking a revolution. They look at the ideal world of how a fully agile company is run, take parts of it and stick them on their own organization. This is like putting wings on a dog and shouting at it:

“Now fly!”

And, lo and behold, the dog will just sit there and look bewildered. Consequently, Scrum gets the blame and the chapter of agility is either closed or “adapted,” with the company running Scrum in name only.

How can you teach your organization to “fly”?

Managing Your Employees vs. Providing a Vision

Change can be taught by one of two methods:

You demand that the student follow your exact instructions. It will hurt, and it will cause muscle ache, frustration and exhaustion. Yet, sooner or later, the student will learn the right technique and will favor it over other techniques, feeling the difference. This method is often used in sports, especially because the wrong moves can cause serious injuries. You start with what the student already does and offer a path of small improvements. This method is preferred if the student simply cannot perform the optimal technique at that time. Singing is a prime example: if you demand perfection, the student will never finish his or her first song; the learning curve is simply too steep.

Having played chess for many years, I prefer the second method and tend to approach problems as I would approach a game. When looking at a company’s agile transformation, I see the current situation as the starting position and the agile ideal as an approach to “win.”

Many preparatory moves are required to get to the finishing move, which in this case would be the implementation of the solutions that Scrum offers. It is like walking through a labyrinth where you are sometimes moving away from your actual goal, having to take one step back to move two steps forward.

Encouraging your organization to “fly” is not necessarily a bad idea. But this should be done by providing a vision and leading your coworkers through the process of change. In this way, they can deal with the actual implementation through evolutionary change instead of having management trying to give exact instructions or ignoring the knowledge and abilities within the teams.

How Should You Navigate the Maze of Agile Transformation?

When I first read about introducing Scrum in a company, I found it excessive, or maybe a type of “showing off” that the literature proposes to have the team executing the transformation use agile themselves as their project management methodology. It sounded like a salesperson proclaiming that their product can be used anytime, anywhere. Yet, after some experience in the industry, my view on this has changed.

The point is that the significant challenge of the agile transformation is that the requirements are not fully defined. Every single organization is different, so there is no standard way of introducing Scrum to a company. This makes it a perfect candidate for evolutionary change--- navigating through these unknowns in small but steady steps.

The First Rule of Teaching Scrum Is to Not Talk About Scrum

The first thing I tell people I coach about Scrum is to forget everything they have previously heard about Scrum. I am in no position to know better than they do what their problems are, or to think that “my” methodology would help them. Scrum is not a magical cure. Management gets too quickly enamored with the idea that there is a method that, once it’s been introduced, will solve their problems. Since this simply isn’t the case, the question remains, how can organizations achieve real change?

In my opinion, change can be achieved only by means of mutual trade. You can win over the other side if you offer an advantage. The simplest way to connect your team with the idea of Scrum is to give them a helping hand. Do nothing else but have them start by writing down impediments, and set up regular meetings where you offer solutions to their problems.

If your team is not yet very experienced with recognizing impediments, you can lead them cautiously by asking direct questions and engaging them in discussions about why some work shows no progress. The more impediments you gather, even small ones, the easier your job will be in the next step. This list of impediments will become the golden key you need to---step by step---warm the team up to the idea of agile thinking.

Next, conduct interviews in the company to evaluate its current status in terms of agile maturity. There are many checklists available online; personally, I find the 50 points from Atlassian very helpful.

After this initial evaluation, categorize the gathered impediments according to the list. If needed, add additional categories for the remaining impediments that do not fit. For example, you might also want to evaluate the agile maturity of external suppliers which need to be integrated into your process.

Once this categorization is done, you can skip all points for which your team has not encountered any impediments. Without empirical evidence to support a certain change in your organization, there is no reason to “improve” the agile maturity in these other categories.

Obviously, the other points impede your team as well. But if there is nothing directly visible for the team, there is nothing you can do about it for now. Remember, you are implementing Scrum to solve actual problems of the team, not to create a PowerPoint presentation for management!

Not only will this give you an invaluable compass in the sea of possibilities of what you can change, but it will also provide you with empirical evidence to support any decision you are making.

We have established our current position by evaluating the status of the agile transformation in your company. We have also established a goal and have identified which of the points we should work on. Now, the real strength of the list comes into place: intermediary stages. Instead of just listing ideal situations, it shows the steps leading there. They represent small stories that can be worked on in individual sprints and thus can serve as a metric for your agile transformation process.

Summary The agile transformation is a complex project itself. The ideal approach to a complex project is agile and evolutionary. Analyzing the current situation and tracking progress with a good metric is key.

How do you navigate through the process of agile transformation? What metrics do you use to track progress? Let me know in the comments below!

Part of a Scrum Master’s Job is to Lose It

Two weeks ago, a developer on our team told me that he wanted to have a sprint planning to go over a code change that he and another developer had been discussing (most of our work is done through Kanban these days).

A sprint planning session would have been overkill for what he was proposing and the number of people involved, but I was very pleased to hear him make the suggestion nonetheless. Last week, I proudly congratulated that same developer when he told me he had passed the Professional Scrum Master (PSM) certification exam. At this rate, he will hardly need me in a couple of years (if he even does right now).

The Scrum Guide states that one of the Scrum Master’s responsibilities is to “[coach] the development team in self-organization and cross-functionality.” Implicit in this statement is the notion that a Scrum Master should work him or herself out of a job.

A coach helps people understand and do what they still can’t understand or do themselves, with the expectation that they will eventually be able to. This is what nutrition coaches, fitness coaches and business coaches do. Therefore, a Scrum Master who serves as a coach should help the development team grow to reduce their dependence on the Scrum Master.

This is not exactly the same as helping individual contributors move into management. Some people want to become leads, managers or executives, and that’s fine. Some don’t, and that’s also fine. You should not force someone into a job role that they do not want.

But since a Scrum Master is not a traditional manager (though the name of the role continues to inspire that misconception), but rather a facilitator, you should expect a development team to continue to grow their skills that help them communicate and work with customers, business stakeholders and other development teams. That should be part of their natural career progression.

Of the three roles in a Scrum team, arguably the one you could most easily do without is the Scrum Master (although you would technically no longer be following Scrum). This does not diminish the Scrum Master’s importance, nor does it mean that the Scrum Master’s role ever really goes away, as Mike Cohn points out in this article.

It is, however, a reflection of the fact that the product owner and the developers must have hard technical skills in order to get their work done, whereas a Scrum Master is essentially a collection of coordination skills concentrated in a single person. You do not expect an experienced product owner to eventually develop coding skills, nor do you usually expect a developer to decide which backlog items are the most important to a company.

But you do expect both of them to become progressively better communicators, planners and collaborators. And that’s really all a Scrum Master does within the scaffolding of the Scrum framework: Foster better communication, planning and collaboration between the business and the developers.

Remember that your goal as a Scrum Master is not to still be chasing resources in five years the same way you do today, but rather to have guided the team to a point where you are their point of escalation instead of their first resort whenever they hit a snag. Coach the team on the importance of planning so that a sprint planning session is no longer just an hours-long ordeal to be endured, but something so natural and necessary to getting quality work done that they bring it up themselves.

By helping the team understand and do what you understand and do, you create a virtuous cycle that helps your current team members, future team members and other teams that your developers will eventually be part of.

Do you agree with my assessment of the Scrum Master’s role? Let me know in the comments section below.

The Essence of Agile

One thing that has changed for me over the last few years is that I find myself working with people for whom agile has become the norm. Indeed, I have even begun to work with people who have never done waterfall. My frames of reference are changing; I am starting to find that comparisons with waterfall don’t carry very much weight these days.

Ten years ago, I was working as a test manager on multiple projects, some waterfall in delivery approach, some with agile aspirations that were experimenting with elements of Scrum. I wrote a piece entitled “The Essence of Agile” to see if I could get to the heart of this new way of doing things.

Here it is:

"Essence of Agile" sounds potent, doesn't it?

Since the Agile Manifesto is already a succinct summary, then its essence will surely pack a powerful punch.

It sounds like something that I might be able to sell. So, before I go any further, I'd better think up some tag lines for my marketing campaign.

"We build software. We build it fast. We build it right. That's agile."

I like that one because: It's snappy, it's bold and it delivers the message that we know what we're doing.

"We build software. We deliver it incrementally. We adjust when we need to. That's agile!"

I like that one because: It's honest, it empowers the customer and it delivers the message that we know what we're doing and are willing to discuss it.

"We build software. You may not get what you want! You may not pay what you want! But you'll get something! THAT'S agile!!"

I like that one because: honesty, humour and exclamations! Knockout!

However, building software is an exercise in engineering, not marketing, so maybe I should put some effort into the product itself. Or at least consult Wikipedia on the definition of the word “essence:”

"...essence is the attribute or set of attributes that make an object or substance what it fundamentally is, and which it has by necessity, and without which it loses its identity. Essence is contrasted with accident: a property that the object or substance has contingently, without which the substance can still retain its identity."

As a way of building and delivering software, “agile” looks to me like the application of common sense in a sequence of coordinated actions designed to deliver a pleasing result.

In the whole short history of software development, we may well consider that all methodologies have been attempts to apply common sense in a sequence of coordinated actions designed to deliver a pleasing result. So, it may be argued that agile methods are simply the natural outcome of smart people working together to build useful software at a reasonable cost.

If we were to pay someone to estimate the dollar cost to businesses and governments of failed software projects, their fee alone would make us yelp.

So how loud would we be yelping if and when we knew the dollar cost of failure?

Maybe we could estimate it using the “software project under-estimation” method: Think of a large number. Now double it.

This is to say nothing of the impact to human lives, societies and communities of failed software projects.

The attributes that make agile fundamentally what it is are: "common sense" and "coordinated action."

This is in contrast to pure common sense which can be suggested, mooted, opined, considered and even written down without ever being translated into a verifiably actioned result (i.e. saleable code).

This is also in contrast to pure action whereby 10 developers or two architects or maybe one developer with a smartphone start to "bash" out what we all hope will one day become saleable code, whilst a project manager and a handful of business analysts engage in long and detailed discussions with the people who want the software built.

Somehow, not everyone is quite exactly available at the same time, so they fly around a lot and talk about how the software will look and review their decisions. Those decisions are then re-reviewed and re-decided with the provision that any decision made can always be unmade, and then made again later, because that is what agile is all about.

Fortunately, the developers never actually meet the business analysts, so they are able to get some real work done without having to refer to outdated and changing requirements.

This is great news for the testers who are able to catch up on their blogging commitments, speaking tours and internet-based self-teaching programmes.

The essence of agile is direct and frequent communication based on a combination of data about how we are measured against what we’re aiming for. The goal in this communication is to evaluate what we did, what we need to do next and what is preventing progress.

It sounds simple, but communication is the key, and it is the hardest component to perfect.

What is useful about the agile approach in this regard is the emphasis on regular, focused conversations in a facilitated format.

We constantly have to check our assumptions and agreements with each other. Have you noticed how easy it is to go off track and how quickly it can happen, even when everybody “knows what they’re doing,” the team is “experienced” and the client “knows what they want?”

In fact, in those cases it is especially easy to get side-tracked. I may know what I’m doing, but is that helpful to our goals right now? The team may be experienced, but what are the lessons of that experience that are going to be useful this time around? Do we have the skills, willingness and courage to learn what is needed as we go? The client may know what they want, but have they asked for what they want? And, how much control are they expecting to exert over what can change over the life of the project?

Taking daily doses of the essence of agile minimises the key killer of software project value:

Doing the wrong thing at the wrong time even if we do end up getting paid for it.

We Can’t Maintain a Sustainable Pace with Many Small Projects

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I prefer to think about this agile principle as: “Anyone who contributes to the success of the product should be able to maintain a constant pace indefinitely.”

The main two groups that I like to bring under the umbrella of “anyone” are subject matter experts and senior stakeholders. These groups are usually outside the development team, but need to be available for frequent conversations with the product owner and to provide timeous feedback at iteration reviews.

We often find that multiple projects are suffering because “anyone” is frequently unavailable, usually due to other priorities. 

In this post, I will highlight how starting too many projects can put an unreasonable strain on those inside and outside of the development team and lower the team’s chances of successfully delivering products.

We Often Need to Split Resources

Obviously, every project that we start needs resources and those are usually limited, meaning that new projects need to be resourced by allocating portions of people’s time.  Suppose we split someone’s time equally across three projects; that means that the person in question will be unable to work on two out of the three projects around 66 percent of the time, or 3.3 days per week.

Being unavailable for that much time is undoubtedly going to have a negative impact on velocity and quality. We can incur up to a 40 percent penalty in productivity associated with multitasking on complex tasks. A quick search on the internet shows just how widely accepted this argument is.

Our Teams Can’t Improve

Another downside of splitting resource and creating teams specifically around projects is that we lose the chance for our teams to continually improve via building relationships, knowing one another’s strengths and weaknesses and solving complex problems together.

According to Robert C. Martin in his book “The Clean Coder”, “Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel.”  

He claims that we can’t even call these creations teams and that there is no such thing as half or quarter of a person and suggests that it is better to assign multiple projects to an established gelled team, who will work together to figure out the best way to get them done.

We Hinder Our Chances of Essential Engagement

Users, sponsors, subject matter experts and senior stakeholders all have jobs to do outside of our projects. Furthermore, the same people tend to be in demand for each small project that we start due to expertise or seniority. This is especially true if those smaller projects are related to a common product or strategic goal.

The more projects we start, the more demands we are making of these people, meaning that they can no longer work at a constant pace and can no longer be available for teams when required. Even when they are willing to work lots of overtime, they can’t be in two places at one time. So, through no fault of their own, they become huge blockers for all projects that depend on them. 

We Introduce Avoidable Dependencies

If we create lots of small projects that contribute to a common product or strategy, we will introduce the overhead of managing dependencies that are avoidable simply by either creating larger projects or allocating projects to an existing gelled team. It’s better to eliminate rather than manage dependencies wherever possible. 

We Risk Perpetual Change

We need to be careful to ensure that the projects we are running concurrently are not delivering changes to the same users. The success of our products will ultimately be decided by our users, so we don’t want to place them in a perpetual state of change, making it impossible for them to get their jobs done without working sustained longer hours.

We should be more concerned with significant process or cultural change here, rather than the well-managed continuous delivery of small software updates, which many users welcome.

We Cause Excessive Overtime

We have seen that starting many projects can put strain on those inside and outside of the development team. The diagram below shows the vicious cycle that we can become trapped in as the negative symptoms of sustained excessive overtime lower our quality, morale and productivity, which in turn leads to more negative symptoms. Thus, the cycle is begun anew.

Choosing the Best Option When Starting Projects

Imagine for a minute that we’re property developers and have purchased two properties that we want on the rental market within 12 months. Each requires six months of dedicated renovation at a cost of $2,000. Property A will receive $2,000 per month in rent compared to the $1,500 Property B will receive. We can choose from three seemingly sensible approaches. The table below shows each approach and how it may broadly impact our profit.


Property A

Property B


Profit (24 months)

Simultaneous: Team works on both properties an equal amount within each iteration





- $8400









Alternate Iterations: Team focuses on each property for an entire iteration alternatively














Linear: Team finishes Property A before starting on Property B














In his book “Agile Portfolio Management,” Jochen Krebs states that we could safely apply a 40 percent penalty to the “simultaneous” approach and a 15 percent penalty to the “alternate” approach, which increases our costs while reducing our income period.

Over a period of 24 months:

The “simultaneous” option is by far the worst and actually results in a loss of $8,400. The “alternate” option is considerably better and results in a profit of $8,100. The “linear” option is by far the best and yields a profit of $30,000. As we prioritize Property A over Property B in terms of pure business value, we finish on time and on budget. Even if we reject the switching penalties completely, this option remains most profitable because we can begin harvesting income from our most profitable property after six months instead of 12.

Kreb suggests that in reality the switching penalties can be much higher on complex projects and increase as the number of active projects grows, which makes the argument for the linear approach even more compelling.

Try to Be Professional

In the previous section, we saw that prioritizing and focusing based on business value offers an earlier and higher return on investment (ROI). It is the professional thing to do, so we need to at least try to be professional when making these decisions.

I say “try” because being a professional is difficult and often requires us to say no to our managers. However, just because it is difficult doesn’t mean we shouldn’t do it. Again in “The Clean Coder,” Robert C Martin agrees:

“Slaves are not allowed to say no, and laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no.”

In my next post, I will demonstrate how to use a balanced agile portfolio, so that making professional decisions and saying no to good managers becomes easier.

In the meantime, feel free to share your thoughts on having many active small projects in the comments section below.

Don’t Limit the Role of the Scrum Master

I’ve heard quite a few questions about the necessity and value of having a Scrum Master in an organization. Sometimes, the role of the Scrum Master is combined into the engineering manager role or any other technical role which would create a conflict of interest. These questions are born either from a poor knowledge of Scrum or a misunderstanding of the principles and values behind it.

However, there are some people who limit the role of the Scrum Master and follow exactly what is written in relevant literature. That’s another problem that affects the community of Scrum Masters in general: the Scrum Guide tells you what to do in overall terms, and it’s your responsibility as a Scrum Master to go beyond that and bring value to both the company and the team. There is never a one-size-fits-all recipe; every team and company has different missions, people, values and cultures.

In this post, I’m going to share some tips and practices to help other Scrum Masters excel in their role and add real value to their organization.

Challenge the Process

As an enthusiastic Scrum Master, challenge the process of the entire company and lead the organization to embrace the agile mindset, principles and values (such as commitment, focus, openness, respect and courage).

Push not only toward continuous improvement, but also toward continuous adaptation. The Scrum Master is accountable for adapting the process in respect of the business strategy and mission.

In certain occasions, perhaps for operations/infrastructure/maintenance teams when it makes sense and is appropriate, the Scrum Master can streamline the process and turn it into a Kanban method. The Scrum Master will benefit from other agile methods, tools and practices as well. Continuous learning is essential.

Coach the Engineering Practices

If you are a Scrum Master who has a good technical background in software engineering, or if you develop some code in your free time, try to foster and coach technical practices within the team, such as continuous integration, continuous delivery, pair programming, test-driven development (TDD), automated acceptance testing and refactoring.

For instance, continuous delivery is a very valuable practice that will allow the team to deliver features into production more often and get better feedback from the stakeholders. Your team code will obtain both quality and performance with the introduction of these engineering practices.

Communicate With Stakeholders

Be the conduit among business and technical stakeholders, make sure the communication is fluid and well understood and spread the knowledge of Scrum. Engaging the stakeholders and making sure they are all on the same page is important for the health of the product. Teach them how to maximize return on investment (ROI) and meet their objectives.

Peer With the Engineering Managers

Help the engineering managers with the team’s performance reviews as necessary.

Encourage them to empower the team and provide any type of support needed. The Scrum Master can also help to expedite the hiring process by finding candidates who would be a great fit for the team.

Educate new engineering managers, product owners and team members on-boarded in the company. Whenever a new person is hired, the team will need to be restructured again to be balanced and continue working efficiently. The Scrum Master is needed to provide training and coaching during that restructuring period.

Scale Scrum and Agile

Scale up large products into multiple agile teams, integrate the pieces all together and promote training to spread the knowledge of Scrum and agile. Help business people to understand the framework. Get them involved and obtain feedback frequently, listen closely and take immediate action. 

Create and foster communities of practice for product owners, Scrum Masters, engineering managers and development teams. Agile is all about collaborating with other teams and people, sharing good practices and learning lessons.

Learn new practices continuously and experiment with them with the teams. There is always a new technique to apply from the Scrum experts, so don’t hesitate to be curious. 

Promote hackathons and dojos to drive innovation and excellence. Both the company and the teams will gain significant benefits from hackathons. People will have an open time to expose their ideas, and the company will have the opportunity to hear those ideas and possibly implement them.

On the other hand, a dojo is a powerful technique to improve your skills, grow up and be more efficient. For example, you can facilitate a coding dojo for new hires and bring experienced software engineers to hook up with them. The newbies will get to see how coding is done in the company while simultaneously bonding with senior-level engineers. It also enables the transfer of knowledge.    

Nurture Scrum structures with high-level managers and executives. Show the benefits of Scrum to them and speak up. Don’t be intimidated by them; if you are seriously passionate about Scrum, you can influence and lead the entire organization to the next level.

Work Closely With Product Owners

While helping the product owner to enhance the product backlog, why not contribute to the backlog and innovate with some new insights and ideas? A great Scrum Master takes an opportunity to understand the business context and drive every decision based on it. Each team and each product require different strategies and, again, no one recipe is a good fit for every team.

Moreover, a great Scrum Master focuses on improving the agile approach the product owner is taking, thereby providing templates and tools for the product roadmap, business-driven development (BDD), Business Model Canvas and mockups/drawings.

Streamline the Scrum Ceremonies

Improve the way retrospectives are held depending on the situation and phase of the product/project. There are several different types of retrospectives that can be conducted to extract the right pain points and identify action items to be tackled.

Call each ceremony a “conversation,” since development teams typically prefer conversations rather than meetings. Remove waste in each conversation and invite people with an effective purpose and clear agenda. If possible, take the team to demonstrate the user stories as soon as they are done by the team. Coordinate with the product owner on what is proposed to be brought during the sprint planning and do your best to make it efficient. 

Assist the Development Team

To remove waste, bureaucracy and unnecessary work assigned to the team, take ownership. In some cases, they need someone to take accountability of the change management control due to compliance regulations or something similar. I once faced a situation in which a company needed to create some documents and present the changes planned to be released into production. It was not rocket science, but it took time and focus from the team.

Run team-building exercises to connect with each other in a positive atmosphere, cultivate happiness across the team members, celebrate each milestone reached and resolve conflicts in a collaborative way.

Collaborate With Other Areas and Departments

There are some companies that have a PMO (project management office), and the Scrum Master can help turn it into an Agile PMO with KPIs and metrics that make sense in terms of deliverables.

Moreover, the Scrum Master can conduct process improvements on the business side and influence them to implement Scrum as well. Scrum is not only for software; it can also be applied in marketing, finance, accounting, HR and many other places. Spread it across the organization.


We used to limit the Scrum Master role according to the parameters provided by literature. However, this is not enough: the world is evolving and demands flexible frameworks adapted to the circumstances of the company and the market in general. One particular method might fit very well with one team, but may not work for another team, it really depends on several factors, such as product, people, technology, company and market. The basis is taught, then from there, you will adapt, experiment, learn and evolve. 

From the topics depicted above, there is a common sense that the Scrum Master role is a long-term assignment and will never end. The success of the Scrum Master relates to the value that it brings to the organization as a whole, as well as the level of happiness the team is experiencing: they are learning, delivering, feeling safe and awesome, working at a sustainable pace and not disturbing their personal lives. Even the best high-performance team can benefit from the Scrum Master role.

After reading all these tips, do you still feel that the role of Scrum Master can be replaced or discontinued? Do you believe that the success of a Scrum Master occurs when the team doesn't need him/her anymore? There are tons of different ideas to be accomplished by a Scrum Master. This post listed only a few, and I guarantee that the work will never be done. As always, be passionate about serving others and delivering value.

If you have any doubts, questions or contributions related to the role of the Scrum Master, feel free to let me know in the comments section below.

Are Your Scrum Sprints Becoming a Backlog in Disguise?

Scrum is complex. We all have an “ideal world” in mind as we approach critical projects, but despite our best intentions, reality seldom follows. We can clearly see that some aspects of our Scrum implementation on our current project are not ideal, despite following all the ceremonies to the letter. It just does not work, and we cannot put a finger on a single cause.

Let us take a look at one common symptom of a malfunctioning Scrum process: a lack of motivation for planning meetings. Your team is smart, and recognizes meetings that are not very useful for them. If the problem is not your team, then what is it? This might sound far-fetched, but perhaps the issue can be found in your definition of a sprint.

What Is the Goal of a Sprint? 

This is one of my favorite questions to ask a client in the first interview, because it reveals so much about a client’s approach to Scrum as well as the relationship between the business and development teams. A common answer is, “The goal is to produce as many story points as possible.”

To me, this indicates that the company is looking for heroes who sacrifice themselves for the project. However, this method is hardly sustainable; it’s a very short-sighted approach to a project that might run for several years. Calling out for a hero means that the team will be inclined to add more stories to the sprint than they expect to finish. In the long-run, fewer sprints will be more successful.

Let’s back up one step and reframe the question:

What Is a Successful Sprint?

If the answer to this question is something along the lines of “Seventy-five percent of the stories are finished,” this means trouble. This approach is even worse than the aforementioned maximization of story points, because the team will stop questioning their approach when they hit that 75 percent mark. As a result, the team will stop learning.

But even if the answer is “One hundred percent,” and even if your team is very good at estimating story points, there is a problem. If you expect the team to hit their average number of story points half of the time (see Figure 1), they might feel pressured to be faster and work overtime (as opposed to producing more value for the customer—which is not necessarily the same thing), or take shortcuts on quality (testing and documentation).

An indicator for this problem is that stories finish late, often just before the end of the sprint.

Even if you safeguard the team, forbid overtime and keep quality standards, it’s likely that the team will miss their expected goal and you will end up with an unfinished sprint.

Figure 1: Bell curve showing the distribution of the time needed to finish all the stories of a sprint. Reducing the sprint size will significantly increase the probability of finishing a sprint within the sprint.

Now, what is so bad about the team just managing to get 50 percent of the sprints done successfully? That sounds like a good percentage, right?

A Slow but Deadly Poison

Unfinished sprints are a slow but deadly poison. They will hamper the planning meetings and ultimately the entire Scrum process in three ways:

With many failed sprints, the team loses their feeling of accomplishment. An unattainable goal is as good as no goal—ultimately, over-ambitious goals will make people ignore sprints and instead focus only on assigned tasks. You have added overhead for additional planning. Stories that are worked on over the course of many sprints become more expensive, as their business value remains unrealized and team members must remember again and again what they were about. They also slow down planning of new tasks and impede the focus of the team when selecting the next story to work on. There is constant pressure from the product owner. If the team decides which tasks to work on and in what order, "uncomfortable" (but maybe valuable) tasks might remain unfinished (there is always something "more important" coming up) and dragged along to future sprints. The product owner then must require team members to conduct work in a specific order, and the concept of a sprint again loses its meaning—becoming more like the backlog—and the team loses its sense of responsibility for the sprint. 100 Percent Workload Is a Traffic Jam

Ultimately, it is "management thinking," the idea that 100 percent workload of the team will maximize the business value of the project, that is the cause of sprints being abandoned in favor of the backlog. In that regard, a production process can be compared to a road. On a road, 100 percent workload is called a traffic jam. You can maximize the efficiency of a road only by using more efficient vehicles: more people per car instead more cars. In that regard, buses could be called the “sprints” of the road.

To profit from the advantages of Scrum, keep a buffer of 10 or 20 percent. If your sprint runs two weeks until Friday, plan sprints so that the team is finished on Thursday and free on Friday. From a management point of view, this idea has a scary outlook: your team has completed its work, now what? Do you send them home? Do you have them start another sprint? Do you add new stories to the completed sprint?

It is important to get away from the idea of 100 percent workload being optimal. That is local optimization for a global problem. When the team is done with the sprint, the team is done! Let the team decide what to do with the remaining time.

People are self-motivated, and they generally like to learn. Give them the opportunity to read books, attend conferences or seminars, research recent technologies or just take a break. Use the time for team building, improving the office atmosphere or generally cleaning up things that have piled up (there is always something!). Encourage them to discuss what projects or program parts could be scrapped.

But, most importantly, let it be the team's time. Set the completion of sprints as the goal and allow the team to celebrate their success.

If you are afraid that, with such a positive outlook, they will aim for less and less each sprint, re-examine your own views and ask yourself: “Why are they not motivated to work on the project?” Asking that question is much more productive than trying to coerce your team into working more, which usually just means having them spend more time in the office staring at their computer screen without any tangible increase in productivity.

Don't Just Ask Why

You might even want to try not just asking “Why?” once, but five times, just as Taiichi Ohno did at Toyota, until you find out the actual reasons for their lack of engagement. The team must lead the project; it is theirs. If you are uncomfortable with that idea, perhaps agile methods are not for you. But, if you want to tap into the power of agile, it is essential that the team feels responsible for the product.

Ultimately, like many elements of Scrum, this approach will reveal the actual problems you have in your company. In other words, existing non-agile business processes are seldom “accidents” that are just waiting to be replaced with Scrum. They are the result of a multitude of related problems which can, with Scrum, be named and discussed objectively.


The team lacks motivation for planning meetings.

Aim for 100 percent sprint completion instead of trying to maximize your story points per sprint. Have the courage to plan for fewer story points than what the team can manage on average. Use extra time to finish outstanding tasks, to refactor or to learn about new technologies.

Have you ever seen or experienced a sprint that was more like a backlog? Do you use other methods to make sprints more efficient? Let me know in the comments section below.

Diagnosing Dysfunction Using The Product Backlog

My first car was a ’79 Oldsmobile Cutlass Supreme, and I think I was the third kid in my family to drive it. My friends and I nicknamed it the “old-mobile,” and like any car that could be considered “numerically challenged,” mine had its issues. Of particular concern was an ongoing radiator leak that could cause the car to overheat. 

I quickly learned to pay close attention to the heat indicator light on the dashboard to help me gauge the car’s daily usefulness. Growing up in Texas, you can imagine how this could be a severe problem during the summer months! However, as long as I kept a close eye on that heat indicator gauge, I could determine if I was ok to continue my journey or if I needed to pull over and add extra antifreeze to the tank. If I ignored that gauge, I risked breaking down and derailing whatever plans I had for the day.

Just like that old car, in Scrum we have our own set of indicator lights and gauges. Our ceremonies and artifacts are built in part to help us recognize potential issues before they become bigger problems. If we pay attention to them, we can successfully navigate our course. If we ignore them, we risk breaking down.

In a recent conversation I had with Kert Peterson, he mentioned that when he consults with a new client the first thing he does is ask to see their product backlog and their definition of done. I’ve since come to realize that these two artifacts can be key to diagnosing the health level of a team.

The definition of done (or lack thereof) can tell you quite a bit about what a team considers important in producing a potentially shippable product increment. The product backlog, however, is revealing in a way I had not previously considered and has become one of the main tools I use in coaching a team.

Looking at the product backlog is like looking at tree rings or a core sample: it provides you with an insight into the partnership between the development team and the product owner. A healthy Scrum team exists in a collaborative environment, so the product backlog should reflect this delicate balance.

If there are problems with the partnership between business and developers, you’ll likely notice it in the makeup of the product backlog. Like shorter tree rings in times of drought, a product backlog reveals the work that was done to produce it and how the various personalities of the team members work together.

In some cases, you can see that the product owner has isolated himself or herself from the development team, resulting in a very business-friendly product backlog: stories are all customer-focused, and little regard is given for the technical architecture of the project. Input from the team has not been considered or worse, not solicited.

The partnership in this case is one-sided and the team is simply taking orders. They deliver exactly what’s been requested but are never given the chance to address technical debt or to contribute their own ideas.

The opposite can also be true for a product backlog that is too developer-centric. In this case, you will see a product backlog full of technical stories with more acronyms than a government agency. Stories will likely not make any sense to the product owner, who is trusting that the technical experts know what they are doing even though he or she has very little visibility into what they are working on.

There are likely strong personalities on the development team that have crossed the line from deciding how to deliver the product increment to defining what the product increment contains. 

Of course, there are a thousand permutations between the two as well, each with their own story to tell about how the Scrum team is collaborating and discovering the requirements as they make the journey toward producing the product.

If you know what you are looking for, though, you can look through the tree rings of your product backlog and find the signs of issues that are preventing your team from realizing its full potential. The product backlog then becomes an incredible diagnostic tool for coaches and can reveal where their time is most needed on the team.

While that “old-mobile” has likely found its way into a scrap heap by now, the lessons I learned from it are just as valid today as they were in high school. When you have a valid indicator that gives you an early warning that a problem is developing, it’s wise to pay attention to it and take corrective action. It’s far better to spend the extra time addressing your issues now before they grow and derail your plans down the road. 

What is your experience? Have you ever looked at the product backlog as a diagnostic tool that reveals the health of your teams? What else do you feel the product backlog reveals? Feel free to share your thoughts in the comments section below.