Agile | Processes and tools aren't evil

The Agile Manifesto clearly states Individuals and interactions over processes and tools, better known as People over processes.

Many people I talk to interpret this definition as follows: Remove all processes and tools and base everything upon excellent communication and interaction between all parties. Processes and tools equals clutter, waste, too much noise...

Is that was is meant by 'People over processes'?

Not really, the word OVER is very important in the above definition and often misinterpreted. It means that communication and interaction are prefered OVER processes and tools. It doesn't state they should be used INSTEAD OF. There is a clear difference between both.

Let me explain...

In a healthy organization both are important and they shouldn't be treated as opposites. The process should be there to serve the people and if they become to bloated they should be fixed so that the roles do not turn around. If you look at methodologies like Scrum, Lean or XP they clearly state you should have processes, having processes is part of a good methodology and you have to grow them within your organization, constantly monitor and improve. A process you have today will probably be unproductive within the year, things change within the organization, so should your processes. But process optimization only works when people communicate and interact often.

You can talk about riding a bike from A to B but at the end you'll still need the physical bike to get there. The bike serves the person, the person doesn't serve the bike.

A while ago I found an article where someone rephrased the definition as Humans over robots.

Humans over robots, that says it all doesn't it, the message is so much clearer. Humans and robots can and should work together, but the robots are there to serve the needs of the human.

Crush ... kill ... destroy

Simplicity and why it matters

As our daily lives have become more complex, more and more people incorporate simplicity into their lives. But finding simplicity in the workplace seems harder these days, not easier. Professionally people are terrified of being simple for fear of being labeled a lightweight. So "when in doubt, add more" is often the guiding principle.

There is a fundamental misunderstanding of simplicity and what it means to be simple today. Many people confuse simple, for example with simplistic and simplism or that which is dumbed-down to the point of being deceptive or misleading. "Simple" to some people means necessarily a kind of oversimplification of an issue, which ignores complexities and creates obfuscation and outright falsehoods.

Simplicity is one of the key ideas in Zen. Arts like tea ceremony and haiku, which can take many years, or indeed, a lifetime to master. These is nothing easy about them, although when performed by a master, they may seem beautifully simple.

So simple refers to being essentially, synonymous for clarity, directness, subtlety, essentialness and minimalism. Something that has been incorporated most clearly with the user experience designer at, especially compared to the people of Microsoft (Gmail versus Outlook). The simple solutions are not necessarily the easiest for them, but results may end up being the "easiest" to use for the end user.

But there is one catch, while trying to create a simple solution it is possible to make it "too simple". Simplicity is the goal, but as Einstein said "Make everything as simple as possible but no simpler".

The problem of simplicity is present at all levels of life. Look at my day job as a software engineer, where you need to try to build a solution that has a short time-to-market period but still it needs to be one that has be designed in such a way that you can cope with change, cope with upcoming specs, cope with change in technology. As an advocate of Lean, Agile and eXtreme Programming I can feel how ever changing software specs are leading us to think about simple design instead of designs that are thought to stand the test of time ... because they never do.

Yagni (You are not going to need it) and Kiss (Keep it simple and stupid) and baked in the way of doing XP. By constantly asking ourselves whether or not we are going to need it, whether or not the specs are really frozen or if they are only 'ideas', thoughts of an optimistic future.

Because our job as a software engineer is supposed to be an 'intellectual' one, one of high expertise in building unbelievable enterprise designs that can stand the test of time, we are supposed to build complex architectures, because... that is what we do. But in reality the only thing that matters is getting your application shipped asap, released very often and having a team / methodology that can cope with extreme spec changes (.i.e. Scrum), technical design is most of the time not even an issue.

Abstractions are often the first signs of an 'evil design'. Take for example the next example. On a project I recently started working at they had designed an application which was backed by an ESB (Mule) for facilitating enterprise messaging, nothing wrong with that all services where nicely designed within the concepts of SOA but instead of just using the ESB they have wrapped it with their own abstraction so that they could plug in our out different ESBs. Sounds nice but reality and years of experience teaches us that this abstraction is pointless because technology changes so rapidly that when you come to the point where you really have problems with that particular ESB, you are not only going to change the ESB, but also the technologies surrounding it and in most cases it is just going to end up as a completely new project because the company's new technology guidelines advice even to use a new programming language (who says we still be doing ESB / SOA) ... "time has moved on" is what the Gunslinger in the "dark Tower" series would have said.

Get started, design something simple, push it to the customers asap and stop thinking ahead, you'll never get it right the first time.

This brings me to whether or not I'll be able to accomplish simplicity at my Devoxx presentation. Time will tell I guess...