How to Develop a Team Identity with A/B Testing

If you’ve ever been fit for prescription glasses, you’ve no doubt had the experience of the eye exam where the doctor flips between different lens strengths and asks “Is this better or worse than before?” It’s basically A/B testing.

This came to mind after reading a research paper authored by Dan Gilbert and Jane Ebert [1] and listening to Gilbert’s TED Talk, “The surprising science of happiness.” The key bit, as described by Gilbert:

Let me first show you an experimental paradigm that’s used to demonstrate the synthesis of happiness among regular old folks. This isn’t mine, it’s a 50-year-old paradigm called the “free choice paradigm.” It’s very simple. You bring in, say, six objects, and you ask a subject to rank them from the most to the least liked. In this case, because this experiment uses them, these are Monet prints. Everybody ranks these Monet prints from the one they like the most to the one they like the least. Now we give you a choice: “We happen to have some extra prints in the closet. We’re going to give you one as your prize to take home. We happen to have number three and number four,” we tell the subject. This is a bit of a difficult choice, because neither one is preferred strongly to the other, but naturally, people tend to pick number three, because they liked it a little better than number four.

Sometime later — it could be 15 minutes, it could be 15 days — the same stimuli are put before the subject, and the subject is asked to re-rank the stimuli. “Tell us how much you like them now.”

The result was that their previous #3 was ranked as #2 and their previous #4 was ranked as #5. This reflects what Gilbert calls “synthetic happiness.” Having been denied their #1 and #2 choices, experiment participants was forced to “settle” for a lesser choice. However, having made the choice they increased they preference for the lesser choice and thereby synthesized happiness with that choice. Just as interesting, the previous #4 choice was pushed further down the scale as if to put some distance between the previous #3 choice. In effect, distinguishing the decision to take home #3 as clearly the better choice.

All this gave me an idea for something to try with a team I’ve working with that needed to rehabilitate their team identity into something healthier. Typically, teams sour on the idea of going through an exercise like this. The team I was working with was no exception. They likened it to defining team goals – a largely tedious and uninspiring chore.

I wanted to know if I could present two possible team identity statements – A/B style – of which one would be clearly undesirable and another more in line with what I suspect the team may be comfortable. The A/B presentation would keep this simple (presenting a selection of six team identity statements as in the experiment with pictures described by Gilbert would be a non-starter.)

Offering a choice should compel them to chose one over the other. I’m counting on their brains to do what brains do. When faced with a choice, they make one. If I were to present them with a single identity statement and ask “How would you like to change this to be more in line with the identity you want?”, I’ve every confidence the room would be filled with silence.

The very first presentation had a blank page on the left and my intentionally lame and inaccurate team goal on the right.

The team was well aware “no goal” wasn’t an option and wouldn’t reflect well on their performance review with HR and management. My theory was that when faced with an empty goal and one that was inaccurate, they’d suggest something, however minimal, that was an improvement on the initial goal. This is what happened and the team then spent a few minutes tuning the goal into something a little less cringe-worthy. This began the process of converting the goal from the scrum master’s goal to the team’s goal.

Then I deliberately let a week or more pass.

On next presentation, the goal on the left was the goal they chose and tuned previously. The second choice was similar but contained one or two slight modifications intended to move the team’s identity in a more positive and healthy direction. Over the course of several months I tested – A/B/Eye Exam style – numerous team goals. “Which goal do you prefer, the one on the right or the one on the left?”

So we had a start. From here on out it was just a matter of improvement. Keying off of things the team said or did, I’d modify the “accepted” goal and present it as an option at the next opportunity.

The key  or driver in this approach, the hypothesis goes, is to set it up so that the team makes the decisions rather than having something foist upon them. The are virtually guaranteed to reject or strongly resist the latter. With the former, they have ownership in the decision. To reject their decision is to say, in essence, that they made a bad or wrong choice, a bad or wrong decision. In general, people don’t like to admit such a thing so they stick with a decision – for better or worse – if it’s a decision they made and are responsible for.

References

[1] D. T. Gilbert, J. E. J. Ebert (2002) Decisions and Revisions: The Affective Forecasting of Changeable Outcomes, Journal of Personality and Social Psychology, Vol. 82, No. 4, 503–514

 

Photo credit: Max Pixel

Working with Distributed Teams

I’ve coached and served as scrum master for dozens of remote teams over the years. In light of current events, I’ve posted a collation of the notes I have for helping distributed teams working effectively.

The rule is, if one person on a team is participating from a remote location, the team is a distributed team. Making distinctions such as “distributed team” vs. “fully distributed team” when some or all members of the team are working from remote locations risks marginalizing team members who are working at locations away from the home or central office. 

To help ensure that the concept of “team” remains intact during distributed team conditions, this post is intended to serve as a guide for scrum masters for how best to facilitate and monitor team interactions and performance with distributed teams. 

Scrum masters have the added burden of developing the skills within their teams for effective distributed team collaboration and communication. Distributed teams can function better than collocated teams when the team’s skills for organization and communication have been improved by necessity such that they are better positioned to function effectively as a team. 

Etiquette 

 Even with ideal conditions (i.e. plenty of bandwidth for audio and video, intra-team familiarity, clear agenda, etc.) working with distributed teams will always have a degree of asynchronous communication. Fields of vision are limited to what’s in frame for the video camera, network latency issues, and a general lack of access to in-person non-verbal cues will cause people to speak over and interrupt each other and miss-read intent more than they would during in-person meetings. To mitigate these constraints, it is important to have a well understood and practiced set of etiquette rules for distributed team meetings. 

Pre-meeting Tasks 

  • The principle challenge is to keep everyone on the team focused. Shorter, more frequent meetings are better than long meetings that invite participants to “multi-task” out of boredom. Invite essential people to the meeting. Use of a responsibility assignment matrix is a very useful tool for determining who to invite. People associated with the consulted” or “informed” roles generally don’t need to be invited to formal Scrum meetings. 
  • Communicate an agenda – however sparse – prior to the meeting. Let the team know what the purpose and objectives of the meeting are so everyone knows when they are done. Agendas are scope management tools and help keep the meeting focused. Set the expectation the everyone on the team will be aware of the agenda prior to the start of the meeting. 
  • Ensure that all the necessary equipment is in working order and that all team members have verified connectivity. Test screen sharing capabilities and application accessibility prior to the meeting. 
  • It is preferred that the scrum master host the on-line meeting so that on the rare occasion they may need to take control of the meeting by muting or bumping someone from the meeting they may do so. 
  • Set the expectation that team members will participate from a location that is free from background noise and other distractions. Joining from coffee shops or while driving is to be discouraged as they end up being distractions for the entire team. 
  • Coach the team for how to take turns in a conversation. 
  • Coach the team on how to use any mute features. 
  • The rules of common courtesy apply to on-line meetings. If we wouldn’t accept a behavior in a face-to-face meeting, it shouldn’t be accepted in an on-line meeting either. 
  • Turn off notifications from applications such as email and instant messaging. 
  • Meeting participants need to be aware of what’s in the visual and auditory background and work to anticipate and mitigate potential interruptions.

In-Progress Meeting Activities 

  • Continue to stress that team members be on time for the meeting. Set the expectation that they will join on-line several minutes early to accommodate any last-minute technical issues. 
  • Meetings serve both a practical and social purpose for distributed teams. Allow time for casual conversation (and still expect everyone to be one time) as it is critical to building and maintaining rapport among distributed team members. Small talk, catching up, sharing interesting news bits, interesting (short) stories – any of these helps make the on-line meeting a more enjoyable experience and help set a positive tone for the duration. 
  • If a team member joins a meeting late, they should not announce to the team they have arrived. Doing will potentially disrupt a conversation already in progress.  
  • When a team member needs to contribute to a conversation while others are talking, the best approach is to state, “I have a comment.” or “I have a question.” and then pause. This serves as a signal to the team that you wish to speak. Either the conversation will naturally break, or the scrum master can listen for a break and offer the team member the opportunity to speak. The natural in-person behavior is to simply start talking. With distributed teams this frequently leads to several people talking at once and a degradation in communication.  
  • Ask for the opinion of someone on the team who has not yet participated in the meeting or has been silent for a period of time. This will help keep them focused on the meeting if they know they may be asked a question. 
  • Team members should leave a comment in the meeting chat window if they need to step away from the meeting for a short time or leave the meeting. Announcing such departures tend to be disruptive, but the team will likely need to know if any team members are not absent from the meeting.
  • Remain attentive to anyone who is dominating the conversation or otherwise preventing others from contributing. 
  • For stand-ups, call out the person who is going to start the conversation. Assign that person the task of choosing the next person to speak and so on until everyone has had their turn at contributing. This will help keep each team member’s attention as they will not sure when they will be called on. Similarly (but less desirable) randomly call on team members and vary the pattern day-to-day. 
  • When conducting a meeting where only one or two people are attending remotely, ensure that both the conference room and the remote individuals are using video. This will allow for additional non-verbal cues to be included in the communication and help keep the conference room aware that one or more of their team members is attending remotely. 
  • Leverage chat for one-off conversations or bringing non-priority items to the host’s attention 
  • If video is in use, be aware of the need for patience when waiting for network latency to catch up with any shared screens. 
  • Start the meeting with everyone on video. After a few minutes for casual conversation and catching up, allow team members to switch off video to reduce bandwidth issues. 

End-of-Meeting Activities 

  • Provide a recap of what was accomplished and identify any of the goal or agenda items were not addressed. 
  • State any next steps. 
  • State any action items and the names of people responsible for completing them. Action items without assigned names are in-action items. 

Troubleshooting 

  • If a member of the team has a pattern of responding to questions with some version of “I didn’t understand the question. Can you restate it?” or they have to be prompted with “Are you there?” due to a non-response, there is a likelihood that they are not focused on the meeting and busy with something else. If the pattern is persistent, the scrum master will need to discuss this with the team member off-line. 
  • Be attentive to the introverts on the team and work to have them contribute to each meeting. Ask them for their opinion or any open-ended question that has more than a yes-no answer. 
  • The metrics a scrum master may use to assess team participation and performance will need to be more robust than the usual data-based and subjective measures. Assessing morale or the presence of intra-team conflict may not be as apparent with distributed teams. Scrum masters may need to meet virtually one-to-one with each of the team members more frequently and asses any time management or morale issues.

References

Additional Articles

How to Collaborate Effectively If Your Team Is Remote by Erica Dhawan and Tomas Chamorro-Premuzic 

SwiftFest Boston ’19: Remote Connections: Fostering Relationships in Distributed Teams

Photo by Tanya Nevidoma on Unsplash (Edited)

The Perfect System in an Imperfect World

With apologies to Winston Churchill,

Many forms of project management have been tried, and will be tried in this world of sin and woe. No one pretends that Scrum is perfect or all-wise. Indeed, it has been said that Scrum is the worst form of project management except all those other forms that have been tried from time to time.

Agile in general, and scrum in particular, has suffered their share of hard yet deserved knocks. But many of these complaints come from people who are expecting perfection, some panacea or magic remedy to what ails their project management world. Often they want this perfection out of the box and miss the hard work needed to implement a relatively simple set of rules and guidelines while shifting from the “old ways” of getting work done.

Consider a flock of geese.

Over the course of hundreds of thousands of years they have worked out an efficient way to migrate. Not perfect, but well adapted to the world in which they live. At the heart of this behavior are several important principles: Shared responsibility, clear communication, and coordinated effort.

Consider Agile similarly. It is a perfect system for an imperfect world. The principles found in the formation of a flock of geese can be found within the Agile Manifesto. Its foundation of assuming the need for experimentation, learning, and adaptation is central to it’s enduring success. If these values are absent from or poorly represented in an organization’s culture, the chances for sustainable success using any methodology are diminished.

Photo by Josh Massey on Unsplash

Friends, Guides, Coaches, and Mentors

The “conscious competence” model for learning is fairly well known. If not explicitly, than at least implicitly. Most people can recognize when someone is operating at a level of unconscious incompetence even if they can’t quite put their finger on why it is such a person makes the decisions they do. Recognizing when we ourselves are at the level of unconscious incompetence is a bit more problematic.

A robust suite of cognitive biases that normally help us navigate an increasingly complex world seem to conspire against us and keep us in the dark about our own shortcomings and weaknesses. Confirmation bias, selective perception, the observer bias, the availability heuristic, the Ostrich effect, the spotlight effect and many others all help us zero in on the shiny objects that confirm and support our existing memories and beliefs. Each of these tissue-thin cognitive biases layer up to form a dense curtain, perhaps even an impenetrable wall, between the feedback the world is sending and our ability to receive the information.

There is a direct relationship between the density of the barrier and the amount of energy needed to drive the feedback through the barrier. People who are introspective as well as receptive to external feedback generally do quite well when seeking to improve their competencies. For those with a dense barrier it may require an intense experience to deliver the message that there are things about themselves that need to change. For some a poorly received business presentation may be enough to send them on their way to finding out how to do better next time. For others it may take being passed over for a promotion. Still others may not get the message until they’ve been fired from their job.

However it happens, if you’ve received the message that there are some changes you’d like to make in your life and it’s time to do the work, an important question to ask yourself is “Am I searching for something or am I lost?”

If you are searching for something, the answer may be found in a conversation over coffee with a friend or peer who has demonstrated they know what you want to know. It maybe that what you’re looking for – improve your presentation skills, for example – requires a deeper dive into a set of skills and it makes sense to find a guide to help you. Perhaps this involves taking a class or hiring a tutor.

If you are lost you’ll want to find someone with a much deeper set of skills, experience, and wisdom. A first time promotion into a management position is a frequent event that either exposes someone’s unconscious incompetence (i.e. the Peter Principle) or challenges someone to double their efforts at acquiring the skills to successfully manage people. Finding a coach or a mentor is the better approach to developing the necessary competencies for success when the stakes are higher and the consequences when failing are greater.

A couple of examples may help.

When I was first learning to program PCs I read many programming books cover to cover. It was a new world for me and I had very little sense of the terrain or what I was really interested in doing. So I studied everything. Over time I became more selective of the books I bought or read. Eventually, I stopped buying books altogether because there was often just a single chapter of interest. Today, I can’t remember the last time I picked up a software development book. This was a progression from being lost at the start – when I needed coaches and mentors in the form of books and experienced software developers – to needing simple guidance from articles and peers and eventually to needing little more than a hint or two toward the end of my software development career.

A more recent example is an emergent need to learn photography – something I don’t particular enjoy. Yet for pragmatic reasons, it’s become worth my time to learn how to take a particular kind of photograph. I need a coach or a mentor because this is entirely new territory for me. So I hired a professional photographer with an established reputation for taking this type of photograph I’m interesting in. My photography coach is teaching me what I need to know. (He is teaching me how to fish, in other words, rather then me paying him for a fish every time I need one.)

Unlike the experience of learning how to program – where I really didn’t know what I wanted to do – my goal with photography is very specific. The difference has a significant influence on who I choose for guides and mentors. For software development, I sought out everyone and anyone who knew more than I. For photography, I sought a very specific set of skills. I didn’t want to sit through hours of classes learning how to take pictures of barn owls 1,000 meters away in the dark. I didn’t want to suffer through a droning lecture on the history of camera shutters. Except in a very roundabout way, none of this serves my goal for learning how to use a camera for a very specific purpose.

Depending on what type of learner you are, working with a mentor who really, really knows their craft about a specific subject you want to learn can be immensely more satisfying and enjoyable. Also, less expensive and time consuming. If it expands into something more, than great. With this approach you will have the opportunity to discover a greater interest without a lot of upfront investment in time and money.

Time Out!

In Estimating Effort – An Explicitly Implicit Approach I stated that time cannot be one of the attributes the team uses to describe what they mean by “effort.” The importance of this warrants the need for a deeper dive into the rationale behind this rule and how excluding time can lead to better predictability for team performance.

The primary objective for coaching teams to think about effort independent of time constraints is so that they can improve their skills for thinking about the actual work involved. Certainly they will spend time completing the work. But the simple passage of time won’t get the work done. Someone has to actually DO something. That something is the effort.

For example, maybe someone on the team says the product backlog item requires a lot of documentation. It isn’t complex and there aren’t any dependencies, it’s just going to take a lot of time – 7 days, maybe. So they want to give that PBI an effort value of 5 or 8 (or 5 or 8 story points, if that’s what you’re using) because it’s going to take a lot of time.

Remember, the purpose of these criteria is to generate a conversation around what the actual effort is. The criteria are just a set of guideposts that help the team hold a meaningful conversation about the effort.  So when someone on a team insists that they estimate using time, I ask them “What are you doing as the time you’ve estimated is passing? Are you just sitting there, watching the seconds tick away?” Of course they aren’t just sitting there. I’m asking the questions to elicit a comment about the actual work they are doing. Maybe they answer with something a little less vague, like “typing words.” That’s good. “What’s the difference between typing those words in a word processor and typing code in Vim?”

Continuing down this line of inquiry usually leads to the realization that typing documentation has many similar traits to coding. It can be complex. It may have dependencies.  It may require research for accuracy and it certainly will need a lot of debugging (professional writers call this “editing.”) Coders typically don’t like writing documentation. To them it’s just about the tedium of banging something out that’s not as fun as code. Sussing out the effort like this will lead to better acceptance criteria and definition of done associated with the PBI.

The downside of time estimates is that they hide all manner of sins and rabbit holes. The planning fallacy, precision bias, availability heuristic, and survivorship bias are just a few of the mental obstacles guaranteed to reduce the accuracy of time estimates. Or you may have to deal with a team member who wants to estimate using time because they know full well it offers the opportunity to hide slow work. (Gamers gotta game.) When teams have run the gauntlet of effort criteria, they are more likely to end up with a better picture of how much work they are being asked to do when time is excluded from the conversation. Effort criteria force the team to be more explicit about the activities they are engaged with as the clock ticks.

The investment in identifying time-independent effort criteria yields further benefits in the retrospective. Was the team unable to complete a PBI in the sprint? Was all the work finished two days early? Have a look at the effort criteria and ask which of them were a factor in making the PBIs a bigger or smaller effort than initially estimated. This is how teams learn and improve their skill at estimating. The better they are at estimating the more predictable their productivity.

OK, so let’s say you have a team doing a great job of determining the effort needed to complete a PBI and they do so without including time. No doubt, management will be unimpressed. They want time estimates. Good news! We can give them time estimates…in two week increments.

With the team focused on figuring out time independent effort values for every PBI in the backlog and an ongoing experience of how much effort they can reliably complete in two week increments, product owners can provide a reasonable forecast for when the release or project will be complete. The team focuses on accurate time independent effort estimates. The scrum master and product owner worry about the performance metrics and time projections.

It’s surprising how hard of a sell this can be for teams. They are hard wired to think in terms of time because that’s what traditional project management has hounded them for since before coding was a thing. I tell teams, “With Agile and scrum, you no longer have to worry about time. That’s the product owner’s job. But you do have to develop very good skills at estimating effort.” It’s common for them to have a hard time adjusting to the new paradigm.

Goals, Mission, and Purpose

When I was much younger I had an obsession with defining and achieving goals. I’d codified my approach into an unpublished workbook titled “The Goal Mapping Process.” There was nothing particularly unique about this process. All it really accomplished was laying out a method for breaking goals down into achievable tasks and then reassembling them in to the larger goal. It was very tactical and it worked. At least it did for me and perhaps that’s why I never published it. Working out the method within a frame of something that others might see forced a level of rigor that I might not have otherwise applied. In the end, it was just another way of getting things done.

Later in life the realization that completing goals had an element of dissatisfaction came into focus. Achieving goals, even big goals, wasn’t enough. The question of “What next?” frequently presented a blank slate. Figuring out how to achieve the goal kept me busy, but there was rarely any thought about what was after the goal. Or more importantly, what the underlying purpose of the goal was in the first place. What I learned was that a goal in and of itself, while often necessary, wasn’t as important to my overall satisfaction with life than the purpose or mission behind the goal. Goals are destinations. Mission and purpose are journeys.

This realization is perhaps twenty five or more years old. It turns out, defining goals and breaking them down into their tactical pieces is relatively easy. Defining an underlying purpose that makes identifying the associated goals is harder. After twenty five years I believe I have worked out a purpose and mission that has been fairly stable for the past five years.

My mission and purpose was influenced by the story of a woman named Janet. She died in 2005 at the age of 51. For ten years preceding her death she had been fighting breast cancer. For most of that time, her diagnosis was “terminal.” The battle statistics are staggering: 55 chemotherapy treatments, many of them high dose; 33 radiation treatments; 4 major surgeries; and uncounted doctor’s appointments. This and so much more is what it took to stretch a two year survival prognosis into ten.

I know Janet’s story because I was with her for every one of her chemotherapy treatments, the recovery after, and for each of her surgeries.

I know Janet’s story because she died in my arms.

I know Janet’s story because she was my wife.

I taught her how to search for and read research articles using Usenet and the nascent World Wide Web. While I was working two jobs Janet was searching these and many other resources for anything that might suggest viable treatment options. This effort is worthy of it’s own post, but does not factor so prominently in my purpose and mission. What does is something we experienced during this process of research.

Due to our heightened interest, news stories that claimed to have some angle on a “cure for cancer” caught our attention. Whenever we heard such news bites, we’d eagerly take note and then work to chase down the details. Invariably, they would end in disappointment. The news had hyper-inflated the claims of the researchers, often to the chagrin of the researchers themselves. We learned to tune out these news stories (eventually, the news altogether.)

I can recall many times during Janet’s cancer battle when I thought of these researchers. Indeed, of all the people working to solve the cancer conundrum. While Janet slept, I’d watch the milliliters slowly drip from the IV bag during the hours it would take for her chemotherapy treatments to run their course. I’d imagine dedicated individuals working long hours to solve chemical problem or design devices that would eventually replace the barbaric “suicide/salvage” strategy of contemporary chemotherapy. These were often moments of despair and feelings of extreme isolation. We were on the dark side of the moon, hoping for signals that would show the way across the cancer cure threshold and bring us home.

In the end, they never came and Janet lost the battle.

I’ve haven’t stopped thinking about the people who work to find a cure. Fifteen years later I find myself on the sunny side of Earth and in a position to help those working to solve the cancer conundrum. And I have to say, it isn’t how I imagined it would be.

There are certainly those who work long hours with a dedication that is both inspiring and humbling. But for the most part, there are people doing what people do – complaining, fighting for turf, lashing out over imagined offenses, scratching for more pay, finding ways to game the system, sinking to the lowest expected level of effort, defensive and afraid to correct bad behavior, perpetuating bad habits, blissfully unaware of cognitive biases that adversely affect their work, unaware yet aggressively protective their own limitations. It’s a lengthy list.

It is, as they say, a target rich environment for applying Agile principles and practices. The room for improvement pretty much matches the amount of space between here and the dark side of the moon.

One of the primary motivation devices in this environment are the success stories. And as well it should be. They are VERY moving and it’s impossible for me to see and hear the success stories of someone making it across the cancer cure threshold and not shed tears. For myself, there are also many untold stories which are similarly motivating and bring me to tears. These are the stories of those who did not make it across the cancer cure threshold but fought, like Janet, with everything they had while hoping a cure would be found before they lost the battle. The stories of the people who were fortunate to have been cured are examples of what we are trying to achieve. The stories of people who were not so fortunate are examples of why we need to find the most effective way possible for working together.

This is my purpose and my mission: Build teams that are communicating clearly and effectively, teams that understand both the value and limitations of diversity and inclusion, teams that are capable of uniting on well-reasoned goals, teams composed of compassionate individuals who are tirelessly seeking to understand themselves within the wider context and the longer view. Today, Agile principles and practices offer the greatest promise for fulfilling this purpose and achieving this mission. When something more effective emerges, I shall adapt accordingly.

Here’s to moving into 2020 with mind and eyes wide open.

Root Causes

The sage business guru Willie Sutton might answer the question “Why must we work so hard at digging to finding the causes to our problems?” by observing “Because that’s where the roots are.”
Digging to find root causes is hard work. They’re are rarely obvious and there’s never just one. Occasionally, you might get lucky and trip over an obvious root cause (obvious once you’ve tripped over it.) Most often, it’ll require some unknown amount of exploration and experimentation.

Even so, I’ve watch as people work very hard to avoid the hard work needed to find root causes or fail to acknowledge them even when they are wrapped around their ankles. It’s an odd form of bikeshedding whereby the seemingly obvious major issues are ignored in favor of issues that are much easier to identify, explain, or understand.

One thing is certain, you’ll know you’ve found a root cause when one of two things happen: You implement a change meant to correct the issue and a whole lot of other things get fixed as a result or there is noisy and aggressive resistance to change.

Poor morale, for example, is often a presenting symptom mistaken for a root cause. The inexperienced (or lazy) will throw fixes at poor morale like money, happy hours, or other trinkets. These work in the very short term and have their place in a manager’s toolbox, but eventually more money becomes the new low pay and more alcohol has it’s own very steep downside.

Morale is best understood as a signal for measuring the health of the underlying system. Poor morale is a signal that a whole lot of things are going wrong and that they’ve been going wrong for an extended period of time. By leveraging a system dynamics approach, it’s relatively easy to make some educated guesses about where the root causes may be. That’s the easy part.

The hard work lies with figuring out what interventions to implement and determining how to measure whether or not the changes are having the desired effect. A positive shift in morale would certainly be one of the indicators. But since it is a lagging indicator on the scale of months, it would be important to include several other measures that are more closely associated with the selected interventions.

There are other systemic symptoms that are relatively easy to identify and track. Workforce turnover, rework, and delays in delivery of high dependency work products are just a couple of examples. Each of these would suggest a different approach needed to resolve the underlying issues and restore balance to the system dynamics behind a team or organization’s performance.

Broken Windows and Broken Scrum

Recently, I was in a conversation with a scrum master that was of the opinion that correcting teams on all the small details of practicing scrum was the best way to develop them into a high performing team. For example, if someone is a minute late to stand-up, call them out. Or the daily stand-up must not deviate from the “Yesterday, today, and in the way” script regardless how well the team is communicating.

I can see the merits of developing discipline. However, this approach reminds me of the Broken Windows Theory of crime reduction. Without explanation or coaching that includes the rational for practicing scrum in such a way, there is a real possibility for negative unintended consequences.

  • The Broken Windows theory was meant to be applied to situations in need of a reduction of crime. To apply this approach to scrum practices is to imply that any deviation from the scrum framework is criminal.
  • Similar to how the Broken Windows theory resulted in the emergence of “zero tolerance” laws, applying such an approach to scrum teams and strictly enforcing how they may or may not follow the scrum framework is likely to result in a lot of command-and-control zero tolerance behaviors. The guides will become rules and, in turn, inflexible laws.

The approach I’ve found to be more effective is to hunt down the root causes to issues, for which being late to stand-ups or poor communication during stand-ups are a symptom. It’s more like being a big game hunger. Seek out the root of the problem, solve that problem, and it’s likely many of the lesser issues will resolve themselves.