The story so far
Penny worked in the IT call centre. Her title was quite bland (she was a Second Level Support – Analyst Class 4), but she pictured herself as a young Sherlock Holmes.
Most of the people in the call centre answered customer calls and listened to their complaints. Most of the complaints were either known problems that the call centre apologised for, or simple problems the call centre operator could solve over the phone. But some were too hard to solve on the phone and these went to the “second level support” crew to look at.
And the problems too complicated for most of the members of the crew went to Penny, because she had a knack for solving the most mysterious and absurdly complicated problems.
Penny loved her job and couldn’t believe she was being paid to solve puzzles all day.
All that was about to change though. Unfortunately for Penny, she had been doing such a good job that people in senior management heard about her.
Senior management decided to promote Penny. And being promoted meant she would be managing people instead of solving the puzzles she so enjoyed wrestling with.
And so it begins
Penny walked into her boss’s office.
Actually, her immediate boss was Tom and she was walking into Sue’s office. Sue Tyorself was the head of the call centre and therefore Tom’s boss. But Sue often forgot to tell Tom when she was making management decisions so Penny was used to going to see her.
“You wanted to see me?” asked Penny.
“Yep – looks like we’ll be losing you from the call centre Penny. Steve wants to set up a new 3rd level support group and we thought you should head it up” said Sue.
“I already do 3rd level support, why do we need a new team?” Asked Penny.
“Apparently the execs want more of a focus on speed and quality” Said Sue, “We are going to adopt agile, so things need to change around here”.”
“What’s agile?” Asked Penny
“It’s awesome. Its a new way of doing things so projects can deliver much faster”
“How, though?”
“I think they get rid of testing and all other the other constraints that hold the developers back”
“They get rid of testing?”
“Apparently – and they don’t have to do any wasteful documentation like requirements or handover documents. It means we can be much faster to market”
“That doesn’t actually sound awesome to me.” commented Penny, “Are you sure they get rid of testing?”
“Apparently, or they have robots do it for them, I wasn’t really sure,” replied Sue Tyorself. “It’s in Steve’s KPI’s. The CEO told him to be agile by the end of the year. So its pretty important.”
“So by ‘awesome’, you mean your boss has it in his performance agreement.”
Sue gave Penny a few details about her new role. Penny would get a pay rise, which was great. She would start her new role immediately, which of course meant that there wasn’t enough time to set up a new role definition for her, nor sort out new reporting lines. So for the moment Penny would report directly to Sue.
Penny would get her own office and would be given a highly trained consultant to help her team become agile, which sounded good in theory. But since Penny was the only one in the team it did seem like a lot of effort to go to.
Either way, Penny also had to go and tell Tom about her new role. So she headed off to give him the good news and to clean up all the things she was currently working on.
That night Penny spent some time researching “agile”. She couldn’t find any reference to getting rid of testing, so she decided she should check that with the consultant.
What she saw seemed sensible, but didn’t explain why she had to rename herself “the agile support team”. In fact almost all the references she found were about application development projects rather than 3rd level support teams.
The team comes together
When Penny entered her new office the following morning she found two people waiting for her.
Sue’s personal assistant Bran was there (Bran is pronounced Braan apparently, though Penny wasn’t sure how that was different to pronouncing it Bran). Bran said hello and handed Penny some folders.
“These are the personnel files for your team members,” said Bran, “and this is Zara Zealot, the new agile consultant who will help you set the team up.”
“Hi,” said Zara, “Can’t wait to get started. Do you have any ideas about where the story wall should go? I was thinking it might look good next to the pot plant.”
Penny smiled politely and glanced at the folders to try and work out what Bran was talking about. She hadn’t realised that “support team” meant she had people reporting to her.
But before she could ask any questions, Bran invited the team in to meet her.
And so they began their first meeting.
“Um, welcome to the agile support team I guess. I’m Penny and I’m the new team leader” said Penny.
Everyone introduced themselves and said what they knew about their new role, which wasn’t much.
Aesop was an ex mainframe developer. According to his file he had actually retired the mainframe he worked on, which was something nobody believed would ever happen, so nobody knew what to do with him. Fortunately people didn’t really know what a third level support team was either. And since they didn’t know what sort of people the team needed and the didn’t know what sort of team to Aesop in, they thought there was a possibility that the skills Aesop had might be the same as the skills the team would need, so they thought the team might be a good fit for him.
The other two members of the team were new graduates on the graduate rotation program. Alice had a double major in testing and philosophy and Peter had a degree in tautological history.
Penny was a little suspicious though because she wasn’t sure that there really was a degree in tautological history and she doubted anyone really studied philosophy anymore, now that you could just use Google to find the answers to most of life’s big questions.
Either way, both Alice and Peter had 6 months experience out of university and seemed keen enough.
“So, what exactly is an agile support team?” asked Alice.
Penny looked across to where Zara had been standing, but Zara had wandered off and was putting masking tape on the wall for some reason.
So Aesop answered instead. “Agile is based on the approach they used in the famous story called Agile Farm,” explained Aesop, “The pigs and the chickens got sick of the way the farmer was running things so they took over the farm and replaced his evil ways by writing a manifesto and empowering all the animals to think for themselves.”
“I think you mean Animal Farm, by George Orwell,” said Peter.
But Aesop did not mean Animal Farm at all. He really did mean the story of Agile Farm.
So Aesop gave his version of where agile comes from.
“Animal Farm was actually a rip off of the original Agile Farm story. In the original, the animals put a big manifesto up on the wall to remind themselves how they should run their farming projects.
Then they threw the farmer and his evil project managers out because they thought the animals could run their farming projects better if they took accountability for the results themselves rather than being bullied by a project manager.
I can’t remember all of the principles they had in their manifesto, but I remember 3 of them:
- Two weeks good, four weeks bad and once every 6 months is right out. We should get our produce to the market every couple of weeks to sell it really fresh rather than only once a month or once a season;
- All team members are created equal, so they should have an equal say in how we do things; and
- Every crop is different, so the team can use a different approach to growing each one based on what will work the best for that crop.
But then the pigs snuck back each week and started changing things to go back to the old ways.
They started by calling themselves slum masters. The animals used to have their own offices and stalls but the slum masters made them all co-locate into one barn to save on rent. Then they started selling the furniture off so that the animals had to have all their meetings standing up.
Then the pigs started slowly changing the rules in the manifesto without the other animals noticing. I think the rules became things like:
- Two week shipments to the market is good but you can’t really do that so don’t worry about it;
- All team members are equal but slum masters are more equal so do what they say; and
- Use a different approach to growing every crop as long as it is done exactly the the same way as all the other crops.
So by the end of the book they are back doing things the old way but with the slum masters running the farm instead of the farmer. Then everyone goes back to the way they used to do things, just like they do after every new methodology comes and goes. And at the end of the book everyone is happy but the slum masters have made them more efficient by cutting back on the facilities costs like offices and furniture”
“It seems odd that we would base a methodology on an old book about farm animals,” said Alice.
“Zara,” Penny called out, “Is agile seriously about pigs and chickens and some manifesto?”
“It sure is,” replied Zara, “You guys are really starting to get it if you know about the pigs and chickens”.”
“So agile is a methodology based on some old book about farm animals,” said Alice, who seemed a little dubious.
“No, that’s a common misconception, agile is not really a methodology, its more of an attitude,” replied Zara as she came walking back to join in the conversation.
“See,” said Aesop”, “people never listen to mainframe developers but they really should. Like I said – agile is an attitude based on a book called Agile Farm.”
“What? What book?” said Zara, “I am not sure where you got that from. Maybe I should explain agile to you all properly.”
“Yes please,” everyone said.
And so Zara explained her understanding of agile.
“Agile was born on Agile Mountain in February 2001. We haven’t officially renamed the mountain yet, so its called something else on the map. But we are hoping to make the name change official pretty soon.
Anyway, seventeen really experienced project managers, developers and IT managers went up the mountain to discuss the importance of a proper approach to projects. They had some healthy and robust discussions and then they all agreed on what makes projects successful.
Then they published the rules for running projects successfully on the web at agilemanifesto.org. Now it contains everything we need to make projects successful.”
“I was doing agile last century though on my projects,” said Aesop, “so it can’t have been invented in 2001.”
“No you weren’t Aesop,” replied Zara, “I know it is hard for mainframe developers to accept change but we have learned a lot since the first mainframe was invented. You might have been doing something similar to agile, but without the right guidance you were probably just thinking you were being agile.”
“If agile is for projects then what does it have to do with a support team?” asked Alice.
“That’s a good question,” said Zara, “I guess we will have to learn to run a support team like a project. But I can help with that”.
“I think you will find that agile was around before 2001. In fact, since it is based on Agile Farm, it was probably around in the 1940’s,” persisted Aesop.
“Sorry, said Zara, but it was invented on Agile Mountain in 2001” .
“OK,” said Penny, “So you are telling that 17 developers, project managers and IT managers all agreed on an approach and then published it. I am not sure I can see even 2 developers agreeing on anything. And it seems a little unlikely that they remembered to document it either. Developers always say they will document things but they never really do.”
“I think Aesop’s version does sound a little more likely,” said Peter, “Developers never agree on anything. I’m not sure whether it comes from an old book, but agile is pretty much a duplication of OODA, which was being used by fighter pilots in World War Two. So I guess agile was around in the 1940’s even if people didn’t realise it at the time.”
Everybody stared at Peter. He seemed confident but nobody knew what he was talking about.
So Peter explained his version of where Agile came from.
“In the Battle of Britain in World War Two, the British had a lot of trouble training enough pilots because they kept getting shot down before they learned how to fly properly.
But they noticed that some pilots got shot down quickly and others seemed to survive even with out proper training. So they looked at what the most critical factors were in surviving in a dogfight.
At the time. most of their training was about avionics and the theory of flight. After that they spent a long time learning how to plan their patrols by coming up with a detailed operation plan and flight manifest. But their dogfights never went to plan and knowing a lot about avionics didn’t seem to help when someone was firing machine guns at them.
So they started to think that the most important things were reaction time and good decision making under pressure.
But then it turned out that you also had to be good at noticing other planes in the sky or you didn’t get to make a good decision before they shot you down. And making good decisions didn’t help if you took too long to make the right decision because you crashed before you had time to think about it.
So eventually they worked out that pilots had to do four things really well:
- Observation – they had to notice other planes in the air, they had to notice when they were off track and they had to notice things like the amount of fuel they had left.
- Orientation – they had to be able to make sense of a lot of information when they noticed it. So they needed to be really good at analysing and synthesising what they observed.
- Decision – it wasn’t enough to analyse information, they had to be really good at making decisions based on that information, and even knowing when to make a decision without enough information.
- Action – they had to be good at acting on their decision, by turning their plane quickly or pulling the joystick back the right amount.
But it wasn’t enough to be good at those four things. They had to do them in the right order and do them faster than the enemy pilot.
And finally, they had to work as a team in the dogfights, but they couldn’t wait to be told what to do like in their training, since nobody had a really clear picture of everything that was happening in a dogfight. So each pilot had to think for themselves and really communicate well with the other pilots rather than wait for the senior officer to work out what to do.
In addition to OODA, They also came up one more theory which they called ‘taking off is optional but landing is compulsory’. That was pilot-talk for the idea that pilots should be responsible for testing their own planes:
- The pilot is the one who is in the plane if it crashes and also the one who knows the most about what would cause a plane to crash, so he is probably going to be better at testing his own plane than anyone else;
- Since you don’t want to crash and die, it is a good idea to have a standard list of things to check so you don’t forget things like putting fuel in the plane. But you would also probably use your own judgement if the engine sounded funny or anything; and
- You have to test everything about your plane before you take off, because if you test it after you take off and find a problem you will probably crash and die, but if you find a problem before you take off then you will just miss out on flying for the day.
So after that they started selecting and training pilots on the basis of OODA and the pilot being smart enough to check their planes worked properly before taking off.
After World War Two, manufacturing started to get more competitive and people started wanting to get things out to market faster than their competitors but also have better quality than their competitors.
Traditional manufacturing said you could either go fast or have good quality. But then someone said “what about fighter pilots – they need to be fast and can’t afford to crash very often”. So they went and copied what the pilots were doing.
But they wanted people to think they came up with their own ideas so they called it lean instead of OODA.
Peter noticed that everyone was looking at him funny so he stopped talking.
“That doesn’t even have anything to do with IT” said Aesop.
“And you didn’t even have a manifesto in your story,” added Zara.
“Maybe manifesto is somehow related to a flight manifest, he had one of them in his story,” said Alice, trying to help Peter out a bit.
“No,” said Peter sadly, “a manifest and a manifesto are different things, they just sound a bit the same.”
“But it would be more fun to be like fighter pilots than farm animals or people talking on mountains. I like your story the best so far,” said Alice.
“It was a nice story Peter. But I am not sure we are any closer to understanding what agile is or how it works in a third level support team,” said Penny. She was not really enjoying this and was thinking it would be more fun doing her old job.
“You can’t really understand agile by defining it”,” said Zara helpfully “you need to understand some of the practices that are involved, then your will understand agile better”.
“You mean like TDD and pear shaped programming?” asked Aesop.
“Exactly,” replied Zara, “er – what kind of programming did you say?”
“I think we have had enough standing around talking about agile for one day,” said Penny, “It’s time we did some work.”
“But what work are we meant to be doing?” asked Peter.
“I guess we can work on some of the problems I still have left over from my old role,” said Penny, “It is third level support at least, and I know Tom and his team are drowning in problems. We can have another go at working out we are meant to be doing tomorrow”
So Zara went back to putting things up on the wall while the rest of the team went to see Tom and ask if he had some problems to solve.
They did get back to working out what agile was the following day. They talked about TDD and pear shaped programming and lots of other things. So if you want to know what happens next then come back next Wednesday evening and we will see how they went.
James King 