The Radical Management Book Club Part 4: Dynamic Linking
I’ve been participating in a multi-week series of online discussions, hosted by IBM, entitled the Radical Management Book Club. These were my opening remarks for the fourth week’s discussions on February 18, 2014, about the way work is coordinated, aka Agile and Scrum and Kanban and Lean, or as I have called all these practices, "dynamic linking".
February 18 2014: Agile – Dynamic Linking
Chapters 6 and 7 of The Leader’s Guide To Radical Management (2010)
As we discussed last week, teams are not a new idea. Throughout the 20th Century, thought leaders recommended teams, starting with the lectures that Mary Parker Follett was giving at Oxford and Harvard in the 1920s, and on through Douglas McGregor and Smith and Katzebach with The Wisdom of Teams and Richard Hackman and so on.
Nevertheless, teams never really entered the mainstream of management in the sense being the default way of getting things done. The default method remained hierarchical bureaucracy and managers controlling individuals. Teams were a kind of stop-gap measure that you used when you couldn’t solve a problem by normal command and control. But when the problem was solved, you went back to normal management.
Managers knew that teams were more innovative than bureaucracy but they didn’t keep them around for one simple good reason. Teams were chaotic. Managers didn’t know how to solve the central problem of combining innovation with disciplined execution. Teams were good at innovation. But they weren’t disciplined. They would do well for a while and then they would start going off on tangents.
So what happened? Management would launch teams when they needed innovation but scrap them when they needed more efficiency and predictability. So over time, you could see organizations oscillating between teams and bureaucracy, backwards and forwards, over and over again.
It was therefore a huge discovery when it was finally figured out how to coordinate work so as to get continuous innovation with disciplined execution. It was the inventors of Agile and Scrum and Lean that eventually made the discovery: Jeff Sutherland, Ken Schwaber, Mike Cohn and their colleagues.
They actually solved the problem that finest thinkers and practitioners of 20th Century management hadn’t been able to solve.
In essence their discovery involved working in short cycles and having clear goals for each iteration and getting continuous feedback from customers or their proxies at the end of each short iteration. Now you could get continuous innovation and disciplined execution. Brilliant!
I believe that if there was a Nobel Prize for management, which there isn’t, and if there was any justice in the world, which there isn’t, these guys would win that Nobel Prize.
They basically solved the problem. There was just one snag. These were the wrong people to have solved it. If this discovery had been made by a group of distinguished Professors at Harvard Business School or the CEO of a Fortune 100 company, then I believe the discovery would have been widely accepted and implemented throughout the business world.
Instead, the discovery was made by software engineers. These were people who managers looked down on as the worst managers in the whole organization. This was a sector that had been immune to command and control. Whippings and beatings and executions had had no effect. Their performance still sucked. In fact, the more you disciplined them, the worse their performance got. Worst of all, these people were disrespectful of management. The software engineers said the problem was management.
So when the software engineers announced that they had made a discovery in management, the managers saw this as the last straw. They knew it couldn’t be true. Just another stupid idea coming out of those losers in software engineering. When will they grow up?
The idea had come from the wrong people. Now this phenomenon of an idea coming from the wrong people has happened in other fields.
In the 18th Century, the problem of measuring longitude was crucial for navigating ships, and no one could solve it. In the end, it was solved, not by the distinguished scientists of the Royal Society, but by a carpenter from Yorkshire. But he was the wrong person to have solved the problem and it took more than a decade for his solution to be recognized, and even then, he never got the huge financial prize that had been promised.
In the 19th Century, the basic theory of genetics was figured out by a pea farmer in Moravia called Gregor Mendel. Now a pea farmer in Moravia was the wrong person to have solved a problem that had stumped the best scientific minds for generations. It took 35 years before Mendel’s discovery was accepted.
In the 20th Century, an Australian doctor from Perth started claiming that stomach ulcers were not caused by stomach acid as all the experts knew, but instead by the presence of a certain kind of bacteria. Moreover to prove it, this crazy Australian even drank a glass full of the bacteria. Sure enough he got stomach ulcers. So that was pretty conclusive, but a crazy Australian from Perth who went around drinking glasses filled with bacteria was the wrong person to have made a brilliant scientific discovery and it took 21 years before he was recognized and won the Nobel Prize for medicine in 2005.
I think that’s what’s happening her with Scrum and Agile and Lean. This is a set of fundamental management discoveries but they have come from the wrong people—software engineers. So the discoveries are having a hard time winning acceptance from general managers. As I said, there has never been a single article on it in Harvard Business Review about it.
Of course, with around half a million software developers in the Agile movement, managers increasingly find themselves on the spot to explain why they are not implementing one kind of Agile. I have written about the ten perennial objections that they tend give.
#1. “Agile is only for stars”
“Agile was designed for experienced, smart, and high-achieving people i.e. stars. You could give these high performers any project, with any method, and they would succeed. We have to work with the staff we have. They need close supervision. So Agile is not for us.”
In other words, they are saying, make do with mediocrity. Agile makes the opposite assumption: let’s assume competence. It expects competent performance and forces action if it doesn’t occur.
#2. “Agile doesn’t fit our organizational culture”
Excellent point! We have spotted the problem. Let’s change the culture.
#3. “Agile only works for small projects and our projects are big”
It’s true that Agile requires small teams. A big effective team is an oxymoron.
But you scale Agile by using the same practices as within teams, with Scrum of Scrum and the like. An ex IBMer, Alan Brown wrote about it in his book Enterprise Software Delivery
. And I have mentioned Bob Sutton’s new book saying the same thing, Scaling Excellence
#4. “Agile requires co-location and our staff are geographically dispersed”
Not true. Co-location is better, but it can also work with dispersed teams.
#5. “Agile lacks project management processes”
True but irrelevant. Agile doesn’t solve all management issues. Agile solves a specific
management issue, namely, how to combine disciplined execution with creativity and innovation.
And here’s another good one:
#6. “Our firm’s HR systems don’t fit Agile”
True! Change the HR systems.
#7. “Agile is just a fad”
Not true. With around half a million software developers world wide and growing rapidly, this is a lot more than a fad.
Here’s a really fake one:
#8. “There are better ideas than Agile”
In other words, Agile is so last-Tuesday. Well, it’s true that Agile keeps evolving and I have suggested some of those evolutions. But the basic discoveries are the foundation for the subsequent evolutions.
Here’s a really lame one.
#9. “Agile isn’t new.”
True. All of the individual components of Agile have been around for quite a long time. What is new is to put those elements together in a coherent and integrated fashion.
#10. “The idea that software developers could teach us about management is absurd.”
I agree. It’s absurd. But as Albert Einstein once said, If at first an idea is not absurd, there is no hope for it. Agile is an absurd idea that happens to be true. There are others. The sun doesn’t revolve around the sun: absurd. Light doesn’t travel in straight lines: absurd. It’s the truly absurd ideas that can revolutionize the world.
As I note in my book: “All this is silliness, of course, but it is the silliness of highly intelligent and articulate people.”
The biggest problem for traditional managers is one that they are not even willing to mention. Agile thrives on transparency. That is the real show stopper. One of the dirty not-so-little secrets of traditional management is that traditional management and control thrive on non-transparency.
So introducing radical management and introducing the practices of Agile, Scrum, Kanban and Lean means exposing all of the non-transparent tricks that hierarchical managers play on their subordinates to maintain power. Is it really any wonder that Agile isn’t popular with the command-and-control gang?
Part 2: practices
Let’s run through some of the practices in chapters 6 and 7. There are really too many of them to cover today even in summary, let alone in detail. That’s why there are courses lasting several days. What I will give you, like David Letterman, is a list of my top ten practices
in terms of Agile, or radical management, practices for coordinating work.
In the end, what’s more important than the individual practices is the mindset. This is not about doing Agile
or doing the practices
of radical management.
It’s about being Agile
. It’s a different way of thinking, speaking and acting in the workplace.
It’s not just doing the practices, it’s about living the practices
, as though they are second nature.
It’s a different lens
for viewing the world.
It’s a different compass
for guiding you through the world.
#1: Focus on Stakeholders and What Is of Value for Them
The first step in developing client-driven iterations is to shift attention from the thing
to the person
and identify the primary stakeholders. Rather than focusing on what is being produced, the focus is on whom it is for.
#2: Deliver More Value Sooner or Cheaper or More Convenient or More Personalized
Once you have the real goal, you can ask: How can we evolve toward that goal sooner? How can we delight the client with partial steps or other means? How can we give the client a taste of what it would be like so he or she can give us feedback? Is it meeting the client’s needs? How it could be improved?
#3: Decide as Late as Responsibly Possible What Work Is to Be Included in the Iteration
By making decisions at the last responsible moment, the team has the best information to make informed decisions. It avoids wasting resources by making unnecessary inventory or early decisions that will have to be undone. This gives the greatest chance to avoid working on something that isn’t needed, as well to include the best possible ideas at the top of the list of priorities to be worked on.
#4: Test Before You Make Any Change
This is something coming from Lean Startups and Eric Ries, where he has the great principle: most changes make things worse for the user.
#5: Spell Out The Goals of Each Iteration Before It Starts
Sounds obvious. But if you look at what happens in big organizations, work starts before people have decided exactly what they are trying to accomplish. Unless we know where we are going, it is hardly likely that we will get there.
#6: Define the Goals of the Iteration in the Form of User Stories
This is one I really like. In the world of traditional management the goal is producing goods or services. Build things. Provide services. How much? How big? How long? How wide? What color? Requirements, sometimes extending over hundreds of pages, often include low-priority things that might be needed.
When work is done in this way, clients are rarely delighted, and workers often see little meaning in their work. That’s because when the requirements are spelled out in terms of abstractions, the reasons for them are typically hidden. Why this much? Why this big? Why this long? Why this wide? Our ability to understand the meaning of our work is limited and our ability to innovate eliminated.
It’s hard to argue with an abstraction. The job is simply to deliver a product or service in accordance with the specifications, come what may. “Just do it” is the implication. “Don’t ask questions.” The possibility that there might be a better way of delighting clients is systematically removed.
Once the goal of work shifts to delighting clients, the definition of work moves from an abstraction to a client experience. The questions become: How do we get inside the mind of the clients and understand what their current experience is like? How could that experience be different as a result of what we can accomplish during the iteration? How can we understand what these clients will be experiencing that will cause delight? Capturing the experience will normally be in the form of a story.
#7 Treat The User Story As The Beginning, Not the End, of a Conversation
When a user story is dropped into a traditional management setting, the likelihood is either that it will be instantly rejected (because it is a story) or that it will become an artifact, an instruction, a new abstract plan to be imposed on the team. Open-minded conversations have the opposite effect: the opportunity for everyone to participate elicits new insights and inspiration to contribute to the complex goal of delighting the client. User stories are a way of shifting the focus from writing abstract requirements to one of discussing what might delight the client.
#8: Find Out More About the Client’s World
Crafting user stories requires knowledge of the context of the client. Becoming de facto ethnographers who visit and live with clients is part of the process of understanding their situation. Go and live in the customer’s world. I am talking with one company right now and they never talk to customers or go and live in their world and see how they are using their products. I ask them why. They say: it’s obvious. Well, it’s not obvious. Usability expert Jeff Patton talked to me about his experience designing software that would be used by people receiving groceries at the loading dock of a grocery store. They went and schlepped groceries for a day and at the end of the day, they had a much better idea of the what those schleppers needed in the way of software.
#9: Don’t Start A Task Until It Is Ready
Sounds obvious. But again, amazing how much work gets started without having the necessary elements in hand to complete it.
#10: Don’t Interrupt the Team in the Course of an Iteration
Interruptions kill productivity. They kill motivation. They kill performance and so they end up killing customer delight. Once having decided what’s really most important to be done, management needs to step out of the way and let the team get on with the work for the duration of the iteration. When traditional managers begin to implement radical management, this is typically one of the points of difficulty. Sounds obvious but it’s not.
There are more. But those are my favorites.