Category: Uncategorized

There is an interesting development that I call the “Google Imitation Fallacy”. More and more companies try their best to make their employees’ breaktime a wonderful experience. They try to inject the maximum amount of fun and/or relaxation into those breaks. It began with simple things like gaming consoles and foosball tables, but now, companies are building whole playgrounds in their offices. I see reports about this on TV every now and then, and everyone goes: “Oh, wow, what a great company!”

Don’t get me wrong – that is not a bad thing! A fun break is better than a boring break.

The problem is that many companies seem to confuse “enjoying your breaks” with “enjoying your work”. But these are completely different things. Sure, a great fun and relaxing break can radiate into your work. It can help you free your head, it can help you be more creative, it can lighten your mood. But if you hate your work, then at the end of your break, you will still go “Oh no, I don’t want to go back to my desk!” Nothing you do during your break will change that. Nothing at all.

Giving you a lot of breaks and filling them with activities is, after all, strictly extrinsic motivation. And extrinsic motivation is lazy motivation. It is easy for the company, because all the company has to do is spend some money. Sounds difficult, because money is something a company is not supposed to waste. But it is so much easier for a company than thinking about how to motivate employees intrinsically. Giving people interesting task, allowing them to self-organize, giving them the opportunity to improve their skills and to respect themselves, their work and their team mates – that is incredibly difficult. It actually means that people managers have to do their job as opposed to just pulling some money out of their budget. Motivating people intrinsically is really hard. Spending a few thousand bucks on the other hand – that is comparably easy. And lazy.

So once again, It is great for employees to have fun during their breaks, but it should not be a replacement for intrinsic motivation. It should not even be a companion for it. It should come only after management has really thought about what they can do to make their team members enjoy their work.

Otherwise, fun breaks (like all types of extrinsic motivation) become the equivalent of the little food samples you are sometimes offered at supermarkets. The strategy there is that after you get a “free” sample, you feel obliged to buy the product, even if you did not like it all that much. And later, you regret it. If you are a manager, do you want your employees to work for you because they feel obliged to do so? Or do you want them to work for you, because they actually want to work for you? And what do you think will yield the better performance and the higher amount of creativity?

Companies should not try to be “cool like Google” by installing swings and slides in their offices, but by actually thinking about how to really motivate people, and managers need to understand the difference between enjoying your breaks and enjoying your work.

I have already mentioned the concept in a previous post: In Agile coaching, people often speak about the Shu Ha Ri – a theory coming from martial arts about how people learn new skills. First, a set of rules is introduced (Shu), then people learn to apply these rules properly to their given situation and possibly to “bend” them, where necessary (Ha) and finally, they understand how to grow beyond the rules, how to live the “spirit” of the rules without even thinking about them.

It seems that in introducing Scrum, there is often a focus on the Shu part. The rules are introduced as strict laws. Fairly little reasoning is given for them. The goal is to establish the rules and to achieve improvement e.g. in performance or quality through whatever benefits Scrum provides. And obviously, Scrum does provide benefits, even if the Scrum team does not understand anything about the agile principles behind Scrum and the greater framework of thoughts and ideas that Scrum is embedded into. Early testing will increase quality. Frequent retrospectives will lead to constant improvement. Iterative work will allow the team to fail fast.

However, I believe that this “Shu-focussed” approach can lead to Scrum implementations that go down a completely wrong path – abominations such as Scrumerfall or tailored Scrum versions that omit the parts which are good for the team and focus on the parts that look good to management. Also, a Shu-focussed team would end up going through the motions of implementing Scrum as a process (which it isn’t) instead of working towards a goal that goes beyond being able to say “We are doing Scrum”.

So in my opinion, just understanding the Scrum rules is not sufficient. The rules are simple. The Scrum guide explains the rules in quite a bit of detail on twelve pages, though I am sure it would be possible to squeeze them onto one page and to learn them in less than ten minutes. So the complexity of the Shu part is quite low.

Consider examples like the games chess or go. The rules for both games are extremely simple and would also easily fit onto a single page. But if you study the rules for chess, you still will not be able to play a very meaningful game of chess. You need at least a basic introduction to the many other considerations that transcend the rules – a few simple openings, general strategic considerations and end game strategies. You need to get an idea of what the Ha and Ri look like before you really get what the game is all about. And I believe it is the same with Scrum.

So it is not enough to just teach people the rules of Scrum or to give people a rough idea of agile principles. I strongly believe it is necessary to motivate Scrum and other agile approaches beyond the pure rules and to at least give people are rough idea of what can be achieved with Scrum beyond just a higher performance.

If someone is needlessly dogmatic when dealing with frameworks like Scrum, it indicates in my opinion that they are still stuck in a Shu mindset and have trouble moving on to the Ha and Ri stages, where instead of blindly following a rigid set of rules, they would learn to apply the rules according to the given situation or even to transcend them and to go beyond a lazy copy&paste implementation of the Scrum Guide.

In motivating Agile and when discussing with people skeptical of Agile, I believe it is always important to clearly distinguish between complex and complicated problems as defined by the Cynefin framework. Just in case you are not familiar with Cynefin, to put it in very simple terms, complicated problems have a fairly predictable cause->effect relationship and the same course of action that has worked once (“best practice”) will usually lead to nearly the same result again and again. In complex problems on the other hand, the relationship between cause and effect clearly exists (otherwise, they would be a chaotic problems), but it can only be deduced in retrospect. These problems are best solved by probe-sense-respond approaches – the kind of tight-iteration and frequent feedback approaches proposed by Agile.

Obviously, software development is a complex problem, as the cause and effect relationship cannot be fully predicted in advance, as anyone knows who has ever had to debug a program that definitely did not do what it had been predicted to do.

But I have often heard arguments against Agile, stating that certain difficult problems are solved quite well by “waterfallish” approaches, and this is seen as proof that a waterfall approach will also work for equally difficult problems in software development.

However, using the informal colloquial word “difficult” lumps various types of problems into the same category. What these problems have in common is that they appear to require a high amount of specialized skill and that many things can go wrong when they are solved – both of which is true for complex and complicated problems.

One example that I have heard is the building of a house. The argument is that a house is built based on a predictable time schedule, using a blueprint that was developed by a skilled architect. If a “difficult” task like building a house can be done in such a waterfall-like approach, then this approach should also be good enough for software.

The only houses that are “simple” (in the Cynefin meaning of the word) to build are Lego houses built unchanged from instructions in the box, as the way Lego stones fit together is near-100% predictable. But beyond that, building a house definitely requires a high amount of various types of non-trivial skills. Beyond that, I fully agree: Building a house is indeed a difficult task.

But is building a house a complex task?

Well, it depends.

There are companies which build the same house again and again. They buy a patch of land and build twenty houses there, which are identical or strongly similar to houses they have built before. Then they sell these houses, move on to the next patch of land and do the same thing. This still requires skill. This is still difficult. But these companies have perfected the process to such an extent that it has become highly predictable. I would claim that this is a complicated problem. In most cases, the planning works out quite well for these houses (let’s ignore for a moment the people who every now and then still have to wait a couple of months for houses that are completed behind schedule). And I believe this is what people refer to who say “If it works for houses, it must work for software!”

But building software is not a complicated problem like building the same or similar houses again and again. A software project is hardly ever a copy&paste from a previous project.

And let us look at another type of building projects: Completely unique one-of-a-kind buildings. As soon as a house is not just a copy&paste from a previous building project, most bets are off when it comes to time and budget planning accuracy, and the more unique the building, the larger the deviations between planned and actual time and budget. Take an extreme recent example from Germany: The Elbphilharmonie. In 2007, it was estimated that construction would take three years and cost €241 million. In the end, it took nine years to build it for a budget of €789 million. Obviously, the usual approach with detailed pre-planning did not work out. Obviously, the builders were dealing with a complex problem here.

So the argument that what works for houses also works for software is meaningless, because the only cases where a waterfallish approach really works are complicated building projects. In complex building projects with many unpredictable aspects, it clearly does not work. And software projects are complex projects.

I believe this is a common pattern in discussions about Agile. Whenever a skeptic compares software development to other types of problems, we should first consider whether the other type of problem is really a complex problem or rather a complicated problem. Just lumping all difficult problems together and proposing the same kind of approach for them does not work.

Always worth watching:

RSA Animate: Drive: The surprising truth about what motivates us

I remember going to the zoo a few years ago and seeing a tiger in a huge enclosure who kept walking back and forth on a path of just a few meters. The tiger never left that path. It was just a constant back and forth, back and forth. My guess is that the tiger was previously locked into a much smaller cage, and then the zoo had built a large beautiful enclosure and transferred the tiger into it, but the tiger had been used to the small cage for such a long time that he kept tracing the steps that he had taken there his whole life, day in, day out.

I think that is a very powerful image, because it can be the same for humans. If I am used to a certain way of doing something for many many years, and then I am given new opportunities that are completely different, it is possible that I have no idea how to use these opportunities. No matter how beautiful this new world is, no matter how much I might have wished for a greater degree of freedom, I might end up not recognizing these opportunities as useful. I might think that they are silly or even dangerous. After all, I did well enough in my old cage.

When trying to give someone new opportunities that give them freedom beyond what they are used to, it is important to understand that they might be locked in their own Caged Tiger Syndome. It is important to have empathy and to understand that what is “common sense” to you is not necessary common sense to someone who has been stuck in a cage for way too long.

Often, I hear that people who promote Agile ideas and methods are viewed as “religious”. It is certainly important to ask ourselves why we could be perceived in such a way.

The most obvious answer is that I used the intentionally provocative word “Evangelist” in the title of this blog. But I feel (or hope) that it is more a statement of my intention rather than my attitude.

The more serious answer is somewhat more complex. It has a lot to do with how people are taught to perceive the world of software development. They are taught early on that you will get nothing but chaos and failure if you do not have a system in place where you pre-plan your work meticulously and where a hierarchy of managers tightly control the project’s execution. There are also many inherent prejudices such as “The customer’s requirements are always terrible”, “It’s the customer’s fault if we don’t understand what they want”, “We’re going to be blamed if something goes wrong”, and so on. Some of these prejudices might be derived from bad experiences, others are defense mechanisms to keep oneself from admitting own mistakes, and others might just be passed down from one generation of developers and project managers to the next. Either way, those prejudices together with the processes everyone was told to adhere to form a kind of box that is not easy to break out of.

Anyone who approaches this box from the outside with ideas that are completely different from what is inside that box will automatically be seen as strange. And the more fervently you start banging against the box, the more likely you are to look like a religious zealot.

Also, the other issue is that even with processes like waterfall that are not optimal, companies still manage to create and sell products. Projects overshoot their budgets, people have to work 80-hour weeks to meet deadlines, the customer doesn’t get what they expected and the software is buggy. But it still sells and the company manages to stay afloat. I call that “successful failure” (I am planning to elaborate more on that in the future), and there are probably many software companies that survive for many many years through a series of successful failures.

The problem here is that when people think of past projects, they like to think of them as successes, because they invested a lot of time and effort into them. Developers and project managers likely define their professional identity through whatever projects they have successfully shipped. So they prefer to see the positive aspects of their projects: They have managed to ship a product, earn money from it, and they have done so even in spite of immense difficulties. And let’s face it – such a glass-half-full attitude is not even the worst thing. But for someone who wants to introduce new methods, that is a difficult environment. Pointing out that previous projects were essentially failures is a dangerous thing to do when you are speaking to people who define themselves through their achievements in these projects. So that is another great way to come across as someone who is “out there” with “bizarre” ideas that have no connection with reality.

So don’t be surprised if you hear something like “But that is how we learned it, and we know it won’t really work any other way. And we have been doing it for 20 years, and look where we are!”

But it sounds like I am only looking for the problem on the “other” side. No, on the contrary. I think one issue is also that many proponents of Agile have had a kind of “agile epiphany” at some point in their lives – a moment or a series of moments where they had the sudden realization how Agile can actually work for them and how it can greatly improve the way software companies work. Such an epiphany is a great thing to have, but it tends to pull people away from others who have not had such an epiphany. And to be honest, it is very much akin to a religious experience. It can be difficult for someone who has had such an epiphany to develop the necessary empathy for people who are following another mindset. So many Agile evangelists can come across as extremely dogmatic without any understanding of other people’s points of view.

The end result of these three issues is that you end up with Agile evangelists who dogmatically tell people that everything they have previously learned is nonsense and that all their previous projects were failures. Now it’s not surprising anymore that such a person comes across as being religious.

So what is the solution? Well, I wish there was an easy answer. The short and overly simplistic answer would be: Don’t be dogmatic, be pragmatic. Don’t tear down old learnings but work on building new ones. Don’t focus on past failures but try to build future successes. Yes, that is easier said than done. And it poses a lot of questions, such as how you can actually motivate an agile transition if you have to tiptoe around the shortcomings of previous non-agile projects? So no, these three points can be suggestions, but they cannot be the full answer, and this topic certainly deserves deeper exploration.

There is one fitting response to the accusation of religious fanaticism though: If I compare Agile approaches with conservative approaches, then I feel people who believe that you can pre-plan a software project on a highly detailed level two years in advance are far more similar to religious believers, while Agile is much more built on empirical evidence and a healthy sense of realism.

I said in a previous post that in my opinion, Agile brings back a certain amount of creativity to the developers that I felt had been lost in a corporate environment. I wanted to elaborate on this based on a concept that I would call “Development for Fun” (DFF).

Back in “Ye Goode Olde Days™” when I took my first steps with software development, most people who chose to learn programming did so in a learning-by-doing self-taught approach and pursued programming as a hobby before transitioning into a professional environment and turning their hobby into a job. Nowadays, it seems to be far more common that developers get their first development experiences in classes (e.g. in high school or at the university). They never experience what it is like to code for fun, but right from the start, they do software development in an environment where they are told what to do and how to do it. They rarely experience the creative freedom that comes with self-teaching and with writing software for ones own enjoyement based on ones own needs and requirements.

But what is so special about “Development for Fun”?

Well, ask anyone how they write software when they do this DFF. I think most people will give a description quite similar to this:

1. Come up with a rough plan.
2. Start coding
3. As soon as you have something that can compile, you compile it
4. Fix compilation issues immediately.
5. Test the resulting software
6. Fix functional bugs immediately
7. Adjust your plan, if needed
8. Write another few lines of code, and go back to step 3

This loop between steps 3 and 8 is usually extremely tight in DFF. Often, you just implement one new function or one new method. In some cases, you might write only a single line of code before going back and checking how it affects your software.

Looks familiar?

This is the probe/sense/respond cycle that the Cynefin framework suggests for complex problems.

So when doing DFF, developers intuitively understand that when you are dealing with a complex problem, it is best to check back very often whether you are on the right path to fix problems and to adjust the planning. It is obvious common sense.

Of course, also when you learn coding in a class, you can make this experience. If your teacher tells you to implement a sorting algorithm by the next day, there is nothing that would keep you from doing the implementation in a tight probe/sense/respond cycle. The main difference is that when doing DFF, you are also collaborating very closely with the customer. In fact, the customer is sitting on your chair, as you are the customer. Customer collaboration can’t get any closer than that. So you not only have the freedom to change a line of code here and there, but you can also get the go-ahead from your customer to change the direction of the whole project based on problems and opportunities you discover during your work.

This is why I believe that DFF is a kind of basic model for agile software development. The only difference is that Agile approaches add rules to this model to make it compatible with working in a corporate environment, with working in a team and with working for an external customer. But the common sense core of DFF remains in Agile and is the key driver. And that is one of the great things about Agile: What was obviously undeniably common sense in DFF is not discarded in Agile but instead built upon. This is why I believe that Agile has the potential for also carrying over the creativity and fun from DFF into a for-profit development environment.

This is also something that developers need to understand. Agile is not supposed to be another management bullshit bingo term that will only create additional work and overhead for them. On the contrary – it is supposed to let them work in a way how they would most likely choose to work if they were given free reign.

Obviously, the name “Agile Evangelist” for this blog immediately leads to the question why would I want to go as far as “evangelizing” Agile, even at the risk of coming across as some kind of religious zealot, as that is the obvious connotation of “evangelizing”. I actually hate the word “Evangelist” for that very reason, but that is also why I chose it: Both as a provocative challenge to the reader and as a provocative challenge to myself.

So why do I believe that Agile is so important that I want to “promote” it by actually writing a blog about it?  A lot of people have very straightforward answers why they think Agile is important, which relate to how Agile is supposed to make teams more efficient, how it is intended to produce higher-quality software, how it allows customers to change their requirements in a controlled manner, and so on. But my answer is not all that straightforward. In fact, it is much more personal.

I started developing software in 1985. For many years, it was my hobby, or even my passion. I had finally found my creative outlet. Others could draw or sculpt or play musical instruments. I could develop software, and I did it well. I had no doubt that I would end up working as a software developer one day. That changed when I began to understand how software development works in an industrial environment. I felt that in common software development methods, creativity is largely suppressed, and the software developer becomes a cog in a huge machine. It reminded me of working in an assembly line. I stopped being interested in being a software developer then, and I ended up going first into the “research” branch of R&D and later into project management.

For a long time, I took for granted that development had to be done that way: as a heavily planned machinery. I realized that a lot of things about conservative processes such as waterfall are nonsensical – the detailed project plans, the arbitrary milestones, the late discovery of bugs, but I admit that I failed to see the alternative – until I heard about Agile.

While Agile seemed to avoid a lot of the aforementioned ridiculous aspects of old-fashioned methodologies, what impressed me the most was that it actually brought back the creativity that I thought was impossible to achieve in a corporate environment. Agile gives the software developer as much freedom as possible, respecting the developers as the experts on the subject, giving them the responsibility to plan their work (as opposed to being planned as a resource) while trusting them to understand the priorities and to make decisions in their development work in the company’s best interests.

This might sound overly emotional and positive, because of course, the developers are still constrained by business needs and should ultimately create a product that generates profit. So if you want to be cynical about this, you could say that this is still about cold hard cash and not about the developer’s well-being, but to me, the key difference is that in Agile, software development is seen as a craft and not as a commodity skill.

A goldsmith, a carpenter, a tailor or other people who work in a craft also have to create a product for sale. They cannot just create anything they want for their pure fun and enjoyement, but they have to work within the confines of their business, and their product needs to be markeatable. Still, I would claim that at the end of the day, a goldsmith, a carpenter or a tailor can look at what they have created with a sense of achievement and even pride. If software engineering is respected as a craft, then a software developer can experience the same.

And once software engineering is respected as a craft, everything else falls into place. Software developers will accept that they need to hone their craft and constantly improve themselves. They will take pride in their work and take pride in creating a high-quality product.

Agile provides the framework for respecting software engineering as a craft and provides the tools for honing this craft and for creating high-quality output.

That is what fascinates me about Agile: Now, a new generation of software developers can expect to work in an environment where they have room for creativity and where at least some of the fun and sense of achievement of hobbyist software development can be carried over into a professional environment.

I think that is a worthy cause.