Please visit The Stoic Agilist on Substack and support my writing efforts by subscribing. Articles published on Substack for the general public will appear here roughly one month later. Subscriber only content will only be available on Substack.
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 may be 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. By the time I concluded my software development career, it had been many years since I last 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 for the majority 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 needed a coach or a mentor because this was entirely new territory for me. So I hired a professional photographer with an established reputation for taking the 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 had a significant influence on who I choose as 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.
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.
How to know when Agile is working
On a flight into Houston several years ago, my plane was diverted to Austin due to weather. Before we could land at Austin, we were re-diverted back to Houston. I’ve no idea why the gears aligned this way, but this meant we were out-of-sequence with the baggage handling system and our connecting flight. Our luggage didn’t arrive at the claim carousel for an hour and a half after landing. Leading up to the luggage arrival was an unfortunate display from an increasingly agitated young couple. They were loudly communicating their frustration to an airport employee with unknown authority. Their frustration was understandable in light of the fact that flights were undoubtedly going to be missed.
At one point, the woman exclaimed, “This isn’t how this is supposed to work!”
I matched this with a similar comment from one of the developers on one of my project teams. Stressed with the workload he had committed to, he declared there are too many meetings and therefore “the agile process is not working!” When explored, it turned out some version of this sentiment was common among the software development staff.
At the airport and on my development teams the process was working. It just wasn’t working as desired or expected based on past experience. In both cases, present events were immune to expectations. The fact that our luggage almost always shows up on time and that agile frequently goes smoothly belies how susceptible the two processes actually are to unknown variables that can disrupt the usual flow of events.
There is a difference with agile, however. When practiced well, it adapts to the vagaries of human experience. We expect the unexpected, even if we don’t know what form that may take.
There is an assumption being made by the developers in that “working agile” makes work easy and stress free all the time. That was never the promise. Agile stresses teams differently than waterfall. I’ve experienced high stress developing code under both agile and waterfall. With agile, however, teams have a better shot at deciding for themselves the stress they want to take on. But there will be stress. Unstressed coders deliver code of questionable value and quality, if they deliver at all.
The more accurate assessment to make here is that the developers aren’t practicing Agile as well as they could. That’s fundamentally different from “agile isn’t working.” In particular, the developers didn’t understand what they had committed to. Every single sprint planning session I’ve run (and the way I coach them to be run) begins with challenging the team members to think about things that may impact the work they will commit to in the next sprint – vacations, family obligations, doctor visits, other projects, stubbed toes, alien abductions – anything that may limit the effort they can commit to. What occurred with the developers was a failure to take responsibility for their actions and decisions, a measure of dishonesty (albeit unintended) to themselves and their team mates by saying “yes” to work and later wishing “no.”
Underlying this insight into developer workload may be something much more unsettling. If anyone on your team has committed to more than they can complete and has done so for a number of sprints, your project may be at risk. The safe assumption would be that the project has a hidden fragility that will surprise you when it breaks. Project time lines, deliverables, and quality will suffer not solely because there are too many meetings, but because the team does not have a good understanding of what they need to complete and what they can commit to. What is the potential impact on other projects (internal and client) knowing that one or more of the team members is over committing? What delays, quality issues, or major pivots are looming out there ready to cause significant disruptions?
The resolution to this issue requires time and the following actions:
- Coaching for creating and refining story cards
- Coaching for understanding how to estimate work efforts
- Develop skills in the development staff for recognizing card dependencies
- Develop skills for time management
- Find ways to modify the work environment such that it is easier for developers to focus on work for extended periods of time
- Evaluate the meeting load to determine if there are extraneous meetings
- Based on metrics, specifically limit each developer’s work commitment for several sprints such that it falls within their ability to complete
Photo by Jason Hafso on Unsplash
Teaching Product Owners How To Fish
Product owners are responsible for defining WHAT the Agile team needs to create. The team is responsible for deciding HOW to build WHAT the product owner needs.
I don’t think any Agilist would fundamentally disagree with that statement. Where there is inevitably a great deal of discussion and disagreement is describing the boundary between “WHAT” and “HOW.” Is it thin or thick? How much overlap is there? Does this depend on the nature of the work or is there a fixed standard? Does it have to be determined for every story? These are often not easy questions to answer.
While reading some neuroscience material yesterday regarding how our brains construct “concepts,” the topic lead into the notion of “goal-based concepts.” Since I’m not a neuroscientist but an Agilist looking for ways neuroscience can be applied to the implementation of Agile principles and practices, the material had me thinking about how product owners might learn from the idea of “goal-based concepts.” How can I teach them about the “WHAT” such that they better understand the type and amount of detail the team needs in order to figure out the “HOW?”
I came up with a series of short dialogs:
Product Owner (to team): I need a fish.
Team: OK.
(Team goes off to work on “fish” and returns the next day with a catfish.)
PO: That’s not what I wanted! I need a fish!
(Team goes off to work on “fish” and returns the next day with a nurse shark.)
PO: That’s not what I wanted either!
What if the PO had been more clear about not just WHAT she wanted, but the goal for that WHAT. That is, a description of the problem that the WHAT was intended to solve.
PO: I’m opening a fish store. I need a fish.
(Team goes off to work on “fish for fish store” and returns the next day with a goldfish.)
PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.
(The team goes off to work on “variety of fish for fish store” and returns the next day with guppies, mollies, swordtails, and angelfish.)
PO: Cool!
Or version two:
PO: I’m opening a restaurant. I need a fish.
(Team goes off to work on “fish for restaurant” and returns the next day with Poached Salmon in Dill Sauce.)
PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.
(The team goes off to work on “variety of fish for restaurant” and returns the next day with Miso-Glazed Chilean Sea Bass, Mediterranean Stuffed Swordfish, and Pan Seared Lemon Tilapia.)
PO: Yum!
Providing a little of the “WHY” for the “WHAT” has helped the team do a better job of delivering WHAT the product owner wanted.
Of course, these are simplified examples. There are many additional details the product owner could have supplied that would have helped the team dial in on exactly WHAT she needed. In the first dialog, the team had to make guesses about what the product owner meant by the rather broad concept of “fish.” This unending loop is an expensive game of whack-a-mole. Except with fish. In the subsequent dialogs, the team at least had the benefit of the context that was of interest to the product owner. In these cases, the team had a better understanding of the goal the product owner had in mind.
In Agile-speak, this context or goal information would be provided in the “As a…” and “…so that…” part of the story. “As a restaurant owner I want fish so that patrons can enjoy a variety of menu options.”
The less clear the product owner is on these elements, the longer it’s going to take for the team to guess what she really wants.
Photo by Ben Wilkins on Unsplash
Layoffs
I’ve never been fired, but have been laid off three times over the course of four distinct careers. I’m also three-for-three for having landed in a much better place after having been laid off. So with three data points, maybe there is some truth to the street wisdom that a little adversity is a good thing.
“I judge you unfortunate because you have never lived through misfortune. You have passed through life without an opponent- no one can ever know what you are capable of, not even you.” – Seneca, On Providence, 4.3
I have also survived 17 layoffs. And I remember them all.
Paradoxically, many of the layoffs I survived were more painful than the layoffs in which I was included. I have clear memories of people I enjoyed working with that one day were simply gone from the place I was spending more than one third of my life. The resulting crash of morale at the workplace simply added to the sense of dread and “why bother” attitude. Their absence became a reminder that we were all living under someone else’s Sword of Damocles, that we would pay the price of poor decisions made by someone else. In some instances, the nauseatingly smug expression of schadenfreude by a few well-connected corporate parasites and toxic individuals cruising the corridors just added to the sting. It doesn’t seem this is easier to deal with by those that remain after a layoff in a distributed work environment.
To say I’ve “survived” all the layoffs that occurred throughout my multiple careers, whether I was culled or not, is more than a little melodramatic. I have truly survived much, much greater losses. Layoffs are not lethal events and living according to several key Stoic principles has helped me to persevere and gain strength from the brief storms of finding work.
“To bear trials with a calm mind robs misfortune of its strength and burden.” – Seneca, Hercules Oetaeus, 231232
Reflecting on work transition experiences, I wondered what is it about having been laid off that made the next place so much better.
I have always worked hard to add value to my employer’s business. If that value was either not appreciated or the business shifted away from needing the value I was capable and willing to provide, it was a clear sign that it’s time to move on. By making this a choice, I could leave with no hard feelings and no burned bridges. Psychologically, this is more intimidating but much healthier.
Seeing the positive side of being laid off can be a little more difficult, particularly if one has been blind to the signs that every company and manager broadcasts when a layoff is eminent and is surprised when they happen. For starters, layoffs erased all the baggage I was carrying that belonged to the employer and made it much easier to strike out in a direction that suited my interests, skills, talents, and goals. Each of the three layoffs launched new, more lucrative and rewarding careers.
“Today I escaped from the crush of circumstances, or better put, I threw them out, for the crush wasn’t from outside me but in my own assumptions.” – Marcus Aurelius, Meditations, 9.13
Switching employers, even careers, more frequently than previous generations is a good career development strategy. In the dot com era, it was the only effective way to find meaningful raises and career advancement. Why toil away for a decade under Management-by-Taylorism to scratch out incremental pay increases when a salary could be increased by 10%-20% just by switching employers? Twenty-five years on, staying with the same employer for more than five years actually looks odd to many recruiters I’ve been talking to.
A friend of mine has a personal policy to commit to an employer for 1,000 days. At that point, she decides if the workplace it meeting her goals and expectations. Doesn’t matter if it’s a shortcoming of her employer or if her goals and interests have changed – a mismatch is a mismatch so it’s time to leave. I think it’s a good policy, particularly in the Age of Information and Knowledge and distributed workforces.
A policy like this builds resilience in several ways.
1. It’s important to know what it takes to persevere with the crap work that goes with just about any job. Flitting from job to job doesn’t develop this. A 1,000 day commitment is enough to show that you made it past the “honeymoon” period every job has, have worked more than a few significant problems into solutions, and generally paid your dues and demonstrated – if only to yourself – you have the chops to do the work.
2. Deciding to leave a job and doing so multiple times throughout your life builds confidence in your abilities to create your future.
3. It adds a valuable layer to your talent stack, as Scott Adams has described it.
If it was generally known that employees had this policy, employers might expand their efforts to foster cultures that allow employees who are creative and collaborative to thrive and grow. Instead of what’s more common: Cube farms propped up by career leaches that brag about having worked at the company for 25 years when in fact all they’ve done is worked one mediocre year and repeated it 24 times.
I’m done with that. Forever.
“There are those too who suffer not from moral steadfastness but from inertia, and so lack the fickleness to live as they wish, and just live as they have begun.” – Seneca, On Tranquility of Mind
Photo by Benmar Schmidhuber on Unsplash
Show Your Work
A presentation I gave last week sparked the need to reach back into personal history and ask when I first programmed a computer. That would be high school. On an HP 9320 using HP Educational Basic and an optical card reader. The cards looked like this:
What occurred to me was that in the early days – before persistent storage like cassette tapes, floppy disks, and hard drives – a software developer could actually hold a program in their hands. Much like a woodworker or a glass blower or a baker or a candlestick maker, we could actually show something to friends and family! Woe to the student who literally dropped their program in the hallway.
Then that went away. Keyboards soaked up our coding thoughts and stored them in places impossible to see. We could only tell people about what we had created, often using lots of hand waving and so much jargon that it undoubtedly must have seemed as if we were speaking a foreign language or retelling a fish-that-got-away story. “I had to parse a data file THIIIIIIIIIS BIG using nothing but Python as an ETL tool!”
Yawn.
This is at the heart of what burned me out on writing code as a profession. There was no longer anything satisfying about it. At least, not in the way one gets satisfaction from working with wood or clay or fabric or cooking ingredients. The first time I created a predictive inventory control algorithm was a lot of fun and satisfying. But there were only 4-5 people on the planet who could appreciate what I’d done and since it was proprietary, I couldn’t share it. And just how many JavaScript-based menu systems can you write before the challenge becomes a task and eventually a tedious chore.
Way bigger yawn.
I’ve since found my way back into coding. A little. Python, several JavaScript libraries, and SQL are where I spend most of my time. What I code is what serves me. Tools for my use only. Tools that free up my time or help me achieve greater things in other areas of my life.
I can compare this to woodworking. (Something I very much enjoy and from which I derive a great deal of satisfaction.) If I’m making something for someone else, I put in extra effort to make it beautiful and functional. To do that, I may need to make a number of tools to support the effort – saw fences, jigs, and clamps. These hand-made tools certainly don’t look very pretty. They may not even be distinguishable from scrap wood to anybody but myself. But they do a great job of helping me achieve greater things. Things I can actually show and touch. And if the power goes down in the neighborhood, they’ll still be there when the lights come back on.
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. Even though this happened fast, 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.
- The truck ahead of me was slowing down. Unusual behavior when the expectation is that traffic would be flowing.
- The driver in the truck was signaling that they intended to move to the left, either to switch lanes or turn left.
- 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 are some of the assumptions that were probably in play?
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. If we don’t do the work to identify and understand the assumptions driving our work processes we will usually be made aware of them when some crisis occurs. Where’s the fun in that?
Photo by Jaroslav Devia on Unsplash
Openness, Grapevines, and Strangleholds
If you truly value openness on your Agile teams, you must untangle them from the grapevine.
Openness is one of the core scrum values. As stated on Scrum.org:
“The scrum team and it’s stakeholders agree to be open about all the work and the challenges with performing the work.”
This is a very broad statement, encompassing not only openness around work products and processes, but also each individual’s responsibility for ensuring that any challenges related to overall team performance are identified, acknowledged, and resolved. In my experience, issues with openness related to work products or the processes that impact them are relatively straightforward to recognize and resolve. If a key tool, for example, is mis-configured or ill-suited to what the team needs to accomplish than the need to focus on issues with the tool should be obvious. If there is an information hoarder on the team preventing the free flow of information, this will reveal itself within a few sprints after a string of unknown dependencies or misaligned deliverables have had a negative impact on the team’s performance. Similarly, if a team member is struggling with a particular story card and for whatever reason lacks the initiative to ask for help, this will reveal itself in short order.
Satisfying the need for openness around individual and team performance, however, is a much more difficult behavior to measure. Everyone – and by “everyone” I mean everyone – is by nature very sensitive to being called out as having come up short in any way. Maybe it’s a surprise to them. Maybe it isn’t. But it’s always a hot button. As much as we’d like to avoiding treading across this terrain, it’s precisely this hypersensitivity that points to where we need to go to make the most effective changes that impact team performance.
At the top of my list of things to constantly scan for at the team level are the degrees of separation (space and time) between a problem and the people who are part of the problem. Variously referred to as “the grapevine”, back channeling, or triangulation, it can be one of the most corrosive behaviors to a team’s trust and their ability to collaborate effectively. From his research over the past 30 years, Joseph Grenny [1] has observed “that you can largely predict the health of an organization by measuring the average lag time between identifying and discussing problems.” I’ve found this to be true. Triangulation and back-channeling adds significantly to the lag time.
To illustrate the problem and a possible solution: I was a newly hired scrum master responsible for two teams, about 15 people in total. At the end of my first week I was approached by one of the other scrum masters in the company. “Greg,” they said in a whisper, “You’ve triggered someone’s PTSD by using a bad word.” [2]
Not an easy thing to learn, having been on the job for less than a week. Double so because I couldn’t for the life of me think of what I could have said that would have “triggered” a PTSD response. The only people I knew who had been diagnosed with PTSD were several Vietnam veterans and a cop – men who had been through violent and life-or-death circumstances. This set me back on my heels but I did manage to ask the scrum master to please ask this individual to reach out to me so I could speak with them one-to-one and apologize. At the very least, suggest they contact HR as a PTSD response triggered by a word is a sign that someone needs help beyond what any one of us can provide. My colleague’s responses was “I’ll pass that on to the person who told me about this.”
“Hold up a minute. Your knowledge of this issue is second hand?”, I asked.
Indeed it was. Someone told someone who told the scrum master who then told me. Knowing this, I retracted my request for the scrum master to pass along my request. The problem here was the grapevine and a different tack was needed. I coached the scrum master to 1) never bring something like this to me again, 2) inform the person who told you this tale that you will not be passing anything like this along to me in the future, and 3) to coach that person to do the same to the person who told them. The person for whom this was an issue should either come to me directly or to my manager. I then coached my manager and my product owners that if anyone were to approach them with a complaint like this to listen carefully, acknowledge that you heard them, and to also encourage them to speak directly with me.
This should be the strategy for anyone with complaints that do not rise to the level of needing HR intervention. The goal of this approach is to develop behaviors around personal complaints such that everyone on the team knows they have a third person to talk to and that the issue isn’t going to be resolved unless they talked directly to the person with whom they have an issue. It’s a good strategy for cutting the grapevines and short circuiting triangulation (or in my case the quadrangulation.) To seal the strategy, I gave a blanket apology to each of my teams the following Monday and let them know what I requested of my manager and product owners.
The objective was to establish a practice of resolving issues like this at the team level. It’s highly unlikely (and in my case 100% certain) that anyone new to a job would have prior knowledge of sensitive words and purposely use language that’s upsetting to their new co-workers. The presupposition of malice or an assumption that a new hire should know such things suggested a number of systemic issues with the teams, something later revealed to be accurate. It wouldn’t be a stretch to say that in this organization the grapevine supplanted instant messaging and email as the primary communication channel. With the cooperation of my manager and product owners, several sizable branches to the grapevine had been cut away. Indeed, there was a marked increase in the teams attention during daily scrums and the retrospectives became more animated and productive in the weeks that followed.
Each situation is unique, but the intervention pattern is more broadly applicable: Reduce the number of node hops and associated lag time between the people directly involved with any issues around openness. This in and of itself may not resolve the issues. It didn’t in the example described above. But it does significantly reduce the barriers to applying subsequent techniques for working through the issues to a successful resolution. Removing the grapevine changes the conversation.
References
[1] Grenny, J. (2016, August 19). How to Make Feedback Feel Normal. Harvard Business Review, Retrieved from https://hbr.org/2016/08/how-to-make-feedback-feel-normal [2] The “bad” word was “refinement.” The team had been using the word “grooming” to refer to backlog refinement and I had suggested we use the more generally accepted word. Apparently, a previous scrum master for the team had been, shall we say, overly zealous in pressing this same recommendation to a degree that it became a traumatic experience for someone on the one of the teams. I later learned this event was grossly exaggerated. The developer had a well known reputation for claiming psychological trauma to cower others into backing down and would laugh and brag about using this club. The strategy described in this article proved effective at preventing this type of behavior.Autopilot Agile
There is a story about a bunch of corporate employees that have been working together for so long they’ve cataloged and numbered all the jokes they’ve told (and re-told) over the years. Eventually, no one need actually tell the joke. Someone simply yells out something like “Number Nine!” and everyone laughs in reply.
As Agile methodologies and practices become ubiquitous in the business world and jump more and more functional domain gaps, I’m seeing this type of cataloging and rote behavior emerge. Frameworks become reinforced structures. Practices become policies. “Daily Scrum” becomes code for “status meeting.” “Sprint Review” becomes code for “bigger status meeting.” Eventually, everyone is going through the motions and all that was Agile has drained from the project.
When you see this happening on any of your teams, start introducing small bits of randomness and pattern interruptions. In fact, do this anyway as a preventative measure.
- One day a week, instead of the usual daily scrum drill (Yesterday. Today. In the way.), have each team member answer the question “Why are you working on what today?” Or have each team member talk about what someone else on the team is working on.
- Deliberately change the order in which team members “have the mic” during stand-ups.
- Hold a sprint prospective. What are the specific things the team will be doing to further their success? What blockers or impediments can they foresee in the next sprint? Who will be dependent on what work to be completed by when?
- Set aside story points or time estimates for several sprints. I guarantee the world won’t end. (And if it does, well, we’ve got bigger problems than my failed guarantee.) How did that impact performance? What was the impact on morale?
- During a backlog refinement session, run the larger story cards through the 5 Whys. Begin with “Why are we doing this work?” This invariably ends up in smaller cards and additions to the backlog.
There’s no end to the small changes that can be introduced on the spur of the moment to shake things up just a bit without upsetting things a lot. The goal is to keep people in a mindset of fluidity, adaptability, and recalibration to the goal.
It’s more than a little ironic and somewhat funny to see autopilot-type behavior emerge in the name of Agile. But if you really want funny…Number Seven!
Image by Ronald Plett from Pixabay
Agile Haiku #5
Help! Show me the way!
Acceptance criteria.
The path is made clear.