Expert 2.0

A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this “Linus’s Law.” (P. 41)

So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.

This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.

Imagine, around 1440, a gentleman from Verona named Luigi D’vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent “movable type.” This last guy actually existed in the form of Johannes Gutenberg.

 

Assuming D’vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg’s interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.

But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the “magic” to happen. Quality “thinking outside the box” doesn’t happen without a lot of prior preparation. You will need to know something about what’s outside the box. And note, there aren’t any limitations on what this “what” may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn’t guarantee that it will be useful. It only enhances the possibility for innovative thinking.

There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the “magic” of innovative thinking, as defined by Haskell (2001, pp. 45-46).

  • Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
  • Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
  • An understanding of the history of the transfer area(s) is vital.

To summarize, in your field of interest you must be an expert of both technique and history (lest your “innovation” turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.

References

Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.

Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O’Reilly & Associates, Inc.

 

Image by István Kis 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 Team Hero

Very good article from Margaret Heffernan, “It’s Finally Time to Retire ‘Good to Great’ From the Leadership Canon.” This quote stands out:

Collins insists that great companies get the right people on the bus and the wrong ones off. But how do you identify them proactively? Collins is thin on detail. Their values matter more than skills, but how can you tell? They’re unafraid to face brutal truths — but we all avoid unpleasant realities, so how do serious leaders foster candor? There’s evidence that what distinguishes high-achieving teams is the quality of connectedness between people rather than the individuals themselves, but such systemic thinking is absent from Good to Great, which inhabits a strictly linear universe. You either are Level 5 or somewhere lower on the ladder. The people on the bus are right or wrong. The toughest parts of leadership are, apparently, easy.

This reminds me of the the 1998 Sydney to Hobart yacht race as described by Dennis Perkins and Jillian Murphy in their book “Into the Storm.” Larry Ellison’s purchased professional crew on his yacht, “Sayonara,” put in a mighty fine performance. But the race was won by the scrappy and tight knit little crew on the “Midnight Rambler.”

If the quality of connectedness between people is a distinguishing characteristic of high-achieving teams, what does that say about the team “hero” – that individual who insists on outperforming everyone else on the team? In my experience, the team hero’s contribution to the team effort is much more likely to be disruptive than productive. I’ve observed the following qualities:

  • They manufacture crisis that only they can solve.
  • They work outside the team, pleasing others – particularly people with status – while progress on work assigned to the team suffers.
  • They hoard information and work assignments.
  • Show little interest in mentoring or helping others on the team succeed.
  • Are acutely sensitive to criticism and dismissive of feedback.
  • Display many of the attributes of a fixed mindset.

Managing a team with a hero on it usually means you spend most of your time managing the hero or scrambling to mitigate the adverse effects of their behavior. The team suffers and second order effects soon follow. I’d much rather manage a team of solid performers who understand how to work together.

 

Photo by Javier García on Unsplash

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and erodes morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the story line.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough for now” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

Photo by juan pablo rodriguez on Unsplash

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

Waste

What comes to mind when you think of the word “waste?” I’d wager a ten spot it wasn’t something pleasant. Rather, something to be pushed to the curb, rinsed down the drain, or thrown into a hole in the ground and buried. Even the sterile waste from technology projects has a high “ick” factor. If Josef Oehmen and Eric Rebentisch of MIT’s Lean Advancement Institute put the amount of time, money, and resource waste in corporate product development at 77%, how can there be anything good about waste?

Now think of something you value quite highly – a piece of fine jewelry, mastery of a sport or musical instrument, or your home. Have you considered how many resources may have been “wasted” to bring those highly valued things into existence? Shiny diamonds get that way by cutting and throwing away pieces of the original, mastering a sport or a musical instrument involves years filled with bad moves or cringe worthy sounds, and a significant amount of material was used and discarded while building your home.

When organizations consider implementing one of Agile’s many formalized methodologies or frameworks, the idea of eliminating waste is a prominent promise that helps close the sale. Cutting out waste means saving money and saving money means increasing profits. Unfortunately, this promise is frequently delivered to the agile teams as: “All waste is bad. Get it right the first time.” This message doesn’t support exploration and discovery. It doesn’t allow teams the space they need to find innovative solutions in what Stuart Kauffman called the “adjacent possible.” And it certainly doesn’t encourage the iterative development of numerous minimum viable products that build upon each other and lead the way toward the delivery of quality products.

The message I work to reinforce is: “Expect to throw stuff away, especially early on.” By itself, this isn’t enough to overcome the many negative connotations around waste. What is needed is a fundamental re-framing around the activities that have resulted in something one expects to throw away. A couple of questions are worth asking. What value is anticipated from the activity? What are the potential positive effects of having engaged in an effort at risk for ending as waste? Pursuing a goal of zero wasted effort is a fool’s errand. What we want to reduce is any effort that doesn’t add value. If 40 hours were spent exploring a technical option “only” to find out that it wasn’t a viable option in the long term, that throw-away 40 hour effort may just have saved 400 hours of developer time spent trying to make it work. And had the less-than-optimal long term option gone to market, the expense of supporting the early wrong decision could make or break the product, perhaps even the business.

Skilled agile practitioners have a strategy for monitoring the value of any project related efforts:

  • Establish definitions of activities that create value. By identifying the intent behind the effort and acknowledging the value, the team is better positioned for focusing on the goals and objectives of the activity. Discovery, exploration, risk assessment, even fun can be worthwhile justifications if it is clear they add value to the overall effort and end goal success.
  • Identify efforts that are wasteful, but nonetheless necessary, and work to minimize the effects of these efforts. Transitioning from a design sprint to actual production work often results in a lull in activity as the design team works to communicate to the production team what needs to be done. Similarly, when production work is handed off to deployment, support, and maintenance teams.
  • Identify clear signs of waste. Gold-plating (over-engineering), lack of a product vision or road map that causes the agile team to “make it up as they go along” and react to the customer’s reaction, infrequent opportunities for feedback (both inter-team and with the client), or time-tracker cards that attract dozens of hours of nondescript time.

From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I’ve included my additions and comments in parenthesis.

  • Overproduction of information
    • Two different groups creating the same deliverable
    • Delivering information too early
  • Over-processing of information
    • Over-engineering of components and systems (Often referred to as Gold-platting.)
    • Working on different IT systems, converting data back and forth (The use of one-off tools rather than leveraging the capabilities within the organization’s suite of tools.)
  • Miscommunication of information
    • Large and long meetings, excessive email distribution lists
    • Unnecessary hand-offs instead of continuous responsibility
    • (Unacknowledged project dependencies, such as the effect of re-architecting system components, on client projects.)
  • Stockpiling of information
    • Saving information due to frequent interruptions
    • Creating large information repositories due to large batch sizes
    • (Withholding opportunities to review work and solicit feedback.)
  • Generating defective information
    • Making errors in component and architecture design
    • Delivering obsolete information to down-stream tasks (Insufficient feedback opportunities, delays in communication due to competing project responsibilities.)
  • Correcting information
    • Optimization iterations (Rework)
    • Reworking deliverables due to changing targets (Design ambiguity, client decision instability)
  • Waiting of people
    • Waiting for long lead time activities to finish
    • Waiting due to unrealistic schedules
  • Unnecessary movement of people
    • Obtaining information by walking up and down the hallway
    • Traveling to meetings

Image by Peggy und Marco Lachmann-Anke from Pixabay

References

Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from https://www.edge.org/conversation/stuart_a_kauffman-the-adjacent-possible

Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from http://hdl.handle.net/1721.1/79838

Remote Teams: Non-verbal Communication

Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.

As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.

  1. I call out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. I’ve found this keeps the rest of the team focused on the conversation better as they won’t know when they’ll be called.  Everyone will have to track who has already presented to the team. In the past I would randomly call out names until everyone on the team had their chance to speak. While they didn’t know when their name would be called they could still count on me to make sure everyone had their turn. Frequently, however, I’d have to call out a name several times to get that person’s attention away from whatever it was they were “multitasking” on. Having the team call out the next person to present has helped resolve this issue.
  2. After the team member has presented and before they pass the conversation to the next team member, I coach them to pause and ask if there are any questions from the team. In addition to signaling the end of their presentation, this makes the remote stand-up a little less mechanical and puts the thought “Do I have any questions?” in the minds of the rest of the team. More specifically, I coach the team with some version of the following: “Pause after your presentation and ask the team if there are any questions, observations, suggestions, comments, or clever remarks.”

Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.

 

Photo by Ivars Krutainis on Unsplash

The Wonder of the Early Web Returns to My Intranet

Once Upon a Time on the World Wide Web, before Google arrived and established a self-fulfilling prophecy as their motto, “Don’t be Evil,” you could ask a question of the Internet and it would reflect what was known about the world’s thinking on the subject. I used to do this quite frequently. I don’t do it so much anymore because all I get back are advertisements or an algorithmic regurgitation based on partially digested bits from my search history and bottom dwelling sludge from who knows what data mining expedition.

I recall one example. Fifteen years ago or so, the phrase “shallow tasking” came to mind as a description of what’s really going on inside people’s heads when they claim to be “multi-tasking.” I wondered if it had been used. It hadn’t. It didn’t show up in any of the searches. It’s still a pretty lonely search result page, I see.

The internet now, thanks to Google, is garbage for this type of purpose. I can’t trust that what comes back is any kind of impartial reflection of what might be happening in the world. That seems to be changing in my own little world since organizing my disparate bits of knowledge and wisdom in Obsidian.

As I add more and more bits and pieces from things I read here and there and couple them with my thoughts – Zettelkasten style – I’m seeing interesting patterns emerge. I’m seeing what I’m most interested in. I’m seeing what I’m obsessing with. I’m seeing how this connects to that which connects to those which connects to these. And I have enough references now that I can search for a word or phrase and see what my little knowledge base has been collecting. I can do this for ideas I didn’t know I was collecting. And once again I have the emerging feeling of interesting curiosity that I used to get when I would query the Internet on Altavista or Yahoo or the pre-Hell-Yeah-We’re-Evil Google.

Of course, there is a significant risk of building little more than a private echo chamber. To counter this, there are a number of safeguards built in to my little microcosm. This blog is part of that system of safeguards. I expose my ideas back to the cruel crucible of the World Wide Web. What, if anything, comes back by way of feedback informs my internal knowledge-base. And it grows stronger, more robust, more valuable.

Taking Work to the Team

Every once and a while I have to work with someone who has the idea that productivity would increase if we had teams that floated from project to project. Worse, float individuals from project to project based on the particular skills they have. “It’s the professional services model,” they tell me. If you happen to work for a professional services firm, this would make good sense. Looking at the evolution of productivity since the industrial revolution reveals the professional services model as a niche approach to managing productive workflows.

A hundred and fifty years ago, if you wanted a horse drawn wagon and didn’t have the skill to build one yourself, you might go to “Smith and Sons Wagon Makers” and work out a deal. You brought the work to the team. In this case, the team is Mr. Smith and his sons. They’d take your order, put it in the queue, and when your order came up they would build your wagon from scratch.

Just over a hundred years ago, Henry Ford figured out a more efficient way to bring work to the team with the invention of the “assembly line.” This brought better quality, product consistency, lower costs, and faster delivery of the successor to the horse drawn wagon. The assembly line also brought greater specialization to the team members.

A modern day example of bringing the work to a team who’s members are extremely specialized is the Formula One pit crew. Twenty plus team members who’s sole objective is to service a race car in the shortest amount of time. The example video shows an amazing blend of team coordination and years of technical evolution to enable the pit crew to complete the task in under two seconds. It’s the end result of a century of scientific management, also known as “Taylorism.”

However, the assembly line and scientific management breaks down when working to improve the productivity of knowledge workers. It doesn’t even serve as a particularly good metaphor for knowledge work. What does “bringing work to the team” look like when searching for ways to improve software development and delivery, for example? Software developers and quality engineers don’t sit at an assembly line work station. Knowledge work, in particular software development, is also creative work. There is only one way a wheel can be attached to an axle if an automobile is going to function properly. But there can be many ways to create software that functions in a particular way. Among software developers and engineers, they may be able to tell which approach is better or more efficient or more robust. Assuming good QA, the the end user probably won’t. A mis-aligned wheel on a car is readily apparent to anyone who knows how to drive.

What is common when taking work to a team is a shared understanding of the process behind the workflow and the need for well-defined coordination among team members. Who does what when and why. The race car pit crew demonstrates this in under two seconds.

There is, in my view, a metaphor that does serve the team of knowledge workers well. That’s the jazz ensemble. Here is a team of highly specialized individuals who have come together to combine their understanding of music theory and individual creativity to produce some amazing music. But this doesn’t happen by accident and it isn’t something that can be scheduled. The musicians have to have complete trust in each other’s abilities and this takes time to establish. The “sound” each ensemble creates is dependent on who’s playing. The talent isn’t interchangeable with other ensembles. Even when it goes well, when an ensemble member is replaced there is a period of time where the trust needs to be re-established. And it’s likely that changing the member composition is going to change the ensemble’s “sound.” But it will still be jazz.

Keeping knowledge work teams together and taking work to the team allows for a number of desirable characteristics to emerge that are critical to high performing teams.

  • Clear and persistent understanding of each other’s capabilities
  • Shared understanding of the work involved
  • Trust in each other’s commitment to the goal

The speed at which a knowledge work team gels into a high performance team is significantly influenced by the tactics employed by management.

  • Be clear with the team what process they are expected to follow (e.g. Scrum, SAFe, etc.) and where in the process they have full creative discretion. A jazz ensemble has full discretion over what they play. But if you’ve hired them, they also need to know where and when they’re expected to play. That’s the deal.
  • Minimize changes to the team’s composition. Like musicians, talent between teams isn’t seamlessly interchangeable. Replacing a team member will require a period of time for trust among team members to be re-established and until it is, performance will decline. How long this takes is dependent on how disruptive the change to the team’s composition has been. Did they lose a leader or a junior member? Did they lose a highly specialized set of skills and product knowledge or something more general and common?
  • The team is best evaluated by the quality of their output, regardless of how they put it all together. Resist the urge to pull out the scientific management stop watch and magnifying glass.