Category: Agile

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

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.

  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 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.

Photo by Ben Neale on Unsplash

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

What does Agile documentation look like?

Reading through Dusty Phillips’ second edition of “Python 3 Object-oriented Programming,” this quote caught my attention:

Further, the most important person you will ever have to communicate with is yourself. We all think we can remember the design decisions we’ve made, but there will always be the Why did I do that? moments hiding in our future. If we keep the scraps of papers we did our initial diagramming on when we started a design, we’ll eventually find them a useful reference.

That strikes me as a good benchmark for acceptable documentation in Agile. Whether coder, UI/UX designer, data architect, or whatever, if you are keeping a good record of what you decided and why, you’ll probably be able to recreate the rationale for why things got to be the way they are for anybody who needs to know. Especially if that anybody is you. And there is a good chance that someone following in your footsteps will be able to pick up the same rationale even in your absence. All this without putting an unnecessary burden on project progress for the sake of detailed documentation.

Of course, what qualifies as “good” is the tricky part. A suggested threshold would be to specify only as much information as makes sense or for what is known given the current situation. Documentation should be subject to iterative practices just as much as code.

Image by Pexels from Pixabay

False Barriers to Implementing Scrum

When my experience with scrum began to transition from developer to scrum master and on to mentor and coach, early frustrations could have been summed up in the phrase, “Why can’t people just follow a simple framework?” The passage of time and considerable experience has greatly informed my understanding of what may inhibit or prevent intelligent and capable people from picking up and applying a straightforward framework like scrum.

At the top of this list of insights has to be the tendency of practitioners to place elaborate decorations around their understanding of scrum. In doing so, they make scrum practices less accessible. The framework itself can make this a challenge. Early on, while serving in the role of mentor, I would introduce scrum with an almost clinical textbook approach: define the terms, describe the process, and show the obligatory recursive work flow diagrams. In short order, I’d be treading water (barely) in recursive debates on topics like the differences between epics and stories. I wrote about this phenomenon in a previous post as it relates to story points. So how can we avoid being captured by Parkinson’s law of triviality and other cognitive traps?

Words Matter

I discovered that the word “epic” brought forth fatigue inducing memories of Homer’s Iliad and Odyssey, the Epic of Gilgamesh, and Shakespeare. Instant block. Solution out of reach. It was like putting a priceless, gold-plated, antique picture frame around the picture postcard of a jackalope your cousin sent on his way through Wyoming. Supertanker loads of precious time were wasted in endless debates about whether or not something was an epic or a story. So, no more talk of epics. I started calling them “story categories.” Or “chapters.” Or “story bundles.” Whatever it took to get teams onto the idea that “epics” are just one of the dimensions to a story map or product backlog that helps the product owner and agile delivery team keep a sense of overall project scope. Story writing progress accelerated and teams were doing a decent job of creating “epics” without knowing they had done so. Fine tuning their understanding and use of formal scrum epics came later and with much greater ease.

“Sprint” is another unfortunate word in formal scrum. With few exceptions, the people that have been on my numerous scrum teams haven’t sprinted anywhere in decades. Sprinting is something one watches televised from some far away place every four years. Maybe. Given its fundamental tenets and principles, who’s to say a team can’t find a word for the concept of a “sprint” that makes sense to them. The salient rule, it would seem, is that whatever word they choose, the team fully understand that “it” is a time-boxed commitment for completing a defined set of work tasks. And if “tide,” “phase,” or “iteration” gets the team successfully through a project using scrum then who am I to wear a the badge of “Language Police?”

A good coach meets the novice at their level and then builds their expertise over time, structured in a way that matches and challenges the learner’s capacity to learn. I recall from my early Aikido practice the marked difference between instructors who stressed using the correct Japanese name for a technique over those that focused more on learning the physical techniques and described them in a language I could understand. Once I’d learned the physical patterns the verbal names came much more easily.

Full disclosure: this is not as easy when there are multiple scrum teams in the same organization that eventually rotate team members. Similarly, integrating new hires with scrum experience is much easier when the language is shared. But to start, if the block to familiarization with the scrum process revolves around semantic debates it makes sense to adapt the words so that the team can adopt the process then evolve the words to match more closely those reflected in the scrum framework.

Philosophy, System, Mindset, or Process

A similar fate awaited team members that had latched onto the idea that scrum or agile in general is a philosophy. I watched something similar happen in the late 1980’s when the tools and techniques of total quality management evolved into monolithic world views and corporate religions. More recently, I’ve attended meet-ups where conversations about “What is Agile?” include describing the scrum master as “therapist” or “spiritual guide.” Yikes! That’s some pretty significant mission creep.

I’m certain fields like philosophy and psychotherapy could benefit from many of the principles and practices found in agile. But it would be a significant category error to place agile at the same level as those fields of study. If you think tasking an agile novice with writing an “epic” is daunting, try telling them they will need to study and fully understand the “philosophy of agile” before they become good agile practitioners.

The issue is that it puts the idea of practicing agile essentially out of reach for the new practitioner or business leader thinking about adopting agile. The furthest up this scale I’m willing to push agile is that it is a mindset. An adaptive way of thinking about how work gets done. From this frame I can leverage a wide variety of common, real-life experiences that will help those new to agile understand how it can help them succeed in their work life.

Out in the wild, best to work with the system as much as possible if you want meaningful work to actually get done.