More on this book
Community
Kindle Notes & Highlights
Read between
May 7 - June 4, 2023
Lencioni offers little practical advice for removing dysfunction once you find it.
If you have the appetite, you can develop the skills that allow you to embrace the painful, candid communication that creates an environment in which teams flourish. At no point will developing these skills be easy.
we are still in the process of emerging from the mass-manufacturing paradigm of the software factory.
The failure of the software factory model has created space for the rise of new, people-centric models like Agile, Lean, and DevOps. But well-meaning attempts to adopt these new models fail when the focus is on processes and methods, reinventing some of the same mistakes of the software factory on a smaller scale, creating “feature factories,” as John Cutler calls them.
Taylor’s view of the world created a very distinctive and dehumanizing workplace culture. The factory was envisioned as one giant machine. Managers were the mechanical engineers, designing how all the pieces should work and checking that they were operating correctly. Workers were merely replaceable parts: they operated within specified tolerances, or they were defective and to be discarded. Communication was top-down and limited to commands and corrections. Conversations were not required. Collaboration was not required. Thought was not required beyond doing the job you had been told to do.
The software industry we joined in the nineties had transplanted Taylor from the factory into the cubicle.
Dr. Alistair Cockburn, a keen and eloquent observer of software practices in the wild, captured the insight in his paper “Characterizing People as Non-Linear, First-Order Components in Software Development.”
The idea that people are the central concern of software methods sparked an extended transformation that has reshaped the building of software since the turn of the century. Lean manufacturing disrupted and transformed the previously dominant Taylorist mass-manufacturing paradigm, scoring tremendous gains in productivity and quality by changing the culture of the factory. Rather than viewing workers as replaceable parts, Lean manufacturing relies on “both an extremely skilled and a highly motivated workforce,” one that anticipates problems and devises solutions.
during the explosion of Agile development, and then of Lean software and DevOps, later adopters missed the importance of human interaction. Leaders thought they could behave the same as they always had—could keep their factory mind-set—and that dictating change to others would be enough. As a result, they focused on the easily monitored, more superficial process changes: standups, work-in-progress limits, tool selection. Without the human element and without the right conversations, these changes were singularly ineffective. As a result, across hundreds of organizations between us, we’ve
...more
Why, then, do we now see, over and over again, “feature factories” operating in the same spirit as those software factories of the nineties while claiming to be Agile? In fact, only the visible artifacts and processes have changed; the mind-set and the conversations, and therefore the culture, are the same. Instead of mounds of documentation and two-year project plans, these teams are fed a steady stream of features to implement without any connection to the upstream customer needs or the downstream business impact. The software assembly line has been replaced by a sweatshop, with piecework
...more
The problem is that, as with Agile development, too many organizations adopt the practices without the underlying spirit.
Bewilderingly, among some enterprises, there is a recent trend of anointing a special team that is separate from development and operations: the “DevOps” team. The whole point of DevOps is to create unity and collaboration among different specialties, not more silos. We even see job ads for “DevOps engineers,” who apparently are a special breed different from normal engineers and system admins. What happened? We believe this is the result of a buzzword-bingo approach to management.
Rather than cultivating “individuals and interactions,” we have organizations hoping to avoid rethinking how to operate and instead get by with a reconfiguration of the software factory. And the surprising thing is that many have achieved that dubious goal.
we’ve met many small organizations and startups where the practices from Lean, Agile, and DevOps are on display, yet the designers and developers and operations people describe themselves as working in a “feature factory,” with all the same micromanagement and autonomy-destroying practices as before. It’s as if the giant software factory has been reassembled using smaller pieces with different names.
Organizations have embraced the process and tools created by the Agile transformation, yet the Taylorist factory mind-set remains. There’s a lot less documentation to write, fewer specifications to read, and hardly any mandated signoffs, but these practices have merely been replaced with endless planning meetings and many pages of tickets in a project management tool—practices that still offer the Taylorist promise of giving management the insight and control they demand, because the role of managers is still to ensure that the right things get done.
The feature factory wants to put humans in the lower-right, “obvious” quadrant: “If we have everyone in the planning meeting and the standup and the retrospectives, then they will collaborate.” This cargo-cult approach to collaboration doesn’t work with humans, whose nature is squarely in the upper-left, “complex” quadrant.
Along with our amazing powers of conversation, we also come equipped with pre-existing, built-in flaws—our so-called cognitive biases
Our cognitive biases pose a threat to any adoption of Agile, Lean, or DevOps methods because they can seriously damage collaboration, relationships, and team productivity.
In theory, we value diverse teams because we understand that diversity can be a strength. A diversity of experiences, a diversity of knowledge, and even a diversity of modes of thought—in theory, these all make a team stronger, because every new element gives the team more information and more ideas, and therefore, more options to make better choices. What we should be seeking from our diversity is productive conflict, through which we harness our differences to create new ideas and better options. In practice, we tend to see differences of opinion as threatening and potentially embarrassing,
...more
Building trust is the most fundamental step in helping your team escape the Taylorist feature factory and build a high-performing culture.
unlock your curiosity by using “TDD for People” to discover differences in reasoning and to align your story with that of others.
still they fight over the future as if they can control it.
They can cite the Agile Manifesto and the Scrum Principles to give weight to their proposals. In fact, there’s nothing wrong with any of these solutions except for one thing: every single one is guaranteed to fail.
Certifications look nice on the wall, a shorter sprint will result in more frequent releases, and a longer retrospective will produce more actions, but none of these changes will make a dent in the outcomes that matter.
fear paralyzes the team, inhibiting creativity and cooperation. A compliant, fearful team fits well into a Taylorist factory, where no thinking is required;
We often see teams trying to make decisions—about process, or estimation, or tooling, or budget, or even who sits where—in a centralized, nonconsultative way. Leaders pursuing efficiency and correctness make fundamental decisions and then communicate them to the team, expecting enthusiastic adoption of the new plan. All too often, as with the cake-mix customers, the reaction is decidedly less positive, with reluctant compliance at best or flat refusal at worst.
Instead, for decisions big and small, use the process of Joint Design, with each member of the team “adding their own egg.” Here is the process: •Include as many people as possible. •Ask genuine questions (see Chapter 2). •Invite opposing views. •Timebox the discussion. •Establish and communicate who will make the final decision (known as a decision-making rule11).
Management is indeed much simpler if we believe that people doing what they’re told is enough. It is easier to staff projects if we consider developers to be interchangeable resources, one of whom can be instantly and painlessly substituted for another. It is even easier if we believe a single engineer can divide her time efficiently among two, three, or even more projects! These beliefs about substitutability and frictionless task-switching fit the Taylorist, person-as-machine model. However, humans aren’t like that, and admitting as much might undercut the basis of the management culture,
...more
Like many managers, Anna was finding that when you tell your staff what to do, they do it—and that was the opposite of the creative, innovative team that their Agile practices could support. Instead, her goal was for her management team to be self-organizing and autonomous, so that “each of them [would] be a good candidate to take over [her] job.”10 And that couldn’t happen while she was stuck in the role of chief task distributor.
Within the feature factory, it would be unimaginable to be completely transparent about delivery and its challenges—why bother, when we’re stifled by rigid dicta at every turn? And the same lack of autonomy makes it pointless to be curious about options for varying goals and tactics, since no variation would be achievable anyway.
Theory Y is a fundamentally different view of humanity. It says that people want to be engaged, that they want to take ownership, and that they carry the drive for success within themselves. If we believe Theory Y, then the Theory X model of management is not just harmful, it’s wasteful. We get better results more cheaply by using the drive for success inherent in each individual. And in a Theory Y organization,
explaining motivation rather than imposing a vision, and providing context to drive commitment. In fact, we agree with Niels Pflaeging that adoption of Theory Y is a precondition for success with Agile, Lean, or DevOps methods.
So what puzzles us is why Theory X is still so pervasive in teams that are, at least in theory, adopting people-centric software methods.
What can you do to overcome this bias toward Theory X? As with most changes like this, we recommend that you enlist sympathetic team members to help you identify and overcome Theory X beliefs and habits in your organization.
In response to such authoritarian micromanagement, “commitment is replaced by compliance, energy is sapped, and morale declines.”
Being accountable means signaling our intent with others who will be impacted even when we think we are right.
