The Emotional Bumblebee

I finished Lisa Feldman Barrett’s book, “How Emotions Are Made: The Secret Life of the Brain,” this past week. It’s the latest exploration in my decades-long journey to better understand myself and others. There’s a lot in this book and it’s been a paradigm shift for me personally. I expect the effects from the insights gained from Dr. Barrett’s work in my professional life will be equally seismic.

As part of this exploration and effort to understand what Dr. Barrett and others are discovering, I’ve been experimenting with different ways to organize and assimilate information. For years I’ve used mind mapping and its served me well. I continue to use this approach almost daily. Ah, but the relentless advancement of technology has resulted in new tools. My current favorite (meaning the one that so far matches how my brain seems to work) is a tool called Obsidian. It’s new and is evolving quickly. I’ve been using Obsidian to organize and study cognitive biases in a way similar to Buster Benson’s work. This past weekend I began a similar process with emotions based on Dr. Barrett’s work.

It’s early but it has already yielded many important insights and benefits. I began by collecting as many words I could find (currently, 514) that are used to describe emotional states or patterns. I then entered them into Obsidian, each connected to a single node, “Words that express emotion.” Here’s a partial screen capture of the Obsidian graph:

The graph is too big to fit on a single screen and have the words show. And Obsidian does not yet have an export feature for graphs into a standard image file. So I’m limited by screen real estate. Where I take this next…I’m not sure, actually. Probably a cycle of refinement and deep dive into definitions and descriptions. I can foresee the creation of a real-time tool for assessing emotional states using a circumplex. Lots of experimentation ahead.

There is a dynamic quality to the graphs in Obsidian that is part of the fun and path-to-insights with the information. I’ve created a video to show the effect and set it to Nikolai Riminsky-Korsakov’s orchestral interlude “Flight of Bumblebee.” If/when you read Dr. Barrett’s book, you will understand why I selected the bee theme. It’s a virtual emotional bee hive inside our heads and bodies. Be sure to expand the video to full screen for maximum effect. Enjoy!

Concave, Convex, and Nonlinear Fragility

Nassim Nicholas Taleb’s book, “Antifragile,” is a wealth of information. I’ve returned to it often since first reading it several years ago. My latest revisit has been to better understand his ideas about representing the nonlinear and asymmetric aspects of fragile/antifragile in terms of “concave” and “convex.” My first read of this left me a bit confused, but I got the gist of it and moved on. Taleb is a very smart guy so I need to understand this.

The first thing I needed to sort out on this revisit was Taleb’s use of language. The fragile/antifragile comparison is variously described in his book as:

  • Concave/Convex
  • Slumped solicitor/Humped solicitor
  • Curves inward/Curves outward
  • Frown/Smile
  • Negative convexity effects/Positive convexity effects
  • Pain more than gain/Gain more than pain
  • Doesn’t “like” volatility (presumable)/”Likes” volatility

Tracking his descriptions is made a little more challenging by reversals in reference when writing of both together (concave and convex then convex and concave) and mis-matches between the text and illustrations. For example:

Nonlinearity comes in two kinds: concave (curves inward), as in the case of the king and the stone, or its opposite, convex (curves outward). And of course, mixed, with concave and convex sections. (note the order: concave / convex) Figures 10 and 11 show the following simplifications of nonlinearity: the convex and the concave resemble a smile and a frown, respectively. (note the order: convex / concave)

Figure 10 shows:

So, “convex, curves outward” is illustrated as an upward curve and “concave, curves inward” is illustrated as a downward curve. Outward is upward and inward is downward. It reads like a yoga pose instruction or a play-by-play call for a game of a Twister.

After this presentation, Taleb simplifies the ideas:

I use the term “convexity effect” for both, in order to simplify the vocabulary, saying “positive convexity effects” and “negative convexity effects.”

This was helpful. The big gain is when Taleb gets to the math and graphs what he’s talking about. Maybe the presentation to this point is helpful to non-math thinkers, but for me it was more obfuscating than illuminating. My adaptation of the graphs presented by Taleb:

With this picture, it’s easier for me to understand the non-linear relationship between a variable’s volatility and fragility vs antifragility. The rest of the chapter is easier to understand with this picture of the relationships in mind.

Estimating Effort – Adaptation

I’ve been running the informed intuition (or if you prefer, “disciplined intuition”)  approach to estimating effort for close to nine months now. For the most part, it has gone very well. The primary objective – inspire and support a conversation around the effort needed to complete a story – has most definitely been realized. Along the way the process has shifted to better support both the conversation and the team’s ability to internalize the process.

Originally, it was proposed that teams rate each of the effort characteristics on a sliding scale – 1 to 10 or 1 to 15, or whatever the team decided was most useful. Feedback from the teams lead to the discovery that it is easier to evaluate each effort characteristic using the modified Fibonacci scale rather than a sliding scale. This provides continuity across the method in that everything about a story’s effort value is considered using the same scale. It also reinforces the rationale behind the use of the Fibonacci scale and seems to facilitating the team’s ability to internalize the method. They are moving more quickly when deriving effort values.

A second adaptation is the use of several sets of characteristics, depending on the type of story, the predominant functional area represented by the team, and the nature of the work. For example, a story that involves the development of a computer board has a different set of criteria from stories that involve the creation of firmware for the board or the UI/UX features of the hardware product. The sets usually contain 3 or 4 common characteristics, such as “complexity” or “dependencies.” However, the hardware board may include something like “part sourcing” or “compliance testing.” This illustrates the importance of having the team deconstruct what “effort” means in the context of their world. When they determine the characteristics, the follow-on conversations about the effort are much more robust and meaningful.

In essence, this method is a reflection of the product owner’s responsibility for the “what” of the story and the team’s responsibility for figuring out the “how” of the story. “What I want,” says the product owner, “is an estimate of the effort involved to complete this story.” The teams effort criteria demonstrate to the product owner how they arrive at any particular value.

Intuition and Effort Estimates

In his book, “Blink,” Malcom Gladwell describes an interview between Gary Klein and a fire department commander. A lieutenant at the time, the firemen were attempting to put out a kitchen fire that didn’t “behave” like a kitchen fire should. The lieutenant ordered his men out of the house moments before the floor collapsed due to the fire being in the basement, not the kitchen. Klein later deconstructed the event with the commander and revealed a surprisingly rich set of experienced-based characteristics about that event the commander used to quickly evaluate the situation and respond. The lieutenant’s quick and well-calibrated-to-the-situation intuition undoubtedly saved them from serious injury or worse.

Intuition, however, is domain-specific. This same experienced-based intuition most probably wouldn’t have served the commander well if he suddenly found himself in a different situation – at the helm of a sailboat in rough water, for example, assuming the commander had never been on a sailboat before.

In the context of a software development environment, a highly experienced individual may have very good intuition on the amount of work needed to complete a specific piece of work assigned to them. But that intuition breaks down when the work effort necessarily includes several people or an entire team. So while intuition can serve a useful role in estimating work effort, that value is generally over-estimated, particularly when it needs to be a team estimate.

Consider work effort estimates when framed by Danial Kahneman’s work with System One and System Two thinking. System One is fast, based on experiences, and automatic. However, it isn’t very flexible and it’s difficult to train. This is the source of intuition. System Two, however, is analytical, methodical, intentional, deliberate, and slower. Also, it’s more trainable. It’s when the things that are trained in System Two sink into System One that new behaviors become automatic. With work effort estimates, we must first deliberately train our System Two using a method that is more deliberate about estimating before we can comfortably rely on our System One abilities.

Once calibrated, any number of changes could signal the need to re-calibrate by employing the deliberate process. Change the team composition and the team will need some measure of re-training of System One via System Two. Change a team’s project and the same re-training will need to occur.

The trained intuition approach to estimating effort develops what Kahneman called “disciplined intuition.” Begin with a deliberate, statistical approach to thinking about work effort. Establish a base rate using the value ranges for the effort characteristics. With experience, the team can begin to integrate their intuition later in the project process. If teams lead with their intuition (as is the case with planning poker and t-shirt sizes), they will filter for things that confirm their System One evaluation. With experience and a track record of success from training their intuition, teams can eventually lead with an intuitive approach. But it isn’t a very effective way to begin.

This method also leverages the work of Anders Ericsson and deliberate practice. The key here is the notion of increasing feedback into the process of estimating work effort. The deliberate action of working through a conversation that evaluates each of the work effort characteristics introduces more and better feedback loops that help the team evaluate the quality of their decision. Over time, they get better and better at correcting course and internalizing the lessons.

It’s like learning to drive a car. A new driver will leverage System Two heavily before they can comfortably rely on System One while driving. This is good enough for most driving situations. However, it wouldn’t be good enough if that same driver who is competent at driving in city traffic was suddenly placed on a NASCAR track in a powerful machine going 200 miles per hour.

A NASCAR track might be where we would go look for expert drivers but not where we would look for competent delivery truck drivers. For work estimates on software projects, we’re looking for a level of good enough that’s a reasonable match for the project work at hand. And we’re looking for better than untrained intuitive guesses.

Thinking Agile about the Pandemic

[Note: The fact that the SARS-CoV-2 virus pandemic is on everyone’s mind has given me an opportunity to expand the scope of topics I may consider on The Agile Fieldbook. Specifically, relating current events to Agile and systems thinking.]

 

I’ve been thinking a bit deeper on the frequent comparison of flu deaths with highway traffic deaths, total US deaths in the Vietnam War, or any variety of raw number comparisons. I’m  working to get at something that feels to be an underlying mis-match in such comparisons.

Part of the challenge is that self-proclaimed epidemiology experts are popping up like Spring daffodils, busy asserting themselves as consummate experts in statistics and government policy while asserting themselves as enforcement authorities. And the Internet has been an amplifier for the echo chambers created by rabble. In short, finding the signal in the noise has become much harder. I can’t recall a time when there has been this much manufacturing and shoveling of confirmation bias around the world. Alas, it’s one supply chain that has grown significantly more robust.

At the heart of the raw number comparisons is a category mistake. Stopping at an equivalence of mortality across all categories for cause of death gives rise the category mistake. Not all causes of death should be considered equal when searching for a course of action that will affect millions – in the case of COVID-19, billions – of people. There are many differentiating factors that could be considered in the case of viral pandemics and traffic deaths. The principle one, in my view, is agency.

I can choose a robust and enjoyable lifestyle that significantly lowers my risk to death due to highway accidents (to use that number for my analysis.) In fact, I have done exactly that. A four mile commute to the office, all on local streets where the highest speed limit is 45 MPH…for exactly 3 blocks. To those that declare “But, many people can’t do this.” my reply is “Maybe.” There will certainly be outliers for a variety of reasons. But in many of these cases, the individuals are nonetheless making choices. Perhaps they don’t want to move or they don’t want to change jobs or they don’t want to up-skill or… There are likely a confluence of many choices in the mix that make it appear they are stuck or trapped. Frequently, even in the outlier cases, when circumstances press hard enough, they “find” opportunities and make changes, perhaps even subsidized by local and federal governments. But that’s a topic I’ll leave for much more qualified bloggers to tackle.

I can make other choices in the form of the car I drive or the route I drive to my destination. I can chose the time of day I drive for errands or the frequency with which I need to run them. I can chose whether to use my smart phone while driving or engage in some other distraction while driving. Or I can choose not to drive at all and take the bus, train, bike, walk, or a combination of any of those.

With a viral infection – as we are learning now – there is virtually no personal agency. The only way to avoid the adverse consequences is to severely curtail our lifestyle. Now. There’s no easing into it. No evening classes at the college annex to up-skill our ability to dodge the virus. No Ecopass that lets us leave the breathing up to someone else. Not much of any choice for replacing a stalled lifestyle with a different one because they’re all stalled.

Which gets me to the thinking behind “Mass transit kills.” It does so because its an efficient vector for transmitting biological infections. The early studies show how quickly COVID-19 spread due to air travel followed by trains, taxis, and buses in crowed urban settings. A fatal car accident, however, is a local event. First responders and surrounding communities are not at risk of death due to the now static car accident. A viral or bacterial outbreak is dynamic and spreads just by virtue of people moving around. Globally, how long would humans have to drive cars before the death toll matched that of the number of deaths that have been attributed to plagues and pandemics throughout history? And historically, plagues and pandemics moved at the speed of rats, mosquitoes, and ox carts. Today, they can move just shy the speed of sound.

Having read close to a couple dozen COVID-19 related research papers (surprisingly, none of them authored by CNN/MSNBC/FOX/CBS/ABC/NBC/BBC et. al.), the chances that we’re approaching a pandemic that won’t offer much of a lead time are increasing. The growth of human population has greatly increased the adjacent possible for animal virus’ to make the jump to humans. The probability of an asymptomatic contagious period combined with lethal morbidity increases as the adjacent possible horizon expands. If such a viral combination were to occur, mass transit will be that virus’ best friend.

My thinking is probably incomplete on this matter, so I welcome your comments.

Strategies for Remote Interviews with Team Candidates

In a recent New York Times column, Adam Grant wrote:

Credentials are overrated, and motivation is underrated. It doesn’t matter how much experience people have if they lack the drive to think creatively, work collaboratively and keep on learning. We’re not just hiring people to do a job today — we’re hiring them to make their team and their organization better tomorrow.

Once upon a time – last century, actually – employers could rely on the conferring of a college degree as evidence of a certain level of competence in the degree subject. In some areas, this is probably still true. Generally speaking, this would apply to the scientific areas of study: chemistry, physics, mathematics, etc. Unfortunately, even these area are becoming suspect as academic rigor is eroded in the interests of removing perceived barriers to this or that special interest group. To be very clear, I’m referring to the importance of thorough and complete understanding of the subject. The mine field that academia has become is indeed rife with self-inflicted and often insurmountable barriers to learning. The egregious rise in the cost of tuition, grade inflation, and credential dilution are but a few examples.

There are other factors in play. The speed at which society moves in the 21st Century is simply too fast for the four-year degree to to have any hope of staying relevant, let alone keeping up. Almost every major university offers free courses in a wide variety of subjects so it is possible for a high school graduate to craft the equivalent of a Bachelors or Masters and complete it for a fraction of the cost and in half the time. Ah, but without having completed the paper chase, how can such an industrious individual establish for a potential employer that they have the requisite competence?

Adam Grant has it right. Credentials are overrated. So how can we assess the quality and potential of team candidates? Grant identifies three key mistakes interviewers make in the interview process.

  1. They ask they wrong kinds of questions.
  2. They focus on the wrong criteria.
  3. They’re overly influenced by the best talkers.

If, as Grant suggests, job interviews are broken than conducting remote job interviews in the midst of a pandemic are significantly more challenging. In this post, I wish to speak to the second mistake identified by Grant and write about what we can do to identify our criteria, what we can do during an interview to elicit information about the candidate’s qualifications, and a strategy for improving the efficacy of remote job interviews.

Identify Important Criteria

For the sake of example, we’ll engage in a little time travel into the future and imagine having hired the perfect product owner candidate. What tasks encountered in your work day are no longer an issue with the new candidate on board? Is the product backlog now well-maintained and in a healthy state? Does the sprint runway extend out 4-5 (or more) sprints? Has a stable sprint velocity emerged (suggesting that the user stories are of higher quality and understood better by the team)? Do conflicts between areas of the business occur less frequently than in the past? Are stakeholders pleased with the results they see at sprint and increment reviews?

If our example were for a scrum master candidate, we would ask ourselves different questions for eliciting important criteria for the position. Is there less conflict among team members? Does the team understand the purpose and value for determining the effort involved to complete a user story? And again, has a stable sprint velocity emerged?

In addition to considering what hasn’t been working well (and therefore illuminating what skills you want a candidate to bring to the table) it is also important to include what has been working. It will not serve the organization if one set of problems are swapped for another. Perhaps, for example, the previous product owner was well liked by the team and helped the team maintain a positive morale, but had a poorly maintained product backlog that prevented a good approximation for a release date. It wouldn’t be much of an improvement if the new product owner kept a healthy product backlog but did so by driving the team as a tyrant might.

Test for Matching Skills

With a good feel for the criteria needed to hire the best candidate you can then craft a strategy for determining how well the candidate’s abilities satisfy your criteria. Prepare tasks for the candidate that will verify congruity between what a candidate says they can do and what they can actually do. One approach, which I use frequently, is to present the candidate with a series of scenarios, each designed to build on how the candidate responded to the previous scenario. While I may only present a candidate 3-4 scenarios, I have several dozen in the queue and present the sequence based on how well the candidates responses to the challenge.

For example, for a scrum master role – a high-touch role that requires consummate communication skills, flexibility, and the ability to solve people problems – I may present an initial scenario as follows:

“I’m going to give you several scenarios. You are free to ask any questions you wish about the scenario and state any assumptions you are making in your responses.

You are being considered for a position as scrum master for a team that is developing a healthcare related web application for use in hospitals. This team is responsible for developing the UI/UX components and works closely with another team responsible for much of the database and middle tier components. As a new scrum master, what questions would you ask of anyone in the organization to help you quickly understand what you need to do to become effective as a scrum master for your team?”

There are many things I would hope to hear in the candidate’s answer. To mention a few, I’d like to hear that they want to speak to the product owner, the stakeholders, and, of course, each of the team members. I’d like to hear that they plan to spend time in information gathering mode rather than work immediately to shape the team into some version of teams they’ve worked with at other jobs. I’d like to hear questions from them about what kinds of metrics does the team use and what have they shown.

There are no right and wrong answers to a scenario like this. Just answers that are better than others. And I don’t expect the candidate to deliver an exhaustively thorough response.

From their responses, I might learn that they are a recipe follower or that they are flexible in adapting to the needs of the business while working to establish good scrum practices. I might learn that they really don’t know scrum at all and are only good at parroting text book examples and jargon. I might hear how they would attempt to leverage several things from previous experience while acknowledging those attempts would be experiments and subject to adaptation based on feedback.

Assuming the candidate responded to the first scenario in a way that scores high marks for satisfying my criteria, I might offer the next scenario as follows:

“Assume you have been serving successfully as scrum master for this team for six months now. The product owner calls the team together and says ‘I need to swap out some of the stories in the sprint for work that marketing wants done before the end of the week.’ As scrum master, how would you respond to this development?”

As with the previous scenario, the candidate’s response would be measured against the criteria I have established for the position. Depending on what I’ve heard, I may continue to offer additional scenarios that build on the candidates developing experience with the scenario scrum team.

This strategy is pursued until I’m satisfied the candidate knows what they claim to know or not. A short interview does not bode well for the candidate. A long interview does.

(I would be interested in hearing about any questions, comments, or creative ways you’ve applied this strategy.)

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.

How to Frame Team Development Challenges

When working with teams or organizations new to Agile and scrum, it’s common for scrum masters to face varying degrees of resistance to the new methods and processes. The resistance can take many forms ranging from passive-aggressive behaviors to overt aggression and even sabotage.

There are two things to consider when looking for ways to resolve this type of resistance.

  1. The specific issues are typically not Agile problems in the sense they won’t be solved by any specific Agile techniques, methods, or frameworks. Rather, they are people problems; issues with how people’s behavior is driven by their values and beliefs. We have to resolve the people problems in concert with implementing Agile or Agile will never be successfully implemented. We also have to be sure not to confuse the two.
  2. We need to look at these challenges as opportunities.

It’s the second point I want to focus on in this post.

To simply paint the often unpleasant experiences we have with coaching our teams in the ways of Agile and scrum as “opportunities” isn’t much of a solution. It’s weak tea and about as useful as “Let’s all just think positive thoughts and eventually it’ll get better.” Nor do I suggest we sugar coat the unpleasantness by sprinkling “It’s an opportunity!” language on our conversations. Losing your job or breaking your leg may be one of those “wonderful opportunities” born from adversity, but only after you’ve found that next better job or your leg has healed. Hustling for new work or sitting idle while in pain and healing is decidedly unpleasant.

I had something else in mind for thinking about the challenges we face as “opportunities.” It’s in the midst of the unpleasant phase where the opportunities are found that lead to success. Seth Godin speaks to this in his book “The Dip.”

The Dip is the long slog between starting and mastery. The Dip is the combination of bureaucracy and busywork you must deal with in order to get certified in scuba diving. The Dip is the difference between the easy “beginner” technique and the more useful “expert” approach in skiing or fashion design. The Dip is the long stretch between beginner’s luck and real accomplishment.

It’s the classic “things will get worse before they get better.” But as Zig Ziglar put it, “Anything worth doing is worth doing poorly–until you can learn to do it well.”

It’s important to recognize and acknowledge when you’re in The Dip. Not just as an individual scrum master on a particular team, but perhaps the entire organization as well. Solving the issues you’re encountering today is exactly what you need to do in order to be successful in the long term. The Dip is inevitable and unavoidable. Part of the scrum master’s purpose is to raise the awareness of this fact so that the underlying issues that need to be resolved can be amplified.

This is what can make serving in the scrum master role particularly unpleasant at times. It’s when you earn your pay. In general, people don’t like to look at themselves in the Agile mirror that scrum masters are charged with holding up in front of them.

The Dip is another way to describe Shalloway’s Corollary applied to teams and organizations. Unlike losing a job or breaking a leg, what we’re dealing with is actually something we most definitely should expect. The system was always going to push back. Now we’re discovering exactly how that’s going to happen. The system is showing us what needs to change in order to become a more Agile organization. No more guess work. It’s a gift. Knowing this should be cause for optimism and viewing the tasks ahead as an opportunity. The way is known. There is less ambiguity. Doesn’t mean the path ahead is easy, just better known. That alone is incredibly useful.

A final thought. “The System” that’s been in place at any organization is what it is. For better or worse, it’s been working, perhaps for decades. Anything that challenges the status quo is going to receive push back. It just happens that Agile is the current challenger. As scrum masters, we have to continually evaluate our own “system” in a way that prevents it from becoming the next version of the problem.

  • Is a particular tool, process, or method fit for purpose?
  • What problem are we trying to solve?
  • Are there aspects of the “old system” that actually make sense to keep in place?
  • Are the frustrations we’re experiencing due to the “old system” pushing back or are they the result of our own ossification around out dated or misapplied beliefs?

The Value of “Good Enough for Now”

I’ve been giving some more thought to the idea of “good enough” as one of the criteria for defining minimum viable/valuable products. I still stand by everything I wrote in my original “The Value of ‘Good Enough’” article. What’s different is that I’ve started to use the phrase “good enough for now.” Reason being, the phrase “good enough” seems to imply an end state. “Good enough” is an outcome. If it is early in a project, people generally have a problem with that. They have some version of an end state that is a significant mismatch with the “good enough” product today. The idea of settling for “good enough” at this point makes it difficult for them to know when to stop work on an interim phase and collect feedback.

“Good enough for now” implies there is more work to be done and the product isn’t in some sort of finished state that they’ll have to settle for. “Good enough for now” is a transitory state in the process. I’m finding that I can more easily gain agreement that a story is finished and get people to move forward to the next “good enough for now” by including the time qualifier.

Busting Assumptions

The video in this post is one I show when talking about the need to question assumptions while working to integrate Agile principles and practices into an organization. It was taken with the dash camera in my car. The drama seems to make it easier for people to see the different points of view and associated assumptions in play. (The embedded video is a lower resolution, adapted for the web, but it still shows most of what I wish to point out.)

First off, no one was injured in this event beyond a few sets of rattled nerves, including mine. This happened fast, however, there were signals that immediately preceded the event which suggested something strange was about to happen. The key moment is replayed at the end of the video at 1/4 speed for a second chance to notice what happened.

  1. The truck ahead of me was slowing down. Unusual behavior when the expectation is that traffic would be flowing.
  2. The driver in the truck was signaling that they intended to move to the left, either to switch lanes or turn left.
  3. This activity was happening as we approached an intersection.

Something didn’t seem right to me so I had started to slow down. That’s why it looks like the driver of the Jeep appears to be speeding up.

So what were the assumptions that can be guessed?

An important piece of information is that the road in the video is a two lane one way street. The driver of the Jeep clearly understood this and assumed everyone else on the road would be following the rules of the road. The driver of the truck appears to be assuming he is driving on a two lane two way street and so prepared to turn left onto a side street. His signaling and subsequent behavior suggest this. So the driver of the truck was assuming everyone else on the road was operating under this incorrect understanding. So when he began his left hand turn he wasn’t expecting the need to check the left hand lane for cars coming up from behind him. One second difference, literally, in the timing and this could have ended badly for several people.

Assumptions are unconscious and everyone has them. By design they never represent the full picture. Yet we almost always act as if they do and, more importantly, that they are shared by everyone around us. Events like those in the video clearly demonstrate that is not the case. If it was, there would be far fewer road accidents.

Organizations that are seeking to implement Agile principles and practices are guaranteed to be operating under a mountain of assumptions for how work can or “should” be done. They’re easy to spot based on how strongly people react when someone fails to follow the rules. It’s important to examine these assumptions so they can be either validated, updated, or retired.