Creativity Under Pressure

[In the fall of 2013, I completed a course on Coursera titled “Creativity, Innovation, and Change” presented by Drs. Jack V. Matson, Kathryn W. Jablokow, and Darrell Velegol at Pennsylvania State University. It was an excellent class. At the end, they invited the class (How many tens of thousands of us?) to submit short essays about our experience. The plan was to select the best of these essays and roll them into a free Kindle book. The following spring, they sent out this update:

We are sorry to inform you that we have decided not to proceed with the publication of a CIC eBook. The submissions were read and commented on by four reviewers.  The consensus was that the manuscripts for the most part would take efforts far beyond our capabilities and means to edit and upgrade to meet the standards for publishing.  We are very sorry that the plan did not work out.

What follows is slightly edited version of the essay I submitted for consideration.]

Creativity Under Pressure – When necessity drives innovation.

Background

When you hear someone speak of an individual they know as being creative, what images come to mind? Often, they spring from stereotypes and assumptions about such an individual being an artist of some sort. Someone unconstrained by time or attachment to career, family, or a mortgage. My personal favorite is the image of a haggard individual wearing a beret, a thin cigarette balanced on their lower lip, and busy being inspired by things us mortals cannot see. A foreign accent adds the final touch to firmly set the speaker’s creative individual in the “That’s not me.” category. Our preconceived notions and assumptions assure us we are not creative.

The truth is all of us are creative. The artist’s Muses are not the only source of inspiration. Chance can inspire creative ideas by the convergence of seemingly unrelated circumstances and events. An activity as passive as sleep can lead to creative ideas. Moving away from beauty toward the other end of the inspiration spectrum, the source may not necessarily be pleasant. Frustration and irritation may inspire us to find a creative solution as we spend an inordinate amount of time searching for a way to scratch a just-out-of-reach itch. Crisis, too, can be a source of inspiration, often of the very intense variety. Chance surrounds all of us. We all sleep. And alas, we are all subject to frustrating or crisis situations from time to time in our lives. We are immersed in opportunities for creative inspiration.

Perhaps the least obvious or explored opportunities for applying creativity and experimenting with innovative ideas happen when we are under pressure to perform. At first glance, the tendency is to think that such situations require extensive knowledge, abundant prior practice, and scenario rehearsals in order to navigate them successfully. It’s fair to say that the chances for successfully responding to a crisis situation are greatly enhanced by deep knowledge and experience related to the situation.

The Apollo 13 mission to the Moon is a familiar example of crisis driven creativity by a team of experts. Survival of the astronauts following the explosion of an oxygen canister depended on NASA engineers finding a way to literally fit a square object into a round hole. The toxic build-up of CO2 could only be prevented by finding a way to fit a cube shaped CO2 filter into a cylinder shaped socket using nothing but the materials the astronauts had with them. Of course we know from history the team of engineers succeeded in this exercise of creative improvisation.

Individual experts have also succeeded in devising creative solutions in crisis situations, and in doing so introduced critical changes in protocols and procedures that have saved lives. For example, smokejumber Wagner Dodge’s actions in the Mann Gulch forest fire on August 5, 1949, introduced the practice of setting escape fires as a way to protect firefighters caught in “blow-ups.”

What I’ve always found interesting about these and similar examples is that, although the creative and innovative solutions were found while “on the job” and using established expertise, the solutions were counter to what the individuals and teams were expected to do. The NASA engineers were paid to design and build an extremely high tech solution for sending three men to the moon and bringing them safely back to Earth. Their job descriptions likely didn’t call for the ability to “build a fully functional CO2 scrubber from a pile of junk.” Wagner Dodge was expected put out fires, not start them.

The Course

What else is important in preparing us to respond creatively in high pressure situations? It’s a question that’s dogged me for years. The “Creativity, Innovation, and Change” (CIC) course offered by Pennsylvania State University and taught by Professors Jack Matson, Kathryn Jablokow, and Darrell Velegol offered an opportunity to explore this question.

The first insight from the course was the importance of the “adjacent possible” to creative and innovative problem solving, even in crisis situations. The phrase was originally suggested by the theoretical biologist Stuart Kauffman to describe evolutionary complexity. The idea is that innovative or creative ideas occur incrementally. While they may appear as substantial leaps forward, they are in fact derived from a collection of adjacent ideas that coalesced to make a single idea possible. As an individual explores deeper and farther into an idea space, they extend the boundaries around which adjacent ideas collect, increasing the potential for new idea combinations. In other words, increasing the likelihood of creative or innovative ideas.

In the case of Apollo 13, the deep experience and knowledge of the engineers allowed them to consider a wide spectrum of possibilities for combining an extremely limited number of objects in a way that could remove CO2 from a spacecraft. In the case of Wagner Dodge, his extensive experience with fighting forest fires allowed him to spontaneously combine a variety of “adjacent possibilities” in a way that lead to the idea of lighting an escape fire.

That’s the theory, anyway. There’s a difference, though, between theory and practice. Albert Einstein explains, “In theory they are the same. In practice, they are not.” The CIC course offered an abundance of techniques and methods that facilitated the transfer of learning and strengthened the connection between theory and practice. In particular, there were two important reframes that opened the door to deliberately improving how I approach creativity and innovation in stressful situations:
“Successful” failures are those that are strategic. That is, not random guesses about what will work, but deliberate experiments designed to succeed. Yet if they fail, the design of the experiments also reveal weaknesses that are preventing the eventual success. Unconsciously, I had already become reasonably good a doing this. But there was significant room for improvement. Using many of the methods and techniques offered during the CIC course, I deliberately unpacked my unconscious competence in this area, consciously explored how I could practice becoming even more competent with this skill, and am now exploring ways to integrate the new capabilities back into unconscious competence.

“Failure” is a necessary, even desired process for finding success. This ran counter to my get-it-right perfectionist approach to success. Likely the result of having to work in too many crisis situations where failure was not an option, it was nonetheless a poor strategy for finding success in day-to-day business. In concert with point number one, these failures should be strategic.
Each of these insights are encapsulated in the “Intelligent Fast Failure” (IFF) principle presented in the CIC course and further described in Prof. Matson’s book, “Innovate or Die!”:

The “Intelligent” part refers to gaining as much knowledge as possible from each failure. The “Fast” part means speeding up the trials to quickly map the unknown thereby minimizing frustration and resources spent.

The “fast” part also increases the pool of “adjacent possibilities” and raises the potential for successful innovations to emerge from the process.

The Test

Has all this experimentation and thought practice made a difference in my ability to respond more creatively in stressful situations? A full-on test in crisis mode hasn’t happened as yet. And frankly, I’d count my self fortunate if I never had to face such a test again. But there are indications the changes are having a positive effect.

These days, work typically offers the most abundant opportunities for stressful situations. Most recently, I was tasked with coordinating a significant change in how an organization went about the process of completing projects. The prevailing process had deep roots in the company’s culture and was incapable of scaling to meet growth goals for the organization. With so much personal investment into the old way of doing things, implementing a more agile and scalable process was going to require as much mediation and negotiation as it was process definition and skill development.

Using the techniques and methods that support the IFF principle, I have been successfully implementing a wide range of new ideas and process improvements into the organization in a way that makes them appear less as a threat and more as a value to each of the stakeholders.


Photo by Ameen Fahmy on Unsplash

Accidental Social Capital and Status

 

I was made aware recently that I have accidentally acquired some interesting social status: I’m not on Facebook. Apparently, it isn’t just that I’m not on Facebook, its that I’ve never had a Facebook account. I’ve also never had accounts with:

  •  MySpace
  • Twitter
  • Instagram
  • TikTok
  • Pinterest
  • Snapchat
  • Reddit
  • Parler
  • The list goes on and on.

I am fairly active on LinkedIn and for a brief time had a Gab account after it first launched. The latter looked like another cesspool in the making so I deleted the account and moved on.

Acquiring this status wasn’t entirely accidental, even if it wasn’t by design. It was clear early on that the only way to win the race to the bottom of the social-on-line game was to not play at all. I’d seen this movie before. I had some experience with this environment in the pre-world-wide-web days of USENET newsgroups so it was pretty easy to see where this was heading. Thought I’d seen some epic flame wars on USENET but USENET newsgroups are to 21st century social media as camp fires are to nuclear explosions, as head colds are to social diseases.

I’m not so naive to think just because I don’t participate in the vast majority of social media that others haven’t contributed data about me without my knowledge or consent nor that I’m immune to the effects of social media. It’s that nuclear explosion thing. I can’t help but be aware of the blast and getting caught in the blast zone, even being targeted for the epicenter are known risks. While zillions of people are blithely working to feed The Beast’s insatiable need for data in exchange for nano hits of dopamine, my efforts are focused on how to avoid the growing tar pit that oozes from The Beast. I study how others have inadvertently been lured into the hot mess and, even more valuable, those few who have successfully wrestled themselves free.

Neither do I think social media is devoid of value or purpose. This is where LinkedIn (so far) seems to rise above the base rabble. There is a modicum of professionalism and elevated expectation of how one behaves on LinkedIn. (Although, I see signs of this eroding at an accelerated pace.)

As I see it, there is no way I can reliably cash in on this newly acquired social capital and status. It’s value is dubious. A small-talk starter at parties. A novelty. A non-thing that’s interesting like not having purple hair, tattoos, and a pierced face is interesting. To really leverage it, I’d have to jump into the social media quagmire, thereby emptying the account or, more likely, go into serious debt. In the end, carefully curated piles of garbage are still garbage.

So there it sits. A helluva thing, maybe valuable only as a note on my headstone.

Here rests Gregory Engel.
@nothing, @nowhere
He lived in the real world.

The Practice of Sizing Spikes with Story Points

Every once and a while it’s good to take a tool out of it’s box and find out if it’s still fit for purpose. Maybe even find if it can be used in a new way. I recently did this with the practice of sizing spikes with story points. I’ve experienced a lot of different projects since last revisiting my thinking on this topic. So after doing a little research on current thinking, I updated an old set of slides and presented my position to a group of scrum masters to set the stage for a conversation. My position: Estimating spikes with story points is a vanity metric and teams are better served with spikes that are time-boxed but unsized.

While several colleagues came with an abundance of material to support their particular position, no one addressed the points I raised. So it was a wash. My position hasn’t changed appreciably. But I did gain from hearing several arguments for how spikes could be used more effectively if they were to be sized with story points. And perhaps the feedback from this article will further evolve my thinking on the subject.

To begin, I’ll answer the question of “What is a spike?” by accepting the definition from agiledictionary.com:

Spike

A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

The phrase “cannot be well estimated” is suggestive. If the work cannot be well estimated than what is the value of estimating it in the first place? Any number placed on the spike is likely to be for the most part arbitrary. Any number greater than zero will therefore arbitrarily inflate the sprint velocity and make it less representative of the business value being delivered. It may make the team feel better about their performance, but it tells the stakeholders less about the work remaining. No where can I find a stated purpose of Agile or scrum to be making the team “feel better.” In practice, by masking the amount of business value being delivered, the opposite is probably true. The scrum framework ruthlessly exposes all the unhelpful and counterproductive practices and behaviors an unproductive team may be unconsciously perpetuating.

Forty points of genuine business value delivered at the end of a sprint is 100% of rubber on the road. Forty points delivered of which 10 are points assigned to one or more spikes is 75% of rubber on the road. The spike points are slippage. If they are left unpointed then it is clear what is happening. A spike here and there isn’t likely to have a significant impact on the velocity trend over 8 or 10 sprints, for example. One or more spikes per sprint is another matter. In this case, numerous spikes in successive sprints will likely cause the velocity to sink. If this happens, a number of corrective actions can be taken – actions that may be missed if the velocity is falsely kept at a certain desired or expected value. In other words, pointing spikes hides important information that could very well impact the success of the project. Bad news can inspire better decisions and corrective action. Falsely positive news most often leads to failures of the epic variety.

Consider the following two scenarios.

Team A has decided to add story points to their spikes. Immediately they run into several significant challenges related to the design and the technology choices made. So they create a number of spikes to find the answers and make some informed decision. The design and technology struggles continue for the next 10 sprints. Even with the challenges they faced, the team appears to have quickly established a stable velocity.

The burndown, however, looks like this:

If the scrum master were to use just the velocity numbers it would appear Team A is going to finish their work in about 14 sprints. This might be true if Team A were to have no more spikes in the remaining sprints. The trend, however, strongly suggests that’s not likely to happen. If a team has been struggling with design and technical issues for 10 sprints, it is unlikely those struggles will suddenly stop at sprint 11 or beyond unless there have been deliberate efforts to mitigate that potential. By pointing spikes and generating a nice-looking velocity chart it is more probable that Team A is unaware of the extent to which they may be underestimating the amount of time to complete items in the backlog.

 

 

Team B finds themselves in exactly the same situation as Team A. They immediately run into several significant challenges related to the design and the technology choices made and create a number of spikes to find the answers and make some informed decision. However, they decided not to add story points to their spikes. The design and technology struggles continue for the next 10 sprints. The data show that Team B is clearly struggling to establish a stable velocity.

 

And the burndown looks like this, same as Team A after 10 sprints:

However, it looks like it’s going to take Team B 21 more sprints to complete the work. That they’re struggling isn’t good. That it’s clear they struggling is very good. This isn’t apparent with Team A’s velocity chart. Since it’s clear they are struggling it is much easier to start asking questions, find the source of the agony, and make changes that will have a positive impact. It is also much more probably that the changes will be effective because they will have been based on solid information as to what the issues are. Less guess work involved with Team B than with Team A.

However, any scrum master worth their salt is going to notice that the product backlog burndown doesn’t align with the velocity chart. It isn’t burning down as fast as the velocity chart suggests it should be. So the savvy Team A scrum master starts tracking the burndown of value-add points vs spike points. Doing so might look like the following burndown:

Using the average from the parsed burndown, it is much more likely that Team A will need 21 additional sprints to complete the work. And for Team B?

The picture of the future based on the backlog burndown is a close match to the picture from the velocity data, about 22 sprints to complete the work.

If you were a product owner, responsible for keeping the customer informed of progress, which set of numbers would you want to base your report on? Would you rather surprise the customer with a “sudden” and extended delay or would you rather communicate openly and accurately?

Summary

Leaving spikes unpointed…

  • Increases the probability that performance metrics will reveal problems sooner and thus allow for corrective actions to be taken earlier in a project.
  • The team’s velocity and backlog burndown is a more accurate reflection of value actually being created for the customer and therefore allows for greater confidence of any predictions based on the metrics.

I’m interested in hearing your position on whether or not spikes should be estimated with story points (or some other measure.) I’m particularly interested in hearing where my thinking described in this article is in need of updating.

[An earlier version of this article originally appeared on the Agile Alliance blog.]

The World Needs More Booths

Remember face-to-face conversation? You know, sharing thoughts, talking through concerns, sketching out ideas, and having intelligent discussions without the overblown internet persona outrage? You have instant feedback through facial expressions, tone of voice, and spoken word. You have instant ability to clarify a particular point, on the spot. You get a better “read” of where the other person is coming from. And, you get better engagement in the conversation. – Rick Knowles

Conference rooms, court rooms, hospital rooms, elevators – these are some examples where the space presupposes a particular way of behaving and communicating (or, in the case of elevators, not communicating.) The informal setting of a booth, however, allows for a comfortable space to let some of the usual barriers to conversation fall away.

 

Many of the most memorable conversations and exchanges of ideas in my life happened in restaurant booths. They weren’t all good, but most of them were and all of them were important. Add in a good cup of coffee and they can be incredibly creative spaces. Perhaps it’s just a lucky spacial anchor thing. However it happened, the result is that booths, particularly coffee shop booths, are my go-to spaces for near-instant solace and creativity. So much so that when we kicked off a major home renovation some years ago it included, among many other things, a breakfast booth off the kitchen. The design of the booth was completed by the same designer/builder of the booths at Racine’s Restaurant – perhaps my second all-time favorite Third Place behind The Market. (Sadly, neither Racine’s or The Market survived the government lockdowns of 2020.)


(Image credit: johnny_automatic)

When Collaboration Becomes Clobber-ation

I was new on site and agreed to co-create a working session with the company Agile coach for developing the skills needed to split large stories into smaller stories. The plan was to develop the skills of the company’s scrum master pool so that they could then deliver this presentation to their teams. Given the diversity of the team projects involved, I proposed that it might be helpful to open the session with a short segment on how to size stories, just to be sure everyone had a baseline understanding. To this end and in the interests of time I offered to leverage a 10 minute presentation that I’d used successfully for several years.

“Great,” she said. “Let’s see it.”

Thirty minutes and an uncounted number of interruptions later to interject what I should do different here and where I was wrong there, I stopped trying to get through my short deck of slides. The interaction had all the feel of turf posturing and a clear need for the company coach to be the sage in the mix. I don’t mind getting thrashed by sharp or well placed feedback from a curious novice or a proven master. These insights are often the most valuable and important to learning and growth as an Agile coach. But if anyone deploys a tear-you-down-to-build-me-up strategy in the name of collaboration I’ve learned it’s best to cut my losses and walk away.

And that’s what happened here. The co-creation dissolved and the working session never occurred. Weeks later, the company coach emailed the approved deck of slides to the scrum masters with instructions to present the deck to their teams. How to do that was “in the notes.”

There were a lot of things wrong with this interaction and, indeed, with the company’s Agile implementation. But the lack of co-creation and collaboration was a core issue. Healthy and productive collaboration includes all of the following:

  • Asking many questions
  • Careful attention and listening to answers
  • Making few statements
  • Setting aside the limitations of “or” and embracing the power of “and”
  • Understanding the goals of the collaboration
  • Understanding the purpose of the collaboration
  • Respect for everyone as professionals
  • Communication that is open and uncontaminated by back channeling and triangulation
  • Patience

Photo by Ashley Jurius on Unsplash

Teams, Tribes, and Community – 0.1.0

Several months ago, I made bold decision: Take command of the helm for a brilliant tribe of diverse creative thinkers dedicated to helping each other succeed. This is the first of an on-going series of posts – maybe once or twice a month – describing this evolving effort.

For an extrovert, this might not have been a bold decision. But in my case, you should know I designed the card that card-carrying introverts carry. So this decision involved a more thorough application of my already robust decision-making process. On a professional level, this may be the most significant challenge I’ve taken on to date. Will my years of experience with forming and guiding teams help this tribe further their success? Will I be able to find the gravitational force that holds us together and the spark that keeps us inspired? These are open questions. They are also questions that occupy much of my thinking.

We are not dedicated to achieving a single goal or moving in a unified direction. We each have our areas of expertise and independent business goals. We are much more a tribe than a team. As such, I believe we will be guided more by tribal dynamics and models than team rules and policies. The path is not clear, but this much I know…

  • There is no leader of this tribe. Not in the sense of a single person who’s responsible for setting the direction and making all the decisions that impact the organization. There is no “Chief” or “Czar” of anything. I’ll fill the role of Launch Commander and Flight Commander in order to get us organized and moving forward. However, I have been clear from the start about my intention to structure our tribe on principles of self-organization.
  • The emphasis is on simple and accessible technology and easy ways to organize meetings based on Agile principles and practices – lean coffee, for example, has served us well for our initial meetings. What has emerged since then are more involved and interactive meeting formats, such as client role-plays and accountability exercises. Keeping things simple and remaining mindful of barriers to participation is vital. Too many tools with too many logins risks the creation of a Tower of Babel. For now, the weekly video call is the center-point around which we all meet. This in itself is enough of a challenge given the global participation. Other than this, email is the acknowledged primary channel for asynchronous communication.
  • We are not accepting new members. Whether or for how long this remains the case is undecided. We have discussed various ways of introducing new members, but have decided to decide on this issue later. The circumstances that brought each of us together created a unique bond of trust and familiarity with each other’s business interests that makes the introduction of new members a risk to maintaining these relationships. At the moment, we are tipped slightly toward being on the large size and everyone acknowledges if we grow much bigger the meetings may become unmanageable and the interactions less valuable. Since trust is foundational, none of the details related to who we are and what we discuss will be revealed in this space. My writing will be limited to the general case of what I discover from having participated in and helped guide our tribe. It is my hope this may help others with forming and guiding their own teams and tribes.

Whatever the outcome, it’s been more fun thus far than I’ve had in a loooooong time.


Image by Youssef Jheir from Pixabay

Agile and Changing Requirements or Design

I hear this (or some version) more frequently in recent years than in past:

Agile is all about changing requirements at anytime during a project, even at the very end.

I attribute the increased frequency to the increased popularity of Agile methods and practices.

That the “Responding to change over following a plan” Agile Manifesto value is cherry picked so frequently is probably due to a couple of factors:

  • It’s human nature for a person to resist being cornered into doing something they don’t want to do. So this value gets them out of performing a task.
  • The person doesn’t understand the problem or doesn’t have a solution. So this value buys them time to figure out how to solve the problem. Once they do have a solution, well, it’s time to change the design or the requirements to fit the solution. This reason isn’t necessary bad unless it’s the de facto solution strategy.

The intent behind the “Responding to change” value, and the way successful Agile is practiced, does not allow for constant and unending change. If this were otherwise nothing would ever be completed and certainly nothing would ever be released to the market.

I’m not going to rehash the importance of the preposition in the value statement. Any need to explain the relativity implied by it’s use has become a useful signal for me to spend my energies elsewhere. But for those who are not challenged by the grammar, I’d like to say a few thing about how to know when change is appropriate and when it’s important to follow a plan.

The key is recognizing and tracking decision points. With traditional project management, decisions are built-in to the project plan. Every possible bit of work is defined and laid out on a Gantt chart, like the steel rails of a train track. Deviation from this path would be actively discouraged, if it were considered at all.

Using an Agile process, decision points that consider possible changes in direction are built into the process – daily scrums, sprint planning, backlog refinement, reviews and demonstrations at the end of sprints and releases, retrospectives, acceptance criteria, definitions of done, continuous integration – these all reflect deliberate opportunities in the process to evaluate progress and determine whether any changes need to be made. These are all activities that represent decisions or agreements to lock in work definitions for short periods of time.

For example, at sprint planning, a decision is made to complete a block of work in a specified period of time – often two weeks. After that, the work is reviewed and decisions are made as to whether or not that work satisfies the sprint goal and, by extension, the product vision. At this point, the product definition is specifically opened up for feedback from the stakeholders and any proposed changes are discussed. Except under unique circumstances, changes are not introduced mid-sprint and the teams stick to the plan.

Undoing decisions or agreements only happens if there is supporting information, such as technical infeasibility or a significant market shift. Undoing decisions and agreements doesn’t happen just because “Agile is all about changing requirements.” Agile supports changing requirements when there is good reason to do so, irrespective of the original plan. With traditional project management, it’s all about following the plan and change at any point is resisted.

This is the difference. With traditional project management, decisions are built-in to the project plan. With Agile they are adapted in.


Photo by Chris Lawton on Unsplash

Fall Reflections – 2021

Over four years ago, I was in a position to retire early. After some thought, the idea didn’t suit me. I was, in the arc of my life, in an entirely novel position. I could be much more selective about where I chose to exchange my time for money. With nothing to lose and a lot to gain, I sought work with a company that would put Agile principles and my coaching skills to a rigorous test. Did I have what it takes to guide a global legacy corporation into an Agile learning organization? I ran this experiment within the software divisions of two different medical device manufacturers. The first was a 6 month engagement that ended when a better option opened up at a much larger manufacturer with more pay and less commute. I was there for three years until a layoff in the spring.

So it is I’ve come to wrapping up an extremely active spring and summer after having tripped a wire that launched me into a career shift about six months earlier than planned – a span of time I’m affectionately calling an unplanned sabbatical. I’m still not ready to retire, but I’m in an even stronger position then I was four years ago – the silent advantage of a Stoic minimalist lifestyle. Shedding the corporate baggage has opened up a universe of space and time for unfettered thought and exploration. Sabbaticals should be integrated into the work lives of every employee who demonstrates integrity and a strong work ethic.

In the coming months, I’ll be writing more about what this new direction involves. A change in direction doesn’t begin to capture the shift. There’s a multi-leveling up in play, too. This fall and winter – seasons ideally suited for deep reflection and planning – will see a continued pace of activity and preparation. Belying the quite stillness of winter, I will be extremely busy moving fieldstones into position and crafting a renewed foundation for success.

The purpose and mission I declared at the very beginning of 2020 is still in place. When I crafted that mission I was at the very beginning of a grand experiment, full of optimism and yet fully aware of the daunting task ahead. The company I was working for presented me with choice: I could accept a new management role or pursue a stated goal of mine to create an official Agile Coach position within the software group. The organization had just created an official scrum master role in the org chart, but the PMO was strongly resisting the idea of an official product owner role. I was an epic turf battle.

The management path offered greater security but had significant downsides. Not only would I have the decidedly unpleasant task of managing people in a highly regulated and bureaucratic organization, I would also be expected to fill in the scrum master gaps on various teams. This sounded like a good way to end my career as an Agile Coach.

The coach path offered the highly appealing challenge of implementing Agile and SAFe in a 60 year old medical device manufacturer. The known risks included a certain tsunami of resistance. I’d be out on a limb, working to navigate in uncharted and dangerous waters. But I had excellent support. The arrival of a new CEO broke up many of the old ways of organizing software development and opened a window of opportunity. After a rigorous decision process, I chose the Agile Coach path. My 2020 mission reflects the enthusiasm I had for having made this choice.

Then things went sideways. The new CEO brought a much bigger broom than anyone imagined and my key executive support left the organization. Two new senior execs were hired that had a rather stunted understanding of Agile, SAFe, and working with software professionals. Progress stalled as head nods and “Yeah, we’ll get to that.” can-kicking substituted for action. A lot of really good people started to leave the organization, including what was left of my support and allies. A deeply disturbing experience while serving as the Unofficial Official Agile Coach and the effects of the pandemic lock-down sunk the Agile Coach boat. The bubble I placed myself on became more so. I’m surprised I wasn’t laid-off sooner.

The period since separating from my previous employer in early 2021 has been a period of immensely positive growth. The gain in perspective on the prior three years has enlightened me to just how toxic the work environment was. Taking that job was an experiment and in the end the primary failure was not discovering sooner that the experiment was destine to fail. My optimism was misplaced. I trusted untrustworthy people. The greater sadness is that the organization has a wonderful mission and excellent products, each held back from what they could be by a select few and their caustic alliances within the organization. My health and well-being are much the better for having left on their dime.

 I finished my 2020 declaration with “Here’s to moving into 2020 with mind and eyes wide open.” And so I did. Where to next will be on my terms. Free from people who talk inclusion but practice exclusion, talk diversity but practice conformity, talk about change but fight for stagnation, and talk about collaboration while protecting their tiny fiefdoms with vindictive ruthlessness. My tuned purpose and mission for 2022 will reflect this. And a good start will be to conduct business operations in ways that are aligned with the Mission Protocol.


Photo Credit: Original, Copyright © 2021, Gregory Paul Engel

Improving the Signal to Noise Ratio – In Defense of Noise

[This post follows from Improving the Signal to Noise Ratio.]

All signal all the time may not be a good thing. So I’d like to offer a defense for noise: It’s needed.

Signal is signal because there is noise. Without the presence of noise we risk living in the proverbial echo chamber. When we know what’s bad, we are better equipped to recognize what’s good. I deliberately tune into the noise on occasion for no other reason than to subject my ideas to a bit of rough and tumble. Its why I blog. Its why I participate in several select forums. “Here’s what I think, world. What say you?”

Of course, noise is noise because there is signal. Once we’ve had an experience of “better” we are then more skilled at recognizing what’s bad. I remember the food I grew up on as being good, but today I view some of it as poison (Wonder Bread anyone?) And there are subjects for which I no longer check out the noise. The exposure is too harmful.

There are subjects for which I seem to be swimming in noise and casting around for any sort of signal that suggests “better.” I’m recalling a joke about the two young fish who swim past an older fish. The older fish says to the younger fish, “The water sure is nice today.” A little further on, one of the young fish asks the other, “What’s water?” I’m hoping to catch that older fish in my net. He knows something I don’t.

To understand what I mean by noise being necessary it is important to understand the metaphor I’m using, where it applies and where it doesn’t.

Taking the metaphor literally, in the domain of electrical engineering, for example, the signal to noise ratio is indeed an established measure with clear unit definitions as to what is reflected by the ratio – decibels, for example. In this domain the goal is to push always for maximum signal and minimum noise.

In the world of biological systems, however, noise is most definitely needed. One of many examples I can think of is related to an underlying driver to evolution: mutations. In an evolving organism, anything that would potentially upset the genetic status quo is a threat to survival. Indeed, most mutations are at best benign or at worst lethal such that the organism or it’s progeny never survive and the mutation is selected against as evolutionary “noise.”

However, some mutations are a net benefit to survival and add to the evolutionary “signal.” We, as 21st Century homo sapiens, are who we are because of an uncountable number of noisy mutations that we’ll never know about because they didn’t survive. Even so, surviving mutations are not automatically “pure” signal. There are “noisy” mutations, such as that related to sickle cell anemia. Biological systems can’t recognize a mutation as “noise” or “signal” before the mutation occurs, only after, when they’ve been tested by the rough and tumble of life. This is why I speak in terms of “net benefit.”

For humans trying to find our way in the messy, sloppy world of human interactions and thought, pure signal can be just as undesirable as pure noise. I’ll defer to John Cook, who I think expresses more succinctly the idea I was clumsily trying to convey:

If you have a crackly recording, you want to remove the crackling and leave the music. If you do it well, you can remove most of the crackling effect and reveal the music, but the music signal will be slightly diminished. If you filter too aggressively, you’ll get rid of more noise, but create a dull version of the music. In the extreme, you get a single hum that’s the average of the entire recording.

This is a metaphor for life. If you only value your own opinion, you’re an idiot in the oldest sense of the word, someone in his or her own world. Your work may have a strong signal, but it also has a lot of noise. Getting even one outside opinion greatly cuts down on the noise. But it also cuts down on the signal to some extent. If you get too many opinions, the noise may be gone and the signal with it. Trying to please too many people leads to work that is offensively bland.

The goal in human systems is NOT to push always for maximum signal and minimum noise. For example, this is reflected in Justice Brandeis’s comment: “If there be time to expose through discussion the falsehood and fallacies, to avert the evil by the process of education, the remedy to be applied is more speech, not enforced silence.” So my amended thesis is: In the domain of human interactions and thought, noise is needed by anyone seeking to both evaluate and improve the quality of the signal they are following.

A final thought…

If we were to press for eliminating as much “noise” as possible from human systems much like the goal for electrical noise, I’m left with the question “Who decides what qualifies as noise?”


Photo by Jason Rosewell on Unsplash