Multipliers extract all the capability from people… We were amazed to find that Multipliers got 1.97 times more. That represents an almost twofold increase - a 2x effect… Multipliers get at least two times more from people.
Liz Wiseman, “Multipliers”
Lately, I’ve been reading Liz Wiseman’s excellent book Multipliers. This has me reflecting on the great people I work with at work. Specifically, I’m thinking about the unique strengths and passions each developer brings to a team and how I can challenge each one to be most effective in their job. In Liz’s words, I want to be a Multiplier. I want to make other people better.
One common thread (of many) that I’m noticing in the book is that Multipliers seek to understand the unique strengths and genius that each person has. Each person is a “native genius” at something. It is our job to find what that is and to put them in a position to apply and grow those unique strengths.
Some minds excel at quantitative analysis or verbal reasoning… Other minds offer creative genius, innovating through fresh thinking and bold ideas. Some minds are critical, spotting every problem or landmine lurking within a plan; the genius of some others is to find a way to tunnel around these landmines.
Liz Wiseman, “Multipliers”
At the same time, I’ve been forcing myself to look at our agile development processes with fresh eyes through a critical lens. I’ve been thinking about the original intentions of the Agile Software movement and the implementation of Scrum that many teams are using these days. I’m questioning processes that I’ve simply thought of as givens before.
I’ve grown concerned that many implementations of Scrum are processes that are actually Accidental Diminishers (e.g. people or processes that mean the best but whose behavior actually stifles the genius inherent in others). How? Devs are sadly often treated as interchangeable cogs in a wheel.
We have a shared backlog, shared ownership of an entire project, knowledge sharing, pair programming, etc. We drive ourselves to prevent the dreaded “hit by a bus” scenario. We also strive for minimizing risk and providing predictability to the execution of the project.
We setup a backlog like a line of dominoes. We suck in the top items from the backlog when planning the next sprint, no matter what developers are available or not. We have developers simply grab the next item off the top of the backlog when they finish up their previous task and no open stories remain in the sprint. Anybody should be able to pick up any part of the project if somebody else is sick or on vacation. Though we don’t realize it, we are effectively treating developers as interchangeable parts.
If software development were as simple as a zero-sum game balancing resources (e.g. people) with tasks to be done, that would be fine. But the world doesn’t work this way. And it certainly doesn’t encourage people to grow their own unique strengths and to discover the best way they can make the team or company better.
People are individuals
Different people have different strengths. Different people have different passions and interests. We should strive to bring out the best in people and finding the problems they are uniquely positioned to solve. Devs shouldn’t be forced into a cookie cutter mold where we consider them all of equal strengths, equal knowledge, equal skills.
One person may have a strong passion around Data Science and be uniquely creative in thinking of ways the business could use the data we have access to. It is a disservice to that person to have them do infrastructure automation simply because it’s the next item on the team’s backlog. How will that improve the person’s career or encourage them to use all the intelligence they are capable of using?
Another person might really love DevOps, automating everything about a system, and monitoring it while it’s running in production; bringing structure and repeatability to chaos. Should we really put that person to work on researching a detailed bug about a subtlety arising from unicode text inclusion in an image generation process simply because it’s the next task on the team’s backlog? How does that encourage the person to be their best self at work?
By having the team adhere to the whims of the Almighty Backlog, I’m concerned we are not doing people a favor. It’s fine to have a common goal or product that we are aiming to ship. That’s healthy. But team members should have shared ownership of the backlog. Team members should feel comfortable tackling tasks that fit into their strengths rather than constantly “taking one for the team.” That’s not a way to be passionate about the work you do.
The Real World is not clean and organized, it’s dirty and filled with complexities. To get the most out of people, we need to constantly think about what their strengths are and how we can encourage them to be doing their best work and stretching their capabilities. How can we best bring a person’s intelligence to bear on a problem? I think that sometimes that may mean finding “lower priority” tasks in the backlog that people are uniquely positioned to knock out of the park. If we don’t do this, I think we are not doing what’s best for our team or the company.
The Agile Manifesto
But is the desire to get the best from people actually in contradiction to the true intentions of Agile?
The Agile Manifesto highlights four key areas of value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I don’t see anything that would contradict the Agile Manifesto. In fact, key area #1 seems to emphasize that we should not be a slave to the process. We should be focusing on our individuals and interactions more than the processes and tools we use to help the team.
I think that pulling in different tasks from the backlog for different people dependant on their strengths actually empowers teams to better develop and deliver working software. By leveraging these unique strengths and getting more out of each person on the team, the team is going to be more productive and allow us to respond to change even quicker than we could otherwise do.
Sadly, this is not how I’ve seen Scrum or other Agile processes used in many companies. Very little thought ends up being given to the individual. Backlogs become a strictly defined list of “marching orders.” Developers are told to simply grab the next item off the backlog when they finish up a task. It’s not uncommon to see a manager and product owner figure out how a story should be done and then break it down into tasks in the backlog. Individual developers are rarely given larger initiatives or projects to drive that are larger in scope than a handful of stories.
Pair programming and knowledge sharing is encouraged so that the knowledge is spread across the team and different developers can “rotate in” to different parts of the system as-needed. Stand-ups turn into “task brain-dump” status reports where people simply share what they’ve been doing.
The unfortunate underlying message that can be sent through most of these practices is that we want devs to be interchangeable. We may not mean to send that message, but we do anyways. Feeling interchangeable really sucks the joy out of work. You fail to see your unique strengths. You are not given the encouragement or latitude to build up your unique strengths and snowball those successes into a larger career path.
It doesn’t need to be this way
We need to encourage each other and help each other discover our strengths. The skills that come to us naturally are skills we often take for granted and can’t see our strength in. As the saying goes, “the fish is the last one to discover water.”
The backlog should take into account the strengths of the team and how to maximize the productivity on the team to help us ship software quicker.
Pair programming should augment the skills of both programmers involved. This can be especially powerful when the weaknesses of one programmer are offset by the strengths of the other programmer.
We need to remember that Agile processes are here to serve us, not the other way around. A process should be serving the best interests of the team. It exists to help make a team better.
We’ve lost our way when we’ve made the team subservient to the process itself. Sadly, that has become all too prevalent today in the age of selling (big s) Scrum into business cultures as a silver bullet.
Have you seen or experienced this?
What has been your experience using Scrum or other Agile methodologies? If you are a developer using Scrum at work, do you feel like the process allows you to leverage your unique strengths and encourage you to use all your intelligence? Do you feel fully present at work?