How to know when Agile is working

On a flight into Houston several years ago, my plane was diverted to Austin due to weather. Before we could land at Austin, we were re-diverted back to Houston. I’ve no idea why the gears aligned this way, but this meant we were out-of-sequence with the baggage handling system and our connecting flight. Our luggage didn’t arrive at the claim carousel for an hour and a half after landing. Leading up to the luggage arrival was an unfortunate display from an increasingly agitated young couple. They were loudly communicating their frustration to an airport employee with unknown authority. Their frustration was understandable in light of the fact that flights were undoubtedly going to be missed.

At one point, the woman exclaimed, “This isn’t how this is supposed to work!”

I matched this with a similar comment from one of the developers on one of my project teams. Stressed with the workload he had committed to, he declared there are too many meetings and therefore “the agile process is not working!” When explored, it turned out some version of this sentiment was common among the software development staff.

At the airport and on my development teams the process was working. It just wasn’t working as desired or expected based on past experience. In both cases, present events were immune to expectations. The fact that our luggage almost always shows up on time and that agile frequently goes smoothly belies how susceptible the two processes actually are to unknown variables that can disrupt the usual flow of events.

There is a difference with agile, however. When practiced well, it adapts to the vagaries of human experience. We expect the unexpected, even if we don’t know what form that may take.

There is an assumption being made by the developers in that “working agile” makes work easy and stress free all the time. That was never the promise. Agile stresses teams differently than waterfall. I’ve experienced high stress developing code under both agile and waterfall. With agile, however, teams have a better shot at deciding for themselves the stress they want to take on. But there will be stress. Unstressed coders deliver code of questionable value and quality, if they deliver at all.

The more accurate assessment to make here is that the developers aren’t practicing Agile as well as they could. That’s fundamentally different from “agile isn’t working.” In particular, the developers didn’t understand what they had committed to. Every single sprint planning session I’ve run (and the way I coach them to be run) begins with challenging the team members to think about things that may impact the work they will commit to in the next sprint – vacations, family obligations, doctor visits, other projects, stubbed toes, alien abductions – anything that may limit the effort they can commit to. What occurred with the developers was a failure to take responsibility for their actions and decisions, a measure of dishonesty (albeit unintended) to themselves and their team mates by saying “yes” to work and later wishing “no.”

Underlying this insight into developer workload may be something much more unsettling. If anyone on your team has committed to more than they can complete and has done so for a number of sprints, your project may be at risk. The safe assumption would be that the project has a hidden fragility that will surprise you when it breaks. Project time lines, deliverables, and quality will suffer not solely because there are too many meetings, but because the team does not have a good understanding of what they need to complete and what they can commit to. What is the potential impact on other projects (internal and client) knowing that one or more of the team members is over committing? What delays, quality issues, or major pivots are looming out there ready to cause significant disruptions?

The resolution to this issue requires time and the following actions:

  • Coaching for creating and refining story cards
  • Coaching for understanding how to estimate work efforts
  • Develop skills in the development staff for recognizing card dependencies
  • Develop skills for time management
  • Find ways to modify the work environment such that it is easier for developers to focus on work for extended periods of time
  • Evaluate the meeting load to determine if there are extraneous meetings
  • Based on metrics, specifically limit each developer’s work commitment for several sprints such that it falls within their ability to complete

Photo by Jason Hafso on Unsplash

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

There Will Never Be an Agile 2.0…

…for the simple reason there was never an “Agile 1.0.”

Claiming to have crafted “Agile 2.0” would be like publishing the “Declaration of Independence 2.0” or “The Laws of Thermodynamics 2.0.” The Agile Manifesto is foundational. It is a statement of first principles that underpin a mindset from which a mountain of tools, techniques, frameworks, and practices have been created.

As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.Harrington Emerson

As a tool, its utility comes from providing a stable base from which we can clarify complicated problems. Much of the 2.0 stuff I’ve read adds complexity and complication to a simple set of values and principles. In this regard it reflects research that shows people are more likely to add to solutions rather than subtract.

It’s this notion of a stable base that flummoxes people seeking to assign versions to Agile. First principles are often unassuming, their beauty and brilliance is masked by their seemingly simple codification of how things best work. Neither are first principles about absolute truths. First principles can have first principles. The first principles by which I use a wood plane are different from the first principles used by the tool manufacturer when milling the steel for the blade. My first principles of use inherit and extend the manufacture’s first principles of milling steel.

The Agile Manifesto identified elements in software development that are non-reducible. To be clear, there are other first principle elements not included in the Agile Manifesto and the Agile Manifesto doesn’t apply to every conceivable context. Twenty years of experience of applying it’s four values and twelve principles to other areas of business have revealed this to be true. They are not, nor will they ever be, an absolute truth. As our understanding of why they work so well improves, so will the underlying principles. Frankly, I’m impressed they have held up this well this far into the Internet Age. And I certainly don’t expect them to withstand every challenge or be as durable as the Declaration of Independence of the Laws of Thermodynamics.

So when I read someone’s declaration of “Agile 2.0,” the first thing I want to know is if their proposal precedes the first principles established by the Agile Manifesto or are they trying to do something else. So far, it’s always been the something else. There may be some interesting thoughts related to an alternate framework or perhaps a change to common practices, but I’ve yet to see anything revolutionary or even evolutionary.

A second thing I look for: Is the author working to falsify any of the principles and have they done a good job of presenting their argument. Again, this hasn’t happened. Mostly I read a lot of complaints about wording or ambiguity or history or stuff that is little more than efforts to tag the foundation with a personal style of graffiti.

I’ve yet to see Agile’s next evolutionary phase. I hope someday I will.

Image by 은주 송 from Pixabay

Cargo Cults in Management


I first read about cargo cults in Richard Feynman’s book, “Surely You’re Joking, Mr. Feynman.”

I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land. (p. 310-311)

I was a newly minted biochemist and Feynman’s unique perspective had a significant impact on my critical thinking skills. It established a “cargo cult” sensor in my brain. As my career developed and branched out into other areas of interest, the ubiquity of cargo cult thinking became apparent.

In the work place, “cargo cult” thinking may not necessarily be a bad thing. As a tool, it can be used as an “as if” frame for working out the solution to complex problems or gaining insight into black boxes. By assembling all the known and visible elements and arranging them to match the form as best as possible its easier to see what’s missing.

If an executive’s minions are behaving in a way that reflects his or her approach to management, is that a good thing? Here is where business leaders get into trouble. Are the executive’s minions imitating or implementing?

Less common, executives attempt to adopt practices that are successful at the knowledge worker level. About a decade ago I had worked to implement an Agile software development process with a small and highly capable development team. It was a daunting task: completely re-architect and develop a poorly coded application while supporting the old application. (In 30 years, this was the first and only time I recommended a complete redesign and rewrite of a major application.) Of course, we started each morning with a “daily scrum” meeting – sometimes called a “daily stand-up” – before the team set off to immerse themselves in code. These are very quick (15 minutes or less) meetings where everyone literally stands up for the duration of the meeting. The idea is that by standing, attendees are less likely to drone on about trivial matters or issues that do not require the entire team’s input. Complicated issues are quickly identified and scheduled for more detailed meetings, if necessary.

Six months into the project it was very clear our approach was working and insofar as the coding effort was concerned, we would be successful. The senior executive to this effort seemed impressed and decided to switch to a “stand-up” meeting format for the executive team meetings. They were “stand-up” meetings in name only. Rather than a once a week meeting that virtually always extended way beyond the originally scheduled 60 minutes, I now had to attend daily meetings that went on for 45-60 minutes during which nobody stood.

There were other issues with implementing the executive team scrum meetings. The senior executive did a poor job of modeling the behavior he sought and there was very little control over the clock. Developers are smart people and they notice things like this even though they are not directly participating. Among those being managed, it does little to inspire confidence in the management staff.

Nonetheless, I like the idea of applying Agile methodologies to management meetings. After action reports, as used by the military, would also help. There is also a place for storyboards and retrospectives. But implementing these and other elements would require a significant learning effort on the part of the management team. Not because the methods are difficult to understand, but because the MBA mindset of many management teams would have to loosen up a bit for the requisite unlearning to become possible.

Rethinking the idea of “management” in the context of Agile principles and practices blends quite nicely with many of the things I’ve learned around the idea of “Management as a Service.”


Feynman, R. P. (1985). “Surely you’re joking, Mr. Feynman!”: Adventures of a curious character. New York, NY: Bantam Books.

Image by Free-Photos from Pixabay

Frameworks, theoretically speaking…

Figure 1
Figure 1

Theoretical frameworks are defined more by what they do than what they are. To understand this, consider a physical framework for a house (Figure 1.) Its purpose and function is, quite literally, easy to grasp. It solves problems in the physical world and it’s easy to understand how such a framework can add value to our lives. It’s also easy to assess the limitations of a physical framework. The house framework reveals the underlying structural of beams, joists, rafters, and such. With this structure, it is easy to imagine this as an ideal solution to protecting a family from the weather. It is equally obvious that this same framework would be wholly inadequate as a sports stadium. The structure in Figure 1 adds value to the eventual solution for protecting a family from the weather, but as a solution for hosting a large sporting event it leaves much to be desired.

Staying with the physical framework for a moment, several useful rules become apparent.

  • The problem defines what framework should be used. Frameworks ideally suited to solving one problem may result in disaster if applied to a different problem. A corollary could easily be that there is no single framework that can solve all physical structure problems. Rather, frameworks can be composed of a wide variety of materials and can come in all manner of shapes and sizes.
  • The choice of physical frameworks defines the tools, techniques, and materials to be used during construction of the overall solution.
  • Frameworks necessarily limit focus. By focusing the crew in this way the contractor can better controls quality, cost, and scope.

Similar to how a structural frame (or framework) to a house provides underlying support in the physical world, a theoretical framework provides an underlying conceptual structure in the world of ideas. Scrum and SAFe are examples of theoretical frameworks. The rules for physical frameworks apply equally well to theoretical frameworks. However, when the conversation shifts to theoretical frameworks, people often struggle with how to apply these rules. Being less tangible, it is easier to inadvertently select a theoretical framework that results in a sub-optimal solution for a particular problem. Without a clear understanding of the problem and the capabilities of a selected theoretical framework, a manager may inadvertently select a set of tools, techniques, and practices that are unsuited to the task. The framework won’t support the desired solution.

Just as with a building designer, the challenge for the leader tasked with implementing Agile is that he or she must first have a clear understanding of the problems they are trying to solve. They must also have a solid understanding of the possible Agile frameworks from which the optimal choice can be made.

As with physical frameworks, theoretical frameworks define the tools and techniques employed during the actual work effort. When the theoretical framework is appropriately matched to the business problem, leadership can more easily identify and define variables and constants, design define meaningful metrics, and make more effective decisions for reaching desired outcomes.

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.


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

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


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


Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from

Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from

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.