How to create a good checklist
Mar 16th, 2012 by Joca

I already mentioned about “The Checklist Manifesto” book in two previous posts, one explaining how important it is to use checklists, and another one on using checklists to deal with the unexpected.

In this post I’ll reproduce some of my highlights from the book. These highlights provide advice on how to create a good checklist:

Pilots nonetheless turn to their checklists for two reasons. First, they are trained to do so. They learn from the beginning of flight school that their memory and judgment are unreliable and that lives depend on their recognizing that fact. Second, the checklists have proved their worth—they work.

There are good checklists and bad, Boorman explained. Bad checklists are vague and imprecise. They are too long; they are hard to use; they are impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on. Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything—a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps—the ones that even the highly skilled professionals using them could miss. Good checklists are, above all, practical.

No matter how much thought we might put in, a checklist has to be tested in the real world, which is inevitably more complicated than expected. First drafts always fall apart, he said, and one needs to study how, make changes, and keep testing until the checklist works consistently.

The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.

You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off—it’s more like a recipe.

5 people like this post.
Restriction driven simplicity
Jan 20th, 2012 by Joca

I just returned from vacation and was reviewing some photos in my cel phone when I found some old photos from a previous trip to SF. In the airport there was an exhibition about TV sets and some old remote controls got my attention. Here’s a picture of them:

Old TV remote control

Old TV remote control

Checkout the number of buttons in the remote control. The maximum is 4. There are some remotes with only one button. When I was a kid I remember the first TV bought in my house with a remote control that had only 2 buttons, one for volume and other for changing channel. That simple! That was around 1975. At the time, the technology for making a remote control was too expansive, so it could not be too complicated and have too many buttons, otherwise it would be too expansive to be sold in the market. That was the restriction that drove the simplicity of those 1st generation remote control. Now we don’t have that restriction and we get remotes that can accomplish much more tasks but are way more complex. Take a look at the picture below (and I even picked a not-so-complex one!):

Digital TV Remote Control

Digital TV Remote Control

So maybe next time we want to design something more simple, we can think of imposing some restrictions to the design process! :-)

4 people like this post.
Using checklists to deal with the unexpected
Jan 2nd, 2012 by Joca

I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.

I was reviewing my Kindle highlights for this book and found this highlight:

Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.

But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.

Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:

It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.

The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.

So next time you design a checklist, remember to include not only task checks but also communication checks.

3 people like this post.
Leading is similar to being a doctor
Apr 27th, 2011 by Joca

Those who has been following my posts know that I like to borrow ideas from medicine and relate them to software development an management. Below are two posts that make comparisons between medicine and software development and management:

The surgery

By the end of February/2011 I was submitted to a cervical spine disc replacement surgery like the one shown below (it’s just an animation with no actual blood):

The result is in the x ray images below:

frontal x ray

frontal x ray

x ray side view

x ray side view

The doctor did the surgery on February, 25th. However, the healing process will take months. According to the doctor, it can take one year until all the symptoms that motivated the surgery disappear.

The comparison

What caught my attention is that the surgeon only did an intervention but all the healing process is done by the body. The same happens when a doctor prescribes a medicine, which is also an intervention, but again is up to the body to actually heal itself.

Leading a team is quite similar. The leader should do some interventions when necessary but is up to the team to do the work in order to get to the goals.

Agile leadership

Leadership is topic that I really enjoy studying and discussing. It’s one of my top topics in this blog with more than 40 posts so far. And I already discussed about agile leadership in some of these previous posts:

In one of my reading session on leadership I found an interesting comparison between leadership and gardening made by Jurgen Appelo, who writes frequently about agile management:

I often compare managers to gardeners. An unmanaged garden is typically full of weeds, not beauty. From a biological perspective, there’s no difference. Either way, the ecosystem in the garden is self-organizing. It takes a gardener (authorized by the owners of the garden) to turn an anarchistic garden into something that the owners will enjoy. Likewise, it takes a manager (authorized by shareholders) to steer self-organizing teams in a direction that delivers value to the shareholders.

Even though I like this comparison, it considers that the gardener/manager has to constantly interfere, which I don’t believe is an appropriate behaviour for a manager. In my view, a manager’s interference should be done only when needed and, after the interference, the team should work by itself to solve things out with little or no intervention by the manager. Hence my comparison to a doctor who interferes only when needed by prescribing change of habits, medicine, physical therapy and / or surgery and who let the body do the work and be in charge of the healing process.

Next time you are in a team, either as part of the team or playing the role of leading the team, think about the leadership role similar to the doctor and the team work similar to the healing process carried out by the body. It helps understand the roles and responsibilities.

3 people like this post.
Agile management
Mar 4th, 2011 by Joca

When we implemented agile methodologies at Locaweb, the same way that some developers asked to leave because they were not willing to adapt to some of the agile principles that we decided to embrace, some of the existing managers also didn’t adapted well to the changes in their roles and responsibilities and asked to leave.

At the time, I discussed this topic with people from other companies and they mentioned that it’s not unusual to have developers and managers leaving the company when moving to agile. I remember even someone mentioning that in average 10% of developers leave. That was back in 2007 / 2008. I’m not sure if this tendency have lowered lately, since agile is becoming more and more mainstream.

I also read – and continue to read – a lot about the topic. One of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.

Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.

He also provides Agile Management courses that seem to be quite interesting:

Checkout also his presentations on slideshare. Checkout this presentation on authority and delegation:

Other posts about the same topic:

1 person likes this post.
Interesting stuff
Feb 19th, 2011 by Joca

  • Customers shouldn’t be the ones who define your products; they should be the inspiration for your products definition. (via @sjohnson717)
  • In general I think that anger is a sign of weakness and tolerance a sign of strength. (via @DalaiLama)
  • Very good article by @simonsinek: Good Marketing vs. Bad Marketing – http://bit.ly/f4kuna
  • …people spend most of their time either jumping to conclusions or else taking no notice at all of facts. (via http://bit.ly/guRxQw)
  • Different modes of behaviour on the part of the wise are to be regarded as due to differences in individuality, not of quality. (via http://bit.ly/guRxQw)
  • Anyone “software professional” who is not humble about the software business is is not actually a professional. (via @JerryWeinberg)
  • Really beautiful REAL Google Earth FRACTALS! But missing Brazil though… http://bit.ly/hja6PX (via @cristobalvila)
  • Interesting notes on entrepreneurship: http://bit.ly/dNS8ga
1 person likes this post.
Under pressure
Feb 7th, 2011 by Joca

Jason Yip just reminded me about the “under pressure” situation:

When people are pressured to meet targets they have three ways to respond:

  1. Improve the system
  2. Distort the system
  3. Distort the data

Fonte: Jason Yip’s blog

Yip is reading what seems to be a very good book on variation, Understanding Variation: The Key to Managing Chaos. In this book the author Donald J. Wheeler, according to an Amazon.com reviewer, “provides managers a rational way to look at daily, weekly, monthly, and yearly figures and tell whether the actions they take have resulted in improvement”. It seems to be a very interesting book from what Yip’s been posting:

Understanding Variation

Understanding Variation

Well, another book for my future reading list. Hopefully it will have a Kindle version soon.

Under pressure

Going back to the “under pressure” topic:

When people are pressured to meet targets they have three ways to respond:

  1. Improve the system
  2. Distort the system
  3. Distort the data

Fonte: Jason Yip’s blog

That’s a good way to see the possible outcomes of a group of people under pressure.

I like to use balloon as a metaphor to help understand under pressure situations.



Here’s why:

  • there’s pressure from inside and from outside.
  • pressure from inside and from outside needs to be balanced.
  • to much pressure from the inside or to little pressure from outside and balloon explodes.
  • to much pressure from the outside or to little pressure from inside and the balloon explodes unless it is one of those balloons where the more outside pressure it gets the harder it is to explode.

Lessons learned

  • There’s no such thing as “no pressure”. A group of people needs pressure from outside (the goal, the target date, lack of resources) as well as from inside (motivation) to exist and do things, just like a balloon.
  • Inside pressure and outside pressure needs to be balanced with some tendency to have a bit more pressure from the outside.
  • Under pressure, a group of people either explode or get stronger.
1 person likes this post.
The Checklist Manifesto
Jun 1st, 2010 by Joca

Se os checklists são úteis para médicos e pilotos de avião, por que não o seriam para operação de TI?

Dr. Atul Gawande escreveu um livro sobre o tema onde ele conta várias histórias sobre o uso de checklists. A argumentação para o uso de checklists é que qualquer ser humano falha, mesmo os mais especialistas.

The Checklist Manifesto

The Checklist Manifesto

No livro ele conta a história do Dr. Peter Pronovost, um especialista em cuidados intensivos do hospital Johns Hopkins em Baltimore. Pacientes de UTIs em sua maioria tem um acesso à sua corrente sangüínea por onde são ministrados os remédios. Esse acesso é chamado de cateter venoso central. Em 2001, 1 em cada 9 cateteres venosos da UTI do hospital Johns Hopkins acabava infectado, prolongando a permanência do paciente na UTI, piorando seu quadro e, às vezes, levando-o à morte.

Cateter venoso central

Cateter venoso central

Dr. Pronovost resolveu pegar emprestado uma rotina usada por pilotos de avião para garantir que tudo está ok para a decolagem, os checklists. Ao ser instalado um cateter venoso, há 5 pontos que devem ser observados:

  • lavar as mãos com sabonete bactericida;
  • limpar a pele do paciente com clorexidina antiséptica;
  • cobrir o corpo do paciente com tecido estéril;
  • usar máscara, chapéu e luvas estéreis;
  • colocar uma proteção estéril sobre o catéter.

Esses passos são muito simples e parecia ser desnecessário fazer um checklist, mas o Dr. Pronovost resolveu fazer uma experiência. Ele deu o checklist para as enfermeiras da UTI e pediu que elas ticassem cada item feito pelo médico e chamassem a atenção do médico que esquecia de fazer algum dos itens.

Os resultados foram surpreendentes: depois de um ano o índice de infecções em cateteres venosos centrais caiu de 11% para 0%. Dr. Pronovost fez as contas, dois anos depois a prática do checklist havia evitado 43 infecções, 8 mortes e economizado dois milhões de dólares.

Segundo o Dr. Gawande:

Nós admitimos que erros e descuidos acontecem – até mesmo alguns devastadores. Contudo, nós acreditamos que nosso trabalho é muito complexo para ser reduzido a um checklist.

Fica aí a dica do Dr. Pronovost e Dr. Gawande: será que não podemos usar checklist para as operações de TI?

Dr. Pronovost

Dr. Pronovost

Dr. Gawande

Dr. Gawande

Todo ambiente de operação de TI é sujeito a mudança: aplicação de um patch, mudança de parâmetros de configuração, instalação de novos softwares, etc. Essas mudanças podem ser controladas pelo processo de gestão de mudanças. E o checklist é o parceiro ideal para um processo de mudança eficaz.

3 people like this post.
The three ways of getting things done (hierarchy, heterarchy and responsible autonomy)
Sep 20th, 2009 by Joca

I just finished reading a very interesting book named “The Three Ways of Getting Things Done“:


by Gerard Fairtlough.


It is about hierarchy, heterarchy and responsible autonomy in organizations.

Gerard main thesis is that the human being is addicted to hierarchy and, because of this addiction, we are unable to consider other options for getting things done. He says that people organize themselves into groups (organizations) in order to get things done and since we are addicted to hierarchy, we believe this is the only way to get things done.

The first paragraph of the book:


The book explains not only why we are addicted to hierarchy, but also that there are other option to hierarchy besides chaos. He introduces two concepts:

  • Heterarchy: “is the divided, supported or dispersed rule where control shifts around depending on the project and the personality, skills, experience and enthusiasm of those who can make things happen. Much of the project work that is becoming common in large technology companies fits this kind of arrangement.”
  • Responsible autonomy: “an individual or a group has autonomy to decide what to do, but is accountable for the outcome of the decision.”

Hierarchy, heterarchy and responsible autonomy form the Thriarchy. Gerard says we should use a mix of the three forms of getting things done, instead of sticking to only one:

There are three ways of getting things done in organizations and the combination of the three is called triarchy, which means triple rule. The Three Ways of Getting Things Done: Hierarchy, Heterarchy and Responsible Autonomy in Organizations.When I was young I thought hierarchy was the only way to run organizations. Although in those days I’d barely heard of the great sociologist Max Weber, I unknowingly shared his belief that an organization couldn’t exist without a hierarchical chain of authority. Now, after over fifty years working in organizations of many different kinds, I’ve come to realise there are two other, equally important, ways of getting things done and that it’s vital for us to understand these other ways. We also need to understand why hierarchy always seems to trump the others.

Today almost all the organizations use hierarchy almost all of the time. According to Gerard:

There is good evidence to suggest that, in the 21st century, organizations are significantly changing the way they get things done. The result, triarchy theory suggests, will be a gradual move away from hierarchy in organizations.

Thiarchy has strong links to sociocracy, Peer-to-Peer theory, complexity theory and Spiral Dynamics.

It is a must read book on the participative management subject.

For those willing to read its first 2 chapter, you can use Google Books:

Be the first to like.
Previsões de leigos e de especialistas
Feb 10th, 2009 by Joca

Acabo de ler o “The Logic of Failure“, de Dietrich Dorner, professor de psicologia da Universidade Otto-Friedrich, na Alemanha.

A escrita tem um pouco de sotaque, dá pra perceber que é um alemão escrevendo em inglês, mas o livro é interessante. O subtítulo “recognizing and avoiding error in complex situations” explica do que se trata o livro, mas parece que o autor concentrou maior foco em “recognizing” e menos em “avoiding”. Uma boa avaliação desse livro, com a qual eu tendo a concordar, pode ser vista em:


This is the first half of a potentially excellent book. Dörner uses computer simulations (more or less sophisticated versions of Sim City) to test under laboratory conditions how real people solve complex problems. These are problems where the variables to be controlled are linked in a non-linear manner, and where new problems can arise as a result of solving the old problems. Real world problems, that is. And most people are pretty useless at it, too, with their well-meaning interventions soon driving the (simulated) populations into disastrous famines or recessions.

All these results appear to be based on detailed experiments and observations. But then Dörner presents a (to my mind) rather oversimplified and overgeneralised model of problem solving, and claims that people should follow this when tackling complex problems. What appears to be missing at this point is a similar set of experiments to validate this model. Where is the comparison of the performance of a control population, and people who use the model?

Sobre previsões de leigos e especialistas, ele comenta um caso interessante, dái o título desse post. Ele fala sobre como leigos e especialistas fazem previsões sobre alguma coisa (bolsa de valores, crescimento da economia, crescimento da população, inflação, etc.). Normalmente essas previsões são feitas tendo um conjunto de dados reais e extrapolando os dados para o futuro. Basicamente a diferença entre leigos e especialistas é que os especialistas conhecem mais curvas para usar na extrapolação. Por outro lado, leigos e especialistas são iguais no seu lado humano. Nesse ponto ele apresenta um cenário muito ilustrativo dessa questão humana. Imagine um especialista com a imcubência de fazer a previsão de crescimento da frota de carros de uma cidade. Agora imagine que esse especialista leva todos os dias 10 minutos para achar uma vaga para estacionar o carro quando vai trabalhar. Numa situação como essa é muito provável que esse especialista “puxe” sua previsão para baixo.

Be the first to like.
»  Substance: WordPress   »  Style: Ahren Ahimsa