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

Message from the Board of Directors

On September 15, Ken Schwaber resigned as President and Chair of the Board of Directors of the Scrum Alliance. Tom Mellor was elected President and Chair of the Board by the Board members. Kenexpressed to the Board his intentions to remain active in the Scrum community. The Board expresses its appreciation to Ken for his service and leadership. Additionally, Jim Cundiff is no longer Managing Director of the Scrum Alliance and a search is underway for a new managing director. The Board anticipates filling the position in the very near future. Questions can be directed to Jodi Gibson at jgibson@scrumalliance.org

posted by Anand Shah (22 Sep 09)

Fonte: Scrum Alliance

Há uma importante discussão acontecendo na lista ScrumDevelopment. Há uma dúvida sobre o papel do membro mais importante do time – o product owner. Jean Richardson começou a conversa com a seguinte questão:

Eu estou trabalhando com um cliente que é novo em Scrum. Até agora, eles estão muito anciosos. Nós tivemos e estendemos lições aprendidas na semana passada em um ½ projeto difícil e eles vêem Scrum como a resposta para suas preces. O seu gerente leu /Gerenciamento de Projetos Ágeis com Scrum/, e um dos membros do time está na metade do livro.

Entretanto, o gerente pediu uma reunião comigo no final desta semana em relação a “quem seria o Product Owner.” Eu acho que seu time está empurrando-o para compartilhar esse papel entre todos eles—ou ao menos 3 deles (ele próprio e mais dois). Então, minha questão é, como é que funciona compartilhar esse papel através de duas ou mais pessoas. Será que isso funciona bem? Se sim, o que é preciso para que isso funcione bem? Que tipos de coisas você vê acontecendo?

Isto é, evidentemente, uma questão ou ocorrência comum.  A maioria dos conselhos caiu em duas áreas:

Área 1: Você deveria ter somente um product owner.  Por exemplo, Dan Rawsthorne sugeriu:

Eu sempre tenho uma resposta simples para "quem será seu product owner". Eu pergunto: "quem deve ser responsável pelo sucesso? Quem tem um alvo em suas costas? Esse é o seu product owner." Na minha experiencia, o PO é normalmente ungido em seu exterior.

Isso trouxe uma série de observações interessantes, uma das quais evocando uma inconsistência na maneira que o product owner é tratado e percebido:

No entanto, isso não traz à tona uma dicotomia interessante para o Scrum? Se o PO é o único com a corda no pescoço da perspectiva de requisitos/ROI, por quê não há uma única pessoa com a corda no pescoço da perspectiva do time?

Eu pergunto porque eu já tive inúmeras conversas com os doutores do Scrum que apontam a falta de responsabilidade no time. Enquanto o time é responsável por tornar-se auto organizado e finalmente fazer o que precisa ser feito, não há nenhuma corda no pescoço quando eles não o fazem. Eu tenho visto os times lutando para se tornar auto organizados. Alguns nunca tem sucesso. É difícil de responsabilizar o time inteiro, especialmente quando muitos membros fazem o seu melhor.

Área 2: No front do "isso depende", o comentário de George Dinwiddie foi exemplar:

Sim, isso pode funcionar bem e ainda dividir a carga de trabalho entre os três. Isso também pode ser um desastre. Eu vi os dois.

Eles compartilham a mesma visão do projeto? Se não, qual a visão que os desenvolvedores tem?

Todos os três podem trabalhar na sala com os desenvolvedores? Se não, isso é uma bandeira vermelha para mim.

Os três podem tomar decisões rápidas juntos? Se não, acho que não irá progredir.

Eles podem "falar como uma só voz?" Se não, quem os desenvolvedores vão seguir?

Quando eles discordarem, tem uma maneira segura de resolver o conflito? Se não, quem os desenvolvedores vão seguir?

Para responder adequadamente a questão, deve existir um acordo sobre qual o papel e quais as responsabilidades reais de um product owner. É ser o ‘único pescoço em jogo’? Será que as responsabilidades são muito mais abrangentes de forma que não possam ser cumpridas em um grande ambiente? Quais são seus pensamentos e experiências?

Fonte: InfoQ

Scrum Flácido

por Martin Fowler
Janeiro 29, 2009

Existe uma bagunça que ouço em muitos projetos recentemente. Funciona assim:

– Querem usar um processo ágil, escolhem Scrum
– Adotam as práticas Scrum, e talvez até os princípios
– Depois de algum tempo, o progresso é lento, porque a base de código é uma bagunça

O que acontece é que eles não prestaram atenção à qualidade interna de seu software. Se você cometer esse erro, irá rapidamente descobrir que seu progresso foi desacelerado, porque é muito difícil adicionar novas funcionalidades que você gostaria. Você caiu no problema de Débito Técnico e seu scrum caiu de joelhos. (E se você esteve num scrum real, saberá que isso é uma Coisa Ruim).

Mencionei Scrum, porque quando vemos esse problema, Scrum parece ser particularmente comum, como o processo nominativo que a equipe segue. Para muitas pessoas, a situação é exacerbada pelo Scrum, porque Scrum é um processo centrado em técnicas de gerenciamento de projetos e deliberadamente omite qualquer prática técnica, em contraste (por exemplo) com Extreme Programming.

Defendendo o Scrum, é importante apontar, que só porque ele não inclui nenhuma atividade técnica dentro de seu escopo, isso não deve levar ninguém a concluir que ele não acha isso importante. Sempre que ouvi Scrummers proeminentes, sempre enfatizaram que você deve ter boas práticas técnicas, para ter sucesso com um projeto Scrum. Eles não dizem quais práticas técnicas devem ser, mas você precisa delas. Afinal projetos enfrentam problemas por causa de qualidade interna pobre o tempo todo, e o fato que muitos entram abaixo da bandeira do Scrum, parece ser mais pelo fato de Scrum ser popular no momento, do que qualquer coisa particular no Scrum. Popularidade e Difusão Semântica tendem a andar juntos.

Então, o que fazer a respeito?

A comunidade Scrum precisa redobrar seus esforços, em garantir que as pessoas entendam a importância de práticas técnicas fortes. Certamente qualquer tipo de revisão de projeto deve incluir o exame de quais práticas técnicas estão presentes. Se você estiver envolvido ou conectado a esse tipo de projeto, faça barulho se o lado técnico estiver sendo negligenciado.

Se estiver apresentando Scrum, garanta que está prestando atenção às práticas técnicas. Tendemos a aplicar muitas do Extreme Programming e eles se encaixam muito bem. Os XPers costumam brincar que com alguma justificativa, Scrum é apenas XP sem as práticas técnicas que a fazem funcionar. De qualquer forma, as práticas de XP são um bom ponto para se começar – e certamente serão muito melhores do que nada.

Sempre gosto de apontar que não são metodologias que levam ao sucesso ou fracasso. Usar um processo pode ajudar uma equipe a subir no jogo, mas no fim é a equipe que importa e que carrega a responsabilidade de fazer o que funciona para elas. Estou certo que muitos dos projetos Scrum Flácidos em andamento, prejudicarão a reputação do Scrum, e provavelmente a reputação maior de Ágil. Mas já que vejo Difusão Semântica como algo inevitável, não estou desproporcionadamente alarmado. Equipes que fracassam, provavelmente vão fracassar seja lá qual metodologias elas – erradamente – apliquem. Equipes que tem sucesso, construirão suas práticas sobre boas idéias e o papel da comunidade scrum é espalhar essas boas idéias.

Muitas pessoas estão olhando para Lean como a Próxima Grande Coisa Ágil. Mas quanto mais popular lean se tornar, mais vai incorrer nos mesmos problemas que Scrum está enfrentando agora mesmo. Isso não torna Lean (ou Scrum) sem valor, apenas nos lembra que Indivíduos e Interações são mais valiosos que Processos e Ferramentas.

Em muitas ocasiões, muitos membros da comunidade ágil reclamam que a certificação Scrum é sem sentido porque quase todos que fazem o curso recebem um certificado. Michael James, da Danube Technologies, escreve que em 1 Janeiro de 2009 este não será mais o caso.

No Scrum Gathering em Stockholm, os participantes deste outono (já CSM’s e CST’s) foram convidados a escrever uma versão beta do teste. A versão atual é um teste de múltipla escolha cujo objetivo é descobrir se a pessoa que faz o teste tem o mínimo de conhecimento sobre Scrum. Simon Kirk fez o teste e se saiu razoavelmente bem – mesmo testando o seu entendimento sobre o Manifesto Ágil. Tom Mellor, CST na State Farm, disse que sua pontuação foi 84/100 e esta foi a média para os instrutores (CSTs) que fizeram o teste. Além disso, ele constatou que o sigma estava baixo e que a nota mais alta foi 89.

Mike Dwyer, Coach ágil na BigVisible Solutions, preferia um teste mais profundo: “Pegue qualquer assunto em Scrum e peça para o aluno listar três argumentos válidos a favor e contra este assunto. Em seguida para descrever sua opinião e justificar. Não deveria haver mais que três questões respondidas e pelo menos dez questões feitas. Eu não quero chegar a um consenso aqui, eu quero respostas bem pensadas porque nós estamos sempre relacionados a novidades e aprendizado.” Enquanto Peter Stevens, do Scrum Breakfast, gostaria de um teste de interpetação de papéis. Uma série de situações e desafios seriam dados a pessoa que estiver se submetendo ao teste como o Daily Scrum from Hell. Sua pontuação estaria associada a como se saíssem nestas situações.

Tobias Mayer, da Agile Thinking, vê valor no teste dizendo:

…encoraja participantes de um curso CSM a reservar um tempo para ler livros, artigos, blogs e grupos de discussão para melhorar o entendimento acadêmico do Scrum, seja antes do treinamento ou posteriormente( o teste é para ser feito online, depois que o treinamento é finalizado). Em outras palavras, encoraja os potenciais CSMs a assumir a responsabilidade de seu próprio aprendizado e não somente esperar para ser mimado por um certificado depois de dois dias de treinamento sentados em uma classe.

Alistair Cockburn, autor do Agile Software Development, acha que o problema básico é mais profundo que somente um teste. Ele diz que pessoas assistem ao curso de CSM procurando por um Scrum Bootcamp que certifiquem eles como prontos para ser Scrum Masters, está além do problema. Ele acha que “milhares de pessoas têm certificados CSM sem possivelmente saber regras básicas do Scrum, o curso de CSM se tornou um Scrum Bootcamp (de fato)”. Ele sugere que é interesse da comunidade Scrum introduzir um Scrum Bootcamp que é direcionado para a maioria das pessoas e usar isto como uma introdução ao curso de Scrum Master que será de interesse de alguns milhares de pessoas.

Por último Tom Mellor, um membro do conselho da Scrum Alliance, nos lembra que:

Ken criou inicialmente o CSM como uma sátira ao PMI. Ele nunca planejou que o curso fosse para ensinar pessoas a serem ScrumMasters; ele queria que as pessoas entendessem (“master”) os conceitos, princípios, e regras do Scrum. É claro, ninguém, incluindo Ken, previu que Scrum se tornaria tão extraordinariamente popular. Baseado no imenso crescimento do CSM, foi uma decisão do conselho de direção da Scrum Alliance, colocar um nível de credibilidade em torno da certificação através de um teste – um elemento que estava visivelmente faltando. Esta decisão surgiu, francamente e de maneira simples, do reconhecimento da demanda de muitas organizações e pessoas para colocar um elemento de integridade para a certificação.

Itens anteriormente em InfoQ que mencionam aspectos relacionados a certificação: We Vouch For e Martin Fowler on Avoiding Common Scrum Pitfalls

Fonte: InfoQ