Why You Don’t (and Can’t) Have a Full-time ScrumMaster

Among the most common impediments facing teams and organizations when they are attempting to adopt Scrum is the lack of a full-time ScrumMaster, Product Owner, Team Members in general, and Team Members with testing expertise in particular. The most unexpected thing about this situation is that the degree to which people are not available (or allowed) to play full-time on one Scrum Team is directly proportional to the size of the organization: the larger the company, the less likely it is that full-time commitment to a single Scrum Team will happen.

I’ve been noticing this effect for several years, through training and coaching in organizations of all sizes, from single-team startups to gigantic companies with thousands of people and potentially hundreds of Scrum Teams. Smaller companies in general find it both logical and perfectly sensible to allow – in fact to insist – that everyone focuses on a single role, committing to the organization and to their teammates a single-minded devotion to performing that role at the highest possible level.

The outcome is always a happy one. People love being able to throw themselves into a productive, valuable, purposeful role that creates the best possible product for the company’s customers. Engaging with others to achieve shared goals, both long-term and short-term, also offers tremendous individual satisfaction and generates powerful intrinsic motivation. Being in a position to help make everyone else better through teamwork and commitment is a powerful aspect of Scrum done well.

Bigger Really Isn’t Better

And then there is the other case. Giant companies typically spread their people across at least two or more so-called Scrum Teams. There is no possibility of commitment, focus, or building the essentials of teamwork. Even worse, with their attention constantly divided and distracted, these individuals never get to experience the intrinsic motivation that is one of the most powerful side-effects of working in a real Scrum environment.

One more time, for emphasis: the larger the company the less likely it is that people will be allowed to play on a single Scrum Team full-time, in any role. This situation begs the question: why would small companies, with very limited resources (primarily money) be better at adopting and using Scrum effectively than large companies whose financial resources are effectively infinite in comparison?


Follow the Money

A recent study* published by William Lazonick, professor of economics at the University of Massachusetts-Lowell, pinpoints the root cause of the problem at the system level. Large companies are chronically understaffed because investment of current profits in the future of the company – a key tenet of capitalism – has been replaced by the theory and practice of Maximizing Shareholder Value, or MSV, which demands that companies return not only all of their profits but also much of their cash-on-hand to the shareholders rather than investing in the company’s future products and productive capabilities. The primary engine of this new business philosophy, which emerged from the US competitiveness crisis of the 1980s, is the stock buyback, followed by the more traditional stock dividends.


Professor Lazonick demonstrates, with publicly available financial data from corporate SEC filings, that many of the largest multinational companies’ stock buybacks and dividends actually exceeded corporate net income for the decade 2004-2013. This includes some of the biggest names in technology: IBM, Intel, Microsoft, Cisco Systems, and Hewlett-Packard. What this means is that these and many other companies spent more than they made in profits over the course of that decade just on stock buybacks and cash dividends to shareholders. Even more startling, many of these companies incurred debt, by selling corporate bonds, to finance their share buybacks. The inevitable result is that companies had nothing left over to invest in future products and future productive capacity.

Cash Out or Invest in Innovation?

Innovation doesn’t just happen: it requires significant investments both in the exploration of new products and technologies and in the people who can carry out those explorations. It requires investments in things that may not provide and instantaneous return, such as within the current fiscal quarter. It also demands that people be allowed to apply focus and commitment to their work every day. Innovation also generally demands that people be allowed to work in stable, cross-functional teams, in an environment that encourages experimentation and can tolerate the occasional failed experiment.


So why can’t you have a full-time ScrumMaster, Product Owner, and dedicated cross-functional Team Members? If you work for a large company, the answer lies in what happens to the profits. Is your company on Lazonick’s list? If so, you know the answer.

* William Lazonick, “Stock buybacks: From retain-and- reinvest to downsize-and-distribute.” Brookings Institute, Center for Effective Public Management at Brookings, April 2015. William Lazonick is a professor of economics at the University of Massachusetts-Lowell, where he directs the Center for Industrial Competitiveness. He is co-founder and president of The Academic-Industry Research Network.

No Estimates! Well, Maybe…

A passionate debate about the value of estimates has erupted in the Agile community. Running under the hashtag #noestimates, advocates of ditching estimates and estimating on Agile teams argue that the estimates serve no discernible purpose other than to add overhead to the work of developing product. Even worse, they argue that estimates are overtly damaging to teams, teamwork, performance, and value delivery. Estimates become a weapon in the hands of management, which demands that teams adhere strictly to their estimates regardless of changing circumstances, new knowledge, etc.

I get it. I really do. However, I am still an advocate of estimates and estimating at the team level. Why, you might ask? (Please do!) Well, here’s the thing. Any tool – and make no mistake, estimates are simply a tool – can be misused, abused, or weaponized, but that doesn’t necessarily mean we simply stop using any and all such tools out of fear of their being abused. If that were the case, we wouldn’t have money, credit cards, the Internet, cars, electricity – you get the idea.

So back to #noestimates. I find that, with proper guidance, teams and organizations make excellent use of estimates as a planning tool. Release Planning, Sprint Planning, daily planning, and even portfolio planning all tend to work much better, be more understandable and transparent, when there are team-based estimates backing them up. It is also very clearly the case – in my experience – that teams gain a great deal from the exercise of estimating using a whole-team, consensus-based estimating technique such as affinity estimating or Planning Poker® (a registered trademark of Mountain Goat Software, LLC). And yes, I even like the traditional modified Fibonacci sequence (1,2,3,5,8,13…).

PitchforkManSo when do I come down on the side of #noestimates? The instant the organization, management, or any other force uses the estimates as a stick to beat the team, I am done with estimates. And yes, I have recommended that teams drop the assignment of numeric estimates or any other sizing in that case. I still want the teams to engage in estimating-like discussions of work items for the learning that takes place, but the estimates can go away.

And yes, I have taken my case to management when estimates have become a stick used to beat the teams. And yes, I have been successful in helping management understand that abuse of estimates is a Very Bad Thing and have facilitated a change in behavior. I have also been invited to leave coaching engagements as a result of insisting on the appropriate use of estimates. I thought that was an appropriate instance of applying a Scrum value: Courage.

What is your experience with Agile estimating techniques and the resulting estimates? I’d love to hear from you!

All for now….


A Higher Purpose

When agilists talk about the reasons to adopt an Agile approach, whether Scrum, XP, Kanban, or any of several others, we typically focus on benefits to products, customers, and the bottom line. We also talk a lot about the benefits of working at a sustainable pace, working in self-organizing, collaborative teams, and building a culture of change and improvement. Sometimes we talk about creating a work environment that builds and maintains high morale and, to the extent that such a thing exists in the 21st century, bilateral loyalty between individuals and the organization.

These are all important considerations. Most of them contribute directly or indirectly to improving the working lives of everyone in the organization, which is one of the primary reasons that I am such a strong advocate of Agile. But I think there is a higher purpose  Agile fulfills that we, as agilists need to recognize and promote.

It’s neither trendy nor popular to talk about what used to be widely known as the “social contract”* in a capitalist economy. The idea was that there existed a mutual commitment between corporations and society at large. Society made the commitment to support and encourage corporate success by a) supplying the brain power and labor that corporations used to build products, and b) constructing a regulatory environment (in democratic societies at least) that did not unduly constrain the corporations’ ability to innovate and make a profit. The corporate commitment was to enhance society by providing stable employment at a rate of compensation that would allow the entire economy and society at large to thrive. This is Adam Smith’s “invisible hand.” Henry Ford, for all his other glaring faults, understood this concept instinctively. He recognized that stable employment and good pay for his workers was good for business.

Yes, I know this is a huge simplification of the concept and reality of the social contract, but for me this is its essence.

So what does the social contract have to do with Agile? That’s where the higher purpose comes into play. A long time ago, W. Edwards Deming formulated what came to be called the Deming Chain Reaction. Basically, the Deming Chain Reaction states that as a company increases the quality of its products, costs drop and productivity increases due to reduced rework, market share increases, the company stays in business, and – here’s the key – provides more jobs to produce yet more high-quality product in a never-ending cycle.

The Deming Chain Reaction is a manufacturing model, but it works equally well, with a few tweaks, for Agile software development.


The point is that as organizations apply Agile frameworks, practices, and techniques to improve quality, to implement continuous improvement within the organization, the Deming Chain Reaction comes into play. Companies that adopt Agile conscientiously, comprehensively, from end-to-end of the value stream, do far more than simply stay in business – they thrive. And in thriving, they help the communities in which they operate to thrive as well – or at least that’s the Deming Chain Reaction model. Making a profit is simply not the point. Profitability is necessary, but it’s a means to an end, not the end in itself anymore than agility is an end in itself.

Agile offers the path to success for companies large and small. The higher purpose of that success – and by extension of Agile itself – is for organizations to create employment that is challenging, interesting, dignified, fairly compensated, and widespread, and in so doing to reflect back on their communities and society as a whole the values and principles that produced that success in the first place. To my mind, that is the higher purpose of Agile.

*Note that this is an economic social contract, not the political Social Contract of Locke or Rousseau.

All for now….


A Heuristic for Task Work

My rule of thumb for Task work – and one I highly recommend Teams adopt as a part of their Team Working Agreement – is as follows: Every Team Member’s name appears on one and only one in-progress, unblocked Task at a time.

This rule does not preclude multiple Team Members from working on the same Task. It does preclude any Team Member from signing up for or attempting to work on more than one Task at time. And that’s the point. Single-item flow is the most effective, most efficient way known to develop a product.


This example (partial) task board shows the task heuristic in operation

The result of this simple rule is that no one is working on more than one Task at once, meaning no one is attempting to engage in multitasking. Another result of this simple rule is that Tasks not yet in progress are available, by virtue of the fact that they live in the To Do column on the Task Board, for any Team Member to work on, until one or more Team Members sign up for the Task. This simple visual cue helps the Team see what needs to be worked on and also helps drive cross-functional behavior on the Team by making it physically possible for anyone to sign up for any available Task.

Excerpt from The Agile Team Handbook, page 139.

All for now….


Visualizing Cross-functionality with a Team Spectrograph

Cross-functionality is a key characteristic of agile teams. The benefits of cross-functionality are well-known, so I won’t go into that here. But how can you tell if your team is cross-functional? How can you help your team become more cross-functional? How can you tell if you’re making progress? All good questions. Fortunately, there is an answer.

Cross-functionality within a team doesn’t just happen, it has to be deliberately and thoughtfully nurtured. So let’s live the principle of Transparency and make it visible! A tool that I have found highly effective is the Team Spectrograph. A spectrograph plots amplitude against a segment of the radio-frequency spectrum. We can do the same thing with team skills, that is, plot the skill levels team members possess (the amplitude) across the spectrum of skill sets the team needs to have.

Here’s how it works. On a white board or tear sheet, draw a standard x-y graph. On the x-axis, list the skill sets the team needs in order to deliver the work it is being asked to do, each skill representing a tic mark along the x-axis. On the y-axis, draw evenly spaced tic marks from 1 to 10, with zero represented by the baseline of the graph. Then, have each team member self-assess his or her skill level on that one-to-ten scale across all of the skill sets depicted. Have each team member use a different color marker and voila! – you have a team spectrograph that captures your team’s cross-functionality as of that moment in time.

The example above depicts a team that is well-balanced across the needed skill sets, but lacks cross-functionality. The independent, non-overlapping peaks represent skill silos within the team.

This example depicts a team that is completely lacking the “Docs” skill set.

Using the Team Spectrograph to Grow Cross-functionality
Now that you can take a snapshot of team cross-functionality, you can take a new snapshot at a team Retrospective every three months, for example, to see progress and indicate areas where the team needs to focus on extending its cross-functionality. Using the first spectrograph above as a starting point, the following four depict the conscious development of team cross-functionality over the course of a year.

After three months…

After six months…

After nine months…

A year later…

Notice how all of the lines have come off the bottom of the graph indicating that every team member has at least some level of skill in each area. Notice also that the many skill areas have pegged the spectrograph. A side effect of transferring skills throughout a team is generally the enhancement of core competencies among team members. In order to teach someone else, we have to get better at what we already do best.

Team members can use their Team Spectrograph as a reminder to focus on techniques that build cross-functional skill sets, pair programming being the single most effective one I know of. The Team Spectrograph is also a reminder that cross-functionality doesn’t just happen – teams grow and nurture their cross-functionality deliberately – one task at a time.

Another benefit of the Team Spectrograph is that it points out individual skills other team members were unaware of. Now that the full range of skills team members possess is visible, the team can take full advantage of its extant cross-functionality.

All for now….


I will be presenting this topic at the Atlanta Scrum Gathering, May 7-9! We’ll have fun learning more about cross-functionality and building a real Team Spectrograph!

Good teams are like good code: Highly Cohesive, Loosely Coupled

The best Scrum teams I’ve worked with have been reflections of the code they produced: highly cohesive — meaning focused on a project or product — and loosely coupled — having minimal direct dependencies on other teams. Like excellent code, excellent Scrum teams don’t just happen; it takes careful planning and continuous attention to detail.

Let’s start with high cohesion. The highest performing Scrum teams are initially built around a purpose, a specific project or product, and allowed to focus exclusively on that project or product. But after that the team’s design is emergent, adapting to changing circumstances and increased knowledge about teamwork, the domain, and the product. Like a well-designed class, the team is directed at its purpose and resists attempts to redirect it. Once the current project or product is complete, the team can take on a new project or product, just like a cohesive class can be instantiated repeatedly. The key is that, like a cohesive class, the team is focused.

Great Scrum teams are also loosely coupled to other teams. What this means is that a great team has very few dependencies on other teams, that is, the team can complete its work without waiting on outside experts or the work of other teams. I can already hear the objections: “Okay, so a great team contains all of the skills and knowledge needed to complete its own work, fine. How can you keep even the best team from waiting on other teams to complete their work?” Okay everyone, turn your eyes to the Product Owners in the room.

A great team must have a great Product Owner. The best Product Owners ensure that their team’s backlog is independent of the backlogs of other teams. Even more, a great team of Product Owners can decouple the backlogs of all teams to the maximum extent possible, ensuring that all of their teams, like all of the objects in a well-designed application, only access each other through well-defined interfaces that minimize dependencies.

The next time you survey your organization’s Scrum teams, think like a software architect and work on making your teams highly cohesive and loosely coupled!

All for now….


Don’t be like Homer Simpson

“In times of trouble, go with what you know.”
–Homer Simpson

Words of wisdom from a notoriously brainless cartoon character seem like an oxymoron — and in fact that is the case. Unfortunately, Homer’s prescription is something I experience over and over again with client organizations. In the midst of a difficult and challenging change, like moving the organization from a sequential development process to Scrum, there is strong temptation to fall back on old habits of mind. Whenever things get uncomfortable, whenever Scrum makes a long-standing problem unbearable, the knee-jerk reaction is to ditch the part of Scrum that “caused” the problem and revert to a previously learned behavior.

One example I have experienced repeatedly is the problems caused by a widely distributed Scrum team, that is, one with some team members in North America while others are in China or India. I recently ran across an issue in which the more experienced North American team members were attempting to work with freshly minted graduates in China who lacked even the slightest shred of domain knowledge. Since the time shift in this case was exactly 12 hours, it was impossible for the team members to work together closely. Not only were there twice-daily hand offs of code between team members in the different geographies, there was also the issue of the Chinese team members lack of experience in the domain.

The response from the domain-expert team members in North America was to clamp down process on their young Chinese peers. Over time, many gates had been constructed to prevent the Chinese team members from doing any damage to the code base. By the time I arrived on the scene, the gates were so restrictive that the Chinese side of the team — and make no mistake, each geography had taken sides — was unable to do any work at all. Even the simplest tasks were impossible to complete without involving the North American side because of the gating requirements.

A better solution, which the organization actually implemented, was to create separate North American and Chinese teams. While this by itself did not solve the bigger issue of domain knowledge being restricted to the North American team, it did allow both teams to work with a degree of independence and to finish the work they committed to each Sprint. The one major adjustment was to have the Chinese team work in one-week Sprints while the North American team worked in two-week Sprints. Shorter Sprints forced the Chinese team to break its work down into very small bites that the North American domain experts could then help with during the short window of overlapping availability each day. By limiting the range of variability — implementing one-week Sprints — the organization was able to move forward with new feature development much more quickly than had been the case with a distributed team and a multiplicity of gates for the Chinese team members’ work to pass through. The organization also unknowingly implemented one of W. Edwards Deming’s credos, that of changing the system to reduce variability. More on that topic in a later post….

All for now….


Got a Morale Problem? Get Quality!

The connection between product quality and morale isn’t a big mystery, but it seems to be one that is frequently overlooked. W. Edwards Deming and, somewhat later, Frederick Herzberg famously linked the sense of accomplishment people experience when doing good work on projects over which they are able to control how the work is done with high morale. Scrum’s emphasis on delivering a working product increment at the end of each Sprint fits into the morale equation perfectly.

So what’s the problem?

We don’t always do as we should. When teams are pushed to take on more work than they can competently deliver, quality is the inevitable casualty. Teams that find more and more of their capacity sucked away by bug-fixing rapidly experience significant, sometimes catastrophic, declines in morale. With morale goes innovation, productivity, and continuity as people seek to flee the bug storm.

An even worse situation occurred in one company’s misguided attempt to focus on its defect backlog while at the same time delivering new features at their accustomed pace. The solution they settled on was to create a bug-fixing “team” — actually a large work group — that would, in essence, clean up the messes left by the over-worked feature group. Freed from the responsibility for the quality of their work, the feature group delivered a large number of features. Unfortunately, the feature group’s freedom from responsibility produced a product strangled by defects which the poor souls on the bug-fixing work group couldn’t hope to save. Both sides blamed the other for the rotten product quality and morale throughout the company hit absolute rock-bottom. An attempt to introduce Scrum into this situation failed because of the maelstrom of blame, mistrust, horrible morale, and fear of change.

The highest morale I have had the privilege to share in occurred on Scrum teams that were allowed to play by the rules of Scrum: only pulling in the work that the team members could commit to, failing tests were simply an indication of “not done,” and nothing that was “not done” ever saw the light of day. The company provided adequate support for continuous integration, TDD, refactoring, and other good engineering practices, which allowed the teams to work without fear of unintended consequences. When a bug did surface, as bugs inevitably will, the team that produced it was responsible both for the fix and the tests to prove the fix. The teams in this organization felt the same degree of ownership and satisfaction when fixing bugs as when developing new features. In short, their morale was in the stratosphere. Their quality was also spectacular.

So the next time you notice one or more teams suffering from poor morale, work on quality. Fix the quality problem and the response to an inquiry about morale will almost certainly be “what morale problem?”

All for now….


Is it a Group or a Team?

This question often occurs to me when I’m on training or coaching assignments. The provocation is usually a statement similar to the following: “We have a development team of 250 highly skilled engineers….” or “Our QA team just can’t seem to keep up with development….” or “The business analysis team writes all of our requirements….” or “Our middleware team serves multiple simultaneous projects.”

It is common usage to apply the term “team” to mean any collection of individuals who perform some related function, regardless of how those individuals actually work. To me, a team is a very specific type of human organizational unit, defined by how it works, rather than by what it works on. Simply put, teams are distinguished by teamwork. I have even, very occasionally, encountered fair approximations of cross-functional Scrum “teams” that fail to meet this most basic definition.

Teamwork describes a particular way of working toward a shared goal. I have distilled the essential characteristics of teamwork into the following (incomplete) list:

  • sublimation of individual ego and need for recognition to the needs of the team
  • sharing and balancing workload dynamically at daily or finer granularity
  • individuals offering and requesting help in an environment of trust
  • willingness to make personal sacrifices in support of the team
  • recognition that the team’s goal outweighs (but does not exclude) individual goals

I’m certain there are many more traits that one could apply to describe teamwork, but this works for me as a starting point for the discussion. The key distinction I see between a team and a group is the collaborative effort a team engages in to meet its collective goal, for example, a Sprint commitment. A group, on the other hand, may indeed consist of skilled, well-intentioned individuals, but without a collaborative framework and a collective goal, teamwork is absent. The common example is the group of developers, each individually working on their assigned tasks, head down, blinders on, either unable or unwilling to share the load with their fellow group members. Sure, they’re all working toward the same end point, but on parallel tracks that by their very nature cannot converge. Group work results in the standard array of dysfunctions and failures that characterize traditional software projects.

Implied in my list of teamwork traits is a self-organizing, empowered team that has the authority to set its own commitments and determine how best to meet those commitments. Another implication is that a team is small. The standard Scrum guideline for team size (seven plus/minus two) has always worked brilliantly in my coaching experience.

So the next time you hear a client or colleague talking about a “team,” make sure you know what they really mean: Is it a Team or a Group?

All for now….