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

Velocity, Capacity and Productivity

This topic comes from some discussions that went on in a mailing list I participate, and also between me and my flatmate, about how productivity should be measured in agile projects, and how is it related to capacity.

I wanted to write this post for some time right now, but today I’ve realized that somebody had already written about it, so I decided to give my opinion too :-).

I totally agree with Simon when he says that velocity is not productivity. As I mentioned in another post, one should be very careful when applying any measure, specially productivity measures, and capacity isn’t one of them, in my opinion.

One simple example that makes me reach this conclusion is bug fixing. If you consider capacity = productivity, how should you count bug fixing stories? They are certainly not adding business value, they are actually delivering business value that was supposedly already delivered, but you can’t deny that the team spent time fixing bugs, and that these points should be considered in the estimation and also in the team’s velocity.

Simon also wrote about how to measure productivity, or even better, how to say if a team is performing well. In his post, he wrote

I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.
…

Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day.

This topic was also covered by Martin Fowler in this post. As Martin said,

So maybe you can’t measure the productivity of a team until a few years after a release of the software they were building.

Despite understanding what both says, I find kind of difficult to specify the performance of a software development team if you link it to the revenue generated by the project. I agree that in order to obtain the best results, the considered system should be as broader as it can be (as Deming proposed).

But I also believe (along with Goldratt) that a team has to have a goal, and this goal should be very carefully considered, since it will drive all team’s actions when they are developing software. Including the client’s business in this equation makes it too complicated, since you don’t have any control in how the client is using your work to generate revenue, and as Martin said, it could take years in order to obtain a good result.

If a team doesn’t have a goal, how could it pursue its objectives? Which are the objectives? If agile is about constant and rapid feedback, should I receive feedback based on which criteria? What should the team try to improve when performing retrospectives?

In my opinion, if you have a client that is specifying which stories are more important to the project, and that is why it is really important to bring the client inside the project, at this moment should the measure end, on stories accepted, which will deliver business value (but might not, if for some business reason the software isn’t used anymore, for example).

Until this point a team has the conditions to change and adapt itself to get better results, and deliver more business value. After it, not anymore.

Cheers.

Quality of Life? Does it Exist?

Today I just want to write about some thoughts that came to my head after reading the InfoQ article about Scrum adoption in China.

The article itself is very interesting, since it shows the benefits (and also problems) that companies have had when adopting Scrum. But what triggered this post was the chart shown below, provided by one of the interviewed companies, when they were asked What’s the benefit that Scrum brought to your project, your company?

What this chart shows is that Scrum improved the quality of worklife of most members of the team. And I am writing about it because I think this is one of the aspects of agile methodologies that isn’t perceived as much as it should.

When you work with agile, instead of working alone, you work in pairs, instead of holding all the problems by yourself, you share it and discuss it, instead of working as an individual, you are part of a team.

And that makes all the diference from when you work in non-agile environments, sit alone in your cubicule and interact only with your computer during all day. That makes a diference in your life.

So, if you don’t want to try agile because of the productivity aspect, at least try it for the sanity of the persons working for you.

“Tell me how you’ll measure me…” (2)

Coincidence or not, after writing the last post, I’ve just received the InfoQ newsletter, which contains this article, about bonus distribution within agile teams. And what does it have to do with measures and incentives?

Well, if you want to have some great individuals, reward them based on individual performance, if you want a great team, don’t try to establish some weird criteria, and measure everyone’s performance based on the team result.

Like Mary Poppendieck cited on her book, distribution of bonus to an Agile team is like playing with dynamite.

Duas Cabeças Pensam Melhor Que Uma?

A fagulha necessária para a criação de um post surgiu na leitura de alguns posts por aí (como esse), que me fizeram lembrar de um assunto sobre o qual eu tenho vontade de escrever a algum tempo: programação em pares.

Uma das razões para eu escrever sobre isso é o fato de eu já ter experimentado a programação em pares em duas oportunidades, a primeira na minha empresa no Brasil, e a segunda agora na ThoughtWorks University, e nesses dois períodos eu tenho percebido muito mais vantagens do que desvantagens nessa prática.

Programar em duplas, embora possa parecer anti-econômico à primeira vista, resulta em código muito melhor, aumenta a produtividade dos desenvolvedores (que não tem tempo para ficar lendo e-mails e falando no msn) e, principalmente, propicia o compartilhamento de informações e habilidades entre todos os membros da equipe, um dos problemas abordados nesse outro post.

Por sinal, o compartilhamento de informações é auxiliado por uma outra prática, que é a troca freqüente de pares, o que é detalhado no artigo Promiscuos Pair Programming, de Arlo Belshee, que também incentiva uma terceira prática, que é de o driver da dupla (o desenvolvedor que está efetivamente teclando) , seja aquele que possui menos experiência no que está sendo feito, para que assim este aprenda novos conceitos o mais rápido possível. Citando o artigo acima:

Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels - and allow someone else to take over for his weaknesses.

E colocando o chapéu de desenvolvedor, para mim o principal benefício da programação em pares é um ambiente de trabalho muito melhor, e uma maior integração entre todos os membros da equipe. Faz diferença trabalhar ao lado de alguém, podendo conversar, trocar idéias e criar um relacionamento, ao invés de simplesmente chegar na empresa, sentar na frente de um computador e ficar lá até a hora de sair, sem falar com ninguém, como eu já vi em alguns ambientes onde eu trabalhei.

É claro que podem também surgir problemas na programação em pares, como é ressaltado nesse post, onde a troca excessiva de pares pode ser um problema. No entanto, ainda acho que esse e outros problemas podem ser resolvidos com bom senso, e os benefícios da prática são muito maiores.

Mas o que me incomoda um pouco (e também é uma das razões desse post), é que no Brasil pouco se tem falado sobre a utilização de programação em duplas. Em todas as listas e blogs que eu acompanho, essa prática era ressaltada a algum tempo atrás, mas parece que foi perdendo força aos poucos e hoje quase não é citada. Além disso, não tenho ouvido muitas notícias de empresas no Brasil adotando essa prática, ao contrário do que acontece no exterior.

Espero que eu esteja errado, e que as empresas estejam percebendo as vantagens de programar em duplas, e de como essa prática pode ser fundamental na formação de uma boa equipe de desenvolvimento de software.

Então, o que vcs acham, duas cabeças pensam melhor do que uma?

Abraços.

Empresas x Funcionários (Round 3)

O post de hoje surgiu de uma discussão que está havendo em uma das listas em que eu participo (round 1), onde o assunto principal é como as empresas devem lidar com a questão do conhecimento, ou seja, como fazer com que o funcionário (que pode ir embora a qualquer momento) não seja detentor de tudo o que uma empresa de tecnologia tem de maior valor: seu capital intelectual.

Como a lista é de métodos ágeis, vcs podem imaginar que o tópico esteja girando em torno da documentação, e de como ela é (é mesmo?) necessária para que a empresa não seja refém (esse é o termo sendo utilizado…) dos seus funcionários.

Essa discussão já gerou um outro post (round 2), onde o Flávio comenta como isso é ainda mais preocupante em pequenas (ou micro) empresas, que realmente não têm todo esse fôlego para pensar em grandes alternativas. Citando o Flávio:

Vejam, falamos de situação em que micro-pequenas empresas precisam sobreviver dia-a-dia ao mercado burocrático e sufocante que o governo provê… são raríssimas as empresas que conseguem parar, respirar, organizar e seguir adiante. É tudo feito sob-demanda.

Então, a solução, é claro, é fazer as “vontades” dos funcionários. Tornar a empresa atrativa para que estes se sintam satisfeitos e reconhecidos, e assim, permaneçam na empresa.

Realmente, eu tenho que concordar com o Flávio. Já tive a minha micro empresa e sei como é esse cenário que ele está descrevendo. No entanto, eu acho que a solução para esse caso é o mesmo do que para as grandes empresas (claro que um pouco mais difícil… )

No meu ponto de vista, realmente a empresa não deve se preocupar em se tornar “refém” dos seus funcionários, simplesmente pelo fato de que ela sempre o é. Eu não tenho dúvidas de que qualquer grande, média ou pequena empresa (de tecnologia), se perder grande parte dos seus funcionários, não terá mais como seguir competindo no mercado. Eu acho que a preocupação que cada empresa deve ter é de não ser refém de um ou poucos funcionários, porque nesse caso sim, a perda de um funcionário específico (o que pode acontecer com certa freqüência), é um grande problema para a empresa.

É claro que o primeiro passo para que isso não aconteça, assim como alguns participantes da discussão levantaram, é fornecer um bom ambiente de trabalho para todos que estão na empresa. Não acho que se deva ser refém do funcionário, nem fazer todas as vontades dele, mas sim respeitá-lo e valorizar o trabalho que ele está fazendo, e isso não passa apenas pelo seu salário, como alguns podem entender. Se dermos uma olhada na Pirâmide de Maslow , que lista as necessidades que as pessoas desejam satisfazer, pode-se notar que a renda (ou segurança de recursos, como está na pirâmide) está apenas no segundo nível de necessidades, e que existem outros três níveis acima, sendo que esses também devem ser providos pela empresa onde essa pessoa está trabalhando (ok, intimidade sexual talvez não…).

Agora alguém deve estar pensando:

Ok, estou fazendo tudo isso, mas nada impede de alguma empresa vir aqui e oferecer um cargo muito melhor para meu funcionário, certo?

Certo. Nada impede isso, e daí que entramos no segundo ponto que eu considero importante. Conforme eu li em algum livro (não me lembro qual), há uns tempos atrás, o dono da empresa (ou gerente da equipe, como era o exemplo do livro) deve sempre saber qual é o Truck Number de sua empresa, ou seja, quantas pessoas devem ser atingidas por um caminhão para que a empresa afunde.

Se esse é um número pequeno, realmente a sua empresa tem problemas. E para resolver isso, nada melhor do que espalhar o conhecimento entre seus funcionários, ou seja, criar uma cultura de troca de conhecimento, e também exigir que os funcionários mais capacitados (os seqüestradores, seguindo a analogia.. ) passem o seu conhecimento para os demais membros da equipe.

E nesse ponto eu discordo de alguma opiniões que eu li durante a discussão, onde se afirmou que deve-se então criar documentos e documentos para armazenar o conhecimento das pessoas. É claro que talvez sejam necessários documentos, mas deve-se ter uma grande atenção na quantidade e também no tipo de documentação que se está criando, já que, assim como em projetos, escrever documentos para ficarem no armário não serve para nada.

O principal é não ter um ambiente (como alguns onde eu já trabalhei), onde cada funcionário é dono do seu nariz, detentor do seu conhecimento e não faz a mínima questão de passar isso adiante, com medo de que se torne substituível por outro. Na minha opinião não serve ter uma pessoa extremamente capacitada se ela não estiver pronta para compartilhar isso com outros.

O mais importante, é realmente criar um ambiente onde o conhecimento seja compartilhado entre os funcionários, seja através de programação em pares, seja através de reuniôes freqüentes, mini-workshops internos ou um wiki da empresa, ou qualquer outro método que se considere interessante, mas ao mesmo tempo não atrapalhe demais o andamento do trabalho, e que realmente seja útil quando aquele funcionário for embora.

Acho que era isso o que eu tinha a dizer, espero que vcs tenham opiniões a respeito!

Um abraço.

Lean no MIT

Pra quem ainda não conhece Lean, ou acha que não é serio, tem uma lista legal de artigos nesse post, que são alguns dos que fazem parte do MIT Lean Advancement Initiative (LAI).

Entrevistas… dois lados complicados de uma mesma moeda

Bom, como eu faço ocasionalmente, esse post na verdade pode ser considerado mais um comentário sobre esse outro, do Guilherme Chapiewski. Na verdade eu estava escrevendo um comentário, mas como estava ficando muito grande, achei melhor promovê-lo para um post aqui.

Apesar de eu ter alguns pontos discordantes, sobre os quais falarei daqui a pouco, achei bem legal o post do Guilherme, e também o fato de eles (ele a sua equipe) se preocuparem com a criação de um processo de seleção. Eu tive uma empresa e entao já passei por essa dúvida de como selecionar pessoas, e com certeza a existência de um processo faz toda a diferença.

Além disso, recentemente eu vi o outro lado dessa moeda (ou da mesa de seleção, para ser mais preciso), porque estive procurando emprego, e então participei de diversos processos seletivos (acabei sendo contratado pela ThoughtWorks UK ), e essa maratona de testes me fez criar algumas opiniões.

O ponto que eu discordo do processo descrito pelo Guilherme é a entrevista tecnica com a equipe, etapa 4, mais exatamente no ponto “perguntas cascudas”. Eu acho que o processo apresentado por ele tem um ponto muito interessante que é a questão dos livros, para evidenciar os interesses e capacidade de auto-aprendizado do candidato, mas eu particularmente acho um desperdício não selecionar alguém por causa de requisitos tecnicos.

Quer dizer, eu acho importante os requisitos tecnicos, como o conhecimento de computação, uma boa formação em nivel de graduação, mas conhecer framework X,Y ou Z, ou então saber aplicar o padrão W, são coisas que, no meu ponto de vista, podem ser aprendidas pelo bom candidato (aquele interessado e com capacidade de auto-aprendizado), tanto em livros, como de noite em casa, como durante o dia-a-dia de convivência com os novos colegas de trabalho.

Claro que se tu fizeres várias perguntas técnicas e o candidato souber todas as respostas além de ser um cara fantástico, só vai te dar mais certeza de contratá-lo, mas o que eu acho é que muitas vezes existem excelentes candidatos, que sabem se virar muito bem, mas que por diversas circustâncias da vida nunca trabalharam com Java, e sim com C++, mas que são excelentes desenvolvedores por conhecerem os fundamentos de computação, e vão ter capacidade de aprender qualquer coisa durante o trabalho.

Além disso, é ingenuidade pensar que as tecnologias com quais a empresa trabalha hoje vão ser as mesmas daqui a 2 ou 5 anos, então não adianta se contratar uma ótima pessoa técnica (partindo do princípio de que se quer formar uma equipe duradoura), se ela não vai ser capaz de superar os novos desafios que estão por vir.

Então por que não eliminar essas “perguntas cascudas” e tentar focar em descobrir se o candidato tem capacidade e interesse de sempre estar melhorando e aprendendo novas coisas? Eu digo isso por que em muitas das seleções das quais eu participei eu acabei não indo bem por que eram feitas perguntas técnicas sobre tópicos que eu realmente não me lembrava (como análise combinatorial), mas que se eu tivesse um computador com acesso à Internet eu poderia descobrir na hora. Por outro lado, as seleções das empresas que eu mais queria trabalhar (no qual a TW é uma delas) não passam perto de questões técnicas (ao menos não no momento da entrevista, quando o candidato está tenso e com muitas chances de se esquecer dos detalhes de implementação daquela determinada biblioteca…), mas sim focam em atividades em grupo, apresentações pessoais e questões de raciocínio.

Acho que a regra de ouro sobre seleções para mim é que se o candidato tiver que estudar para vir ser entrevistado, então o processo está avaliando as habilidades erradas.

E acho que além disso, o único ponto que está faltando na minha opinião no processo do Guilherme, que talvez exista mas não tenha sido comentado, é a questão do feedback. Não tem preço para um candidato (e para a impressão que ele tem da empresa) o fornecimento de um bom feedback sobre o processo de avaliação, que passa por dizer se ele passou ou não (o que muitas empresas se esquecem, avisando somente aquele que foi selecionado) e também explicar por que se achou que ele não preenchia o perfil do profissional desejado. Não tem nada pior do que se submeter a um processo de seleção extenso, e depois ficar se sentindo mal por não ter sido escolhido sem saber que, muitas vezes vc ficou de fora não por ser um incompetente, mas por que a vaga exigia um perfil mais ou menos técnico, o que ajuda a pessoa a se preparar para outras seleções.

Acho que era isso. Desculpem por ter ficado tão longo, mas eu considero esse um tópico bastante interessante!

Dêem suas opiniões!

Fantasmas do Passado

Ontem eu estava lendo o livro “O Ponto de Mutação” (pra quem leu os outros posts, acho q já deu para reparar que eu tenho uma queda pelos clássicos ), e li uma frase que não podia deixar de colocar aqui.

“A complexidade de nossos sistemas industriais e tecnológicos atingiu agora um ponto em que muitos desses sistemas já não podem ser modelados ou administrados. Avarias e acidentes ocorrem com freqüencia crescente, custos sociais e ambientais imprevistos são continuamente gerados, e consome-se mais tempo mantendo e regulando o sistema do que fornecendo bens e serviços úteis.” - Fritjof Capra - O Ponto de Mutação.

Não vou falar muito sobre isso, acho que vcs podem tirar suas conclusões, mas o que eu acho mais interessante é que esse livro foi escrito em 1982, mas se mudarmos uma palavrinha ou duas, essa frase se adapta perfeitamente ao cenário de desenvolvimento de software atual.

A Fantastica Fabrica de Testes (nao seria melhor a de chocolate…?)

Ha alguns dias (ou seriam semanas?) atras, foi enviada uma noticia para uma das listas de e-mail das quais eu participo, sobre a criacao de uma fabrica de testes no Parana. So essa noticia ja eh impactante para mim (como foi para os outros membros da lista), mas alem disso ha algum tempo vem exisitindo uma tendencia de criacao de empresas especializadas em testes, tanto que eu acho interessante comentar isso por aqui.

Primeiramente, eu acredito que pelo conteudo de um meu outro post, vcs ja devem saber qual vai ser a minha opiniao a respeito da existencia de equipes especializadas em teste de software. Primeiro a gente tinha analistas especializados, agora a gente tem testadores especializados, e inclusive empresas responsaveis soh por desenvolver testes, as “fabricas” (argh) de testes. Qual sera o proximo passo? Especialistas em testes unitarios? Especialistas em analise de software usando diagramas de sequencia UML?

Pra comecar, o proprio fato de existirem especialistas em cada area, cada um tratando do seu nicho, soh traz maleficios para uma equipe, se eh que se pode chamar de equipe um grupo de pessoas onde cada uma trabalha em uma tarefa separada sem existir um foco no resultado final, que eh software rodando para o cliente. Alias, o final dessa frase eh que faz toda a diferenca, na minha opiniao. Conforme foi escrito pelo Goldratt no livro “A Meta”, “Diga-me como serei medido que eu te direi como me comportarei“. Essa afirmacao resume tudo, pq eh claro que se existir um cargo que eh medido pelos seus diagramas, teremos como resultado diagramas extremamente requintados, e se tivermos um que for medido pelos testes que gera, o que teremos? Testes, testes e mais testes, necessarios ou nao.

Mas esse eh soh o primeiro dos problemas da fabrica de testes. Eu considero particularmente a realizacao de testes umas das principais contribuicoes do movimento agil para o desenvolvimento de software, principalmente quando se falar em TDD. Mas essa validade acaba e comeca a contar pontos negativos quando os testes nao sao mais utilizados para guiar nem para verificar o desenvolvimento de software, e sim para serem criados apos o desenvolvimento e darem uma “cara” de seriedade para o codigo sendo desenvolvido.

Alias, acho que esse eh o principal motivo da existencia das equipes de testes. A impressao de seriedade que a empresa quer passar para o cliente, dizendo que seu software eh testado por uma equipe especializada, sendo que essa equipe certificou que o software esta funcionando corretamente. No meu ponto de vista, a palavra “certificou” diz tudo sobre as intencoes que existem por tras disso :-). Primeiro vem o CMM, depois o MpsBr, e agora os softwares saem certificados por testadores especializados.

Quero deixar claro aqui que eu nao sou contra a existencia de especialistas, e muito menos contra a existencia de testes. Acho que os especialistas sao necessarios, e todo mundo tem um assunto no qual tem mais interesse e torna-se por isso mais experiente, e tambem acho que todas equipes precisam de especialistas . O que eu nao concordo eh com a existencia de especialistas que fazem somente uma coisa, e nao estao inseridos dentro de uma equipe multidisciplinar que conta com diversos especialistas em diversas areas. Em relacao aos testes, conforme eu falei antes, acho eles vitais quando inseridos dentro do ciclo de desenvolvimento do software, na forma de testes unitarios, de aceitacao e de qualquer outro tipo que se quiser fazer. O que eu nao entendo eh desenvolver milhares de linhas de codigo e passar para uma empresa testar, e dai depois de tres semanas voltar um relatorio com milhares de erros, quando os desenvolvedores que trabalharam naquele codigo ja estao preocupados com outra coisa.

Eh tao dificil assim fazer o mais simples?