Uncertainty

This came to my mind when I was watching this lecture, given by Ricardo Semler at the MIT Sloan School of Management, in 2005.

At some point in the lecture, Ricardo talks about intuition, and how intuition is very useful to solve problems, but still is not accepted in the corporate world.

In his words, talking about the chess match between Kasparov and Deep Blue:

How is it possible, at all, for something with 4 moves (Kasparov) to play something with 4.000.000 moves (Deep Blue)?

…. There is only one thing that he has that the machine has not, and that  is intuition.

…. Where are we putting intuition to play in the corporate world?

And this thought stayed in my head. Why the majority of people find it so difficult to accept intuition and to deal with uncertainty? In Ricardo’s words, why are we willing to trick ourselves and everybody else into thinking that we have control?

And why is this topic relevant to software development?

Because that’s one of the reasons that make agile methods so difficult to be accepted. Most people are not prepared to accept that the project duration can’t be precisely measured. Or that the scope should be flexible, because we still don’t know (oh my God!) what is important and what isn’t. And that the decisions we make should not be based on a complex function point calculation, but in simply in the team’s intuition?

Instead, they prefer to develop software in ways that have failed for many and many years, but still thinking on having control over all the project. They find easier to believe in an excel-calculated estimate for the total project of 170.1234hs than in an estimate that says “roughly 1 month”, and they hope to deliver software within fixed budget, size, scope and quality (good luck with that).

As Ricardo cited, it doesn’t matter if you are wrong, but you have to be precisely wrong.

Cheers

Don’t Blame The Prime Directive

I’ve been wanting to write this post for some time now, but just now I figured out what I wanted to say, so let’s do it!

What triggered this post was this article published in InfoQ, replied also in this other blog, about a discussion around the Retrospective Prime Directive, which, for those who don’t know, goes like this:

“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”

I don’t want to comment here the whole article, since it’s a big one (and you should read it) , but I just want to make some points about it (3, to be exact).

Number One

I sincerely believe in the prime directive, and I think that all the persons in the team should also believe in it, and not “pretend” to, as suggested by someone in the article. As Mary Poppendieck pointed (actually Deming and Juran) , when an individual is not performing as expected, most of the times is a systemic problem, and not related to that specific person. Before blaming and pointing fingers, people should look at the system, and try to understand why that person is acting that way. What she said:

“both Deming and Juran observed that when a worker made mistakes, about 80-85% of the time it was due to a problem with the system, not the individual. I have found this to be generally true. It’s not that individuals don’t get tired or sloppy, because they do. But a system that does not ever allow a worker to get tired or sloppy is a bad system.”

Number Two

Here at ThoughtWorks, usually before a retrospective, a safety check is performed. This practice ensures that every member of the team can say anonymously how comfortable he/she feel about to discuss any problem that may arise. If you have a major trust problem in the team, probably that will be shown in the safety check, and then the retrospective should not even start before addressing it.

And if everybody is comfortable talking about anything, then I don’t see why they shouldn’t discuss any specific topic, if that’s affecting the team’s performance and as long as the retrospective doesn’t become a blame game, with criticism and finger pointing. The objective should always to improve the team’s result. As pointed before, probably if someone is acting in a way that isn’t positive for the team, probably that someone has his/her reasons, and could benefit from hearing that he/she is affecting the team’s result.

Number Three

But if you believe that some member of the team is deliberately acting against the team’s objectives, with intention of sabotaging the result in some way, then your problem isn’t really the prime directive. The problem is in reality much bigger, and I don’t think the retrospective will help you to solve it.

Cheers.

“Tell me how you’ll measure me…”

Reading some posts on the web, I’ve found this one, written by Liz Keogh, which talks about perverse incentives, i.e. , situations when an incentive is given to reach some goal, but instead of helping, it works against the objectives of the people who proposed the incentive.

I agree with all Liz has said on the post, and while reading the post, I couldn’t help but thinking about something that was written in The Goal, a book I’ve read a while ago:

“Tell me how [and when] you’ll measure me, and I’ll tell you how I’ll behave”

I think this sentence says it all. People should be very careful when proposing ways to measure and (especially) evaluate persons. What they don’t realize is that the metric that is used will define how the persons will behave when trying to perform their jobs.

If you measure tests written, you’ll have lots of tests , if you measure number of bugs found, guess what you’ll have?

So what I should measure? How should I rate my employees? Well, that’s easy. The only metric you should use is the ultimate goal of your company or team, as broad as it can be. And that’s one of the reasons why I believe agile projects work, because the main metric that is always used, is the business value delivered to the client (ultimate goal, remember?).

I’m not saying that people can not use all kinds of metrics, like code coverage or any other, to develop software. I’m just trying to explain that all the other metrics, besides the goal of the project, have to be used as secondary way to see if the project is going fine. There is no benefit in having a 100% tested code, if you can not deliver any business value to the customer. What is he paying for?

So, as a last thought, when you are thinking about incentives, think with care, and make sure the incentives you are giving aren’t going to be perverse!

Good News!

Enough of this developer non sense! Here is the solution:

Introducing Mingle Proj-o-matic

Regards.

The Turning Point

As you may have noticed, with the language change (from portuguese to english), I decided to also change the blog’s name, since the previous one wasn’t saying very much.

The new name is based on the book I’m currently reading (and recommend), The Turning Point, by Fritjof Capra, which can be described like this (from Wikipedia):

It begins by outlining and tracing the history of science and economics, highlighting the flaws in the Cartesian, Newtonian, and reductionist paradigms. It narrates how such viewpoints have grown inadequate for modern technology and ecology needs, then argues that science needs to develop the concepts and insights of holism and systems theory to solve society’s complex problems.

Just to show you why I am really enjoying this book, here goes a sentence extracted from it (it has been already posted before, but it was in Portuguese, so I thought about translating it… free translation from the portuguese version):

“The complexity of our technological and industrial systems has now reached a point where many of these systems can not be modeled or managed. Failures and accidents occur with increasing frequency, unexpected social and environmental costs are continually generated, and more time is consumed maintaining and regulating the system than providing useful goods and services.” - Fritjof Capra - The Turning Point

Despite being from 1984, I think this specific sentence could be used to describe the vast majority of software development projects now in 2008 (just 24 years later), and that’s why I’ve chosen this blog’s title. Because I believe that the software development industry is reaching its turning point, the paradigm is changing (not as fast as we want, that’s true), and this blog is meant to be just another forum to discuss the new ideas being proposed (and also the old ones, when they are better than the new.. ).

Well, that’s it. Hope you enjoy!

Cheers.

Language change… (again?)

Well, well, well….

As you may notice in the future posts, this blog isn’t written in Portuguese anymore, and from now on, I will try to write all my posts in English. The reason behind this change is that I wanted to share ideas with a greater number of persons, and also because I realized that mantaining two different blogs would request much more time than I am prepared to spend doing it.

I’m sorry for changing the language (again), but you have to understand that this is a new blog, written by a new guy who just moved to a new place . Hope you don’t mind that I might have also a bad written english knowledge sometimes (still learning…). If you find anything wrong, please let me know!
As far as the brazilian public is concerned, I sincerely believe that all persons reading this blog can easily read english, so I don’t think they will be prejudiced. Hope I’m right!

See you next post!

Angels Orphanage

Esse post sai um pouco dos assuntos habituais do blog, mas nem por isso trata de algo menos importante. Pelo contrário, trata de um assunto muito mais relevante do que como desenvolver software.

Contextualizando, eu estou atualmente participando da ThoughtWorks University, em Bangalore, na Índia. Ontem, devido à inspiração fornecida pelo Roy, que é o dono da empresa (e tambem um cara excepcional), e devido a organização realizada por alguns outros colegas (aos quais eu sou extremamente agradecido ), nós fomos visitar o Angels Orphanage, um orfanato aqui da cidade, onde 70 crianças vivem em um espaço que deve ser um pouco maior do que os quartos onde nós costumamos dormir.

Essa foi a minha primeira visita a um orfanato, e também foi a primeira vez que eu percebi a alegria que pode ser proporcionada a essas crianças somente dando pequenos presentes, como uma bola de futebol, ou oferecendo um pouco de tempo e atenção durante uma tarde, como fizemos ontem.

De certa forma fiquei um pouco pra baixo por essa ter sido a minha primeira vez, principalmente pq eu venho do Brasil, um lugar onde também existem milhares de crianças nessa situação que eu poderia ter ajudado de alguma forma. Mas por outro, também fiquei contente por ter finalmente feito isso, e espero que consiga continuar e não ter que esperar outros 25 anos por uma nova oportunidade.

E se eu tiver sorte, espero poder influenciar alguma pessoa que venha a ler esse post, para que ela também possa vir a ajudar.

Um abraço.

Hello world!

Well, like the title says.. “Hello World”. Since this is my first post, I´m just writing to let you know I´m alive. Come back soon for some posts about software development, agile methodologies and other stuff.

Since I’m brazilian, I will be writing posts in portuguese and english. I hope you don’t mind!