Categories
Administração Agile

Um empresa inteira “ágil”?

Conversando no mês passado com meu amigo Siraj ficamos nos perguntamos porque a “filosofia” ágil não emplaca nas empresas como um todo. O que eu quero dizer é que é razoavelmente fácil hoje em dia encontrar o departamento de desenvolvimento de produtos/software de uma empresa usando métodos ágeis, mas o que falta para o RH, Marketing, Financeiro, Administrativo, Comercial e todos os outros departamentos também entrarem nessa?

Quando você começa com desenvolvimento ágil não é só o processo de desenvolvimento de software que muda mas também vários detalhes de como a sua empresa funciona. Por exemplo, é muito difícil imaginar um time ágil que funcione com “comando-e-controle”. Os times são auto-gerenciados, o que implica em um outro estilo de gestão. Ao invés de chefes que cobram, aparecem os líderes-servidores, que dão todos os recursos possíveis para que seus times possam trabalhar e tomar decisões. A base da pirâmide é que passa a decidir e não mais o topo, porque eles são os mais indicados por deterem o melhor conhecimento para fazer isso. Em alguns casos mais extremos em empresas mais modernas como a Semco, são os próprios funcionários que contratam seus gerentes.

Ou seja, quando falamos de métodos ágeis, por mais que estejamos nos referindo aos métodos ágeis de desenvolvimento de software existem uma porção de outros conceitos e filosofias que acabam entrando no mesmo barco por serem tão intimamente relacionados.

Tenho um exemplo para tentar explicar melhor onde eu quero chegar. Uma vez eu trabalhava numa empresa de tamanho razoável que, como várias outras desse porte, tinha um tradicional departamento de RH. Num dia eu tive um problema bem urgente e precisei da ajuda do pessoal do RH. Quando fui conversar com eles, duas coisas desagradáveis aconteceram. Primeiro, eles me trataram mal e como se estivessem fazendo um favor pra mim. Segundo, eles disseram que meu pedido só seria atendido em alguns dias, porque eles tinham muitas coisas importantes para fazer. O que acontece é que minha filha estava muito doente, eu tive um problema com meu plano de saúde e eles não estavam liberando meu atendimento por nada. Um time de RH com a “cultura ágil” saberia em primeiro lugar que, dado que eu sou o principal “usuário” deles, eu mereço atenção, respeito e os meus problemas são os problemas deles. As urgências dos funcionários deveriam ser mais importantes do que qualquer papelada que eles tenham para fazer. E em segundo, mesmo que o backlog deles fosse absurdamente grande, um assunto com tamanha severidade com certeza “furaria” a fila.

Então, quando eu digo que outros departamentos das empresas poderiam ser “ágeis”, não estou sugerindo que eles trabalhem com desenvolvimento ágil de software – o que não faria nenhum sentido – mas sim que eles usem os mesmos conceitos de liderança, times auto-organizados trabalhando num ambiente participativo, baseado na confiança e cooperação, fazendo um movimento e esforço maiores para entenderem quem de fato são seus “usuários” e quais são suas necessidades, criar visões para seus produtos e departamentos (que os ajudariam a tomar melhores decisões) e por aí vai.

Pegando esse departamento de RH que falei acima como exemplo, não seria perfeitamente aceitável que eles fizessem um exercício de personas para descobrirem qual é o perfil dos seus usuários? Não seria ótimo que eles fizessem sessões de chartering, discutissem seus valores, fizessem retrospectivas para descobrirem como melhorar seu processo e assim por diante? Imagine quão transparente e organizado seria chegar na sala deles e ver um quadro de Kanban mostrando sua linha de atividades, o progresso delas e os gargalos da equipe?

Acho que talvez isso não aconteça porque grande parte do material e exemplos disponíveis sobre esses assuntos estão formatados para pessoas relacionadas à desenvolvimento de software. Sim, existem livros como os do Ricardo Semler que estão categorizados nas livrarias como “Administração” ou “Negócios”, mas não sei porque o pessoal de Administração e Negócios não parece se interessar por esses assuntos. Porque será?

Já está na hora desse “fork” entre a comunidade ágil das empresas e as outras áreas acabar. Chega uma hora que parece que existem duas empresas funcionando totalmente diferentes dentro de uma. Precisamos trazer pessoas das outras áreas e outros níveis hierárquicos para as conferências e para o nosso mundo. Vou adorar o dia que eu for na Agile Conference e conversar com Gerentes de RH, VPs de Marketing e outras pessoas que não sejam do departamento de desenvolvimento; ou então quando for nas reuniões de grupos de usuários e não encontrar somente os “agilistas” mas também os administradores, os analistas de recursos humanos, os contadores e por ai vai.

E aí, por onde vamos começar?

Categories
Eventos

[Agile 2008 Conference] Vídeos e fotos da conferência

Para quem quiser saber um pouco mais sobre o que rolou na Agile 2008 Conference, veja a página especial do InfoQ sobre a conferência. Foram filmadas 18 apresentações que serão disponibilizadas conforme o calendário que está no site. Assistam no mínimo 10 Ways to Screw Up with Scrum and XP do Henrik Kniberg, que inclusive comentei aqui no blog! Essa é muito legal!

Além disso têm algumas fotos que você pode ver no meu Flickr e no do Marcello Azambuja. Enjoy!

Categories
Eventos

[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams

Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…

O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.

Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.

A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.

Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!

Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.

Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.

A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.

Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.

A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.

Pense fora da caixa!

Categories
Eventos

[Agile 2008 Conference] Henrik Kniberg: 10 ways to screw up with Scrum and XP

Gostei muito da apresentação do Henrik Kniberg “ensinando” 10 maneiras para arruinar seus projetos mesmo usando XP e Scrum. É óbvio que eu não quero acabar com os meus projetos, mas é legal debater sobre os erros mais comuns nas adoções de metodologias ágeis e seus motivos para poder evitá-los.

Uma coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a apresentação (mesmo quando ainda não tinha assistido) e o seu blog sempre foram boas fontes de referência para mim.

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

  • Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um P.O.! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  • Definition of Done: muitos times não tem uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.
  • Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.
  • Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.
  • Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.
  • Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.
  • Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.
  • Product Backlog: não existe ou não está priorizado corretamente.
  • Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.
  • Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

É óbvio que essas não são as únicas maneiras de fazer besteiras em projetos com XP e Scrum e pode até ser também que tenham algumas maneiras mais “eficazes” que essas. No entanto esses problemas são muito comuns e acho que por isso mereceram destaque na apresentação.

Você pode encontrar os slides da apresentação no site do Henrik Kniberg. Esses slides são de uma apresentação um pouco mais antiga mas não há muitas diferenças.

Categories
Eventos

[Agile 2008 Conference] Mary Poppendieck: The five dimensions of a system

Agile 2008 - Mary PoppendieckPela primeira vez tive a oportunidade de assistir uma apresentação da Mary Poppendieck, e devo dizer que fiquei impressionado pela qualidade da apresentação… A mulher é simplesmente uma enciclopédia humana!

A Mary começou falando sobre histórias de “plank roads” (estradas de tábuas de madeira). Há muito tempo, quando todas as estradas eram de terra e cheia de buracos, alguém teve a idéia de fazer estradas de tábuas de madeira. Os benefícios foram muitos e enormes para a época: os transportes ficaram muito mais rápidos, o desgaste dos carros ficou muito menor, e por aí vai. Como essas estradas tinham um custo muito alto para serem produzidas, estimou-se que seriam necessários dez anos para que elas se pagassem. No entanto, quando as estradas ficaram com cinco ou seis anos começaram a se deteriorar, e era seria necessário fazer uma grande reforma para que elas voltassem a ser usáveis. Desta forma as estradas de tábuas se mostraram um péssimo negócio, pois com esse ciclo de implementação e manutenção jamais se pagariam. E aí a Mary levantou uma questão: assim como acreditava-se que as estradas de tábuas de madeira resolveriam todos os problemas do mundo até que os pontos negativos foram percebidos, será que o desenvolvimento ágil também não é uma estrada de tábuas e a qualquer momento vamos achar seus problemas?

Isso foi o gancho para ela mostrar várias histórias de estradas de tábuas, ou seja, histórias de coisas que acreditava-se que eram excelentes mas que depois foram mostrando seus problemas. Ela citou vários exemplos desde o waterfall até as ferramentas RAD, e levantou vários pontos sobre porque essas idéias fracassaram.

O que estamos tentando fazer hoje com desenvolvimento ágil é uma tentativa de resolver vários desses fracassos que tivemos em experiências passadas. A experiência com esses problemas e o entendimento das suas causas fez com que nascessem várias das linhas de desenvolvimento ágil que temos hoje como o XP, Lean Software Development e Scrum. Ainda acredita-se que o desenvolvimento ágil está no caminho de resolver vários problemas, portanto, respondendo à pergunta inicial, na opinião da Mary ainda não existem evidências de que o desenvolvimento ágil é uma “estrada de tábuas”.

Para encerrar, a Mary falou das cinco dimensões de um sistema e algumas questões sobre essas dimensões. Se você responder sim para todas essas perguntas (ou pelo menos a maioria), você está no caminho certo para desenvolver software de qualidade, de forma eficiente e que atende aos seus clientes.

Motivo/Razão do sistema

  • Os especialistas técnicos estão sempre atualizados com o objetivo geral do sistema?
  • Os técnicos do time vão checar por sí mesmos qual é o verdadeiro problema que o sistema deverá resolver?
  • Existe um líder técnico que é responsável por atingir o objetivo do sistema e que guia o time tecnicamente caso necessário?
  • Existem ciclos de aprendizado para descobrir se o sistema está servindo para o que se propõe e melhorá-lo de acordo com os objetivos?

Estrutura

  • O time tem uma boa visão do todo sobre o que eles estão produzindo, sobre a empresa e sobre como o seu trabalho se encaixa no todo?
  • Existem ciclos de aprendizado que munem os desenvolvedores com feedback sobre o uso do sistema?
  • Os desenvolvedores menos experientes são treinados e supervisionados para garantir que eles produzirão código de boa qualidade que incorpora a aprendizagem de erros cometidos anteriormente?
  • O trabalho é revisado por alguém apropriado?

Integridade do sistema

  • A integridade do sistema é parte integrante do desenvolvimento, e quando ele é finalizado pode-se assumir que o sistema já está completamente testado?
  • O sistema é desenvolvido de tal forma que é necessário um tempo desprezível para merges e testes no final?
  • As falhas são raras e são investigadas a fundo para descobrir padrões que podem servir para resolver e previnir problemas similares no futuro?
  • Esse conhecimento é capturado, consolidado e disseminado de uma maneira efetiva?

Tempo de vida do sistema

  • O tempo de vida e possíveis futuras modificações são considerados no projeto e desenvolvimento do sistema?
  • As pessoas que vão operar o sistema estão envolvidas no seu projeto?
  • O time de desenvolvimento permanece envolvido com o sistema a longo prazo?
  • As recompensas estão estruturadas de forma que desenvolver um sistema robusto que funcione bem ao longo dos anos é o comportamento mais encorajado?

Resultados do sistema

  • O sistema atinge muito bem o seu objetivo e os clientes conseguem antecipar algum retorno sobre o investimento?
  • O sistema atinge seus objetivos financeiros, dentro do seu custo e prazo planejados?
  • O sistema funciona sem falhas e há confiança que ele continuará assim?
  • O sistema atende plenamento àqueles que o operam, usam, suportam, mantém e criam algum valor com ele?

Você pode encontrar os slides da apresentação no site da Mary Poppendieck.

Categories
Agile Eventos

Agile 2008 Conference, aí vou eu!

Agile 2008Na próxima semana estarei em Toronto/Canada para a Agile 2008 Conference, a maior conferência sobre desenvolvimento ágil do mundo!

Com mais de 400 apresentações em 5 dias, o calendário da conferência, divulgado no início do mês passado está ótimo! Teremos a presença de vários nomes conhecidos do mundo ágil como Jeff Sutherland, Mary Poppendieck, Robert Martin (o Uncle Bob), Mike Cohn, Henrik Kniberg, Dan North, Mishkin Berteig, Scott Ambler, Linda Rising, Jim Highsmith, Neal Ford, James Shore… Vai ter tanta coisa legal que está até difícil escolher quais apresentações vou assistir! E isso tudo sem falar do amigo brasileiro e ThoughtWorker Danilo Sato, que apresentará o case do Coding Dojo de São Paulo.

Quem lê meu blog já deve ter percebido que desenvolvimento ágil é um dos meus assuntos favoritos, por isso podem esperar que provavelmente vou blogar mais do que o normal na semana que vem!