This is another excerpt from my upcoming book “Agile in the Bloodstream: Creating Change-Ready Teams Using the Power of Systems Thinking.” It was also the basis of my talk at Agile 2009. I hope you enjoy it.
Although I’m an Agile coach by trade, I’m really a storyteller. In this article, I’d like to tell you five stories, mostly based on real life that might help you see how Agile can become mechanical. I have changed the names to something ridiculous to make sure I don’t implicate anyone.
Agile Expert Syndrome
Once upon a time, in a company called Neverland Insurance, there was a team and an Agile consultant. Together, they decided to try to build an application. The team was about ten people, and the Agile consultant had a really, really good reputation as a brilliant person and dedicated Agilist. The team felt lucky to have him. The Agile consultant’s name was Sticky LaGrange.
Sticky helped the team get started and taught them all the Agile practices. The team carefully followed Sticky’s words and asked him questions whenever they weren’t exactly sure what to do. Sticky was very helpful and patient. Not only that, but Sticky prided himself on writing more code than any other team member, even though he was spending so much time coaching people. Sticky was truly amazing.
At the end, the application was finished on-time and within budget. Everyone at Neverland was so impressed. The team was so proud.
Then the wicked king of Neverland cut budgets and the team had to say goodbye to Sticky. Surely they could they succeed without Sticky, he had taught them so well. So the team went on to another application and began work. They tried to remember everything that Sticky had told them. If in doubt, someone in the team room would inevitably ask “What would Sticky do?” The group would try to remember what Sticky would have done and then replicated it faithfully.
But things were falling apart. Different team members remembered Sticky’s advice differently. And sometimes, inexplicably, Sticky’s advice seemed to be wrong! When applied in this new situation, Sticky’s advice broke down. How could Sticky be wrong?
Some team members said that maybe they should go beyond Sticky’s advice. But other people thought this was a terrible idea. “That’s not True Agile!” they cried. Why deviate from Sticky’s advice if it had worked so well the first time?
Unfortunately, the team at Neverland had fallen into what I call the Agile Expert Syndrome. This is when people feel like they have to follow the advice of an expert, either in the form of a consultant or a book or an article.
Whenever a team gets into this compliance mode, they are in trouble. They are performing Agile mechanically. And teams that are doing Mechanical Agile always get into trouble, because they will always hit a snag that falls in between the advice they received from the Expert. And as soon as that happens, they will get into a rut where they are trying to guess what the Expert would do, instead of applying their own intelligence and doing the best thing they can think to do.
Separation of Decision-Making and the Work
Once upon a time there was a clothing manufacturing company called Cheap Green Shirts.com. The company had several Agile teams that were doing a great job and were highly productive. Their velocity was high, the teams were happy and the business was benefiting.
“I think we can juice these teams up even more,” said one of the vice-presidents. “I’ve noticed that Team A is doing significantly better than the other teams, so we should take the best practices from Team A and give them to the other teams. That way, we’ll have all teams performing at the level of Team A. It will be great!”
So the vice-president set up a group of Agile experts that he called a Software Engineering Process Group (SEPG) that was able to advice the teams. The SEPG (pronounced seepage) experts carefully examined each practice used by each team, harvested them and chose the best of the best, then gave them back to the teams.
Surprisingly, the teams didn’t use many of the new practices. The SEPG experts were incensed. “These teams don’t want to learn,” the SEPG experts groaned. “The SEPG dudes don’t understand our work,” said the teams.
So the vice-president mandated that the groups use what the SEPG experts had come up with. The groups dutifully used the new practices. At this point, velocity dropped for each and every group. How could this happen? The SEPG experts explained “The teams are doing the practices wrong!” The teams replied “These practices don’t work for us.”
The vice-president fell into a mechanical Agile problem that we call “separation of decision-making and the work.” The further the decision-making happens away from the person doing the work, the worse the result will be. The SEPG group was far removed from the teams, they weren’t familiar with the details of the day-to-day work, and so , even though they were experts, their recommendations failed miserably. At the beginning, the teams were making their own decisions about which practices to use, which ones were best for them. By removing that decision-making from the local team members and giving it to a separate group, the vice-president reduced velocity, team satisfaction and caused problems for everyone. The vice-president was thinking that the teams were machines, not people.
Blame the Person, Not the System
A company had two teams working together. One team was providing a set of requirements for the other team to implement in code. The first team we’ll call the Uppities, because they were upstream in the process. The second team we’ll call the Downers, because they were downstream in the process.
First of all, the Uppities and the Downers were both doing Agile, just different variations. The Uppities were on a longer iteration cycle of 6 weeks, whereas the Downers were using 2 week iterations. But everyone was doing some flavor of Agile.
Still, the Uppities did not get along too well with the Downers. The Uppities tended to have big emergencies and would dump high-priority work into the Downers area, even in mid-iteration. Since the Uppities work was the most important work in the company, the Downers had to comply.
One day, I was in a conversation with someone from the downstream team, the Downers. Let’s call him Donny.
I asked Donny what he thought was the origin of the conflicts between the Uppities and the Downers. “Well, it’s the Uppities, of course!” he said. “They have no respect for other teams! They think they own the place!”
I asked Donny if he could imagine what it was like from the Uppities perspective.
“Oh sure, that’s no problem. I used to work there,” Donny said, to my surprise. “And when I was an Uppity, it was pretty obvious that the Downers were the problem. But now I can see the REAL story, that the Uppities are the entire problem, and not the Downers!”
I couldn’t help wondering if Donny was falling into another aspect of Mechanical Agile, which I call “Blame the Person, not the System.” Donny, no matter which team he belonged to, was thinking that the other team was the problem, instead of thinking that the system was the problem. By system I don’t mean the software application, I mean the methods of interaction between the two teams, even the culture. There were probably problems in the overall system that were causing this conflict, and those systemic problems were being misinterpreted as “the other guy’s fault.”
If we can always take an attitude of “Let’s fix the system together” rather than getting into a blame-game of determining who’s at fault (Hint: it’s always the other guy), we can make much more progress.
Just Tell Me What to Do, Boss
My employer, Pillar Technology, has a very rigorous interview process for developers. Part of our process is that the prospective recruit has to pair with one of our Pillar experts to allow us to evaluate the person’s ability to perform as a test-driven developer.
In one case that I was able to observe from across the team room, a prospective recruit came into the room and sat down with our Pillar expert. We’ll call the prospective recruit Emo. Since this was about test-driven development, the Pillar expert asked Emo to look at some existing code, and an existing unit test, and try to figure out how to make the test pass.
The test was very simple. It provided some input and then asserted that the variable being returned should equal “12.”
Emo looked at the test, then flipped over to the code. After a quick glance at the code, Emo took the cursor and deleted it all. In its place, Emo wrote code that would make the return variable equal to “12.” Then Emo smiled at the Pillar expert.
This was both the shortest pairing interview I have ever seen, and the longest post-interview retrospective.
Emo fell into an aspect of Mechanical Agile that I call “Just Tell Me What to Do, Boss.” If our team members get into a mindset where they just want to take direction from their boss, we’re all in trouble. We need every team member to be applying their full intelligence to every problem. As soon as they get into the mode of following directions, then we get solutions like what Emo did in the interview.
Team members can get into this way of thinking quite easily. Managers who are coercive create team members like this, because people are afraid to do anything different than exactly what the manager specified. But even the presence of detailed documentation on “what you should do” can create these types of team members.
We need to do everything we can to avoid getting our team members into a mindset like poor Emo.
Competition Between People and Teams
A VP at a telecom company had six Agile teams all doing great work. Then he had an idea. He realized he could “kick it up a notch” by getting his teams to compete against each other for a monthly prize.
We’ll call this VP Emeril.
Emeril said he would offer free lunches for a week for the team that could top the other teams in velocity.
The competition began. The teams immediately started looking for ways to game the system. They found that if they made their storypoints smaller, they could deliver more of them without doing extra work. The teams went through a period of “storypoint inflation” for several months until the VP realized what was going on. Finally, he mandated that the storypoints had to be all the same size.
Then the teams realized that quality and defects were not part of the measurement, so they reduced the amount of time they spent on testing in each iteration. Sure enough, the points went up, but so did the defects.
So, the VP eventually jumped in and mandated that defects would be part of the measurement. The more defects found, the lower the team would score.
This sounded okay, but the VP didn’t realize that the testers were also part of the teams. They were also in line for free lunches. So, by making this third decree, the VP was telling the testers “Don’t find too many defects or you won’t get the free lunches.”
And on it went. You can imagine that these competitions didn’t help things much. And the cooperation that naturally was occurring between the teams disappeared. Why help the other team gain velocity at our expense??
The VP was suffering from a symptom of Mechanical Agile called “Competition Between People and Teams.” Put people or teams in competition with each other and you will ensure that they will meet your targets, even if they have to destroy your organization to do it.
Five Symptoms – Five Stories
These are some of the problems that keep your Agile teams from scaling up and sustaining. And they all relate back to treating people like machines instead of like people.
To solve the Mechanical Agile, no amount of new practices or Lean, Kanban or Six Sigma will help you. Scrum of Scrums won’t really help you. More meetings won’t help you. Only addressing the attitude of thinking of people as machines will help you.
Some Ideas That May Help
Here are some suggestions to improve your teams’ ability to scale and sustain. These aren’t meant to be singular solutions to the first five symptoms, you could say that all five of these solutions solve all five symptoms.
If You See a Best Practice By the Side of the Road – Kill It
The idea of “best practices” can become quite mechanical. It can lead directly to Agile Expert Syndrome of any of the problems we’ve discussed above.
I’m not saying that you can never take a practice that you see elsewhere and try it in your situation. I’m saying that you shouldn’t do it blindly.
Blindly following “best practices” always gets us into trouble. We can try to understand practices used elsewhere, but then we can jump into answering “How can that work here? How do we need to change it to fit?”
Close the Gap Between Decision-Making and the Work
As we saw with the SEPG experts, it hurts when we take decision-making away from the person doing the work. The further that gap, the bigger the hurt. We need to move decision-making as close to the work as possible. If the person doing the work can make all decisions about that work, that is optimal. If we have to separate it for some reason, try to keep it as close as possible (within the same team, hopefully).
Break Down the Boundaries Between Teams
A manager’s biggest responsibility is to break down the boundaries between teams. Having teams compete against one another erects boundaries. A manager stating that “Everything must go through me” to communicate to other teams erects boundaries.
The best Agile manager will work to remove boundaries, finding ways the team can have unfettered communication with other teams, groups, departments.
Value the Unstructured
Quite often when we see a problem, we try to invent some structure to fix it. Have two Agile teams that need to communicate more? Set up a Scrum of Scrums meeting.
But there is also value in the unstructured. Sometimes it is worth trying to find a way to solve problems that doesn’t involve more structure, more meetings, more roles, more documents, more setup.
Are there things we can change about our attitude that can improve the situation? If so, what can we do to change our own attitudes? How can we change the culture of the way work is done in our team?
Avoid Over-Engineering Your Processes
We often use the term software engineering to describe how we create software. Software, once created, is certainly mechanical, so thinking of ourselves as building something mechanical can make sense when describing software creation.
However, it can cause trouble when we try to engineer processes. Our processes cannot be mechanical, for all the reasons in my stories above. They have to be living, breathing processes that can adapt effortlessly. The only way to have processes that are alive like this are to have openings in them for people to do what they think is the right thing to do. We need to allow people to act like people, and not try to force them into a machine model that we’ve created for them.
Photo credit – gfpeck on Flickr
Subscribe to this feed