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

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.

Parkinson’s Law of Perfection

C. Northcote Parkinson is best known for, not surprisingly, Parkinson’s Law:

Work expands so as to fill the time available for its completion.

But there are many more gems in “Parkinson’s Law and Other Studies in Administration.” The value of re-reading classics is that what was missed on a prior read becomes apparent given the accumulation of a little more experience and the current context. On a re-read this past week, I discovered this:

It is now  known  that  a  perfection  of  planned  layout  is  achieved  only  by institutions  on  the   point  of  collapse.  This   apparently  paradoxical conclusion is based upon a wealth of archaeological and historical research, with the  more esoteric details of  which we need not concern  ourselves. In general  principle, however, the method pursued has been to  select and date the buildings  which  appear to have been perfectly  designed for  their purpose. A study and comparison of these has tended to prove that perfection of planning is a symptom of decay. During a  period of exciting discovery or progress there is  no time  to  plan the perfect headquarters.  The time for that comes  later, when all the important work has been done. Perfection, we know, is finality; and finality is death.

Several years back my focus for the better part of a year was on mapping out software design processes for a group of largely non-technical instructional designers. If managing software developers is akin to herding cats, finding a way to shepherd non-technical creative types such as instructional designers (particularly old school designers) can be likened to herding a flock of canaries – all over the place in three dimensions.

What made this effort successful was framing the design process as a set of guidelines that were easy to track and monitor. The design standards and common practices, for example, consisted of five bullet points. Building just enough fence to keep everyone in the same area while limiting free range behaviors to specific places was important. These were far from perfect, but they allowed for the dynamic vitality suggested by Parkinson. If the design standards and common practices document ever grew past something that could fit on one page, it would suggest the company was moving toward over specialization and providing services to a narrow slice of the potential client pie. In the rapidly changing world of adult education, this level of perfection would most certainly suggest decay and risk collapse as client needs change.

Image by EWAR from Pixabay

Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

Image by M. Maggs from Pixabay