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.

What Trust is Made Of

Dysfunctional Teams

Some years ago, when the team I was on was starting to Scrum, I dove into agile. A whole world opened up for me. It was like somebody had written down what I’d been carrying around as wishful thinking for quite some time. About a year later I was getting rather frustrated. We were doing Scrum and were pretty good at delivering working software every iteration, but other than that we weren’t really being agile.

I spoke with several people about my experience. J.B. Rainsberger was one of them, and after hearing my description of day-to-day life at the office, he recommended Patrick Lencioni’s "The Five Dysfunctions of a Team" to me.

Hit the nail right on the head, he did.

Improving Trust the Lencioni Way

“The Five Dysfunctions of a Team” explains what lack of trust in a team can lead to, and how the consequences can seriously affect the bottom line. If you haven’t already, I recommend reading this book. The parable is a nice read even if you are not interested in dysfunction or trust. If you are, it will give you a lot of food for thought.

At the back of the book, Lencioni provides tools to assess your team’s health and discusses how to remedy each of the five dysfunctions. When I first read this book, I was quite taken with all his advice. After digging into the concepts of trust and vulnerability a lot further, it impresses me less. To start rebuilding trust, Lencioni mentions a number of techniques:

Personal history exercise Team effectiveness exercise Personality and behavioral preference profiles 360 degree feedback Experiential team exercises

One problem I have with them is that using these techniques means calling meetings. When you are the leader of a team, you may be able to get away with calling a meeting and doing the exercises “because you think it’s a good idea.” But, when you are “just a grunt” like I was at the time, you have to convince the members of your team to take part. That involves broaching a subject that is thorny at the best of times and positively hazardous at the worst.

A second problem is that each of these exercises themselves requires a willingness to open up. That’s not going to be easy in a situation where there is little trust to go around to begin with.

Lastly and most importantly, these exercises focus on connection and mutual understanding. While these are important in allowing trust to grow, they don’t constitute trust itself. It really doesn’t matter how much I know about your private life, your personality, your behavioral preferences or how many shared experiences we have; if your behavior remains such that I cannot count on you, the likelihood that I will trust you will remain slim indeed.

What is Trust?

If connection and mutual understanding are not trust and don’t necessarily lead us to trust each other, then what is trust? What behaviors would signal that you could trust me if you’d be willing to do so? What behaviors would inspire you to trust me?

I found the answer to these questions quite serendipitously.

On one of my browsing adventures, I happened upon Brené Brown’s “Listening to Shame” TED Talk in which she shares her experience with her TEDx Houston talk, “The Power of Vulnerability.” This led me to take part in the first ever “Living Brave Semester.”  In the lead-up to that, we all received a free pass to Brown’s class, “The Anatomy of Trust.”  

The main video of that class (which is freely available) provided me with what I felt was lacking in all other discussions about trust. Where other discussions of “building” trust always feel like they are overcomplicating things or confounding trust with connection, the Anatomy of Trust is powerful in its very simplicity (see my blog post, “Myths and Misconceptions About Trust” for more on this matter).

“The Anatomy of Trust” is outlined with the acronym “BRAVING:”

You respect my boundaries, and when you’re not clear about what’s okay and not okay, you ask. You’re willing to say no. Reliability
You do what you say you’ll do. At work, this means staying aware of your competencies and limitations so you don’t overpromise and are able to deliver on commitments and balance competing priorities. Accountability
You own your mistakes, apologize, and make amends. Vault
You don’t share information or experiences that are not yours to share. I need to know that my confidences are kept, and that you’re not sharing with me any information about other people that should be confidential. Integrity
You choose courage over comfort. You choose what is right over what is fun, fast or easy. And you choose to practice your values rather than simply professing them. Non-judgment
I can ask for what I need, and you can ask for what you need. We can talk about how we feel without judgment. Generosity
You extend the most generous interpretation possible to the intentions, words and actions of others. Surprising Realizations

These definitions were a revelation to me. The acronym would not have had half the impact on me if not for the definitions that Brené Brown attached to each word.

I never understood the idea that setting boundaries is simply telling people what is okay and what is not, defining what you like and what you don’t like and saying “No” to inappropriate requests.

It was a shock to realize that my inability to say “No” to requests in general meant I was a lot less reliable than I had previously thought. Since that sunk in deeply, saying “No” has become much easier for me. It no longer means not being nice or cooperative. Instead, it is now tied to improving my reliability and thus my trustworthiness.

Seeing accountability defined like this cleared up a lot of misunderstandings I had about it. Until seeing these definitions I confounded accountability and reliability. As a result, I often shirked “being held accountable” as I thought it meant having to live up to (someone else’s) estimates or targets. Now, I am fine with being held accountable since it is clear to me that it is about owning your decisions and the consequences that come with them.

The vault made me realize that trustworthiness also means not allowing other people to share information with me that’s not theirs to share. In other words: it’s not just about not gossiping yourself, but also about stopping other people from gossiping to you. After all, what they can do with you they can also do to and about you.

I don’t know how or why it got to be like this, but saying somebody was a person of integrity to me simply meant that he or she was honest and sincere. Brené Brown’s definition of integrity made me realize where many trust failures come from. You will be hard-pressed to find anyone in software development who will not stress the importance of quality, maintainability and robustness. Yet, when push comes to shove, managers will ask for speed and developers, including me, don’t stand their ground nearly as often as they should.

Non-judgment surprised me. Without the definition provided, I would have interpreted it to be about not judging other people. However, it is just as much about not judging yourself.

Judgment and a lack of generosity often go hand-in-hand. They are the fastest ways to erode trust. Where failures in all the other anatomic parts of trust may not affect our emotions directly, judgment and less-than-generous interpretations of our intentions hit close to home, perhaps even more so when they touch upon our insecurities. For example, our insecurity about our professional skills, our mistakes and our social skills.

Practical Application

Where Lencioni’s advice to rebuild trust involves meetings and group exercises, “The Anatomy of Trust” can be applied individually. You don’t need anybody else to start adopting behaviors that are (more) in line with BRAVING.

Setting boundaries is the most important practice. Upholding your integrity and being generous in your interpretation of what your teammates say and do is not possible without setting boundaries. You can’t practice your values if you are not setting boundaries around behavior that is not in line with your values, while being generous without setting boundaries is being a doormat – letting people walk all over you.

Practicing reliability may get you some flak. People may at first be taken aback by your candid “No, I can’t do that” or “What would you like me to drop instead?” However, they will soon pick up on the fact that when you say “Yes” you mean “Yes,” and they can count on you to deliver.

Practicing accountability is interesting. Acknowledging your mistakes instead of making excuses or pointing your finger at someone else may feel extremely dangerous, especially when you are in a team with a culture of blame. It takes guts and trust--self-trust. My advice is to take baby steps. Start with acknowledging your mistakes to yourself, then acknowledge a small mistake to your peers: “Oh, darn, I forgot to add that new file to source control. Sorry about that.”

Practicing the vault is pretty straightforward, I’d hope.

Practicing integrity is probably the hardest task. For integrity, you need clarity on your values, especially your core values. That will require some, if not a lot, of self-work. Starting is simple though. Pick one thing you really, really, really find important. Kindness, for example. Then, start showing it more often and start stopping yourself from being unkind. You know what they say: it’s like a muscle, you need to train it.

Practicing non-judgment and generosity aren’t a piece of cake either. Forming judgments and interpreting intentions is built into our system, or at least has been driven into it by our upbringing and education. It’s hard to stop, even when we know it’s not likely to improve our relationships. However, it’s still important to try.

The effect that judgment and lack of generosity have on trust is huge, and is what makes giving feedback so hard. Effective feedback requires you to get past your emotions, focus on observable facts and request what you want and would like to see. I’ve found Jurgen Appelo’s feedback wraps helpful in this.

The simplest way to start practicing non-judgment is to start with yourself. Be non-judgmental about not knowing something. Start asking for help. In the process, you may be met with judgmental responses. Don’t bite and don’t retort. Just say something like “Yes, will you help me learn?” There are no guarantees, as some teams are toxic beyond repair, but I’m willing to bet the judgmental responses will decrease and it may not be long before your teammates will feel safe enough to start asking for help themselves.


The fun part of BRAVING is that as you start practicing it, chances are that your example will spread. Maybe not like wildfire, but the people around you can’t help but notice.

Vulnerability begets vulnerability and trust begets trust.

As you start displaying more vulnerability (like owning your mistakes) and setting boundaries around inappropriate responses (telling people that sarcasm is unwarranted and not very helpful), your teammates will feel safer to follow your lead.

The best thing about it is that you don’t even have to care whether your example is copied.

Practicing BRAVING has done wonders for my self-trust. I now know that I can count on myself to take care of myself, to set boundaries around toxic behavior and to be generous to myself when I stumble. To pick myself up, dust myself off, be self-compassionate and try again when showing my vulnerability is met with harshness.

What BRAVING has done for me, and what I hope it will do for you, is provide an easy-to-remember acronym that shows you what inspires trust. Behave in alignment with the definitions of “The Anatomy of Trust” and your trustworthiness will increase. Behave out of alignment with them and your trustworthiness will decrease. It’s as simple as that.

Be brave and BRAVING!

PS: If you’d like to discuss BRAVING, for example in a retrospective, just Google “BRAVING download.” That should bring up several results for the original BRAVING poster by COURAGEWorks (Brené Brown’s company).