This is the second post on where Executives and Agile Experience diverge. It relates to the attitude towards Dragon Slayers and Farmers.

The Dragon Slayer

The executive sat in their office looking out toward the team. They hoped that today would be a quiet day, a day without Dragons. Draco arrived late and unpacked their back pack over their desk. Draco was often late because they nursed the system late into the early hours until it was stable and on its way to a successful run. Draco had saved the Executive’s job several times… a week… ever since the executive had taken over.

The executive opened outlook and started to scan their e:mails and mark them as urgent or important. As they worked down the list, a small crowd of the usual players gathered around Draco’s desk. Draco took a sip of their coffee as they listened, put down the coffee, and removed their glasses to pinch the bridge of their nose. They closed their eyes and remained still for a moment before silently nodding consent. How many times had the executive seem this ceremony play out? The players were headed towards their office. Behind them, the executive noted Giles and returned his wave. Giles pointed at their wrist indicating they would be over in five minutes for their one-to-one. Giles would push the executive for more money to invest in irrigation and fences, not an exciting decision for a battlefield commander. The delegation was now at the executive’s office. They paused at the threshold to make eye contact and agreement to progress. The executive waved them in and they rushed to their familiar spots around the executives small table, with the major positioned at the white board.

“Dragons! Dragons!”

The major cleared their throat. “The trades failed to cross the bridge. There was a new variant of trade that caused the check-point to fail.”

The executive nodded. “Go on.”

The major drew three squares on the white board and tapped on them before crossing one out. “I propose we clear the bridge, delete the offending trade and restart. We should be done by the deadline and the Prince need not know anything about it.”

Out of the corner of their eye, the executive saw Farmer Giles hovering at the threshold to the executive’s office. The executive waved the farmer away. The one-to-one would have to wait. There was a Dragon to slay!

The executive stared out his window at the office directly opposite. The office with a small leather sofa AND a small table. The office that they hoped would be theirs one day, providing the Dragons did not kill the executive’s career. “Draco, what do you think? Will it work.”

Draco blinked behind their thick glasses. Remained silent for a few seconds and then replied. “It won’t work. There are several reconciliation points which would fail later on as they check to make sure every trade is present.”

The major jumped in. “So what should we do?”

Draco, more confident now. “Lets clear the bridge. I’ll copy the bridge script and create a tweaked version for the new trade. We should hit the deadline.”

They turned to the executive who continued to stare out of the window. “Draco. Will it work?”

Draco was quick to answer. “Yes. It will”

The executive closed their eyes. This is a good decision for a battlefield commander. “Do it!” they said.

“I’ll get my men to clear the bridge and prepare for the script variant.” The major was happy to have a role to play in slaying the dragon. They all rushed from the executive’s office.

Later in the day, the executive looked up to see the Prince laughing and joking with Draco and the Major. The Prince saw the executive looking at them and waved. He strode over toward the executives office. “Great team you have here.” And then the Prince was gone.

The Farmer

The farmer signaled to the executive that they would join them in a few minutes as they passed behind Draco and co. The farmer checked the monitors for their system. Nothing had happened. Boring, boring, boring! Just as they liked it.

They dropped their bag on their desk and headed over to the executive’s office wondering whether their weekly one-to-one would happen. It was cancelled more often than not by a wondering Dragon that Draco needed to slay.

The executive waved the farmer away. They frowned, it would mean longer until they got more capacity in the lower field.

The farmer was grateful that they did not have to fight Dragons every day. The first few months had been hard. Early starts, late finishes and never a chance to help with the school run. The arguments with their partner because they could not take the kids to school or drop them off. Hiring the right people, shaving the Yak, introducing effective tests, removing technical debt. “Digging ditches and mending fences” as he explained to the executive and Prince. Now the system was boring, boring, boring. The farmer saw no reason to leave, provided they got the promotion they expected.

The Annual Appraisal

The executive hated the annual appraisal and promotion round. There were always people who were angry and annoyed. This year was going to be worse than normal, the Prince had told the executive that there would only be one promotion in their team. They would have to choose between Draco and Giles.

The executives focused on the questions that formed the promotion request.

“Please give evidence of leadership and problem solving.”

“Please give evidence of calm leadership under pressure.”

“Please give evidence of where the candidate has put the company first.”

It was easy to fill out the form for Draco. Draco filled the form several times a week. They barely knew Giles, it had been a month since the last one-to-one. He remember that he had been quite stressed when he started the job, and the executive had doubted their strategy of digging ditches and building fences when the dragons were flying overhead. In fact, the executive remembered feeling quite anxious about it all.

Besides, the Prince knew Draco well and did not know the Farmer at all.

The Aftermath

The executive was quite pleased with the way things were. Unfortunately Farmer Giles had left after it was announced that Draco would take over, something that had only been made possible by an ingenious double promotion. As soon as Giles and some of his team left it became apparent that they had been hiding things. Dragons had started to appear but luckily they had Draco in place to cope with them, the executive was sure that the system was now in safe hands. The executive looked forward to their new office.

The executive picked up the book in front of them “Agile Software Development” by Alistair Cockburn. Something about the story of the author’s son planting next year’s profit bothered them but they could not work out why.

Author’s note

There are a couple of points I want to confess to with this post…

1. This is faction. It is based on several real experiences and observation made since first reading Alistair’s book.
2. This is the first blog post I’ve tried to deliberately write in a gender neutral manner, trying to use “They”/”Them” instead of “He”/”She”. It was harder than I expected and it does not flow as well as I would like.
3. The photo of the Dragon guarding the City of London was taken yesterday outside of Chancery Lane tube station. I tried to snap the Dragons in Moorgate and Bishopsgate but they are gone. Perhaps it is a sign that there are fewer Dragons in the city thanks to Agile?
4. The photo is the first that I have edited. The dark original with tree branches and a tower is shown below side by side with the edited version finally used.

It is a commonly held belief that Executives and Agile are aligned and the problem with Agile adoption lies with the Frozen Middle (Management). Although Agile and Executives are aligned on many things, there are some core beliefs where some executives diverge. This is the first post in a series that explores those areas where the divergence occurs.

Sustainable Pace

The easiest way to spot an IT executive who does not have experience on the front line as a developer or manager is their attitude to overtime. Anyone with experience as an agile developer or working closely with developers knows that any code written after six in the evening has to be rewritten at some point, ideally the following day but often at a later date when it costs more to fix. One of the core tenets of Agile is the concept of “sustainable pace“, that developers work at a pace that can be sustained over an indefinite period. This sustainable pace leads to more predictability regarding the delivery of value that gives business sponsors confidence and reliability. Sustainable pace reduces cost because it reduces staff turnover , especially experienced developers who have a choice as to where they work. In order to maintain a sustainable pace, managers need to ensure they have slack which is also contrary to the goals of many executives.

Sustainable Pace is particularly important when developers are following an Agile approach to development, or more precisely Extreme Programming (or Dev Ops as it often called these days). Extreme Programming is a very disciplined and rigorous approach to developing software. Developers follow the disciplined “Red-Green-Refactor” pattern. This approach requires discipline and focus that is enhanced by the practice of pair programming which further keeps developers focused on a problem and reduces interruption. Extreme Programming is rigorous and relentless, requiring both discipline and focus. Simply put, if a developer is following extreme programming practices, they are simply unable to work beyond 6pm for an extended period without becoming tired and making mistakes. These mistakes lead to reduced productivity and introduce uncertainty into the development process.

Cheap developers reduce costs

Associated with the belief that sustainable pace is unimportant is the belief that some executives have that cheap developers reduce cost. Experienced Agile Developers and managers that have worked with them know that good developers are much cheaper than inexperienced ones when you consider productivity. Experienced Agile developers “shave the Yak” as they go along. They ruthlessly refactor legacy code bases so that they can deliver value faster. They do not have have to do massive refactorings as a big batch but rather have the skills to continuously improve the code base. All of this whilst continuously improving the velocity at which they deliver value using the “Red-Green-Refactor” pattern.

Book of Dead Code

A few years ago I visited Nat Pryce and his team. They were looking after a complex code base to support a web site for complicated financial derivatives. Nat showed me a graph that plotted the number of lines of code over a six month period. Over six month his team had reduced the code base from a million lines of code to one hundred thousand. The code base was approximately ten percent of its original size.

I once worked with Steve Freeman on a project. In a few short weeks he reduced the size of one of the most complicated areas of the code base by 80% and trained the graduate on the team in Extreme Programming at the same time. The pair also wrapped the code base in automated tests as part of the process.

If you want to understand why that is so significant, consider the following two images. In which one is it easiest to spot the bug (Waldo)?

Some Agile Developers have a practice of creating a book of dead code. Code that has been deleted from legacy code bases that was unnecessary. A book of dead code is a good way of demonstrating to business investors how much unnecessary and wasteful code they have paid for because they hired inexperienced developers.

Inexperienced developers tend to generate bigger code bases as they “cut-and-paste” to solve problems. A lack of automated tests leads to risk aversion which means they avoid touching the original code and copy it instead, tweaking the new version and leaving the original untouched.

If you want to reduce your short and long term costs, invest in Agile developers who have extensive experience in Extreme Programming practices.

Value versus Cost

Unfortunately executives do not value experienced Agile developers. They prefer to hire cheap off shore developers who are often recent graduates in the belief that cheap is better than experience.

The reason for this is well known.

IT departments in traditional organisations have a pretty poor track record at delivering value. A few years ago I heard a quote from a CEO. It was something like “I love off-shoring. Now when a project fails, it does not cost as much“. This highlights the reality that business leaders do not trust their IT departments to deliver value, so they focus on reducing cost. Agile focuses on delivering value rather than reducing cost. Cost reduction occurs by only building features that customers value and avoiding the features that are not valued and therefore not used.

Good developers want to work with good developers

So now that we understand that hiring good developers is better than hiring cheap developers for reducing overall costs. How do we hire good developers?

Executives think that paying experienced developers is enough to motivate them. They think that coersion applied through the hierarchy and the appropriate (currently in vogue) reward and appraisal system is all that is needed to achieve the goals they set.

Good developers want to write good code. They look for environments where they are respected for their ability and managers and executives are constantly looking for ways to help the developers become more effective. Good developers want to work in an environment where they have the tools they need to perform. If they do not have those tools, they will move on.

Good Agile developers want to work with good agile developers. They want to develop their skills and they are not going to be able to do that working with a bunch of graduates.

The good news is if you create the conditions that allow developers to deliver, they will come to you. There are several companies in London with large clusters of Agile Developers. As soon as an Agile developer discovers a good place to work, they reach out to their friends to pull them in. That’s why companies like Springer, Sky, Net-A-Porter, BBC, that are known to be favorable environments for Agile developers. They do not need to advertise as developers make a bee line to them.

It takes time to establish a reputation as a “go to” agile organisation. For those organisations that want a kick start and for those executives who do not have access to the network of established agile practitioners, you might consider starting with established agile consultancies rather than those whose practice is based in waterfall. Consultancies like Equal Experts, BJSS, Zulkhe, Industrial Logic, Crisp and ThoughtWorks. The ideal is to hire the alumni of those consultancies.

Teams OVER Individuals

Executives who are experienced with agile appreciate the value of individuals and appreciate the value of gelled teams of experienced individuals even more. A few months ago Microsoft closed the London Office of Skype in a strategic reorganisation. Enlightened individuals at Amazon appreciated the opportunity this represented and at the end of the same day they were standing outside of the Skype office handing out Apple Macs to developers. They did not insisted on interviews but hired entire teams in one go.

Being ready to respond to an opportunity like that. That is true agile management.

Dragon Slayers and Farmers

In the next post I will discuss the divergent attitude towards Dragon Slayers and Farmers.