Once upon a time, in a country far, far away, a programmer was walking down a narrow path through the wood. She was on her way to the open spot, down the path, she looked sad. Matter of fact, she was crying a little. She was thinking of how during the night she would dream of beautiful code she would make and about perfect systems that her team would create. And she was thinking of the crappy code that she saw at the end of the day, and the messy system they would deliver. Suddenly, she hears a crack behind the brushes — is it a wolf? There were a lot of wolves in the wood, but she didn’t wear a red riding hood, so she was safe from them. There was no wolf. Instead, a man appeared. A man with a large pointy hat with golden stars and a wide brim, he was wearing a starred robe too.
“What makes you cry, my child?” the wizzard asks her. Because, of course, that’s what he was, a wizzard. Who else would wear a large pointy hat with stars when strolling through the woods? She startled. Through her tears, she said
“I am not crying, it is just a tear. Just one. Who are you?”
“I am No Na, the wizzard of the East Wood”, the man said. “tell me, now, what makes you so sad?”
And she told him about her dreams of beautiful code, about the perfect systems she saw, about the daily standup meeting at the open spot in the wood, about the specks she was given that didn’t make sense, about her team of good people that somehow never managed to do something well. When she stopped speaking, they stood silent for a while. Then she said
“I know they’re intentions are good. Last year, we took a rugby clinic, we practised scrumming, we practised team work. We were given a large white board and tons of yellow pieces of paper, to make us work better. At the open spot in the wood, we stick yellow papers on the board, we get an assignment, and we go back to work. But the longer we work on the project, the less it all makes sense to me. They make me program screens and functions and everything in a way that doesn’t seem to fit. I spend a day creating a button when I know I could have created it in seconds, if only they let me change the specks a little. I never geta say in the parts of the system that is not coding.”
She starts to cry again, and through her tears, she says “and in the end, the customers aren’t happy with what they get, and our team is blamed for that”.
The wizzard sits down on the stump of an old tree, our unhappy programmer sets herself on a stone. They sit in silence, for a long time. A wolf is watching from the distance.
“My child, I will tell you a story. Can you spare some time?”
“Yes I can. I am late for the stand up meeting anyway, and frankly, I don’t want to go there any more”.
“Right, then.”
“Once upon a time, in a country far, far away — because that’s when and where stories happen: once upon a time, in a country far, far away — there was a young programmer. He was unhappy, I take it you know how come. He left the village where he grew up, he left his parents and his sister behind, to find a new job and a new life elsewhere. A better job, and a better life. He walked through the woods for a day, and when he started to look for a place to sleep, he saw a speck of light. When he approached, he saw it was a little window in a cottage. He realized he was hungry, so he walked to the cottage. Before he could knock on the door, it opened, and a girl came out. She looked at him.
“Who are you?”
He told her his name.
“Hi. I am Take”, she says, pronouncing her name as as “Tah-Keh”, “You must be hungry. And do you have a place to sleep for the night? No? Right. You can have dinner with me, and I have a spare bed. Come in.”
They ate, they drank wine, they talked. He told Take about his job, the lack of results, the clueless project manager.
“And now I’m on my way to find a new job”.
“What kind of job?”
“Any job. As long as it doesn’t come with a clueless project manager”.
Take thinks for a while. She finishes her wine. Then she smiles.
“Come with me, tomorrow. Our team needs another programmer, you seem smart and capable. Why don’t you work with us for some time? It pays well, the people are very nice, and they are very good at what they do. Try it, if only for a few days. I’m sure you’ll like it”.
Our unhappy programmer smiles.
“That’s what they said about the team I was in until now. But it turned out to be disastrous.”
“Try. I promise, you’ll like it. Do it in return for the food and the wine. You can stay with me for a few days, and then make up your mind. Please?”
He has nowhere else to go, the girl is very nice to him, the wine is good, and he is tired like he has never been before.
“Ok, I will try. A few days, then we’ll see”.
The next morning when he wakes up, breakfast is ready. He eats a giant mushroom stuffed with scrambled eggs. Then there’s coffee, espresso-style, in tiny cups.
“Now off we go. Work starts at eight, we don’t want to be late”.
And off they go, work starts at eight, they don’t want to be late. They walk down a path, after ten minutes they come at an open space. A few people are already waiting. There’s a small fire, and the smell of coffee. A moka pot is hanging over the fire.
“Take, who’s your new friend?”
“He’s our new programmer. He was unhappy because his work wasn’t valued and his skills weren’t used to the max. He’ll work here for a few days. That ok with you guys?”
“Sure, who can say no to a good programmer?”
After they have exchanged names, and laughs, and hand shakes, and hugs, and coffee, someone suggests they start the project. To his distress, our unhappy programmer sees a large white board, nailed to a tree. He looks for the pieces of yellow paper that should come with it, but he doesn’t see any.
Take takes charge.
“Right. Today we need to make an app for the innkeeper. She wants people to use an app so they know in advance when the Inn makes fresh beer, what the menu will be that day, and other things. Any ideas?”
A young man walks to the white board, gets a piece of charcoal, and draws a few screens. Then a woman takes the charcoal from him, draws some lines and circles through the screens, and smiles. Everybody draws on the board, erases parts, redraws them, and they keep talking and arguing, and laughing. Then Take sees our unhappy programmer, looking sad.
“Hey, what’s with you? How come you look so sad. And how come you’re sitting there, you’re not participating?”
“I am sad, because this all ressembles the projects back home. People arguing, and I wait until I get my say about the whole thing. When all decisions have already been made”.
“What??” She chokes in her moka.
“You aren’t taking part. Goowey here has drawn some screens, I would expect you to argue with him, so together you’d create something that works. But you just sit there. Here, take a fresh piece of charcoal, tell us what you think!”
Our unhappy programmer is a bit shy. He doesn’t like to be in the spotlight, especially in a new team. He barely knows these people.
“Well, these screens, they look good, but they are not material design. Also, I think if we make some small changes,” and he starts to draw on the board “the users will like it more. Also, on the screen for the innkeeper, I have some questions, so we have to plan a meeting so we can ask.”
“What meeting?” an elderly lady jumps in. “I am the innkeeper, just talk to me”
They bicker, they argue, they talk, they laugh. A young man joins in.
“Look, I am the help desk. I disagree with what you say.”
Unhappy looks at him in surprise.
“Help desk? What are you doing at this standup meeting?”
“Excuse me? You guys build this app in a few days. I get to help people use it for the next twenty years. Don’t you think I deserve a say in all this?”
Then the sales person wants changes in the screens, the brewer makes suggestions for the API, Goowey makes some more coffee, and before they know, they have a brilliant design of the app on the white board. Someone has created a feature list, based on the design. They make more moka, then they bring out the laptops and start to work. Unhappy has just brought up his IDE, when Goowey sits next to him, and says
“Ok, what graphics do you need? Which features do you want to start with? When you set up the app plumbing, I can start with some basic graphics.”
After half an hour, they have Gooweys basic graphics in Unhappy’s first version of the code. They run it on an emulator. It’s not right yet. They keep changing graphics and refactoring code, until at lunch time, they are happy with the result. The innkeeper has been watching them.
“Looks great guys, there are just some things I want to say about it. Lets talk after lunch.”
Take folds her laptop, she has been working on another part of the app, with the helpdesk person and the sales rep.
Lunch is roasted giant mushrooms stuffed with blue cheese, and beer from the cask that the innkeeper brought. They seem to like stuffed giant mushrooms here. They sing, and laugh, and dance, then after about an hour they go back to work. Unhappy now gets to work with Take and the innkeeper, the sales rep is talking to Goowey, Helpdesk is making phone calls, and everyone is busy in little groups. Every fifteen minutes or so, someone walks up to the white board — which is really a piece of bark from a very large birch — and takes off a feature.
“Take, how can they just take off features at will, shouldn’t there be a Tackle Master to decide on that?”
Take laughs, and laughs, then rolls over laughing. Goowey says
“What? Dear Unhappy, you must have been unhappy for a long time. We work on the features that we think suit our skills best, the ones that we think we’re best equipped to make, that we like most, and that fit our schedule. We never argue, we all have different skills and preferences. You saw it yourself, you and Take are programmers, you got two features to work on, Take took two also, you were both happy, and you both finished your features in record time. I worked with you on a number of things I know I am good at, Take worked with Dewey who is good at other stuff than I. Now we work in different combinations, because we have different tasks at hand. Don’t you think that makes sense? Or rather, don’t you think we are having a lot of fun?”
Unhappy needs to think that over. How is the amount of fun you have a measure of how well the project is going? But he must admit, he has coded more lines in a few hours than he has ever done in days. Goowey seems to be happy too, working closely with programmers, and letting programmers in on making decisions on screen design. Then he realizes that he has asked Goowey a few questions about the code. He has actually let Goowey in on the coding part. Not in creating actual code, but on a more abstract level, how to make the code fit the design. Then he sees the innkeeper and Helpdesk talk to Take, who is typing code so fast you hardly see her fingers. They seem happy with what comes up on the screen. Slowly, Unhappy comes to realize that what is happening here is a better way to create software than what they do back home. He gets a say in how to make the screens work so that users are happy, Goowey listened to him, worked with him, and the Inkeeper is not a person that you plan meetings with once every two months, she’s happy to participate. Unhappy now appreciates Helpdesk and his twenty year task of helping people use the app, and the sales rep who will have to sell it to the dwarfs in the wood.
But then, with all these people involved, isn’t this an expensive way to work?
“No”, says Take. “We have some kind of budget, but it’s flexible. If it takes more, it takes more. If it takes less, it takes less.”
“Who makes those decisions?”
“We do. You do. I do. If you think we need something, we’ll get it. Same for all of us. Our assignment is an app, one that works, one that is received well, one that doesn’t break. Nobody tells us how to do that, or what the app should be like, because that’s what we’re supposed to know”.
That, Unhappy needs to think about for a while.
At the end of the afternoon of the third day, Helpdesk holds up a phone, and shows the group the final result. Take smiles. Innkeeper is happy, receiving the phone from Helpdesk in a would-be ceremonial way. Sales applaudes. Unhappy is still confused, about this project that should have taken a month, but was done in three days. Then the beer comes out, Unhappy is unsure of what happened after that.
The wizzard smiles at the unhappy programmer.
“Did you like the story?”
“Yes, of course! I liked it a lot. What Take and her team did was so much better than what we do. In your story, everyone in the team is valued, they all get a say in the project, they all get a chance to excell in what they are good at. Even the ones who aren’t the best in their field, I imagine that working in a team like that will make them the best in record time. Who wouldn’t like to work in a team like that?”
“My child, you have fully understood the story. The more you work with one another, not against one another, the better. The fewer the barriers between programmers, designers, sales, owners, helpdesk, and what have you, the better the quality of the product, the faster it is done, and the happier everyone is. Don’t you think that being happy working makes your code better? Don’t you think that the happiness of a programmer and the beauty of the code created, are the same thing? Don’t you think that goes for everyone? For the designers, the supporters, the owners, and even the concierge?”
Our not-so-unhappy-any-more programmer looks at the wizzard. It gradually dawns to her what the story means, what the wizzard is trying to say to her. If a team manages to get the best out of all participants, the product gets so much better. If members of a team, whatever their job, each have a responsibility for the project as a whole, for the budget, for the timing, for everything, if everyone gets to make decisions, people are more happy and code gets more beautiful. Our happy programmer’s head is spinning with these thoughts. They remain silent for a while, the wizzard smiling, the programmer spinning her head. Then she looks up. She’s terribly late for the meeting at the open spot.
“Dear child, I see what you think. I am a wizzard, you know, I have done two things. I put us back in time, you will be in time for your meeting. Also, I have put a charm on you, so when you get at your meeting, you tell the story about the Unhappy Programmer, they will understand. It is your one chance to make your project better”.
“Wizzard, thank you so much. I’ll always keep you in my mind. Thank you. There’s one thing I’d like to know. How do you know this story? Who told it to you?”
“Dear child, the Unhappy Programmer in the story, it was I”.
In the nineties, I was starting to do freelance work as a programmer, and as a management consultant. Before, I had worked at a company named BSO (don’t google for it, google for “Eckart Wintzen” instead), also as a programmer, AI engineer, and management consultant. I had multiple shelves with management books, some were ok, most were boring. When in 1995 a book came out with the title “The Knowledge Creating Company”, I bought it, and I read it in one go. It changed my thinking about knowledge, about innovation, about project management, about management in general. It is the one book that I would recommend to read for anyone in any business. The authors Ikujiru Nonaka and Hirotaka Takeuchi set off to find out why Japanese companies at the time were so much better at innovation than both US and European companies. They found that delegating responsibilities to a team is key to the success of that team, and thus of the product they create. Do read the book. Or read the the article by Nonaka in Harvard Business Review here.
Around 2000, I started a company that made software for email encryption and signing, Izemail. There were six of us: me, a sales person, and four programmers. We rented an office, I bought computers, and I bought an espresso machine. We set off programming, we called potential customers, we came up with a feature list, we decided that we’d have a major release every six months, a minor release every three months, and maybe a tiny release every six weeks. The feature list was just a list, programmers would pick the feature they though they could do best, or they liked most, or they thought customers would love most. I didn’t order the list, I just kept telling everyone what I thought was important. They would listen, or not. Which was ok with me. Same for the sales person. When a release was created, one of the programmers would announce a feature freeze, build the system, and start testing procedures. If your feature didn’t make it to the freeze, no problem, there will be another release in three months.
Every morning we’d come in around nine, the first person arriving would switch on the espresso machine, we’d start our laptops, read email, then fifteen minutes later we’d find ourselves in the little kitchen, for coffee. That was the time of day that Wiebe would say “hey, I’ll be working on this feature today, but I could really use some help”. Or Igor would say “I need feedback on a complicated encryption feature, I want Christine and Martijn to have a look at it.” Mathijs would remain silent. He was working on a big UI feature, with not much relation to everything else, he’d only call us in in his cubicle for a demo every other week or so to show us the beautiful stuff he’d made. Sybren, the sales, would come up with some new features, from phone calls with customers, and Peter would offer to talk them over.
Then coffee time was over, it took only fifteen minutes, and everybody went to work. We never decided on these espresso meetings at nine thirty, standing around the coffee machine, discussing yesterday’s work and today’s work. They just happened.
In 2009, I was doing some work on an app. We were making a splash screen and a menu screen. On iOS they had something that looked nice and worked nice, but on early Android phones, screen sizes were different, screens weren’t so good, and I didn’t manage to get the graphics, derived from the iOS version, right. So I went to the graphics designer, and explained to him. I wanted both a landscape version and a portrait version, something that showed the logo’s and menu in the right proportions, but that would still show a good gradient on different phones. We talked about putting in different layers, he told me how it should look, I told him what I could do, he gave me new graphics, I put them in the app and showed him, again new graphics, again in the app, and after about an hour and a half, we had wat we both aimed at. He was happy with how it looked, I was happy with how it worked. I listened to him, he listened to me, we had a perfect result in record time. I hope he remembers these one and a half hours as well as I do.
In 2010, I was working as a freelance programmer. In all projects I did, they were doing Scrum, with daily standup meetings, Scrum poker meetings, and everything that comes with Scrum. I started to hate that, because it felt awkward, it felt like wasting time, I thought it was utterly useless. In my experience, if you put the right people together, and let them just do what they do best, you get excellent results. I learned that at Izemail, I learned before, at Tryllian, were we used Xtreme Programming before anyone else did.
I decided to read up on Scrum, I bought all books I could find, looked up my Xtreme Programming books, and I read. There was one paragraph that enlightened me. I didn’t notice it when I went though this book the first time, but on reread I saw.
The rugby metaphore in Scrum comes from “The Knowledge Creating Company”.
I dropped the book, closed my eyes, and I sat thinking for an hour. Finally, I understood. If Nonaka and Takeuchi are at the roots of Scrum, then I knew what Scrum was supposed to be like. Also, I saw how Scrum had gone terribly wrong. And finally, I saw how and why it had gone wrong.
Suppose, you’re Picasso, and you want to teach a group of young artists how to paint. There are two things you can do. Either, you put them in a class room, tell them how you break up the process of creation of a painting, how you do first the background then the colors, or whatever a person like Picasso would say or do. You write a ton of books on how to paint a Picasso painting. Or, you take them on a walk, show them the woods, the meadows, the mountains, the sunset, the colors in nature, and you talk about the beauty of it all. You don’t tell them what to do, but rather you show your vision, your enthousiasm, and you keep asking them questions. Or, as the saying goes, if you want a person to build a boat, don’t teach them how to build a boat, teach them love for the ocean instead.
Scrum — and “Agile” in general — broke when people started to write books about them. It broke when people went to Scrum training. It broke when it turned from a brilliant idea into a simple recipe everyone was supposed to follow.
I cannot un-break Scrum.
But you can.
References
