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

Scrum | Story changes during Sprint

At the beginning of each Sprint the team commits to a number of Backlog stories which end up being the Sprint Backlog. Once the Sprint starts these stories aren't allowed to change, they are fixed, frozen until the end of the Sprint.

A frozen Sprint Backlog allows the team to focus on delivery instead of having to deal with change. Every change whether it is small or big is by default denied and placed on the Backlog so it can be prioritized and dealt with later. So what is delivered at the end of a Sprint isn't always according to the latests specifications. Short iterations cause these changing specifications to be implemented much sooner than later.

Or at least that is the theory...

In practice it can be up to the team to decide whether or not they can handle the change within the current Sprint iteration, just call it common sense. Some changes are small enough not to impact the Sprint iteration.

But what if business comes to you with big changes, very big changes? The team has committed to 6 stories (2 week Sprint). After 4 days business comes to you and tells you that 2 stories have been analyzed completely wrong (90% wrong), one of these stories the team has already started on. Even worse, if they implement it as-is it will have very negative impact on several upcoming tasks. What do you do?

In theory Scrum says all changes should be denied, we could do that. Practice teaches us to evaluate each change upon their impact. We can quickly conclude that the impact of these changes is a nightmare for the current iteration, so we deny the change, right?

Don't forget that denying them will cause a disaster upon upcoming tasks, what will you do? How sure is the business about these changes, or about the impact? The business has been wrong before, right? But this time they have truly done their research and it will make your life a living nightmare if you don't implement the new changes...

What do you do?
What do you do?

I know what I would do...

Scrum | Stop the blame

Today I want to talk about something that I find particularly common for teams that are adopting Scrum for the first time ... blame.

Let's start by defining blame:

"To blame is to hold another person or group responsible for perceived faults, whether these faults are real, imagined, or merely invented for pejorative purposes. Blame is an act of censure, reproach, and often outright condemnation. Blame is used to place responsibility and accountability for faults onto the blamed person or group."
-- Wikipedia

Key to the definition above is accountability something which you will also find in Scrum, but different. Accountability within Scrum means that not a person is responsible for failure but the team as a whole.

Like any team sport, you win or loose as team. Like they say there is no "I" in team. But reality teaches us that when we loose we feel the need to make someone accountable for the loss. Even worse, blame is basic to hominid behavior. Studies have showed that blame seems to be an essential part of human development. When language skills develop, one of the first practical things which can be done with them is to apply them to blaming others for one's own misdeeds, and getting them sanctioned, or punished, while one simply continues with more of the same.

So don't get all cracked up on the fact that your team start blaming during the daily stand-up or even worse during the retrospective after a 'failed' sprint. We can't help it, it is in our nature ... see, we can even blame the fact that we blame solely on being human :-D

So why is there no place for blame within Scrum? Actually for this we need to look beyond Scrum and look at its daddy called Lean. Key to Lean is waste elimination which is achieved by continuously trying to improve the process, also known as Kaizen.

Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work, and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

To be most effective kaizen must operate with three principles in place:

• consider the process and the results (not results-only) so that actions to achieve effects are surfaced


• systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view) in order to avoid creating problems elsewhere in the process


• and a learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent will allow the re-examination of the assumptions that resulted in the current process.

Blaming is wasteful, a simple truth but just because blaming is part of our nature so hard to achieve. So don't go expecting team members to stop blaming from day one but guide them into the magic world of getting things done like a team. Guide them towards spotting waste, guide them towards process optimalization and continuous improvement, help them to stop thinking about blame.

I make mistakes, I do things wrong, I don't know the answer to everything, but so don't you! That's life!

An example

During a retrospective a member of the team put up a post-it saying "Commitment?" and said "I think this needs no further explanation".

You kinda get the idea that such statements are not very constructive nor are they identifying waste = the real issue. So what should have happened and what was behind his frustration?

The frustration was actually caused by team members working on tasks in parallel, doing multiple stories at the same time. And by doing so they started blocking each others work, tasks depending on other tasks. And even worse the guy that had put up the "Commitment?" paper in the first place was working on multiple tasks in parallel, blocking a complete story and was not willing to give some of his tasks to someone else and by doing so unblocking the ongoing work.

Everyone in the team got frustrated because they could not proceed, and the one doing the multiple tasks was frustrated the most because he felt he was doing all the work. Causing him to sit behind his desk until late at night.

So during the retrospective he felt frustrated and blamed the team not being committed. Should he have kept quiet? Hard to say, yes and no. Because he was new to Scrum he could not really pinpoint what went wrong so yes I believe he was in his right to do so. But then it is up to the team members to react and explain what really had happened, not that he was blocking everything but that as a team they made bad some bad decisions upon dividing the workload on the task board.

During the daily, the moment everyone was grabbing the tasks he will be working on the team or at least the Scrum master should have reacted and warned about the fact that they were starting on multiple tasks in parallel ... so actually they failed as a team.

In the story above the person should have concluded that failure of the sprint was due to the fact of badly implementing Scrum, doing multiple stories / tasks in parallel and not the fact that there was no team commitment.

It isn't always easy to spot waste, nor process inconsistencies, nor is it to keep your emotions under control! A learning, non-judgmental, non-blaming environment in which we continuously try to improve ourselves isn't something we can achieve in one day, but by practicing Kaizen we take each day a little step towards this goal.

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...