The Agile Island

 Posted by on Sep 20, 2011  Add comments
Sep 202011

One of the saddest patterns I’ve seen several times in my career is that of an agile island. The story usually goes along this route: a highly motivated middle manager finds herself in some difficult situation and decides that agile is the right way out of her turmoil. She starts to read books, she engages skilled consultants, she gets the team on board, introduces self-organization, finds skillful product owners, and, after one year or so, she has a highly successful agile team. Well, not everything is really perfect, but after all, the situation is way better than it was before the transition and the clients notice a significant difference — though there is still some way to go.

Throughout the transition, the manager has turned into an agile evangelist; she speaks on conferences, writes articles about her success, gives internal presentations on how she managed the turnaround, and is happy to act as a reference for whatever they used. (Professional) Life can be great!

However, one or two years later, things start to behave strangely. The budgets for the final steps of the transition suddenly get reduced and the final steps of test automization never get finished. For some reason, the technical debt seems to grow rather than decrease. The team refuses to make some decisions and the working atmosphere seems to become colder and colder. Even worse, her own bosses start to put pressure on the team to deliver more, ignoring all carefully balanced planning processes. Again she calls in her consultant who runs the next retrospective and afterwards supports her findings: there is still some defiance in the implementation of agile development practices, the team seems to be afraid of self-organization, and there is a lack of commitment together with a fatalistic attitude in the team. After some discussion, the consultant finally asks:

“What does your boss say about the current situation?”

“You see,” she answers, “he completely trusts me to run this team, so they deliver what is necessary.”

“Does he understand the potential and the implications the agile transition has for his business?”

“Well, he’s a marketing guy and basically wants not to be molested with this nerd stuff. That’s why he hired me.”

“So does he really trust you to run this? Or is he basically uninterested?”

The manager feels that her consultant is touching a delicate subject here: “Well, to be honest, I believe that he doesn’t have any idea of what software development really means and he’s not interested in it.”

“When was the last time your boss gave positive feedback to the team?”

“I think that was last year at the Christmas party, when he gave this speech.”

“Yes, I remember him saying, ‘This Scram process really helped you to manage this crisis, but now it’s time to address our real problems and become more productive.’ And this was 11 months ago. Would you really consider this positive feedback?”

“I had asked him afterwards and he answered, ‘Well, these are all professionals, they get money for getting their work done. It’s not the management’s job to run around like a babysitter and praise them all the time.'”

“I understand,” answers the consultant, “this explains, also, why he could never find time to meet me for more than 15 minutes.”

Let’s analyze what was going on in this conversation. Apparently, the manager’s boss did not consider software development as anything important to him. Maybe his day was filled with “real business stuff,” such as M&As; maybe he considered software development as nerdy magic of uncontrollable geeks. But what our manager interpreted as trust in her was in reality lack of interest. So the agile team had built an island of happiness within an organization that basically did not care.

However, this disinterest had two major effects on the team. At first, the team did not get the resources needed. Instead of reducing workload to provide time for paying back technical debt, the boss increased the pressure. This led to frustration in the team and stole time needed to do better work.

But what was even worse was the feedback behavior of the boss. If there was any communication at all, the boss smacked the team for not being as productive as he wished. This was a completely negative one-way communication. There was no interest in the source of the problem. There was no attempt to understand the team’s point of view and its needs. There was a complete lack of respect for software developers.

An agile team needs to learn self-organization. This is a complex task and the only way a team can learn complex tasks is by fair and timely feedback. The team will react to positive feedback by strengthening the behavior that brought members there, but the team will weaken on negative feedback. This is just the way we humans learn. However, if the team receives only negative feedback, it won’t be able to adjust its behavior and will start to distrust everyone. Self-organization will then lead to defensive, unproductive behavior. Although the team obeys all agile practices, it won’t become high-performing.

So what can you do if you find yourself on an agile island? There’s not much advice here within the boundary of the agile team. Any real help has to include the boss. You can try to find a language your boss understands and change his or her perspective. Try this early; try this often. Chances are you may really accomplish something. But if you find that you might as well be trying to defy gravity, keep the old saying in mind: if you can’t change your company, change your company. People who have gone through an agile transition successfully have at least worked effectively on their market value.


Jens Coldewey

Jens Coldewey, based in Munich, Germany, is a Senior Consultant with Cutter’s Agile Product & Project Management Practice. He specializes in deploying agile development and object-oriented techniques in large organizations.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>