Ontem (27/07) organizamos outra sessão de Coding Dojo aqui na AdaptWorks, especialmente dessa vez contamos com novos participantes da Gonow e da Fujitsu, que enriqueceram muito o Dojo.

Agradeço a participação e paciência de todos.

Veja todas as fotos do Dojo

Realizamos outra sessão de Coding Dojo no dia 18/05 aqui na AdaptWorks. Dessa vez além de ter fluído melhor, conseguimos organizar melhor o Dojo e os participantes por sua vez estão mais colaborativos e cada vez mais disciplinados.

Veja todas as fotos do Dojo

Sua empresa quer produtividade o tempo todo? Velocidade máxima em tudo?

Cuidado! Ao invés de melhorar, vocês podem estar piorando o cenário!

Isso é resultado do estudo realizado com 343 empresas pela Economist Intelligence Unit, que ao final concluíram que empresas que se lançaram a inciativas sem nenhuma trégua para tentar obter uma vantagem tiveram muito menos lucro e receita operacional que outras que “pararam para pensar”.

Este resultado foi publicado na Harvard Business Review, e corrobora com o pensamento que temos na AdaptWorks. Aliás, é um pensamento totalmente baseado em Scrum, onde de tempos em tempos fazemos uma retrospectiva, onde analisamos como tem sido nosso desempenho e tomamos ações para que a empresa como um todo melhore.

Claro, ainda precisamos melhorar muito, mas pelo menos sabemos que nossa forma de pensar é bastante parecida com a de muitas boas empresas por aí.

E a sua empresa, como ela pensa e age?

Ontem realizamos o primeiro Coding Dojo aqui na AdaptWorks. Foi uma ótima experiência tanto para os participantes quanto para a AdaptWorks, pois foi o primeiro evento que organizamos na nova sede.

Na retrospectiva encontramos vários pontos que devemos melhorar para os próximos dojos, mas mesmo assim foi muito divertido, o que nos incentiva a repertimos a dose.

Veja todas as fotos do Dojo

Tempos atrás me encontrei em uma situação interessante. Por problemas de comunicação, eu estava em um lugar e deveria estar em outro. Quem já não passou por isso?

Mas o que me chamou a atenção foi a primeira pergunta que me foi feita quando notamos o problema. “Quem falou para você vir para cá?”. Por reflexo respondi, mas fiquei com isso na cabeça.

O que eu vi acontecer nos próximos minutos foi uma rápida caça às bruxas. O importante não era descobrir como eu chegaria a tempo no local certo e sim descobrir quem era o culpado por eu estar no lugar errado. Não tem algo de estranho por aqui? O que seria ganho encontrando o culpado?

Isso é um traço cultural de muitas empresas. Essa “cultura do culpado” é muito forte e costuma trazer efeitos desastrosos. O erro passa a ser tratado como a pior coisa que pode acontecer e não como parte do aprendizado. Como o erro é uma ofensa terrível, ele deve ser escondido. Pronto. Acabamos de destruir uma empresa. Esses erros que ficam ocultos vão minando as bases da empresa até o ponto em que ela fica insustentável.

Uma solução a essa “cultura do culpado” é uma “cultura da solução”. O culpado passa a ser um personagem secundário. O realmente importante é encontrar uma solução e voltar o mais rápido possível ao estado normal de trabalho. Essa forma de agir tem algumas vantagens:

• Seus problemas são solucionados mais rápido
• O erro passa a ser parte do aprendizado e por isso não faz sentido ter medo e escondê-los
• Como seus erros estão visíveis, você finalmente tem a chance de fazer melhorias reais para evitar que eles aconteçam novamente

Essa “cultura da solução” é um dos principais pontos dentro de Scrum (e também é uma das mais difíceis de serem implantadas). Toda a parte de Inspecionar e Adaptar só é possível se você tiver (não apenas dentro do time, mas com todos os envolvidos no projeto) segurança para relatar os problemas que tem acontecido.

Recentemente, acompanhando a lista de discussão sobre Scrum “Scrum Development”, vi uma discussão interessante sobre um programador que afirmava precisar de tempo de isolamento para trabalhar.

Isso me fez pensar bastante. Realmente várias vezes eu senti necessidade de me isolar para poder trabalhar (em especial em um momento me que eu precisava implementar algum algoritmo específico ou precisava otimizar determinado código). Isso fez muito sentido na minha cabeça e durante um tempo cheguei a concordar com o programador. Mas será que isso é uma coisa boa?

Vamos analisar a curto prazo. Durante duas horas eu me isolo da equipe (não posso mais chamar de time pois estou trabalhando sozinho) e resolvo o problema. Foi vantajoso porque se eu parasse para discutir ou utilizasse pair-programming demoraria cerca de 8 horas (algoritmos são bem difíceis de explicar para quem ainda não teve contato com ele). Aumentei a velocidade do time e isso foi uma coisa boa, correto?

Não. Essa foi a pior atitude que poderia ser tomada. Pensem na sequinte situação ocorrendo logo após essa.

Novamente a equipe é confrontada com um problema semelhante. Quem é o único que tem experiência resolvendo esse tipo de problema? Eu. Então novamente me isolo da equipe para resolvê-lo. Começaram a notar onde pretendo chegar?

No momento em que me isolei da equipe, eu causei um dano muito sério. Retive conhecimento ao invéz de compartilha-lo. Se apenas eu sei como lidar com o problema, na próxima vez que ele ocorrer ou quando for necessário dar manutenção, eu preciso trabalhar nele. Ou seja, o Truck Factor para aquele trecho de código é 1.

Porque isso é muito ruim? Um programador com tendência de concentrar informação, não vai concentrar apenas um dos pontos. Ele irá agir dessa forma muitas outras vezes. Logo, ele será o único com conhecimento para resolver muitos problemas, causando um sério impedimento. Isso sem contar que a equipe não vai ter a oportunidade de crescer e aprender a resolver esse problema.

Isso é uma atitude de muita irresponsabilidade. O crescimento da equipe deve ser prioridade para todos os programadores da equipe. Apenas agindo dessa forma a equipe poderá passar a ser um time.

Depois de muitas conversas e acertos, foi confirmado um encontro do ScrumAmazonia durante o Lima Agile Day 2010. O mote do encontro será o intercâmbio de experiências entre Brasil e Perú. A partir desse evento inicial, esperamos uma aproximação maior entre Brasil e Perú em termos de Agile e Scrum.

O encontro será dia 17 de abril, das 15 às 20 horas no auditório do Instituto Superior Tecnológico Cibertec localizado na Av. Salaverry 2255, San Isidro, Lima, Perú. A AdaptWorks estará participando do evento. Fabiano Milani e Heitor Roriz estarão falando sobre suas experiências com Coaching e Scrum Distribuído.

Como membro do ScrumAmazonia, Marco Mafra do INdT estará falando sobre a experiência do INdT na implantação do Scrum em um ambiente com ISO. Essa é uma palestra bastante interessante que foi apresentanda anteriormente em um dos encontros do grupo, em Manaus.

Mais detalhes sobre a agenda do dia 17 de abril, juntamente com uma descrição das palestras - em espanhol, você pode ver em no site do ScrumAmazonia.

Algumas semanas atrás estava conversando com o Alexandre Magno a respeito do evento Agile Brazil que acontecerá em junho, após um bate-papo bacana ele me disse algo que nunca tinha pensado antes e que ficou marcado: “…palestras boas são aquelas feitas por pessoas que tem história pra contar…” pensando nisso resolvi criar um post contando um pouco da minha trajetória.

Confesso que já cheguei a pensar que algumas vezes fiz más escolhas, e já me senti um idiota por ter ficado tanto tempo em determinadas empresas, mas logo vejo que isso me trouxe até a Adaptworks, por isso não tem como me arrepender das escolhas que fiz no passado. Sendo sincero, não tenho muito conteúdo pra falar sobre meu currículo, a não ser um período que talvez pudesse ter refletido em vários aspectos, a época em que era um “estagiário”.
Passei o ano de 2003 inteiro fazendo entrevistas e só consegui um estágio em 2004, nem preciso falar a alegria que senti naquele dia, sempre procurava matérias a respeito de estágios, como ser um estagiário de sucesso e blá blá blá. Ser estagiário era muito animador, pois toda programação era voltada para uma ferramenta comercial e não para exercícios propostos na faculdade, mesmo defendendo o rótulo de estagiário já me passaram responsabilidades desde o primeiro dia de trabalho, e caso fizesse alguma coisa de errado eu não levava uma nota baixa, e sim uma provável demissão e rompimento do contrato.
Meu dia-a-dia como um mero estagiário era +- assim:

• não participava de reuniões de planejamento
• as tarefas já chegavam com prazo de entrega
• só me passavam tarefas simples (alterar estilo, criar form de cadastro, mudar endereço da empresa…)
• não tinha voz ativa

Eu só tinha oportunidade de tentar inovar ou pegar alguma tarefa mais difícil quando eu persistia muito, ou quando eu fazia “escondido” e mostrava pro chefe depois de pronto, muito ruim concordam? infelizmente essa era a cultura da empresa que trabalhei por um bom tempo. Hoje me pergunto: “como seria essa fase de estagiário se usassemos scrum? teria sido melhor/pior?”, acredito que seria melhor e vou explicar o que me levou a chegar nessa conclusão.

Planning
Em um planning não importa se você é um programador experiente ou não, todos tem voz ativa, todos podem opinar e o que for decidido será o melhor para o time. Essa é a hora de ouvir todos os pontos de vistas, entender que nem todos tem capacidade de terminar uma task tão rápido e incentivar os demais.

Kanban
A vantagem do uso do kanban é que com ele não existe delegação de tarefas, pois ninguém pode decidir o que você deve fazer, cada membro do time pode pegar a tarefa que desejar.

Essa semana tive a oportunidade de ler o livro “Liderança Radical” do Steve Farber (muito bom por sinal) e achei que alguns aspectos sobre liderança tinha tudo a ver com programação, pra ser mais preciso sobre evolução. Farber cita que liderança é uma posição nada confortável, pois o líder sempre esta exposto aos demais. Com programação é parecido, só se sente confortável o programador que está contente em seu mundinho, estagnado pelo que sabe e pouco se importa em inovar ou arriscar, a famosa “zona de conforto” onde a pessoa fica lá, quetinha no seu canto, fazendo sempre a mesma coisa e segura de que isso vai lhe trazer os melhores benefícios em sua vida, essa é a falsa sensação que traz o sentimento de “segurança” no cenário do trabalho, na verdade você deixa de crescer e a partir do momento que você se permite olhar para fora da caixa, ferrou, porque você vai gostar do que vai ver, vai cair pra fora dela e duvido que vá querer voltar um dia pra dentro dela.
Quando pegamos uma task do kanban, estamos de um modo indireto deixando claro que estou responsável por aquela task e que pretendo e vou tentar terminar no prazo estipulado por todos no planning, quer exposição maior do que essa? Ok, posso estar exagerando, mas de certa forma é um tipo de exposição e uma boa forma de tentar aprender algo de novo.
O que quero dizer é que com planning, kanban, daily meetings…minha fase de estagiário provavelmente seria melhor, teria a chance de participar das reuniões de planejamento, ajudaria a decidir os prazos além de ter a chance de pegar qualquer task que desejasse, não precisaria implorar por pegar tarefas simples e nem fazer nada escondido.
Talvez fosse diferente se tivesse começado a estagiar em outra empresa, mas como disse lá no começo, essa é a minha história.

A APLN (Agile Project Leadership Network) é uma organização sem fins lucrativos que visa o avanço do gerenciamento de projetos, focando no suporte a líderes de projetos interessados em aprimorar-se cada vez mais. No Brasil, temos um capítulo da APLN, em estabelecimento e expansão. Para saber mais sobre a APLN e sua estrutura, clique aqui.

O capítulo APLN Brasil foi iniciado em julho de 2007, em Manaus. Foram realizados dois encontros locais desde então, com muito pouco realizado em termos de alcance na comunidade Agile. Tendo em vista a forte expansão, aceitação e sucesso de Agile no Brasil, o cenário atual torna-se ideal para a expansão do capítulo.

Missão do Chapter Brasil
Dar suporte e avançar nos conceitos e aplicação da liderança ágil, colaborando com líderes de projeto alavancando o gerenciamento de projetos, tornando o Brasil um ícone em termos de Gerenciamento Ágil de Projetos, com conhecimento sólido gerado e trabalhado pela comunidade e difundido de norte a sul pelo país. Em paralelo a isso, o chapter precisa estabelecer-se no país, tendo como pilares existenciais representantes de empresas que aplicam Agile no seu cotidiano, assim como representantes da comunidade Agile do país, os quais atuarão de forma colaborativa para a criação de casos de sucesso de APM (Agile Project Management) em projetos de diversas naturezas, não apenas de TI.

Visão do Chapter Brasil
O capítulo brasileiro visa expandir-se e solidificar sua existência e atuação pelo país, em torno de representantes de empresas e da comunidade Agile do Brasil como pilares da existência e foco das atividades de suporte do grupo. Esse board de representantes trabalhará de forma a tornar a APLN Brasil como ponto de referência de APM no país, sendo os responsáveis pela difusão da missão da organização e deixar clara a contribuição da comunidade Agile para o gerenciamento de projetos.

Contamos com a colaboração de todos os entusiastas de Scrum e Agile para a criação do conhecimento vinculado à APLN!

Essa é uma pergunta muito frequente e geralmente confunde as pessoas. Já vou iniciar dizendo que Scrum é um framework. Agora vamos responder dizendo porque Scrum não é nem metodologia nem método. Agora, você pode se perguntar: porquê não utilizar uma palavra em português, como a tradução de framework? Não vamos esquecer que Scrum foi originado dos EUA e sendo assim, seus termos advêm do inglês. Vejamos a definição da ScrumAlliance:
“Scrum: A team-based framework to develop complex systems and products.”

Usamos palavra “framework” porque a tradução oficial de framework para o português não é tão abrangente no seu sentido como o vocábulo em inglês! Isso podemos verificar nos dicionários mais comuns como Michaelis, Collins, Rideel, Oxford-Duden. O que ocorre geralmente, principalmente na computação, é a criação de neologismos. Daí surgiram o “vamos deletar”, o “vou fazer um design”, ou o “vamos navegar na web”. Neologismos não são ruins, aprimoram a linguagem e a fazem evoluir. Talvez fosse melhor se criássemos uma palavra nova a cada conceito novo que derivássemos ou aprendêssemos a partir de outras línguas, mas isso é tarefa dos Holanda Ferreira.

Scrum é um modelo? Inicialmente, a definição de modelo em inglês é a mesma em português. Assim, de acordo com a tais definições dadas nos dicionário citados, temos para o substantivo:

1 - “um padrão”
2 - “uma representação da realidade, utilizada para investigação.”

Geralmente, um modelo é uma descrição metafórica de alguma realidade, seja esta descrição matemática ou não. No Computing Dictionary, vamos encontrar a definição com a qual o pessoal da computação está mais familiarizado: uma abstração ou representação simplificada da realidade, ignorando certos detalhes. Transcrevendo uma parte, temos: “Models allow complex systems, both existent and merely specified, to be understood and their behaviour predicted”. Utilizando Scrum, podemos predizer o comportamento de papéis ou do produto envolvido? Utilizando apenas Scrum, não podemos. Talvez realizando estudos empíricos abrangendo algumas ciências como Psicologia, Matemática, podemos atingir tal objetivo. Veja que a definição de modelo está sempre ligada a uma posterior investigação, independente do modelo ser matemático ou não.

Vamos ao vocábulo “metodologia”. A tradução de methodology é metodologia. No inglês, verificando qualquer um dos dicionários citados acima, podemos compilar (mais um neologismo) tudo e chegar a:

1 - “A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; scientific methodology”
2 - “The system of methods followed in a particular discipline”

No português, verificando os principais dicionários (Aurélio, Houaiss, Aulete e Michaelis) vamos encontrar uma definição com o mesmo conteúdo semântico. Metodologia, então, implica em algo que define procedimentos, regras documentadas (ou o estudo das mesmas) para a regulamentação de uma determinada disciplina. Metodologia nos ensina a pesquisar e estudar algo. Na computação, de acordo com o Computing Dictionary, vamos encontrar:

“An organised, documented set of procedures and guidelines for one or more phases of the software life cycle, such as analysis or design. Many methodologies include a diagramming notation for documenting the results of the procedure; a step-by-step “cookbook” approach for carrying out the procedure; and an objective (ideally quantified) set of criteria for determining whether the results of the procedure are of acceptable quality.”

Scrum não se encaixa em nenhuma das definições acima, principalmente na última. Isso porque Scrum não nos ensina a fazer pesquisa, não nos ensina ciência nem muito menos responde perguntas de Engenharia de Software que possam surgir no decorrer do Ciclo de Vida de um software. A última definição, inclusive, já nos permite descartar Scrum como metodologia de imediato, tendo em vista que Scrum desenvolveu-se e pode ser aplicado a outras realidades de projetos e não apenas a projetos de software.

E método? A definição de método, de acordo com os já citados dicionários, nos leva a:

“Procedimentos, técnicas ordenadas; processo ou sistema que ordenam uma determinada atividade”

De acordo com tal definição, poderíamos até dizer que Scrum é um método. E de fato dizemos: é um método ágil. Porém, se verificarmos abaixo a definição de framework, vamos ver que Scrum se encaixa melhor a ela.

Um framework é um conjunto de conceitos, valores e práticas que constituem uma forma de ver a realidade. Se considedrarmos Scrum como sendo aplicável a projetos genéricos (mas não a qualquer realidade de projeto) veremos que é um framework. Scrum per se é um conjunto de valores, mais que um conjunto de regras e processos. Obviamente, existem regras a serem seguidas, isso é inevitável, mas por se tratar de algo genérico, Scrum é como se fosse um conjunto de massinhas de brinquedo, daquelas que brincamos quando criança. Podemos ler assim na caixa do brinquedo: “Utilizado para organizar seus problemas de forma lúdica”.