In the early- and mid-90’s, I was working in AI and knowledge management, in a company named BSO, founded by Eckart Wintzen. One of the things I did was creating a method to calculate the total value of the knowledge of a large knowledge intensive company, KEMA. In their 1994 annual report, I wrote a paragraph on the value of the total knowledge in the company relative to the financial value of the company.
In 1995 a book came out, titled “The Knowledge Creating Company”, by Ikujirō Nonaka and Hirotaka Takeuchi. It was based on their article in the Harvard Business Review in 1991. Nonaka and Takeuchi wondered why Japanese companies at the time were so much more successful at innovation than American or European companies. They found the clue to be in the way knowledge is used in companies. They explain the difference between “explicit knowledge”, which is the knowledge that is written down in books and documents and web sites, and “tacit knowledge”, the knowledge that is not easy to explain in words, that is available in the minds of workers. This was a key finding, that matched my experience in knowledge projects that I had been involved in. It matches your experience in college: your physics professor had a ton of knowledge in their head that was not available online or in books.
Another key finding in TKCC is how to innovate: the best innovations are made by multidisciplinary teams involving every area of expertise in the company that have full responsibility and power to create a new product. As I was (and still am) a big fan of Tom Peters, the idea of delegating responsibilities to a team (“empowerment” as Peters calls it) struck a chord with me. And, as Peters wrote in all his books, you can’t delegate without handing the means and the power that come with the responsibilities to the team. Empowerment is key.
Between 2000 and 2010 I worked in AI, IT security and software development as an entrepreneur. In 2008 I went back to working as a software developer, as a freelancer. As Google had just introduced Android, I started creating Android apps for clients. That is how I was introduced to Scrum. Every single client I worked with used Scrum in their IT department. One of the clients sent me to a Scrum training. I read two books on Scrum. And I didn’t like Scrum. I think it’s a waste of time to spend half an hour every morning standing in a half circle telling your team what you did yesterday (which they already know because we discussed it when I was doing it) and telling them what I’ll do today (which, also, they already know). It’s a waste of time to spend a day discussing user stories and give story points for features that you don’t know much about yet. The biggest waste of time is that you create features in sprint N, after which you have to replace most of your code in sprint N+1 because of new features that require a totally different approach of the underlying software. It’s a waste of time to have a UI designer design “wire frames” and then when they throw them over the wall, having to go back to them and have them change the designs because of the way you want to implement them. It’s frustrating to have a lot of experience in creating apps, and software in general, but not getting a say in how to make them because a UI designer creates wire frames without your involvement. What’s also frustrating is that programmers sit in one room creating code, designers are in a different room on a different floor, and the “product owner” is in a different building. You can communicate online, but that’s not the same as sitting at someone’s desk and discuss their code or their designs. It’s not the same as having a designer tell you how they want it, then show it to them five minutes later and discuss.
I decided to educate myself more about Scrum. I read all books I could find. It turned out that some of the books I already had. Scrum refers to Xtreme Programming, which we practiced around 2000 in Java projects. And then I read a paragraph about where the word Scrum comes from. It comes from a rugby metaphore in my favorite management book. Nonaka and Takeuchi in their book TKCC compare a product development team to a rugby team: it’s not about the individual players, it’s about the team. It’s not about the person carrying the ball, it’s about the other players running elsewhere on the field, ready to catch the ball. Only a team that cooperates, a team in which one player can rely on all other players can win a game. If there’s no blind trust in your team mates, you’ll lose the game. Now I knew what is wrong with Scrum.
When Honda wanted to create a new small car, competing with succesful small cars from Europe, they did the following. They set up a team of designers, sales people, engineers, marketing people, financial people, kitchen sink people, everyone. They gave the team a space to work in. They gave the team a budget. They didn’t give the team specifications, other than “we need a small city car that will sell well. Come show it to us when you’re done.” Read TKCC for more details and more examples.
So imagine setting up your app project (or any IT project, or any project) in the same way. The board decides your company should have an app with which customers can explore products. They put a few programmers, designers, a marketing person, a sales person, a finance person, two product engineers (or generally, “people from manufacturing”) in a room (a space, a building, whatever). The assignment is “create an app for us. Come show us when it’s done”. The team gets a budget, they can hire additional people, they can do whatever they deem necessary for creating the app. Maybe they’ll do some market research. Maybe they’ll build prototypes or demos. Maybe they’ll talk for days on end. They may travel, attend conferences or training sessions. They’ll go for a walk. They may even publish a beta version of an app. They may invite the board to demo sessions for feedback. There is only one requirement: there is no hierarchy in the project. If the finance person has input to the UI design, their opinion is welcomed. Decisions are made based on knowledge and expertise. All team members have the lead in their area of expertise. It doesn’t really matter how they do it: if you put smart people in a room, they will emerge with a cool product. But they will only do so if all of them have a sense of involvement, if all of them know they contribute to the end product.
This is not how I see Scrum working in projects. I don’t even think this is how Scrum is supposed to work. Scrum is not based on empowerment. The UI designer has to do what the product owner tells them to do. The programmer has to make the code that fits the design made by a designer. The sales person is not involved in the project, nor is the finance department. The team does not know what’s at the horizon: they only know what needs to be done this sprint. If a sprint is just three weeks, the horizon is rather close.
When I learned that Scrum has its roots in TKCC and in Xtreme Programming, I realized I had been working along the same lines for many years already. Around 2000, at Tryllian, we used Xtreme Programming. A few years later, at Izemail, we invented our own daily standup accidentally. As seasoned programmers we were all coffee buffs, so the first investment I made in the company was an espresso machine. The person arriving first at the office would switch it on, in the next half hour we’d all arrive and have our first coffee in the tiny kitchen. This was the moment that Igor would ask Hes about a feature he was going to build today. It was when Mathijs would say he’d like to demo us something cool he made. Sybren would ask about a feature that a potential customer asked about yesterday. Martijn would write a new feature on the whiteboard. And after our second espresso, we’d go to work. When someone was done with a feature, they’d check the backlog, and pick a new feature. At three month intervals, Martijn would draw a line on the whiteboard, marking the features that would be in this sprint’s release. Peter would make a build, and start tests. We never had meetings, other than impromptu gatherings at the coffee machine when someone would start talking about an important architectural decision, or about a feature we didn’t have but dozens of potential customers seemed to want. Any one of us would pick up the phone when it rang, provide support to customers, provide info to prospects, talk to journalists, anything. This felt like the projects Nonaka and Takeuchi wrote about in their articles and book. This felt like how Tom Peters writes about empowerment. This felt like how Scrum was probably supposed to be. And it didn’t feel at all like how Scrum works out in reality.
Nonaka and Takeuchi don’t provide a time schedule of what should happen at 9am or 3pm. They don’t prescribe the roles and responsibilities of individual team members. They don’t say there should be a hierarchy in the project. They just say “put the relevant smart people in a room, then wait”. Peters says “whatever they come up with, it’s what the market needs”. Because they are the experts.
So here’s my advice for your next IT project (or any project). Put software developers (or engineers, or whatever type of project you have), designers, marketing people, sales people, a finance person, manufacturing people, everyone, in a room (or rooms, or a building, or whatever). Tell them what you need, in one short sentence. Give them access to resources. Empower them. Be available to them at all times. Then wait. They will amaze you.
The picture at the top says Ikiro, meaning “Be Alive”, by Takahiro Suzuki
The coffee machine in the picture is a Bezzera Giulia