Um Arquétipo de Problema

Imagine a seguinte situação: você está bem acima do peso e decide iniciar uma dieta. Para isso, foi a um nutricionista, aprendeu várias dicas sobre alimentação saudável e elaborou uma dieta infalível para atingir a tão desejada redução de peso. Mas no primeiro dia da dieta, você é convidado para um super almoço em comemoração ao final de um importante projeto em sua empresa. Nesse almoço, você pensa “ah, só hoje não vai fazer mal!”. E imbuído desse pensamento, você literalmente “mete o pé-na-jaca” e come e bebe de tudo.

No dia seguinte, após muito “sal de fruta”, você “realmente está decido” a retomar sua missão e, até a cumpre no café da manhã e no almoço. Contudo, ao final do expediente, você recebe uma ligação convidando-o para um divertido happy-hour com aqueles “brothers” que há muito tempo não os via. E o mesmo arquétipo de comportamento ocorre nos dias seguintes, até que você esquece totalmente de sua missão e jogue a toalha definitivamente.

Conhecimento x Atitude

Observe que nesse cenário não lhe faltavam conhecimentos sobre dietas ou sobre as qualidades dos alimentos, mas sim, houve um típico caso de autossabotagem. Essa autossabotagem ocorreu pois você não criou uma forma de lidar com as perdas das “coisas” que você teria que abrir mão para emagrecer. E esse cenário de perdas é guiado por seu modelo mental, que é composto por valores e crenças sobre o que é ou não é importante para você. E esse sentimento de perda lhe fez desenvolver pensamentos que culminam com uma falta de atitude para iniciar ou manter uma mudança.

Uma boa forma de você entender isso é lembrando do famoso modelo que indica que competência é formada pelo acrônimo CHA (Conhecimento, Habilidades e Atitudes). Onde conhecimento obviamente é tudo aquilo que você aprende (não importa o meio), habilidade é sua proficiência em fazer algo bem feito (é necessário ressaltar que a habilidade vem por meio da execução ou repetição contínua daquele conhecimento) e a atitude consiste em você ter os comportamentos de “iniciativa e acabativa” para por o seu conhecimento em prática e desenvolver de forma deliberada, uma sustentável e perene habilidade.

Portanto veja que no corriqueiro cenário acima, você teve o conhecimento, mas não teve a atitude necessária para iniciar e manter a disciplina de uma dieta.

No Mundo Corporativo

Efeito semelhante acontece em outros contextos, sejam pessoais ou profissionais. No campo profissional, é comum ver nas empresas diversas iniciativas de consultoria ou mentoria para que seus colaboradores desenvolvam mais conhecimentos sobre novos processos ou novas e melhoras técnicas de trabalho. Contudo, em igual proporção, é comum ver que muitas dessas iniciativas são frustradas pois os seus colaboradores não têm atitude suficiente para manter tais melhorias. Não ter essas atitudes não significa maldade ou má fé por parte dos colaboradores. Mas essa lacuna de atitude existe pois os colaboradores por muitas vezes não acreditam ou não enxergam importância naquela iniciativa.

Na prática, essa “não-ação” de uma determinada pessoa pode ser em função de como o seu modelo mental lhe faz perceber aquele assunto. Essa questão de percepção é o divisor de águas entre ter um pensamento que lhe faz agir ou ter pensamentos que lhe deixa parado.

Propósito do Coaching

A percepção pode estar sujeita a um perigoso ciclo de distorções que o indivíduo tem. Segundo o autor Timothy Gallwey, esse ciclo de distorções atua diretamente no senso de responsabilidade, nos resultados obtidos e principalmente, na autoimagem que indivíduo tem. Esse ciclo de distorções é o que causa pensamentos como “não posso!”, “não consigo!”, “não vai dar certo!”, “nunca ninguém me apoia!”, etc. Esses pensamentos, de uma maneira imperceptível, são o principal responsável pela inércia de atitudes de uma pessoa face aos seus desafios e desejos.

Ajudar um indivíduo a explorar os seus modelos mentais e fazer com que por si só tome consciência de suas percepções e suas distorções é um dos objetivos do processo de Coaching. Em linhas gerais, Coaching é um processo focado em desenvolvimento de potencial e performance humana para se atingir determinado resultado. Esse processo de desenvolvimento acontece tipicamente entre dois papéis: o Coachee e o Coach. O Coachee é o indivíduo responsável por atingir uma determinada meta e, para trilhar esse caminho, recebe a ajuda do Coach.

Papéis e Como Funciona o Processo de Coaching

O Coach é o profissional que, por meio de um ciclo de sessões individuais, fornece o processo formal de Coaching ao Coachee. Essas sessões, tem como principal objetivo fazer com o que o Coachee explore o seu próprio modelo mental, de forma que o mesmo consiga quebrar o ciclo de distorções presente em seu modelo mental, e com isso, gerar ações para alcançar os resultados planejados.

O Coach faz com que o Coachee se visualize como um sistema composto por diferentes partes interligadas para um propósito. E como já vimos anteriormente, esse sistema também pode ser chamado de modelo mental, que é composto por partes que representam seus valores, suas crenças, seus propósitos, suas percepções e principalmente, os seus comportamentos.

Por meio dessa visão sistêmica, o Coach promove uma metaposição do Coachee, ou seja, o Coach ajuda o Coachee a adotar diferentes pontos de vista, para que ele se visualize por outras perspectivas. Essa visão sistêmica multidimensional torna possível o uso de diferentes técnicas, que usadas sozinhas ou combinadas, proporcionam uma mudança em alguma parte do modelo mental do indivíduo. O objetivo dessa mudança é causar uma cadeia de efeitos positivos em seu sistema pessoal, como por exemplo, ajudar o Coachee a mudar o ciclo de distorções que o impede.

Coaching Num Contexto Ágil

Um bom processo de Coaching é baseado numa Meta, que desperta Comportamentos, que geram determinados Resultados e esses resultados são passíveis de um processo de Melhoria Contínua.

Para apoiar essa melhoria contínua para um indivíduo, o processo de Coaching funciona como um espelho ao Coachee. Com esse espelho, o Coachee pode visualizar quais resultados ele está obtendo e principalmente aprender de forma empírica como melhorar seu comportamento para alcançar resultados ainda melhores.

Para atuar como uma base para esse ciclo de melhoria contínua de um Coachee, uma boa sessão de Coaching normalmente contém a seguinte estrutura:

• Quais os aprendizados desde a última sessão?
• Quais os avanços que o Coachee teve desde a última sessão?
• O que podemos desenvolver (ou melhorar) a partir dessa sessão atual?
• Quais os aprendizados dessa sessão atual?
• E quais tarefas o Coachee identificou e se responsabilizou em desenvolver até a próxima sessão?

Essa característica faz com o que o processo de Coaching tenha uma sinergia muito grande com a filosofia Ágil. Essa sinergia acontece pois todas os métodos ágeis são baseadas na ideia de melhorar continuamente uma forma de ação, para melhor atingir um determinado objetivo.

Nesses ambientes que estão adotando a filosofia Ágil, é comum haver um Coach como um profissional externo à equipe para auxiliar o líder ou a própria equipe para melhorar seu comportamento no atingimento das suas metas.

Também é importante salientar que o processo de Coaching pode ser usado de maneira informal como uma competência de um líder num projeto. O propósito dessa competência é ajudar o líder a melhorar o seu comportamento no desafio de liderar uma equipe ágil de desenvolvimento. É possível identificar que um dos principais desafios na adoção de métodos ágeis é o desenvolvimento de novas competências necessárias para atuação em novos papéis e como forma de representar uma nova cultura organizacional fruto do paradigma ágil. Dessa forma, o desenvolvimento dessas novas competências passa pela mesma questão de ter um conjunto de conhecimentos, que serão a base para ter atitudes diferentes e que a longo prazo, vão lhe proporcionar alguma habilidade na execução daquele conhecimento.

Conclusão

De maneira geral, alcançar algum resultado gera a necessidade de ter um desempenho melhor e, para ter um desempenho melhor, é necessário desenvolver um aprendizado sobre uma nova forma de pensar, de sentir e principalmente de agir. Essas novas formas, devidamente inter-relacionadas e alicerçadas em valores e propósitos, ajudarão um individuo a chegar com sucesso numa determinada meta. Portanto, quando você estiver com a necessidade de alcançar objetivos, experimente contar com a ajuda de um Coach, pois com certeza sua caminhada em direção a um resultado será muito mais efetiva. Veja que assim como o exemplo de dieta do início do texto, o ponto crítico em adoções ágeis também continua sendo a questão da atitude. Cabe então ao processo de Coaching ajudar o indivíduo a explorar e tratar os seus próprios obstáculos para ter verdadeiras atitudes ágeis.

A AdaptWorks inova mais uma vez, trazendo pela primeira vez ao Brasil o treinamento “Manage Your Project Portfolio”, ministrado por Johanna Rothman.

Johanna Rothman, é fundadora do Rothman Consulting Group, uma líder reconhecida na comunidade Agile. Escreveu vários livros sobre gestão, incluindo “Manage It! Your Guide to Modern, Pragmatic Project Management”, “Behind Closed Doors: Secrets of Great Management” (com Esther Derby), “Hiring the Best Knowledge Workers, Techies & Nerds”, “Corrective Action for the Software Industry” (com Denise Robitaille) e “Manage Your Project Portfolio, Increase Your Capacity and Finish More Projects”, sendo este último o mais recente.

Este último livro conta-nos, essencialmente, sobre como identificar os primeiros projetos a serem realizados e os que jamais devem seguir adiante. Muitas organizações têm projetos que vêm se estendendo há muito tempo e talvez o caso seria interromper esses projetos, pois eles deixaram de gerar valor. Ou, em alguns casos, um outro rumo pode ser necessário ao projeto, assim como dividi-lo em dois, por exemplo.

O treinamento que Johanna fará aqui no Brasil abordará justamente essas questões, entre outras, tais como:

• Desenvolver e manter um portfólio ágil, aplicando práticas ágeis e lean.
• Avaliar os projetos, classificá-los e selecioná-los para incluir no portfólio.
• Criar confiança entre todos os envolvidos, permitindo uma melhor colaboração.
• Iterar sobre o portfólio e medir o essencial em projetos e programas.

Em novembro de 2011, ela participou da “Developer Conference” na Suécia, em uma sessão em que abordava o planejamento de um portfólio ágil.

Depois de 03 turmas no Brasil, já temos agora mais de 50 pessoas que participaram do nosso treinamento Management 3.0, que é licenciado por Jurgen Appelo – autor do livro com mesmo título.
O feedback destas turmas foi bastante positivo, seguindo o nosso novo modelo de avaliação de treinamentos, temos um NPS (Net Promoter Score) de 9.2, o que nos rendeu inclusive o seguinte tuíte do autor:

Mas, o que discutimos nestas turmas? Como padrão, no início de cada um destes treinamentos, avalíamos as principais questões de cada aluno que possam ser atendidas por uma das visões do Management 3.0 e trabalhamos nelas em cada parte do treinamento. Dentro deste contexto, os pontos abaixo foram os mais trabalhados nestas turmas:

• Como trabalhar na resistência que as pessoas têm a um processo de mudança?
• Como posso manter as equipes fiéis à proposta de mudança?
• Como identificar o que motiva cada pessoa de um time?
• Como desenvolver a maturidade da equipe para melhorar a auto-organização e colaboração?
• Como motivar o time a auto-organizar de verdade?
• Como influenciar outros departamentos da empresa a adotarem/aceitarem métodos ágeis?
• Como melhorar o entendimento do cliente por valor?
• Como favorecer a troca de conhecimento?
• Como liderar em ambiente fortemente competitivo e com projetos de alta complexidade?
• Como adaptar novas pessoas no ritmo de um time ágil?
• Como posso manter a empresa como um todo alinhada e respeitar as limitações de negócio?
• Como manter alguma ordem em um ambiente sem previsibilidade?
• Como ajudar o comercial a entender o novo mindset de Agile?
• Qual é a melhor forma para dar feedback para times e indivíduos?
• Como criar disciplina nos métodos ágeis para projetos grandes com equipes remotas?
• Como lidar com um Product Owner ausente?
• Como unir times que trabalham com tecnologias e metas diferentes?
• Como favorecer a comunicação entre times?
• O que fazer para a auto-organização não desmotivar especialistas (arquitetos, testers, etc.)?
• Como avaliar o progresso do investimento em conhecimento para o time?
• Como melhorar meus conhecimentos de liderança?
• Como posso remover o medo que as pessoas tem em “prestar contas” (accountability)?
• Como trazer o cliente para dentro do processo de mudança?
• Como envolver stakeholders funcionais em meus projetos?
• Como fazer com que o time não perca a motivação em projetos com prazo definido?
• Como trabalhar com metas setoriais (PMS) em um ambiente ágil?
• Como dar empoderação para times remotos?
• Como empoderar sem se desligar do que tem que ser feito?
• Como gestor, ao empoderar times não estarei “cavando minha própria cova”?
• Quais as melhores estratégias para liderar uma transformação de Agile na minha empresa?

Por mais que possa não haver uma resposta exata para algumas destas questões, todas elas –  e outras – foram bastante discutidas, reunindo experiências e confrontando possibilidades. O resultado tem sido bastante interessante e praticamente todos os alunos têm saído de sala de aula com um “plano de ação” para aplicar de imediato vários conceitos do Management 3.0.

E você, em quais dos seus problemas você acredita – ou gostaria – que o Management 3.0 possa lhe ajudar?

Se você se encontra nesse dilema pode ter certeza que não está sozinho.

Nos tempos atuais, cada vez mais temos muitos projetos para iniciar, sem ao menos terminarmos aqueles que já começamos. Parece que o conceito de “multitasking” está cada vez mais enraizado nas corporações, desenvolvedores trabalhando em vários projetos em paralelo, cada um com uma natureza de negócio diferente, gerentes de projetos conduzindo 4 ou 5 projetos ao mesmo tempo, enfim, um verdadeiro caos que não é gratificante nem para esses profissionais e muito menos para as empresas. E como ficam os múltiplos projetos emergenciais tratados integralmente como de alta prioridade? Quantos débitos técnicos estamos gerando nas entregas, em decorrência da falta de foco ou até mesmo porque os próprios desenvolvedores não têm tempo de atuar? Os clientes não estão preocupados com a quantidade de projetos que você está conduzindo, mas por outro lado estão cuidando de seus próprios produtos, então qual é a estratégia a ser adotada?

A gestão de um portfólio de projetos é um meio de organizar o fluxo de entrada de projetos, além de incentivar a que cada um deles termine, ajudando a restringir o que realmente trará valor para o negócio. O portfólio ajuda a limitar o número de projetos ativos e o quanto menor for o número de projetos em andamento, menor será a competitividade de alocação de pessoas entre eles. O resultado da correta gestão de portfólios é, por incrível que pareça, um maior fluxo de entrega de projetos para a empresa, focando no que realmente trará benefícios.

A combinação dos métodos ágeis ajuda a criar uma gestão ágil de portfólio, onde podemos considerar não somente projetos mas também épicos e features dentro do dashboard e limitar a quantidade deles, priorizando aqueles que são de maior valoração para o negócio. E nesse sentido combinar com os princípios do pensamento Lean, ou seja: pensar em termos de valor, ajudando o cliente a defini-lo; criar um fluxo que permita que os problemas fiquem transparentes para todos, propiciando condições suficientes para que a equipe consiga realizar as suas tarefas sem interrupções; incluir métricas visíveis para todos, tais como gráficos de velocidade, burndown/burnup e o backlog do portfólio; criar um mecanismo que permita que as pessoas terminem o seu trabalho antes de começar um outro e eliminar o multitasking.

À medida que você avança com o seu portfólio ágil, você percebe que acaba entregando mais features para o seu cliente, os projetos terminam com antecedência, você tem menos features emergenciais, as pessoas focam em uma feature por vez, finalizam aquelas de maior valor em um determinado timebox, além de permitir que a própria equipe construa o produto junto ao cliente e evolua a sua própria capacidade. Neste sentido, os gerentes precisam de times menores e mais focados, finalizando features com mais agilidade.

Johanna Rothman, líder muito reconhecida na comunidade Agile, referência no assunto sobre gestão ágil de portfólio, autora de alguns livros sobre gestão, entre eles “Manage It!”, “Behind Closed Doors”, “Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People” e “Manage Your Project Portfolio”, discute sobre como gerenciar o portfólio de forma ágil em uma entrevista na InfoQ.

A AdaptWorks irá continuar esse assunto para você entender como gerenciar o seu portfólio de forma ágil em seus próximos posts, aguarde!

Não são poucas as empresas e times de desenvolvimento que vem questionando o papel do ScrumMaster. Precisamos realmente de um ScrumMaster? O que faz um ScrumMaster se o time já sabe auto-organizar? E se não há impedimentos, o que ele deve fazer? E se não uso mais Scrum, o que farei com o ScrumMaster? Neste post pretendo discutir esses e outros pontos para tentar desmistificar o trabalho do ScrumMaster.

Por que preciso de um ScrumMaster?

Se você revisitar o paper que “oficialmente” deu origem ao Scrum (Scrum Development Process, Ken Schwaber, 1995) e procurar por alguma referência ao papel de ScrumMaster não encontrará absolutamente nada! Isso porque quando da “criação” do Scrum este papel simplesmente não existia. Mas então por que ele foi criado? Essencialmente, porque Scrum é difícil de ser colocado em prática, a resisência é muito grande, e foi percebido que se não houvesse alguém realmente comprometido e dedicado a fazer isso acontencer, a mudança não aconteceria.

Quais as principais dificuldades para colocar Scrum na prática?

Segundo a edição mais recente da pesquisa “State of Agile Survey”, organizada pela Version One, 58% das empresas que disseram usar Agile mencionaram Scrum como o método que utiliza, e mais 17% citaram que usam Scrum e Extreme Programming (XP). Nesta mesma pesquisa, quando perguntados sobre as principais barreiras para fazer Agile funcionar, responderam:

• [ 51% ] Habilidade para mudar a cultura organizacional
• [ 40% ] Resistência geral a mudança
• [ 40% ] Disponibilidades das pessoas com as habilidades necessárias
• [ 34% ] Suporte da Gestão
• [ 31% ] Complexidade ou tamanho do projeto
• [ 29% ] Colaboração do Cliente
• [ 21% ] Confiança na habilidade para escalar Agile
• [ 19% ] Tempo percebido para transição
• [ 13% ] Restrições de orçamento
• [ 12% ] Nenhum
• [ 06% ] Outros

Bom, se sua empresa está decidida a aplicar Scrum a ponto de ter alguém com um papel chamado “ScrumMaster”, os impedimentos acima são os principais a serem combatidos por este profissional. Mas aí eu pergunto: quantos ScrumMasters você conhece que estão se envolvendo nos impedimentos organizacionais? quantos estão influenciando a Gestão para conseguir mais apoio? Quantos estão trabalhando com as pessoas para reduzir a resistência a mudanças, trazendo o cliente para dentro do projeto, ajudando áreas resistentes a entender e se aproximar de Agile…quantos?

Infelizmente eu tenho visto pouquíssimos, o que portanto me faz acreditar que grande parte dos questionamentos em volta deste papel seja pelo fato de poucos ScrumMasters estarem conseguindo fazer bem o seu trabalho. Portanto, a culpa é do ScrumMaster, certo? Não necessariamente. Grande parte do problema tem sido o fato  das empresas não empoderarem este papel de forma adequada. Não estão dando a ele a autonomia necessária para se envolver em questões organizacionais que estão impactando aquele projeto.

O que tem faltado aos ScrumMasters?

Segundo Thiago Santos, que atua em papel equivalente ao de ScrumMaster na R7.com, “Faltam mais habilidades humanas, relacionadas a técnicas de facilitação, coaching e motivação de pessoas.”. Além disso, pelos pontos citados no “State of Agile” podemos perceber claramente que falta aos ScrumMasters investir no estudo de gestão e liderança, e ainda no conhecimento organizacional. Se grande parte dos reais impedimentos estão fora do ambiente de projeto e muitas vezes até fora de TI, um ScrumMaster que não conseguir influenciar outras áreas da organização se tornará fraco.

Mas se a empresa (ou departamento/área) não deu o nível de empoderação necessária ao ScrumMaster, é dever dele influenciá-la para conseguir isto. “Os primeiros meses foram terríveis, para praticamente todos os impedimentos que apareciam eu tinha que dar a resposta ‘Não tenho como resolver, vou ter que escalar.’. Passei então a investigar porque era tão difícil para a Gestão me dar autonomia, e comecei a ver que não era chatisse ou necessidade de mostrar poder. Trabalhei então nos pontos que descobri tentando mostrar ao PMO como poderiam ter a mesma ‘segurança’ ao me dar um certo nível de autonomia em alguns pontos.”. diz Charles Bennini, brasileiro que trabalha como ScrumMaster no Coutts Bank em Londres.

ScrumMasters precisam ainda entender que em sistemas complexos a gestão é diferente do que estamos acostumados a ler nas cartilhas de “boa gestão”. Em sistemas complexos o conceito de auto-organização é natural, e portanto a gestão tem que ser focada no sistema e não no trabalho que as pessoas fazem ou deixam de fazer. Recentemente fiz o seguinte comentário no blog da Lambda3 em uma discussão relacionada à figura do gerente:

Basicamente minha mensagem é: novos gerentes devem esquecer a idéia de gerenciar pessoas…e devem aprender a gerenciar sistemas, “apenas” isso. Uma mudança difícil, mas com impactos radicais. Restrições são necessárias em sistemas complexos – se não estes se tornam caóticos – e é aí onde entra a figura dos “novos” gerentes.

[...]

No meu ponto, o gerente A gerencia X que é o sistema onde B, C, D, E trabalham o sistema onde as pessoas trabalham, e não o trabalho das pessoas.  Mas para garantir que este sistema não caia na falácia da linearidade…e nem no caos; ele precisa trabalhar com as restrições do ambiente, e para isso precisa trabalhar – dentre outras coisas – com os fatores humanos (ufa…rs).

É um trabalho full-time?

É comum os livros de Scrum afirmarem que um ScrumMaster deve ser um trabalho em tempo integral. Mas isso, na minha opinião, só faz sentido se ele possuir (ou estiver em busca de) empoderação suficiente para atuar em problemas que envolvam a estrutura da empresa, ou seja, quando ele realmente assumir a figura de um agente de mudança, que na verdade é o que esperamos dele. Mas caso isso não aconteça acho difícil conseguir uma justificativa para mantê-lo em tempo integral, aí o natural vai ser atribuir a ele novas responsabilidades e, comumente, dar a ele um outro título. “Apesar de ser um trabalho em tempo integral, como o título ScrumMaster não representava bem o papel, este passou a ser chamado de ‘Consultor de Projetos’.” diz Thiago Santos da R7.com.

Além disso há ainda a situação de empresas (ou times) pequenas, que possuem uma natural auto-organização e pouca interrupção da cultura organizacional. É bastante comum nestes casos haver o compartilhamento do papel de ScrumMaster com outras funções ou papéis.

O que um ScrumMaster deve estudar

É quase um consenso que o que mais tem faltado aos ScrumMasters tem sido habilidades de gestão e liderança, “ScrumMasters precisam de habilidades menos técnicas e mais interpessoais” afirma Milene Fiorio, Especialista em Agile na Petrobras, que cita que na sua área ScrumMasters são responsáveis por auxiliar os desenvolvedores e resolver os impedimentos, e comumente fazem parte do próprio time de desenvolvimento.

“Logo após servir e dar coaching aos times [de desenvolvimento], os [Certified] ScrumMasters devem considerar servir e dar coaching aos gerentes e líderes da organização” escreveu Jurgen Appelo, autor do livro Management 3.0, no post “What Comes After Certified Scrum Master?”.

Para finalizar, minha recomendação de estudo para ScrumMasters está concetrada em 03 pontos:

• Complexidade Organizacional: Teoria da Complexidade, CAS – Complex Adaptive Systems, System Thinking, o impacto da complexidade nas organizações, organizational design, …
• Gestão e liderança em Sistemas Complexos: Management 3.0 (Leia Você sabe o que é Gestão 3.0?), Beyond Budgeting, Radical Leadership,  …
• Relacionamento de Agile com: Governança de TI, Operações, Área de Negócios, e outras áreas e processos da organização.

Recentemente tive uma conversa com o @cmilfont e o @lucascs via twitter (se é que é possível chamar isso de conversa…)

A conversa girou em torno de uma pergunta feita pelo Milfont:

Pq voce faz um pull request para um projeto open source e não admite fazer nada de graça para seu emrpegador?

Minha idéia inicial girou em torno de que são duas relações diferentes.

O mundo OpenSource inicialmente te dá tudo que ele tem e diz que se algum dia você tiver vontade, você pode contribuir de volta. Isso sem contar aquela sensação de estar trabalhando para um bem maior, etc.

Já o seu empregador, em geral apenas te dá algo se você der algo pra ele primeiro. Você só recebe o salário se trabalhar.

Eu achei que essa diferença de relação já era suficiente para desmotivar o profissional a colaborar com outros projetos da empresa.

Alguns dias depois, eu assiti à palestra do Magno sobre Metas Compartilhadas e isso me deu um estalo.

Será que o problema não é que os profissionais de nossas empresas se focam apenas nas metas do projeto, e não da empresa? Como podemos criar metas entre os projetos para incentivar a colaboração dentro da empresa inteira ao invéz de apenas no projeto? Será que é util para a empresa?

O que vocês acham?

Palestra Inédita com Jurgen Appelo – 22 de Agosto das 19hs às 22hs.

Jurgen Appelo, autor do livro Management 3.0: Leading Agile Developers, Developing Agile Leaders estará no Rio de Janeiro, dia 22 de Agosto e ministrará uma palestra de 120 minutos (com tradução simultânea) sobre o tema de seu livro que descreve o papel do gestor nas organizações ágeis.

Público Alvo

Gestores que querem se tornar ágeis e Agilistas que querem se tornar Gestores.

Frase pinceladas do Livro

• Por 10 anos o Agile ignorou o importante papel da gestão e por isso muitos gerentes ignoram o Agile.
• A gestão ágil é uma parte do Agile muitas vezes esquecida.
• Quando as organizações adotam desenvolvimento ágil de software, não só os desenvolvedores e gerentes de projetos precisam aprender novas práticas; Gestores e líderes de equipe de desenvolvimento também devem aprender uma abordagem diferente para liderar e gerenciar as organizações.
• Vários estudos indicam que a gestão é o maior obstáculo nas transições para o desenvolvimento ágil de software.
• Os gerentes precisam aprender qual o seu novo papel nas organizações de desenvolvimento de software no século 21, e como tirar o melhor proveito do Agile.

Antes da palestra do Jurgen Appelo, haverá ainda a seguinte apresentação:

Scrum e Mudança Organizacional

Esta palestra, ministrada por Alexandre Magno, objetiva alertar sobre os grandes riscos que as empresas terão caso ignorem o fato de que Agile deve permear a organização para gerar bons resultados.

Testes devem começar dessa forma:

Primeiro, Deus criou o céu e a terra…
E Deus disse, “Haja luz”…

E devem terminar da seguinte:

a besta que viste, era e não é, está para emergir do abismo e caminha para a destruição

Quando você começa a escrever o teste, não deve existir nenhuma dependência com o estado de um teste anterior. Se você vai usar o banco, ele deve estar vazio. Se vai usar uma classe que guarda estado em um campo static (ugh!), precisa (além de refatorar esse código), reiniciá-la.

Tem uma razão para que isso seja feito. Cada teste deve se comportar como um experimento que sempre dará o mesmo resultado (desde que você não mude o código) não importa quantas vezes você o rode.

Porque você quer isso? Para que não aconteçam falsos negativos e nem falsos positivos. Seus testes precisam ser confiáveis ou você vai passar a ignorá-los.

Imaginem o seguinte caso:

public void testaQueSalvaOsDados(){
	//Código que salva "bobagem"

	String dado = //código que recupera "bobagem";
	assertEquals("bobagem", dado);
}

public void testaQueListaDados(){
	List<String> dados = //código que busca todos os dados;

	assertEquals(1, dados.size());
	assertEquals("bobagem", dados.get(0));
}

Se você rodasse esses testes, o segundo teste passaria apenas na primeira vez. Após isso, ele iria falhar no primeiro assert (o do tamanho da lista).

Esse é um caso bem óbvio de utilização de efeitos colaterais de outro teste. E pode acontecer coisa pior. Imagine que depois de rodar os testes a primeira vez, você quebra o “código que busca todos os dados” e ele passa a trazer apenas o primeiro encontrado. Você terá um bug muito difícil de encontrar, porque os testes passam.

Novamente, esse é um caso bem óbvio. Interações bem mais sutis que essas podem acontecer e você vai sofrer muito para encontrar.

Por isso, sempre que seu teste causar algum efeito colateral, desfaça esse efeito. A sanidade dos programadores que vão dar manutenção no seu código agradece.

Se quiser aprender mais sobre testes, dê uma olhada em nosso treinamento Scrum Developer Skills.

Semana passada eu presenciei uma cena inusitada (talvez nem tanto). Estava esperando minha namorada sentado em um estabelecimento comercial, quando o dono do lugar sobe as escadas nitidamente irritado e, sem ligar muito para mim ou os outros dois clientes que estavam na sala, começa a discutir com a secretária, perguntando porque Fulano não foi fazer a entrega à Ciclano. A resposta da secretária foi curta, simples e precisa. “A minha parte eu fiz”. Ela complementou a frase com algo que nem lembro mais, mas essa primeira frase foi marcante.

O que estava acontecendo? Uma entrega não foi feita. Um cliente está insatisfeito. Um chefe está irritado e a secretária não quer correr o risco de ser culpada pela entrega não feita.

Já viram algo semelhante na empresa onde trabalham? Acho que muitos vão responder afirmativamente.

A ação do dono do lugar nitidamente foi uma caça às bruxas. Ele nem pensou que talvez resolver o problema do cliente fosse melhor que procurar o culpado.

Mas o que me chamou a atenção dessa vez foi a ação da secretária.

Sem pensar duas vezes, ela se exime da culpa. Após se eximir da culpa, ela foi tentar solucionar o problema. Essa sequencia de ações mostra que existe algo de muito errado dentro dessa empresa.

Se antes de procurar qualquer solução a pessoa precisa deixar claro que não é culpado, nitidamente existe uma relação de opressão (afinal, se ela for a culpada e o cliente importante, ela pode ser demitida). A cultura dessa empresa não permite erros. Se não permite erros, não permite aprendizado.

Deixemos essa empresa de lado e pensemos em nossas empresas. Trabalhamos com TI, correto? Seja desenvolvendo, gerenciando, dando treinamentos, ou qualquer outra coisa. Para TI, aprendizado e inovação são simplesmente vitais. A cada dia temos que fazer coisas que ninguém nunca fez antes. Cada linha de código nunca foi escrita antes (pelo menos não por aquela pessoa naquele projeto). Com certeza vamos errar. E quando errarmos, o que vai acontecer? Se você estiver em um ambiente opressivo, aprendizado não vai ser a sua primeira preocupação.

Uma das coisas que aprendi lendo o Artful Making do Lee Devin (e depois com o incrível treinamento homônimo também do Lee) é que para trabalhos criativos (como é o desenvolvimento de software) é necessário que exista um ambiente seguro para você errar, pois senão não conseguirá ir para frente. Errar deve fazer parte do seu dia a dia e não ser algo temido. Deve ser visto como uma oportunidade de aprendizado e não como um atraso no projeto.

Scrum é um processo empírico, correto? E processo empírico implica em errar e aprender com os erros. Para que Scrum funcione corretamente na sua empresa muitas vezes são necessárias mudanças culturais e comportamentais. Essa é uma delas.

Durante o ano passado fui bastante questionado sobre qual era a minha posição quanto ao uso do Kanban em projetos de desenvolvimento de software. Como naquele momento meu contato com este método ainda era pequeno, eu me reservei o direito de por várias vezes dar a simples resposta “Ainda não tenho uma posição totalmente formada sobre o assunto, a princípio algumas coisas fazem bastante sentido para mim e outras me deixam preocupados.”. Pois bem, depois de bons meses de pesquisa, estudo e algumas aplicações práticas, compartilho com vocês o que acho sobre o assunto.

Recapitulando

Conforme mencionado em recente post do Tiago Motta aqui no blog AdaptWorks, o Kanban que estamos falando aqui é uma espécie de derivação do modelo de cartões do Sistema Toyota de Produção para o desenvolvimento de software. Esta derivação, popularizada sob a liderança do David J. Anderson (aquele do time que criou a FDD – Feature-Driven Development), é formada principalmente por três princípios: fluidez, valor e pessoas. Estes princípios criam forma através de práticas bem interessantes, como a definição de um Limited Work-In-Progress nas filas de trabalho.

Talvez o ponto de maior diferenciação deste Kanban para os mais conhecidos métodos ágeis, como Scrum e Extreme Programming, seja o fato dele trabalhar com um fluxo cadenciado, enquanto os outros focam seu trabalho no conceito de time-box.

Caso você ainda não esteja familiarizado com a idéia do Kanban para desenvolvimento de software, sugiro fortemente a leitura do seguinte material:

• Kanban e Scrum: obtendo o melhor de ambos do Henrik Kniberg
• Kanban: creating a kaisen cultures… do David J. Anderson

Menos prescrição

Se você trabalha ou conhece bem os conceitos do Scrum, provavelmente ao ler sobre Kanban fará alguma das perguntas abaixo:

• Cadê o Product Owner? E o ScrumMaster?
• Meu time não é multi-disciplinar?
• Não faço planejamento de uma Sprint? Como assim não há Sprint?
• E a melhoria contínua? Não paro para pensar em como melhorar produto e processo?

Veja, essas perguntas não são tão diferentes das que muitos fazem quando estão partindo de um método waterfall-like para os ágeis:

• Cadê o Gerente de Projetos?
• Não há hierarquias nos papéis?
• Não faço um planejamento detalhado no início do projeto? Como assim não há escopo fechado?
• E meus artefatos? Cadê meu cronograma?

Essa reação sempre se repetirá quando você estiver de saída de um processo mais prescritivo para um mais leve, com menos coisas definidos. E da mesma forma que Scrum é menos prescritivo que muitos dos métodos waterfall-like, o Kanban é sim menos prescritivo que o próprio Scrum.

Hmmm, então significa que Kanban é uma evolução do Scrum? Não é bem por aí. Adaptabilidade é algo maravilhoso e que obviamente sempre será beneficiada  quando do uso de métodos menos prescritivos. No entanto o quão “adaptável” deve ser o seu processo é, na minha opinião, mais uma das decisões que você deve tomar empiricamente, projeto a projeto. Em algumas situações uma solução com mais processos definidos pode sim ser mais adequada que uma com menos. Já em outras isso pode travar as pessoas e burocratizar o trabalho. Scrum pode ser burocrático demais para alguns cenários? Não tenho dúvida que sim, mas também pode ser aberto demais para outros. O mesmo digo em relação ao Kanban.

Fluxo ou pacote?

Essa, na minha opinião, é a principal pergunta que você deve fazer quando da decisão de usar Kanban ou não. O conceito de time-box, rigidamente utilizado pela maioria dos métodos ágeis, dá lugar à procura por fluidez dentro de um processo baseado em fluxo unitário. O jogo funciona mais ou menos assim:

• uma padaria waterfall planeja no início do dia a quantidade total de pães que precisará e então os produz faseadamente. Teremos todos os pães prontos de uma única vez, talvez, ao final do dia.
• uma padaria Scrum define time-box’s rígidos e no início de cada “rodada de produção” estima quantos pães é capaz de fazer dentro daquele tempo. Teremos, por exemplo, pequenas fornadas de pão saindo a cada hora.
• uma padaria Kanban trabalhará de forma fluída: planejando, construindo e entregando pão a pão continuamente. O primeiro pão pode ficar pronto em 02 minutos, e já estar disponível para o consumo, o outro pode vir 05 minutos depois, o outro 01 minutos, e por aí vai, fluindo.

Lógico que o pão aqui é apenas uma analogia, mas com ela espero que você consiga perceber que, dependendo do que você precisa, uma dinâmica pode parecer mais interessante que a outra. Um Product Owner pode muitas vezes se perguntar do por que dele precisar ficar esperando o fim da Sprint para receber uma funcionalidade X que já está pronta. Ele adoraria já ir recebendo cada funcionalidade quando esta estivesse pronta sem ter que esperar o “pacote” estar pronto. Já um outro Product Owner poderia achar isso péssimo, já que ele gostaria de poder programar melhor as entregas e não enxergaria valor em ter apenas uma daquelas funcionalidades na sua mão. Tudo depende.

Minha perspectiva

Depois de assistir algumas boas palestras de Kanban, das quais destaco a do Karl Scotland no Scrum Gathering de Amsterdam, participar do treinamento de Kanban aqui da AdaptWorks e ler muitas coisas a respeito, decidi então partir para a prática.

Nos últimos três meses me envolvi no trabalho com três times Kanban. Todos fazem parte de empresas que já estão há algum tempo fazendo algo relacionado à Agile, um exemplo disso é que todos os três times estavam vindo de Scrum. Abaixo compartilho um pouco desta experiência bem como minha percepção sobre ela.

Por que eu sugeri a transição de Scrum para Kanban?

Nestes casos específicos ficou evidente que o conceito de pacotes do Scrum tornava o ambiente “duro” demais. Algumas características deste cenário que me levaram a pensar sobre Kanban:

• O Product Owner não conseguia ter uma quantidade de requisitos READY para o planejamento de uma Sprint, visto que muitas coisas “apareciam” e “eram descobertas” ao longo da sua execução.
• O time estava extremamente “estressado” pois todo planejamento era mudado (!) ao longo da Sprint.
• O tal “pacote” da Sprint era composto por coisas sem nenhuma relação, muitas vezes até de produtos ou áreas diferentes.
• Sprints eram interrompidas frequentemente para fazer “algo urgente” e, veja, este algo não surgia por falta de planejamento ou incompetência das pessoas envolvidas. Ele surge porque a dinâmica do negócio daquela empresa é assim mesmo.

O que há de comum em todos os problemas que citei acima? Todos são derivados do conceito de time-box. E foi durante a busca da causa raiz destes problemas que me convenci que para aquele time uma outra dinâmica no fluxo de trabalho melhoraria diversos pontos.

E como ficaram as outras práticas do Scrum já que não eram mais obrigatórias?

Se você conversasse comigo há alguns meses atrás escutaria que um dos maiores medos que eu tinha em relação ao Kanban era o de que times poderiam “relaxar” com algumas das práticas essenciais de Agile que agora passariam a ser opcionais (percebe que este é o mesmo medo sentido pela turma do XP quando alguém fala de Scrum). Felizmente o que percebi na prática foi que, uma vez que um time ou uma organização aprende que multi-disciplinaridade e auto-organização – dentre outros conceitos – são benéficos para seus resultados, elas não mais abrirão mão deles.

Ainda tenho dúvidas quanto a este ponto quando penso em um time que nunca utilizou algum método ágil indo diretamente para Kanban.

E mudou tudo?

Em ambas as empresas nas quais pratiquei Kanban, o Scrum foi mantido para a maioria dos times. Em um dos casos, de um total de treze times ágeis, apenas dois fizeram a transição para Kanban. Por que? Porque o Scrum, seus timeboxes e outros conceitos continuou se mostrando a melhor opção, ou pelo menos a mais adequada para muitos deles.

Isto não é sobre ser mais fácil ou menos invasivo, isto é sobre escolher a opção mais adequada

Não gosto quando vejo alguém falando que irá começar a utilizar Kanban pelo fato de não ter conseguido utilizar Scrum, ou pelo fato de Kanban ser menos invasivo. Ora, se vou utilizar Kanban tem que ser porque, para aquele propósito, o considero melhor que Scrum, XP, Crystal, Waterfall, etc., e não simplesmente porque é mais fácil!

Para finalizar este post entenda que eu faço parte daquele grupo de pessoas que não acredita que há ou haverá um único processo correto, capaz de combater todos os tipos de problemas e se adequar à todos os cenários. Tenho adorado minhas recentes aventuras com Kanban, e continuo vibrando com o que Scrum pode fazer – e tem feito – por muitos times e empresas.

No nosso treinamento “Sistema Kanban para desenvolvimento de software” são abordados importantes detalhes sobre o uso deste método. Veja as datas de nossas próximas turmas.