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
Daryl Kulak
Chief Sales, Fulfillment Officer
(Excerpt from the upcoming book “Agile in the Bloodstream” by Daryl Kulak and Dr. Hong Li)
Agile is an exciting prospect. It is usually pretty easy to see that an Agile project is physically different than other ways of developing software (team rooms, pair programming, etc.). Moving to Agile can feel like jumping across a chasm into a whole new territory.
Once you’re there, and it starts working well, Agile can be exhilarating. We’ve seen teams experience true joy from producing results quickly and being so deeply in touch with their customers using Agile.
But often a strange thing happens with Agile teams inside non-Agile organizations. They don’t expand. The Agile team may be able to produce great successes but the rest of the organization doesn’t recognize the team’s victories or, worse, start working against the team to ensure its failure.
Is this crazy? Is the rest of the organization insane with jealousy because the Agile team has found something new and useful? Yes, this is possible. But, in our experience, there is more going on. Introducing Agile into a non-Agile organization creates all kinds of issues that the organization and the Agile team need to address upfront if the team wants to be successful in the long term. We group these issues into a category we callillth.
Agile is Like Wal-Mart (Sort Of…A Little)
Illth.Nineteenth century English art critic John Ruskin created this word to describe the messy bits that came along with wealth. In Ruskin’s time, he saw that wealth was being created in various ways in England, with businesses and factories, but with those advances came the “side effects” of wealth, which were not as desirable. Underpaid and overworked laborers’ dismal lives could have been considered illth. The pollution and grime created by the factories in the community would have been illth. And the unrelenting movement of money from the poor to the rich was certainly illth in Ruskin’s mind.
Here is the definition of illth in Ruskin’s own words:
Wealth, therefore, is ‘The possession of the valuable by the valiant’; and in considering it as a power existing in a nation, the two elements, the value of the thing, and the valour of its possessor, must be estimated together. Whence it appears that many of the persons commonly considered wealthy, are in reality no more wealthy than the locks of their own strong boxes, they being inherently and eternally incapable of wealth; and operating for the nation, in an economical point of view, either as pools of dead water, and eddies in a stream (which, so long as the stream flows, are useless, oronly to drown people, but may become of importance in a state of stagnation should the stream dry); or else, as dams in a river, of which the ultimate service depends not on the dam, but the miller; or else, serve as mere accidental stays and impediments, acting not as wealth, but (for we ought to have a correspondent term) as ‘illth,’ causing various devastation and trouble around them in all directions; or lastly, act not at all, but are merely animated conditions of delay, (no use being possible of anything they have until they are dead,) in which last condition they are nevertheless often useful asdelays, and ‘impedimenta.’
Although Ruskin‘s definition sounds overly damning toward the rich, we still feel there are aspects of this definition that can be quite useful.
Since Ruskin’s time, illth has been used only sparingly in books and speech, mostly notably by George Bernard Shaw in his essays on socialism. But it seems like a good word. Certainly, often when we do something good in our community, there are bad things that come with it that we need to deal with. Pollution is the best example in our own time. Our incredible engines of growth in North America, Europe and Asia have generated great wealth for millions of people. But the scourge of pollution has inevitably followed that wealth, darkening its splendor.
Wal-Mart is a great example of wealth and illth. When Wal-Mart comes to town, there are great things that happen. People can get stuff for good prices and there are more jobs, lots more jobs. But there is also illth. Wal-Mart has a tendency to have a bad effect on the local smaller stores, putting them out of business because they can’t compete with the low prices.
What does illth have to do with Agile? Please don’t be offended that we are comparing Agile to Wal-Mart, and please don’t think that we’re saying that Agile team members are very like the idle rich that Ruskin seems to detest so much.
When you look at a highly-functioning Agile team, you can see their success as a form of wealth. An Agile team is often somehow magically able to accomplish mountains more work than a comparable waterfall team, and yet they work fewer hours and are happier with their work. The wealth flows.
So where is the illth? It might not be within the team itself, but it could be leaking into the teams surrounding the Agile team. How does the Program Management Office (PMO) feel about the Agile team? Are they “feeling the wealth” or “feeling the illth?” What is the effect of Agile on the team that deploys applications into production? How about the competency centers? Or the human resources teams?
You don’t have to scratch the surface very hard to find people in a large organization that are actually upset about the Agile team’s successes. Yes, this might sometimes be due to their jealousy of the success, but there is another aspect to it.
Think of your large organization like the body of an animal or a person. What happens when your body ingests something that it doesn’t recognize? White blood cells attack the new thing and try to kill it. War is on, and either the intruder is flushed out of the system or the body dies trying.
Is that necessary in your organization? It doesn’t have to be if you, the Agile team, can manage your illth.
First, let’s examine the problems that an Agile team can create for its neighbors in the large organization. After that section, we’ll look at some solutions that can help Agile and non-Agile co-exist.
Here are some types of Agile illth:
- Agile vanity
- Agile project within Non-Agile program
- Incremental impedance mismatch upstream
- Incremental impedance mismatch downstream
- Clash with the corporate methodology
- Clash with the corporate project management structure and tools
- Clash with competency centers
Here is a bit about Agile vanity. (We’ll discuss the other topics in a later post.)
Having seen Agile projects in many, many situations and variations, we’ve had the chance to observe a peculiar Agile tendency that we call “Agile vanity.”
In fact, it is quite natural, once you’ve discovered a new and better way of doing something to feel a bit full of yourself for a while. The only trouble is that this can cause great strain in your organization. Let’s look at some of the things that happen when Agile proponents turn into “Agilistas.”
Inside the Agile team, the observation of results helps to create enthusiasm and a willingness to commit time and energy. The team feels like they are being productive and are working well together.
When someone in the team is discussing their project with people outside the team, they may give a sunny picture of what is happening due to their own happiness with their work. The outsider is likely to question these new methods, especially if they haven’t seen it work themselves. This may put the Agile team member on the defensive a bit, feeling like they need to give the most articulate answers or this person might think the Agile team is just being duped by the latest software development “fad.”
Each time this happens, the Agile team members may feel like they just shouldn’t bother interacting with those outside the team, or if they do, maybe they shouldn’t discuss Agile too much for fear of being in a defensive situation again. The other aspect that can arise is that the team members discuss the successes of Agile among themselves but decide that the others “just can’t understand the Agile way.” This creates a barrier between the “insiders” and “outsiders.” This is what we call “Agile vanity.”
The danger here is that, as soon as the team erects this barrier, those outside instantly feel that they need to defend themselves against being viewed as stalwarts of the “old way.” The outsiders begin to come up with lists of reasons why Agile can’t possibly work and why the Agile team’s successes are due to factors other than the Agile practices they are using.
As you can imagine (or possibly as you’ve experienced), this is not productive. The outsiders can be other teams or they can also be the executive managers of the Agile team. The direct and indirect managers of the team can cause a great deal of havoc for the team, at worst hemming them in with random directives that are, subconsciously, being done to ensure the failure of the team.
The same things that help the team stick together can be the very things that distance them from the outside world. And those outsiders are people the Agile team needs to be successful, whether direct managers, co-workers, upstream or downstream projects, or other connecting teams. Agile vanity, although it feels good at the time, can be quite destructive.
It is worth paying equal attention to what is happening “outside the Agile team room” as well as inside. Too many of our Agile practices and principles deal with the goings-on inside the room, but it is what’s happening “out there” that can kill the project too.
Daryl Kulak
Chief Sales, Fulfillment Officer
Leadership in an agile world is something that I’m always very passionate about. So when I saw a presentation list at Agile 2009 by Gilles Brouillette called “Developing Agile Leaders & Teams”, it grabbed my attention. Since the room was overflowing to the point where threats of a fire marshal were invoked, the topic is apparently on the minds of a lot of other folks, too!
When I work with an organization that wants to transform, I like to tell them about what impact they’ll see in their culture and the rate which roles will adapt to the change. The business is always first to get on board. They’ve been asking for more involvement and more collaboration in delivering IT projects for years, so that’s kind of a no-brainer. The next are usually the developers. Suddenly people are focused on helping them to become craftsmen and to get first-hand feedback from the people using their products. That’s a pretty easy sell, too. Third are those that I’ll lump together in the BA and QA space. Their roles change, but become more relevant and meaningful to the team. Fourth are the IT managers, directors and VP types. They need to make the shift from “controlling” resources to “enabling” teams. The last role to adapt is always the PM and PMO. Describing why is probably a blog entry in and of itself.
It’s always been my position that managers, directors and VPs in the organization are the 2nd most important group to transform (the first, if you were wondering, is the business). Management can do more to kill an agile transformation than any other role in the organization. On the flip side, they can also do more to make the initiative successful than any other role in the organization. Sadly, I tend to find more in the former category than the latter. Brouillette’s presentation suggested that about 90% of leaders fall into a mindset that fosters heroics, focuses on self and pretty much embodies everything that would make them a poor leader in an agile organization. They’re tactical, reactive, competitive and generally resistant to change. Think about it; that means only 10% of the leaders are carrying the mindset that would allow them to foster agile growth in their organizations.
It certainly explains the root cause of most agile transformations that I’ve seen fail. Hearing some actual data around it just made me sad.
The good news is that it is possible to move from the 90% group to the 10% group. It’s more than training, it’s transforming. It becomes about moving people from our typical “command and control” style of management to one of servant-leadership. It’s a focus on listening more than telling. It’s about fostering collaboration more than competition. So how do we do that?
How about this. What would a leadership team look like if typical quarterly objectives and bonus plans rewarded how much you helped a peer succeed versus your own achievement? Or how many peers you helped to succeed? Or a score on a 360-degree evaluation that puts an emphasis on listening, transparency and collaboration? These are all things that most of us would agree are valuable assets in an agile leader. Unfortunately, most of would have to admit that the goals we set continue to be around hitting dates, generating revenue, meeting a schedule, etc. Don’t get me wrong; those things are important. The problem is they don’t drive the behavior we want in our agile leaders and, in fact, drive the exact opposite behavior.
Although I still don’t have a magic answer of how to transform leaders, mainly because that answer will different for each individual, I do have better awareness of scope of the issue that I keep encountering again and again. From the attendance, a lot of people have that awareness, too. It’s a step.
John Huston
Chief Operating Officer
He said Management 1.0 is the old style command and control and that Management 2.0 is more the manager as coach model. Management 3.0 is the art of empowering the teams and adopting a servant leadership approach to leading teams. The class was very experiential with lots of hands on exercises and small group work. I really appreciated the opportunity for networking and for gaining insight into the challenges that leaders at different organizations are facing in their transition to managing agile teams.
