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

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

Deliberate Practice and Coding

Deliberate practice applied to coding offers some unique opportunities. Unlike other skills, like learning to play the cello (to pick one that I have some experience with), you can go very far without a personal mentor. The feedback from the computer is about as objective as it gets. It will let you know exactly how good your code is.

This also helps remove the emotional component – positive and negative – that can sometimes impede progress with an in-person mentor. This doesn’t remove all emotion, however. Just about everyone who’s worked in a professional coding shop has witnessed the rare occurrence of a coder cursing at or even physically attacking their computer because their code isn’t working as expected. Those are surreal moments when an avalanche of cognitive biases and unconscious behavior become visible to all but the coder. That’s a topic for for a different post. Suffice it to say, learning how to control your emotions, channel frustration, and ignite curiosity is part of what distinguishes good coders from great coders.

Which gets met to finding quality feedback. While I’ve made a good living writing mountains of proprietary code for various business and corporations, I earned my coding chops by working on or authoring open source projects. This was the best source I found for getting feedback on my code. It also taught me another important lesson: Do not attach your identity to the code you write. Like any noob, I had a lot of pride in my early code that was pretty much untested outside my little work environment. In the open source world, the feedback was often swift and harsh. Or, at least is was when my identity was attached to it. Learning to separate work product from identity revealed just how much emotional spin I was putting on what was in hindsight reasonable feedback. I have concerns that the current climate in the coding world is opting for soft feedback and good feelings over legitimate and reasonable feedback. This, too, is for another post.

It’s worth giving some thought about the the pros and cons of working with an actual person for mentorship. Along with good instruction, a single mentor will pass along their own limitations and biases. Not necessarily a bad thing, just something to be aware of. So multiple mentors are better than just one, which starts to move down the path of actively participating in open source projects. By “actively” I mean not just contributing code, but studying the code (and it’s history) of existing successful projects. There are usually many ways to solve a problem with software. Work to understand why one approach is better than another. Insights like this are best gained, in my experience, by studying good code.

Somewhat related, if you are working from a book or a training program, actually type in the examples – character by character. Don’t cheat yourself by copy-pasting code examples. This is the muscle memory component to coding that you will find when learning other more physical skills (like playing the cello.) If you really want to experience the gnarly edge, ditch the IDE and code with at text editor. I still do all my coding in vim and this keyboard.

Another approach to deliberate practice is the idea of coding “katas.” This never clicked with me. I attribute this to having studied martial arts for 25 years, most of that time at the black belt level. Mapping the human psycho/physical world and the purpose of katas in the dojo to the machine world is too much of a mis-match. Much is lost in the translation, in my experience. The katas in the dojo, regardless the art form, translated easily to other styles and practices. The coding “katas” are more tightly coupled to the coding language in which they are written. In my view, it’s yet another example of swiping a cool sounding word and concept and force-fitting it to another domain. A software version of cargo cults – expecting form to create function. “Black belt” or “Ninja” coder are other force-fits. Yet again, something for another post.

But those are my limitations. Your experience will no doubt be different. As learning exercises and proficiency tracks, many of the coding “katas” look to be very good.

(For related thoughts on how building your own tools can deepen your understanding of a skill, see “Tools for Practice.” The examples in the article combine software development and cello practice.)

 

Image by Robert Pastryk from Pixabay

Tools for Practice

Building the tools you need to develop a skill will also deepen your understanding of that skill.

The pandemic has offered unprecedented opportunity for reflection and self-improvement. Unsurprisingly, most people don’t see it this way and therefore have failed to take advantage of the opportunity. Upsetting the status quo and the familiar – however slight – leads to a disproportionate amount of stress and anxiety for many people. The prospect of getting to know their families or themselves better proves uncomfortable enough to drive people toward bing-watching TV, over-eating, alcohol, or any number of other distractions. Anything to avoid introspection. My theory is that this happens because most people have either lost or never had the skills for self-reflection. External validation is the way of the 21st century. That usually ends up with them expending exorbitant amounts of effort justifying their shortcomings or assigning blame to the nearest face they can put on their problems – an “annoying” partner, an “uncooperative” co-worker, etc.

I also believe it takes very little effort to begin the work of reflection, introspection, and self-improvement. Start simple.

When it was clear the pandemic lock-downs were going to go on longer then the “experts” kept saying – evidenced by the weekly movement of the goal posts – I began to wonder how I might use this newfound flexibility for how I organize time. No longer confined to the hours during which I would normally be in the physical office, I could now complete my 8 hours of work – broken into pieces – at almost at any time during my waking hours. Plus the distance I had to commute back and forth from home and work shrank to an incredibly small fraction of what it used to be. This, too, opened up more time. This change didn’t just occur in my world, but globally. And since everyone else still needed to stay employed, many creative people found ways to continue their professions in a virtual environment. Suddenly, engaging in things of interest but were unattainable because of time and space requirements became available.

I had been wanting to rekindle my interesting in playing cello for years. I hadn’t had a lesson in over 10 years and practice had fallen by the wayside. Now, connecting with an instructor was not only possible, but the number of options had exploded. There are now many on-line videos and instructors available. After a little research, I connected with an instructor in New York City and have been taking weekly lessons for the past three months.

The re-introduction of live music – particularly music that I’m playing – has had a surprisingly positive impact on my disposition. As a card carrying introvert, I thought I’d been handling the pandemic lock down pretty well, especially when compared to many of my peers. Yet this small change, focused on personal development, brought warmth and light to mid-winter days.

So that’s the back story. Now that I’m in the groove again with playing cello, I can describe several things about this experience that I’ve learned with respect to practice, particularly deliberate practice.

Along with playing cello, I wanted to deepen my understanding of music theory and learn how to sight read music. During one of my lessons, the instructor and I kicked around the idea of using flash cards. The card would show a single note and the student would play that note. Searching later for such an application was unsuccessful. It probably exists, but it wasn’t something I wanted to spend more than 30 minutes trying to find.

All the flash card programs I looked at are designed to teach things in a question – answer format. They work well for subjects like history or learning a new language. But nothing that would simply show a new card after a time delay. So I wrote my own program to accomplish this. In the process, I developed my understanding of the cello’s range of notes and music keys in general. Here’s a screen capture of the first iteration’s MVP:

At an adjustable interval, a new note within the cello’s range is displayed in the selected key. For my skill level, this is immensely challenging. And I can tell it is developing my skills for sight reading and quickly finding a particular note on the instrument.

Developing tools like this is second nature to me and the result of many years of experience working with wood and solving business problems with software. Each of these activities has a tenet that if you can’t find a tool you need, you build what you need from scratch. This tenet is all the more powerful by having stewed in the mindsets associated with hand tools and open source software. In a very real sense, creating tools that support acquiring a new skill are part of the practice. To build an effective tool, you must fully understand the problem it is intended to solve. An effective tool is the result of having asked and answered many good questions. And, of course, all this is driven by an Agile mindset (iterations, tests, experiments, redesign, retest, etc.) design thinking, and understanding the context in which the tool will be used (systems thinking.)

 

Image by endri yana yana from Pixabay

The Path to Mastery: Begin with the Fundamentals

Somewhere along the path of studying Aikido for 25  years I found a useful perspective on the art that applies to a lot of skills in life.  Aikido is easy to understand. It’s a way of living that leaves behind it a trail of techniques. What’s hard is overcoming the unending stream of little frustrations and often self-imposed limitations. What’s hard is learning how to make getting up part of falling down. What’s hard is healing after getting hurt. What’s hard is learning the importance of recognizing when a white belt is more of a master than you are. In short, what’s hard is mastering the art.

The same can be said about practicing Agile. Agile is easy to understand. It is four fundamental values and twelve principles. The rest is just a trail of techniques and supporting tools – rapid application development, XP, scrum, Kanban, Lean, SAFe, TDD, BDD, stories, sprints, stand-ups – all just variations from a very simple foundation and adapted to meet the prevailing circumstances. Learning how to apply the best technique for a given situation is learned by walking the path toward mastery – working through the endless stream of frustrations and limitations, learning how to make failing part of succeeding, recognizing when you’re not the smartest person in the room, and learning how to heal after getting hurt.

If an Aikidoka is attempting to apply a particular technique to an opponent  and it isn’t working, their choices are to change how they’re performing the technique, change the technique, or invent a new technique based on the fundamentals. Expecting the world to adapt to how you think it should go is a fool’s path. Opponents in life – whether real people, ideas, or situations – are notoriously uncompromising in this regard.  The laws of physics, as they say, don’t much care about what’s going on inside your skull. They stubbornly refuse to accommodate your beliefs about how things “should” go.

The same applies to Agile practices. If something doesn’t seem to be working, it’s time to step in front of the Agile mirror and ask yourself a few questions. What is it about the fundamentals you’re not paying attention to? Which of the values are out of balance? What technique is being misapplied? What different technique will better serve? If your team or organization needs to practice Lean ScrumXPban SAFe-ly than do that. Be bold in your quest to find what works best for your team. The hue and cry you hear won’t be from the gods, only those who think they are – mere mortals more intent on ossifying Agile as policy, preserving their status, or preventing the perceived corruption of their legacy.

But I’m getting ahead of things. Before you can competently discern which practices a situation needs and how to best structure them you must know the fundamentals.

There are no shortcuts.

In this series of posts I hope to open a dialog about mastering Agile practices. We’ll begin by studying several maps that have been created over time that describe the path toward mastery, discuss the benefits and shortcomings of each of these maps, and explore the reasons why many people have a difficult time following these maps. From there we’ll move into the fundamentals of Agile practices and see how a solid understanding of these fundamentals can be used to respond to a wide variety of situations and contexts. Along the way we’ll discover how to develop an Agile mindset.

Photo by simon sun on Unsplash

Building Mastery One Day At A Time

Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. “Excuse us, but can you tell us how to get to Carnegie Hall?” The musician stopped playing and thought for a moment before replying: “Practice.”

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence like chess and music. In each of these areas, the rules are relatively simple, but mastering them isn’t easy. It’s pretty easy to tell when someone is playing an instrument out of tune or off-beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they’re the ones who win against all challengers regardless the time or place of the match.

For areas of human endeavor where the edges are less well defined, like business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

Developing expertise with scrum is a blend of both of these. The rules are simple, but they are not easy to master. At the same time the territory isn’t well defined and frequently changes. A new client, a new team, or a new project and the edges for what is possible change. Misunderstanding this has been at the root of much of the frustration I’ve observed among people new to agile. They come from a world with well-defined edges – traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that “must” be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small thing. We like the comfort of well-defined rules. And when there’s work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super comfy confines of past practices and rule sets?

Practice, of the deliberate variety. As Emperor Hadrian might have put it, “Brick by brick, my fellow citizens, brick by brick.”

Research following on the “10,000 hours of practice” generalization has shown that it isn’t just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it’s deceptively easy to fall into a complacency of thought whereby we convince ourselves there isn’t anything else to learn. That is until some seismic paradigm shift makes it clear the rules have changed and we’d let our mastery go stale. The consequences of this are captured by Greene (2012) in his book, Mastery:

“We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable.” (pg. 176)

If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren’t a hacker until other recognized hackers call you a hacker. It’s a title to be earned, not claimed. The unfortunate title of “scrum master” aside, it is useful to take this credentialing tradition to heart with scrum as well. Consider yourself an apprentice scrum practitioner until other recognized scrum masters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never ending improvement.

I’ve been practicing, leading, or coaching scrum in one capacity or another for over 10 years and based on my billable hours over the past several years, I’m quite confident I’ve passed the 10,000 hour mark for practicing scrum. Even so, I’m not a master scrum master…yet. The reason is simple and is expressed by the great cellist Pablo Casals’ response to filmmaker Robert Snyder’s query as to why Casals continues to practice five hours a day at 80 years of age, “Because I think I am making progress.” I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time I think I’ve heard every excuse for not following the scrum framework, someone on one of my teams surprises me.

If you’re interested in staying on the path toward scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.

  • Frequently review the framework for scrum and compare what’s there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialog about these differences during your retrospectives.
  • If possible, ask your fellow agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.
  • There are probably a number of excellent agile related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

Image by sarfarazis from Pixabay

References

Greene, R. (2012). Mastery. New York, NY: Viking Penguin

Concave, Convex, and Nonlinear Fragility

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

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

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

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

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

Figure 10 shows:

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

After this presentation, Taleb simplifies the ideas:

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

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

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