Se você tem um único quadro e apenas 5 pessoas no time, ele é gratuito. Para um maior número de pessoas no time e múltiplos quadros, o software passa a ter custos a partir de US$ 19,00 mensais. Há ainda uma versão community disponível.

O site onde o software pode ser encontrado: http://www.leankitkanban.com

Alguns filminhos demonstrando seu uso:

Scrum Master é um nome que sugere ser o guardião do processo Scrum. Ele é um agente de mudança que apoia sua equipe ao mesmo tempo em que ensina e socializa o Scrum por toda a organização. Ele garante o bom andamento das atividades da equipe erradicando os impedimentos e mantendo a equipe protegida de distrações externas. Entretanto, em certos cenários, equipes ágeis sentem que o Scrum Master em si é o maior impedimento.

Siddharta descreveu um cenário, que ele acreditar prevalecer em equipes offshore devido à cultura hierarquizada e à estratégia de comunicação tradicionalista. Aqui, o Scrum Master acaba se tornando um gargalo entre a equipe e o cliente.

Segundo Siddharta,

Muitas equipes não possibilitam acesso dos membros do time ao cliente ou mesmo ao Product Owner (especialmente se estes não estão fisicamente disponíveis, mas apenas remotamente). Assim, o fluxo de informação é algo como

Você <-> ScrumMaster <-> Product Owner <-> Cliente

Tobias Mayer reagiu a isto sugerindo que se o Scrum Master estiver se tornando um intermediário para a equipe, então a causa do problema é outra.

[Isto é] um estilo simplificado de comando e controle. Chamar alguém de Scrum Master não faz dele um verdadeiro Scrum Master, especialmente se ele estiver profundamente impregnado com o "pensamento arcaico" e não teve treinamento para mudar essa mentalidade.

Jaibeer Malik, compartilha do argumento de Tobias quando menciona que a causa parece se a maneira como Agile está sendo implementada e seguida.. Ele ressalta que a comunicação é a questão fundamental de um processo ágil e que todos os membros da equipe devem ser capazes de se comunicar com qualquer pessoa da equipe sem o intermédio do Scrum Master.

Já Roberto Fasciolo apontou outras razões pelas quais os ScrumMasters estão caindo nos velhos problemas do pensamento tradicional. Ele observou as seguintes armadilhas,

• Scrum Master se comprometendo com o sprint backlog – Isto ocorre particularmente quando o Scrum Master é também um membro da equipe. O time simplesmente aceita o que ele tem a dizer.
• Scrum Master indicando ao time sobre o que fazer ao invés de orientar a auto-organização – Isto acontece muitas vezes quando o Scrum Master é um ex gerente de projetos. O efeito disto é que o time pode se tornar completamente dependente de seu Scrum Master.
• Scrum Master agindo como um proxu entre o time e o Product Owner – – Isto é semelhante ao cenário descrito por Siddharta e é prevalente em equipes offshore distribuídas.

Mike Cottmeyer complementa que se o Scrum Master estiver apenas mantendo registro de impedimentos, então ele é o impedimento. Um bom Scrum Master não deve apenas ser capaz de registrar e remover impedimentos, mas também deve ser um Antecipador que pode antever os problemas e trabalhar com o time para não permitir que as coisas deem errado.

Cesario Ramos descreveu uma situação interessante na qual o Scrum Master também está tão envolvido com o time que suas próprias tarefas de Scrum Master se tornam um impedimento por estarem no caminho crítico.

A questão aqui é que o Scrum Master está fazendo tarefas de projeto “de valor”. Ele ou ela está tentando fazer coisas de que os outros membros da equipe dependem para fazer suas tarefas. Isto pode até chegar ao ponto em que o Scrum Master sente que não conseguirá ter uma sprint concluída sem que ele/ela busque remover todas estas tarefas importantes/difíceis.

Boris Gloger, também tem uma história parecida para contar quando fala que o SM de Scrum Master não significa (S)uper (M)an. Um Scrum Master que não esteja fazendo seu papel adequadamente ou que esteja tentando incorporar múltiplos papéis além de seu papel principal é, na verdade, um impedimento para o time.

Por isso, há muitas situações em que um Scrum Master pode impedir, conscientemente ou não, as atividades do time. A chave aqui está em identificar estas situações o mais cedo possível e tomar as ações corretivas enquanto ainda há esperança para o projeto.

Fonte: InfoQ

Patrick Wilson-Welsh, Chris Beale, Gary Baker, John Huston, Daryl Kulak e outros estão tentando popularizar a ideia de um novo papel, o "Líder de Equipe Ágil", em substituição aos papéis de liderança existentes que normalmente rodeiam equipes ágeis.

Nas palavras de Wilson-Welsh:

Estamos deliberadamente tentando apagar o velho papel de gerenciamento de equipes ágeis e sua responsabilidade rotulada como o Scrum Master e o Gerente de Projetos, que cada vez mais acreditamos estarem fundamentalmente defasados. Achamos que a controvérsia sobre este assunto deve-se justamente aos inconvenientes da empresa: a colcha de retalhos que se tem com a gerência de equipe ágil, a gerência do projeto, os clientes e proprietários do produto e a gestão de melhoria do processo resulta em mais buracos que um queijo suíço.
…

Seja você contra ou a favor, o fato é que precisamos de uma mudança de paradigma envolvendo a liderança em equipes ágeis. Nós precisamos de uma liderança que possa ser mais consolidada, mais focada, mais definida e mais adequada à dialética entre as necessidades internas da equipe e as necessidades externas dos clientes e stakeholders. Nós precisamos de uma pessoa que possa ser responsabilizada na medida em que a autoridade da equipe ágil e a responsabilidade são, de fato, congruentes.

Segundo ele propõe, esta pessoa seria um "Líder de Equipe Ágil". Wilson-Welsh ainda prossegue em apresentar um esboço sobre o que se esperaria de tal papel. Uma visão resumida deste (já resumido) esboço inclui as seguintes cinco categorias de responsabilidade:

• Liderança Contínua

  A compreensão do lugar da equipe dentro dos objetivos organizacionais, sendo um ponto único de liderança (para a equipe) e responsabilidade (para os stakeholders), criando um "ambiente seguro" no qual a equipe possa trabalhar, aumentando a confiança e o respeito entre a equipe e os stakeholders, além de melhorar continuamente a coesão da equipe.

• Planejamento Contínuo
  Garantir que a equipe seja cada vez mais capaz de se realizar seus próprios compromissos já estabelecidos, garantir que todas as coisas estejam sempre "grandes e visíveis", gerenciar métricas, reconhecer a "culpa" no plano (ao invés de atribuí-la às pessoas) e garantir o atendimento às mudanças no plano.
• Execução Contínua
  "Monitorar/gerenciar a velocidade/taxa de entrega da equipe", assegurar recursos, remover e escalonar impedimentos. Por fim, "manter o fluxo, o momentum e o foco da equipe".
• Redução Contínua de Risco
  Identificar riscos e deixar seu "impacto potencial grande e visível para as pessoas certas", garantir que a redução de riscos aconteça e quantificar a efetividade do gerenciamento de riscos.
• Melhoria Contínua (Agile Coaching)
  Comandar as "melhorias acerca das Definições de Pronto como um todo", saber identificar e dedicar a devida atenção às quedas de desempenho, facilitar as melhorias na equipe nas áreas certas e ajudar a equipe no aprendizado de boas práticas emergentes onde quer que elas estejam.

O feedback inicial sobre esta iniciativa é misto. Abby Fichtner (aka, "The Hacker Chick" ou "A Garota Hacker") e John McFadyen ambos apoiam as ideias de Wilson-Welsh, mas se questionam no que um papel de "Lider de Equipe Ágil" difere de um "Scrum Master". Abbey destaca ainda como o pensamento de "a liberdade levando a falhas" depreendido das responsabilidades descritas a fazem lembrar da apresentação de Jared Spool no Agile 2009 na qual ele destacou 3 características comuns de muitos dos projetos "descontroladamente bem sucedidos".

Tobias Mayer discorda deste conjunto responsabilidades sendo determinante para seleção de pessoas quando diz que "cada membro da equipe precisa" encarnar as virtudes descritas por Wilson-Welsh. Segundo Mayer:

Criar um "papel" de líder de equipe é o início de uma jornada de volta ao comando-e-controle. É um aspecto do vigilantismo; uma desculpa para não facilitar o real desafio de se consolidar uma equipe como um líder de verdade faria.

E você, o que acha? Um papel com esta definição poderia ser útil? Se sim, como este esboço de definição poderia ser melhorada? Ou tratar-se-ia de um papel redundante, ou quem sabe não seja de fato uma ideia ruim (como Mayer propõe)?

Fonte: InfoQ

Neste curto período no Brasil eu tive a oportunidade de conversar com muita gente, tanto do Rio quanto de outros locais que vieram para workshops ou eventos. Como não é novidade para ninguém o Brasil está cada vez adotando mais metodologias menos burras -ou “ágeis” se você preferir.

E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.

Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!

Só cuidado para não quebrar as barreiras que protegem o time.

Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.

E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.

Não vai.

Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.

Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.

Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.

Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.

E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.

E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.

A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.

Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.

Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”

Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.

Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.

E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.

É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.

Fonte: Blog Fragmental

Palestra realizada no Google Tech Talk, em 4 de Setembro de 2008.

A empresa Webgoal colocou em seu site, na área de recrutamento um texto do perfil de profissionais que está a procura:

Estamos contratando desenvolvedores que são independentes de linguagem, que saibam trabalhar em par e não precisem de um gerente!

Tem que saber planejar, estimar, analisar, modelar e desenvolver software em equipe. É um diferencial ser formado em ciência ou engenharia da computação. Mas se você for muito bom mesmo, isso não importa.

Você precisa ter experiência com a maior parte desta sopa de letrinhas: MVC, UML, XML, HTML, CSS, JS, PHP, C#, JAVA, RUBY, TDD, BDD, SCRUM e XP.

Você precisa ter muita responsabilidade, disciplina e pró-atividade, pois aqui você será livre. Gostamos de trabalhadores do conhecimento. Esse é o pré-requisito mais importante.

Você vai ter que trabalhar 40 horas por semana. Por favor, não insista. Você precisa ter um tempo para você, sua família e amigos.

Além dos benefícios costumeiros oferecidos pelo mercado, ainda temos plano de carreira, plano de formação profissional, participação nos lucros obtidos com os nossos produtos e um ambiente de trabalho diferenciado e motivador.

Quanto estamos pagando? Isso só depende de você. Nossa escala de salários (aqui é CLT) para profissionais raros vai de R$ 1.000,00 (estagiário) a R$ 7.000,00 (engenheiro de software).

Você é a pessoa certa? Se sim, preencha o formuláro abaixo e envie-nos seu currículo.

É quase um manifesto ao desenvolvedor ágil. Parabéns pela evolução na forma de contratar.

Fonte: Twitter @andrediasbr

Apenas hoje fiquei curioso, qual seria o retorno de pesquisa em um site de colocação profissional das palavras: scrum, agile, pmi e pmp.

Seguem os resultados:

Scrum

Agile

PMI

PMP

PMI e Scrum

O link utilizado para a pesquisa foi: http://v.catho.com.br/buscar/empregos/?tipoBusca=palavra_chave&perfil_id=4

O Workshop será conduzido por Manoel Pimentel e Paulo Igor. Nesse treinamento o participante será imerso numa visão pragmática dos valores, princípios e práticas ágeis da metodologia Extreme Programming (XP), através de muitas dinâmicas e compartilhamento de exemplos reais, mostrando como a adoção da XP, em equipes de desenvolvimento, pode gerar software de forma mais ágil e com alta qualidade para as organizações e clientes que realmente valorizam seus investimentos em projetos de software.

Nesse workshop o participante também exercitará a aplicação real dos valores do XP através de algumas sessões de Coding Dojo, onde será possível praticar e melhorar as técnicas de programação, construindo em conjunto com outras pessoas uma aplicação, compartilhando experiências e exercitando boas práticas de programação orientadas a filosofia do XP.

O número de vagas é limitado, se inscreva no site http://www.tasafo.org/wsxp_inscricao.php

A ementa do workshop encontra-se logo acima do formulário de inscrição.

Confira no link PMI Launches New Communities of Practice

Fonte: Twitter Ricardo Vargas