Achieving 10x

Crossed paths with an old but still relevant conversation thread on Slashdot asking “What practices impede developers’ productivity?” The conversation is in response to an excellent post by Steve McConnell addressing productivity variations among software developers and teams and the origin of “10x” – that is, the observation noted in the wild of “10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries.”

The Slashdot conversation has two main themes, one focuses fundamentally on communication: “good” meetings, “bad” meetings, the time of day meetings are held, status reports by email – good, status reports by email – bad, interruptions for status reports, perceptions of productivity among non-technical coworkers and managers, unclear development goals, unclear development assignments, unclear deliverables, too much documentation, to little documentation, poor requirements.

A second theme in the conversation is reflected in what systems dynamics calls “shifting the burden”: individuals or departments that do not need to shoulder the financial burden of holding repetitively unproductive meetings involving developers, arrogant developers who believe they are beholding to none, the failure to run high quality meetings, code fast and leave thorough testing for QA, reliance on tools to track and enhance productivity (and then blaming them when they fail), and, again, poor requirements.

These are all legitimate problems. And considered as a whole, they defy strategic interventions to resolve. The better resolutions are more tactical in nature and rely on the quality of leadership experience in the management ranks. How good are they at 1) assessing the various levels of skill among their developers and 2) combining those skills to achieve a particular outcome? There is a strong tendency, particularly among managers with little or no development experience, to consider developers as a single complete package. That is, every developer should be able to write new code, maintain existing code (theirs and others), debug any code, test, and document. And as a consequence, developers should be interchangeable.

This is rarely the case. I can recall an instance where a developer, I’ll call him Dan, was transferred into a group for which I was the technical lead. The principle product for this group had reached maturity and as a consequence was beginning to become the dumping ground for developers who were not performing well on projects requiring new code solutions. Dan was one of these. He could barely write new code that ran consistently and reliably on his own development box. But what I discovered is that he had a tenacity and technical acuity for debugging existing code.

Dan excelled at this and thrived when this became the sole area of his involvement in the project. His confidence and respect among his peers grew as he developed a reputation for being able to ferret out particularly nasty bugs. Then management moved him back into code development where he began to slide backward. I don’t know what happened to him after that.

Most developers I’ve known have had the experience of working with a 10x developer, someone with a level of technical expertise and productivity that is undeniable, a complete package. I certainly have. I’ve also had the pleasure of managing several. Yet how many 10x specialists have gone underutilized because management was unable to correctly assess their skills and assign them tasks that match their skills?

Most of the communication issues and shifting the burden behaviors identified in the Slashdot conversation are symptomatic of management’s unrealistic expectations of relative skill levels among developers and their inability to assess and leverage the skills that exist within their teams.


Image by alan9187 from Pixabay

Agile Team Composition: Generalists versus Specialists

Estimating levels of effort for a set of tasks by a group of individuals well qualified to complete those tasks can efficiently and reliable be determined with a collaborative estimation process like planning poker. Such teams have a good measure of skill overlap. In the context of the problem set, each of the team members are generalist in the sense  it’s possible for any one team member to work on a variety of cross functional tasks during a sprint. Differences in preferred coding language among team members, for example, is less an issue when everyone understands advanced coding practices and the underlying architecture for the solution.

With a set of complimentary technical skills it’s is easier agree on work estimates. There are other benefits that flow from well-matched teams. A stable sprint velocity emerges much sooner. There is greater cross functional participation. And re-balancing the work load when “disruptors” occur – like vacations, illness, uncommon feature requests, etc. – is easier to coordinate.

Once the set of tasks starts to include items that fall outside the expertise of the group and the group begins to include cross functional team members, a process like planning poker becomes increasingly less reliable. The issue is the mismatch between relative scales of expertise. A content editor is likely to have very little insight into the effort required to modify a production database schema. Their estimation may be little more than a guess based on what they think it “should” be. Similarly for a coder faced with estimating the effort needed to translate 5,000 words of text from English to Latvian. Unless, of course, you have an English speaking coder on your team who speaks fluent Latvian.

These distinctions are easy to spot in project work. When knowledge and solution domains have a great deal of overlap, generalization allows for a lot of high quality collaboration. However, when an Agile team is formed to solve problems that do not have a purely technical solution, specialization rather than generalization has a greater influence on overall success. The risk is that with very little overlap specialized team expertise can result in either shallow solutions or wasteful speculation – waste that isn’t discovered until much later. Moreover, re-balancing the team becomes problematic and most often results in delays and missed commitments due to the limited ability for cross functional participation among team mates.

The challenge for teams where knowledge and solution domains have minimal overlap is to manage the specialized expertise domains in a way that is optimally useful, That is, reliable, predictable, and actionable. Success becomes increasingly dependent on how good an organization is at estimating levels of effort when the team is composed of specialists.

One approach I experimented with was to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered. The idea is that with a weighted expertise factor calibrated to the problem and solution contexts, a more reliable velocity emerges over time. In practice, was difficult to implement. Teams spent valuable time challenging what the weighted factor should be and less experienced team members felt their opinion had been, quite literally, discounted.

The approach I’ve had the most success with on teams with diverse expertise is to have story cards sized by the individual assigned to complete the work. This still happens in a collaborative refinement or planning session so that other team members can contribute information that is often outside the perspective of the work assignee. Dependencies, past experience with similar work on other projects, missing acceptance criteria, or a refinement to the story card’s minimum viable product (MVP) definition are all examples of the kind of information team members have contributed. This invariably results in an adjustment to the overall level of effort estimate on the story card. It also has made details about the story card more explicit to the team in a way that a conversation focused on story point values doesn’t seem to achieve. The conversation shifts from “What are the points?” to “What’s the work needed to complete this story card?”

I’ve also observed that by focusing ownership of the estimate on the work assignee, accountability and transparency tend to increase. Potential blockers are surfaced sooner and team members communicate issues and dependencies more freely with each other. Of course, this isn’t always the case and in a future post I’ll explore aspects of team composition and dynamics that facilitate or prevent quality collaboration.


Image by Gerd Altmann from Pixabay

Relative Team Expertise and Story Sizing

In Parkinson’s Law of Triviality and Story Sizing, I touched on the issue of relative expertise among team members during collaborative efforts to size story cards. I’d like to expand on that idea by considering several types of team compositions.

Team 1 is a tight knit band of four software developers represented in Figure 1.

Figure 1 - Team 1
Figure 1 – Team 1

Their preferred domain and depth of experience is represented by the color and area of their respective circles. While they each have their own area of expertise, there is a significant overlap in common knowledge. All four of them understand the underlying architecture, common coding practices, and fundamental coding principles. Furthermore, there is a robust amount of inter-domain expertise. When needed, the HTML5/CSS developer can probably help out with JavaScript issues, for example. The probability of this team successfully working together to size the stories in the product backlog is high.

Team 1 represents a near-ideal team composition for a typical software related project. However, the real world isn’t so generous in it’s allocation of near-ideal, let alone ideal, teams. A typical team for a software related project is more likely to resemble Team 2, as represented in Figure 2.

Figure 2 - Team 2
Figure 2 – Team 2

In Team 2, the JavaScript developer is fresh out of college,  new to the company and new to the business. His real-world experience is limited so his circle of expertise is smaller relative to his teammates. The HTML5/CSS developer has been working for the company for 10 years and knows the business like the back of her hand. So she has a much wider view of how her work impacts the company and product development. As a team, there is much less overlap and options for helping each other through a sprint is diminished.  As for collaborative story sizing efforts, the HTML5/CSS and C# developers are likely to dominate the conversation while the JavaScript developer agrees with just about anything not JavaScript related.

As Agile practices become more ubiquitous in the business world, team composition beings to resemble Team 3, as shown in Figure 3.

Figure 3 - Team 3
Figure 3 – Team 3

The mix now includes non-technical people – content developers and editors, strategists, and designers. Even assuming an equal level of experience in their respective domains, the company, and the business environment, there is very little overlap. Arriving at a consensus during a story sizing exercise now becomes a significant challenge. But again, the real world isn’t even so kind as this. We are increasingly more likely to encounter teams that resemble Team 4 as shown in Figure 4.

Figure 4 - Team 4
Figure 4 – Team 4

As before, the relative circle of expertise among team members can vary quite a bit. When a team resembles the composition of Team 4, the software developers (HTML5/CSS and C#) will have trouble understanding what the Learning Strategist is asking for while the Learning Strategist may not understand why what he wants the software developers to deliver isn’t possible.

When I’ve attempted to facilitate story sizing sessions with teams that resemble Team 4 they either become quite contentious (and therefore time consuming) or team members that don’t have the expertise to understand a particular card simply accept the opinion of the stronger voices. Neither one of these situations is desirable.

To counteract these possibilities, I’ve found it much more effective to have the card assignee determine the card size (points and time estimate) and work to have the other team members ask questions about the work described on the card such that the assignee and the team better understand the context in which the card is positioned. The team members that lack domain expertise, it turns out, are in a good position to help craft good acceptance criteria.

  • Who will consume the work product that results from the card? (dependencies)
  • What cards need to be completed before a particular card can be worked on? (dependencies)
  • Is everything known about what a particular card needs before it can be completed? (dependencies, discovery, exploration)

At the end of a brief conversation where the entire team is working to evaluate the card for anything other than level of effort (time) and complexity (points), it is not uncommon for the assignee to reconsider their sizing, break the card into multiple cards, or determine the card shouldn’t be included in the sprint backlog. In short, it ends up being a much more productive conversation if teammates aren’t haggling over point distinctions or passively accepting what more experienced teammates are advocating. The benefit to the product owner is that they now have additional information that will undoubtedly influence the product backlog prioritization.

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

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.

Layoffs

I’ve never been fired, but have been laid off three times over the course of four distinct careers. I’m also three-for-three for having landed in a much better place after having been laid off. So with three data points, maybe there is some truth to the street wisdom that a little adversity is a good thing.

“I judge you unfortunate because you have never lived through misfortune. You have passed through life without an opponent- no one can ever know what you are capable of, not even you.” – Seneca, On Providence, 4.3

I have also survived 17 layoffs. And I remember them all.

Paradoxically, many of the layoffs I survived were more painful than the layoffs in which I was included. I have clear memories of people I enjoyed working with that one day were simply gone from the place I was spending more than one third of my life. The resulting crash of morale at the workplace simply added to the sense of dread and “why bother” attitude. Their absence became a reminder that we were all living under someone else’s Sword of Damocles, that we would pay the price of poor decisions made by someone else. In some instances, the nauseatingly smug expression of schadenfreude by a few well-connected corporate parasites and toxic individuals cruising the corridors just added to the sting. It doesn’t seem this is easier to deal with by those that remain after a layoff in a distributed work environment.

To say I’ve “survived” all the layoffs that occurred throughout my multiple careers, whether I was culled or not, is more than a little melodramatic. I have truly survived much, much greater losses. Layoffs are not lethal events and living according to several key Stoic principles has helped me to persevere and gain strength from the brief storms of finding work.

“To bear trials with a calm mind robs misfortune of its strength and burden.” – Seneca, Hercules Oetaeus, 231232

Reflecting on work transition experiences, I wondered what is it about having been laid off that made the next place so much better.

I have always worked hard to add value to my employer’s business. If that value was either not appreciated or the business shifted away from needing the value I was capable and willing to provide, it was a clear sign that it’s time to move on. By making this a choice, I could leave with no hard feelings and no burned bridges. Psychologically, this is more intimidating but much healthier.

Seeing the positive side of being laid off can be a little more difficult, particularly if one has been blind to the signs that every company and manager broadcasts when a layoff is eminent and is surprised when they happen. For starters, layoffs erased all the baggage I was carrying that belonged to the employer and made it much easier to strike out in a direction that suited my interests, skills, talents, and goals. Each of the three layoffs launched new, more lucrative and rewarding careers.

“Today I escaped from the crush of circumstances, or better put, I threw them out, for the crush wasn’t from outside me but in my own assumptions.” – Marcus Aurelius, Meditations, 9.13

Switching employers, even careers, more frequently than previous generations is a good career development strategy. In the dot com era, it was the only effective way to find meaningful raises and career advancement. Why toil away for a decade under Management-by-Taylorism to scratch out incremental pay increases when a salary could be increased by 10%-20% just by switching employers? Twenty-five years on, staying with the same employer for more than five years actually looks odd to many recruiters I’ve been talking to.

A friend of mine has a personal policy to commit to an employer for 1,000 days. At that point, she decides if the workplace it meeting her goals and expectations. Doesn’t matter if it’s a shortcoming of her employer or if her goals and interests have changed – a mismatch is a mismatch so it’s time to leave. I think it’s a good policy, particularly in the Age of Information and Knowledge and distributed workforces.

A policy like this builds resilience in several ways.

1. It’s important to know what it takes to persevere with the crap work that goes with just about any job. Flitting from job to job doesn’t develop this. A 1,000 day commitment is enough to show that you made it past the “honeymoon” period every job has, have worked more than a few significant problems into solutions, and generally paid your dues and demonstrated – if only to yourself – you have the chops to do the work.
2. Deciding to leave a job and doing so multiple times throughout your life builds confidence in your abilities to create your future.
3. It adds a valuable layer to your talent stack, as Scott Adams has described it.

If it was generally known that employees had this policy, employers might expand their efforts to foster cultures that allow employees who are creative and collaborative to thrive and grow. Instead of what’s more common: Cube farms propped up by career leaches that brag about having worked at the company for 25 years when in fact all they’ve done is worked one mediocre year and repeated it 24 times.

I’m done with that. Forever.

“There are those too who suffer not from moral steadfastness but from inertia, and so lack the fickleness to live as they wish, and just live as they have begun.” – Seneca, On Tranquility of Mind


Photo by Benmar Schmidhuber on Unsplash

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

Good Intentions, Bad Results

In The Logic of Failure, Dietrich Dörner makes the following observation:

In our political environment, it would seem, we are surrounded on all sides with good intentions. But the nurturing of good intentions is an utterly undemanding mental exercise, while drafting plans to realize those worthy goals is another matter. Moreover, it is far from clear whether “good intentions plus stupidity” or “evil intentions plus intelligence” have wrought more harm in the world. People with good intentions usually have few qualms about pursuing their goals. As a result, incompetence that would otherwise have remained harmless often becomes dangerous, especially as incompetent people with good intentions rarely suffer the qualms of conscience that sometimes inhibit the doings of competent people with bad intentions. The conviction that our intentions are unquestionably good may sanctify the most questionable means. (emphasis added, Kindle location 133)

That sounds about right. To this I would add that incompetent people with good intentions rarely suffer the consequences of imposing their good intentions on others.

The distinguishing feature of a competent individual with good intentions and an incompetent individual with good intentions is the ability to predict and understand the consequences of their actions. Not just the immediate consequences, but the long term consequences as well. The really competent individuals with good intentions will also have a grasp of the systemic effects of acting on their intentions. People with a systemic view of the situation are deliberate in their actions and less likely to act or react emotionally to circumstances. Doesn’t mean they will always get it right, but when they fall short they are also more likely to learn from the experience in useful ways.


Photo by Michael Dziedzic on Unsplash

Moving Past “I Don’t Know”

In 2015 I attended the Mile High Agile conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

 

Image by Gerd Altmann 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