Friends, Guides, Coaches, and Mentors

The “conscious competence” model for learning is fairly well known. If not explicitly, than at least implicitly. Most people can recognize when someone is operating at a level of unconscious incompetence even if they can’t quite put their finger on why it is such a person makes the decisions they do. Recognizing when we ourselves are at the level of unconscious incompetence is a bit more problematic.

A robust suite of cognitive biases that normally help us navigate an increasingly complex world seem to conspire against us and keep us in the dark about our own shortcomings and weaknesses. Confirmation bias, selective perception, the observer bias, the availability heuristic, the Ostrich effect, the spotlight effect and many others all help us zero in on the shiny objects that confirm and support our existing memories and beliefs. Each of these tissue-thin cognitive biases layer up to form a dense curtain, perhaps even an impenetrable wall, between the feedback the world is sending and our ability to receive the information.

There is a direct relationship between the density of the barrier and the amount of energy needed to drive the feedback through the barrier. People who are introspective as well as receptive to external feedback generally do quite well when seeking to improve their competencies. For those with a dense barrier it may require an intense experience to deliver the message that there are things about themselves that need to change. For some a poorly received business presentation may be enough to send them on their way to finding out how to do better next time. For others it may take being passed over for a promotion. Still others may not get the message until they’ve been fired from their job.

However it happens, if you’ve received the message that there are some changes you’d like to make in your life and it’s time to do the work, an important question to ask yourself is “Am I searching for something or am I lost?”

If you are searching for something, the answer may be found in a conversation over coffee with a friend or peer who has demonstrated they know what you want to know. It maybe that what you’re looking for – improve your presentation skills, for example – requires a deeper dive into a set of skills and it makes sense to find a guide to help you. Perhaps this involves taking a class or hiring a tutor.

If you are lost you’ll want to find someone with a much deeper set of skills, experience, and wisdom. A first time promotion into a management position is a frequent event that either exposes someone’s unconscious incompetence (i.e. the Peter Principle) or challenges someone to double their efforts at acquiring the skills to successfully manage people. Finding a coach or a mentor is the better approach to developing the necessary competencies for success when the stakes are higher and the consequences when failing are greater.

A couple of examples may help.

When I was first learning to program PCs I read many programming books cover to cover. It was a new world for me and I had very little sense of the terrain or what I was really interested in doing. So I studied everything. Over time I became more selective of the books I bought or read. Eventually, I stopped buying books altogether because there was often just a single chapter of interest. Today, I can’t remember the last time I picked up a software development book. This was a progression from being lost at the start – when I needed coaches and mentors in the form of books and experienced software developers – to needing simple guidance from articles and peers and eventually to needing little more than a hint or two toward the end of my software development career.

A more recent example is an emergent need to learn photography – something I don’t particular enjoy. Yet for pragmatic reasons, it’s become worth my time to learn how to take a particular kind of photograph. I need a coach or a mentor because this is entirely new territory for me. So I hired a professional photographer with an established reputation for taking this type of photograph I’m interesting in. My photography coach is teaching me what I need to know. (He is teaching me how to fish, in other words, rather then me paying him for a fish every time I need one.)

Unlike the experience of learning how to program – where I really didn’t know what I wanted to do – my goal with photography is very specific. The difference has a significant influence on who I choose for guides and mentors. For software development, I sought out everyone and anyone who knew more than I. For photography, I sought a very specific set of skills. I didn’t want to sit through hours of classes learning how to take pictures of barn owls 1,000 meters away in the dark. I didn’t want to suffer through a droning lecture on the history of camera shutters. Except in a very roundabout way, none of this serves my goal for learning how to use a camera for a very specific purpose.

Depending on what type of learner you are, working with a mentor who really, really knows their craft about a specific subject you want to learn can be immensely more satisfying and enjoyable. Also, less expensive and time consuming. If it expands into something more, than great. With this approach you will have the opportunity to discover a greater interest without a lot of upfront investment in time and money.

How to Frame Team Development Challenges

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

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

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

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

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

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

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

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

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

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

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

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

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

What’s in YOUR manual?

You go to see a movie with a friend. You sit side-by-side and watch the same movie projected on the screen. Afterward, in discussing the movie, you both disagree on the motives of the lead character and even quibble over the sequence of events in the movie you just watched together.

How is it that two people having just watched the same movie could come to different conclusions and even disagree over the sequence of events that – objectively speaking – could have only happened in one way?

It’s what brains do. Memory is imperfect and every one of us has a unique set of filters and lenses through which we view the world. At best, we have a mostly useful but distorted model of the world around us. Not everyone understands this. Perhaps most people don’t understand this. It’s far more common for people – especially smart people – to believe and behave as if their model of the world is 1) accurate and 2) shared with everybody else on the planet.

Which gets me to the notion of the user manuals we all carry around in our heads about OTHER people.

Imagine a tall stack of books, some thin others very thick. On the spine of each book is the name of someone you know. The book with your partner’s name on it is particularly thick. The book with the name of your favorite barista on the spine is quite a bit thinner. Each of these books represents a manual that you have written on how the other person is supposed to behave. Your partner, for example, should know what they’re supposed to be doing to seamlessly match your model of the world. And when they don’t follow the manual, there can be hell to pay.

Same for your coworkers, other family members, even acquaintances. The manual is right there in plain sight in your head. How could they not know that they’re supposed to return your phone call within 30 minutes? It’s right there in the manual!

It seems cartoonish. But play with this point of view for a few days. Notice how many things – both positive and negative – you project onto others that are based on your version of how they should be behaving. What expectations do you have, based on the manual you wrote, for how they’re supposed to behave?

Now ask yourself, in that big stack of manuals you’ve authored for how others’ brains should work, where is your manual? If you want to improve all your relationships, toss out all of those manuals and keep only one. The one with your name on the spine. Now focus on improving that one manual.

Collaboration vs Clobber-ation – Redux

I was taken to task for “not being a team player” in my example of walking away from an opportunity to co-develop a training program with a difficult Agile coach. It was easy to set this criticism aside as the person offering it was in no position to be familiar with the context or full story. Nonetheless, the comment gave me pause to consider more deeply the rationale behind my decision. What experiential factors did I leverage when coming to this seemingly snap decision?

I can think of five context characteristics to consider when attempting to collaborate in an environment charged with conflict.

First, is the disagreement over the details of the work to be done? My peer and I didn’t have agreement on whether or not it was important or useful to include information on basic story sizing as part of the story splitting presentation. I wanted to include this information, my peer did not.

Second, is there a disagreement over how the work is to be done? I wanted to preface the story splitting section with a story sizing section whereas my peer was intent on eviscerating the story sizing section to such an extent as to make it meaningless.

Third, is there any type of struggle around status or who “should” be in charge? My peer demonstrated unambiguous behavior that she was “The Coach” for the company and that anything that may be presented to employees should be an expression of her authorship. When she instructed me to send my deck of slides to her for “revision” and I refused, she visibly bristled. By this point, I wasn’t about to release my copyrighted material into her possession.

Fourth, are there corporate politics that promote – intentionally or unintentionally – silos and turf protection? My client’s organization could be be held forth as a textbook example of Conway’s Law. The product reflected an uncounted number of incomplete efforts and failed attempts at unifying the underlying architecture. The Agile Coach’s behavior was just one more example of someone in the organization working to put their stamp of value on the ever-growing edifice of corporate blobness.

Finally, is there a conflict of personalities or communication styles? Again, this was true in this case. I wanted to co-create whereas my peer wanted to commandeer and direct. I wanted to present, she wanted to interrupt.

No work environment is free of these characteristics and it may be they are all present in some degree or another. I expect these characteristics to be in place no matter where I work. However, in this case, it was clear to me we were not in alignment with any of these characteristics and each of them were present at very high levels. Sorting this out wasn’t worth my time at just about any price. Certainly not at the price I was being paid. Walking away wasn’t going to burn any bridges as there were no bridges in existence to begin with.

Behind the Curtain: The Scrum Master Role

It is popular to characterize the scrum master role as following a “servant leader” style of engagement with scrum teams. Beyond that, not much else is offered to help unpack just what that means. The more you read about “servant leadership” the more confused you’re likely to get. A lot of what’s available on the Internet and offered in trainings ends up being contradictory and overburdening to someone just trying to help their team excel. Telling someone they’ll need to become a “servant leader” can be like telling them to go away closer.

So let’s unpack that moniker a little and state what it means in more practical terms for the average, yet effective, scrum master.

To begin, it’s most helpful to put a little space between the two skills. As a scrum master you’ll need to serve. As a scrum master you’ll need to lead. When you’re a good scrum master you’ll know when to do each of those and how. Someone who tries to do both at once usually ends up succeeding at neither.

As a servant, a scrum master has to keep a vigilant eye on making sure their servant behaviors are in the best interests of helping the delivery team succeed. If the scrum master lets the role devolve to little more than an admin to the product owner or the team then they’ve lost their way. It will certainly seem easier to write the story cards for the team, for example, rather than spend the time coaching them how to write story cards. This is a case where leadership is needed. On the other hand, if someone on the team is blocked by a dependency due to a past due deliverable from another team, then the scrum master would indeed serve the best interests of the team by working with the other team to resolve the dependency rather than require the delivery team member to shift focus away from completing work in the queue.

As a leader, a scrum master has to recognize any constraints the context places on the scope of their responsibilities. In meet-ups and conferences I’ve heard people say the scrum master “should be the team spiritual leader,” the team “therapist,” or “a shaman,” and able to administer to the team’s emotional needs. I take a more pragmatic approach and believe a scrum master should be able to recognize when someone on their team is in need of a qualified professional and, if necessary, assist them in finding the help they need. (HR departments exists, in part, to handle these situations.) This is still good leadership. It’s important to recognize the limits of one’s own capabilities and qualifications. Scrum master as therapist is a quagmire, to be sure, and I’ve yet to meet one with the boots to handle it.

Servant leader aside, the “master” in “scrum master” is the source of no end of grief. It’s partly to blame for the tendency in people to ascribe super powers to the scrum master role, such as those described above. In addition, the “master” part of the title implies “boss” or “manager.” It is a common occurrence for team members to address their stand-up conversation to me – as scrum master – rather than the team. I have to interrupt and specifically direct the individual to speak to the team. I’ve had team members share that they assumed I was going to take what was communicated in the stand-up and report directly to the product owner or the department head or even higher in the organization. “How come you’re not taking notes?”, they ask.”The stand-up is for you, not for me. Take your own notes, if you wish,” I reply. (I do take notes, but only for the purpose of following-up on certain issues or capturing action items for myself – things I need to do to remove impediments that are outside the team’s ability to resolve, for example.)

All the downside of what I’ve describe so far can be amplified by the Dunning–Kruger afflicted scrum master. Amplified again if they are “certified.” To paraphrase from the hacker culture on how you know you’re a hacker (in the classical sense), you aren’t a scrum master until someone else calls you a scrum master. There is always more to learn and apply. A scrum master who remains attentive to that fact will naturally develop quality servant and strong leadership skills.

Finally, the scrum master role is often a thankless job. When new to a team and working to establish trust and credibility the scrum master will need to build respect but often won’t be liked during the process. Shifting individuals out of their comfort zone, changing bad habits, or negotiating 21st Century sensitivities is no easy task even when people like and respect you. So a quality scrum master will work to establish respect first and let the liking follow in due course.

Having succeed at this the scrum master’s business will likely shift to the background. So much so some may wonder why they’re taking up space on the team. Working to establish and maintain this level of performance with a team while remaining in the background is at the heart of the servant part of servant/leader.

OnAgile 2017

Attended the Agile Alliance‘s OnAgile 2017 Conference yesterday. This is always an excellent conference and you can’t beat the price!

I created a mind map throughout the course of the conference as a way to organize my thoughts and key points. This doesn’t capture all the points by any means. Just those that stood out as important or new for me. I missed most of the first session due to connectivity issues.

Clouds and Windmills

I recently resigned from the company I had been employed by for over 5 years. The reason? It was time.

During my tenure1 I had the opportunity to re-define my career several times within the organization in a way that added value and kept life productive, challenging, and rewarding. Each re-definition involved a rather extensive mind mapping exercises with hundreds of nodes to described what was working, what wasn’t working, what needed fixing, and where I believed I could add the highest value.

This past spring events prompted another iteration of this process. It began with the question “What wouldn’t happen if I didn’t go to work today?”2 This is the flip of asking “What do I do at work?” The latter is a little self-serving. We all want to believe we are adding value and are earning our pay. The answer is highly filtered through biases, justifications, excuses, and rationalizations. But if in the midsts of a meeting you ask yourself, “What would be different if I were not present or otherwise not participating?”, the answer can be a little unsettling.

This time around, in addition to mind mapping skills, I was equipped with the truly inspiring work of Tanmay Vora and his sketchnote project. Buy me a beer some day and I’ll let you in on a few of my discoveries. Suffice it to say, the overall picture wasn’t good. I was getting the feeling this re-definition cycle was going to include a new employer.

A cascade of follow-on questions flowed from this iteration’s initial question. At the top:

  1. Why am I staying?
  2. Is this work aligned with my purpose?
  3. Have my purpose and life goals changed?

The answers:

  1. The paycheck
  2. No.
  3. A little.

Of course, it wasn’t this simple. The organization changed, as did I, in a myriad of ways. While exploring these questions, I was reminded of a story my Aikido teacher, Gaku Homma, would tell when describing his school. He said it was like a rope. In the beginning, it had just a few threads that joined with him to form a simple string. Not very strong. Not very obvious. But very flexible. Over time, more and more students joined his school and wove their practice into Nippon Kan’s history. Each new thread subtlety changed the character of the emerging rope. More threads, more strength, and more visibility. Eventually, an equilibrium emerges. Some of those threads stop after a few short weeks of classes, other’s (like mine) are 25 years long before they stop, and for a few their thread ends in a much more significant way.

Homma Sensi has achieved something very difficult. The threads that form Nippon Kan’s history are very strong, very obvious, and yet remain very flexible. Even so, there came a time when the right decision for me was to leave, taking with me a powerful set of skills, many good memories, and friendships. The same was true for my previous employer. Their rope is bending in a way that is misaligned with my purpose and goals. Neither good nor bad. Just different. Better to leave with many friendships intact and a strong sense of having added value to the organization during my tenure.

The world is full of opportunities. And sometimes you have to deliberately and intentionally clear all the collected clutter from your mental workspace so those opportunities have a place to land. Be attentive to moments like this before your career is remembered only as someone who yells at clouds and tilts at windmills.


1 By the numbers…

1,788 Stand-ups
1,441 Wiki/Knowledgebase Contributions
311 Sprint/Release Planning Sessions
279 Reviews
189 Retrospectives
101 Projects
31 Internal Meet-ups
22 Agile Cafés
10 Newsletters
5.5 Years
3 Distinct Job Titles
1 Wild Ride

2 My thanks to colleague Lennie Noiles and his presentation on Powerful Questions. While Lennie didn’t ask me this particular question, it was inspired by his presentation.

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.

False Barriers to Implementing Scrum – II

In a previous post, I described several barriers to implementing scrum. Recently, an additional example came to light similar to the mistake of elevating scrum or Agile to a philosophy.

In a conversation with a colleague, we were exploring ways on how we might drive interest for browsing the growing wealth of Agile related information being added to the company wiki.  It’s an impressive collection of experiences of how other teams have solved a wide array of interesting problems using Agile principles and practices. Knowing that we cannot personally attend to every need on every project team, we were talking through various ways to develop the capacity for exploration and self-education. I think I must have used the phrase “the information is out there and readily available” a couple of times to many because my colleague reacted to where I put the bar by comparing learning Agile to surgery.

Using the surgery metaphor, she pressed the comparison that all the information she needs about surgery is “out there and readily available” but even if she knew all that information she likely wouldn’t be a good surgeon. Fair point that experience and practice are important. And if that is the case, then everyone should be taking every opportunity they can to practice good agile rather than regressing to old habits.

More importantly, perhaps, is the misapplied metaphor. Practicing agile isn’t as complicated as surgery or rocket science or any other such endeavor that requires years of deep study and practice. Comparing it to something like that places the prospects of doing well in a short amount of time mentally beyond the reach of any potential practitioners.

Perhaps a better metaphor is the opening of a new rail line in the city. A good measure of effort needs to be expended to educate the public on the line’s availability, the schedules, how to purchase fares, where the connections are, what are the safety features, etc. Having done that, having “put the information out there where it is generally available,” it is a reasonable expectation that the public will make the effort to find it when they need it. It is unreasonable, and unscaleable, to build such a system and then expect that every passenger will be personally escorted from their front door to their seat on the train.

It is also interesting to consider what this does to the “empathy scale” when such an overextended metaphor is applied to efforts such as learning to practice Agile. If we frame learning Agile as similar to surgery then as people work to implement Agile are we more inclined to have an excessive amount of empathy for their struggles and be more accepting or accommodating of their short comings?

“Not to worry that you still don’t have a well formed product backlog. This is like surgery, after all.”

Are we as an organization and each of our employees better served by the application of a more appropriate metaphor, one that matches the skill and expectations of the task?

“We’ve provided instruction as to what a product backlog is and how to create one. We’ve guided you as you’ve practiced refining a product backlog. You know where to find suggestions for improving your skills for product backlog stewardship (wiki, books, colleagues, etc). Now role up your sleeves and do the work.”

Successful coaching for developing the ability in team members for actively seeking answers requires skillfully letting them struggle and fail in recoverable ways. It is possible to hold their hand too long. To use another metaphor, provide whatever guidance and instruction you need to so they know how to fish, then let them alone to practice casting their own line.


Photo credit: langll

Agile Interns

I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…

The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…

Failure

It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.

Chaos

We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.

Confusion

One of the values for bringing interns into the organization is the fresh perspective they offer.  Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that  seeks alternative points of view. In this organization, everyone gets their own coffee.