No post em que diferenciei complicado, complexo e caótico eu explico alguns conceitos que deixam claro em quais tipos de projeto faz sentido uma abordagem ágil, e em quais faz sentido uma abordagem tradicional, baseada em cascata. Explico também o que significa ser simples, complicado, complexo, e caótico, além de explicar as características de um contexto complexo. Você vai aproveitar melhor este post se ler aquele primeiro.

Estou estudando o framework Cynefin e percebo que alguns conceitos complementam bem o que eu já havia iniciado, já que ele levanta os modelos de gestão apropriados a cada contexto.

A categorização é parecida com a que eu havia proposto antes, e que é parte do curso de Professional ScrumMaster:

Nesse gráfico, temos expostos os contextos em que uma situação, um projeto de software, por exemplo, acontece. Estes contextos são classificados em ordenados e desordenados:

1. Nos contextos ordenados as decisões são baseadas em fatos, existe uma clara relação de causa e efeito (causalidade), e o sistema restringe os agentes, ou seja, é possível limitar as ações e criatividade das pessoas e ainda assim obter resultados. Um estilo comando e controle pode funcionar, ainda que eu prefira uma liderança democrática, e não autocrática. Os contextos simples e complicados são contextos ordenados.
2. Nos contextos desordenados há necessidade de avaliação empírica, e a análise de padrões é que determina a resposta. Há pouca ou nenhuma relação evidente entre causa e efeito (ainda que ela exista, é difícil de medir). Nesse cenário, somente o autogerenciamento e a autoorganização libertam os agentes para criar soluções que realmente endereçam os problemas que aparecem. Hierarquia estrutural e autocracia são o melhor caminho para o fracasso. Os contextos complexo e caótico são contextos desordenados.

O problema maior é tomar um pelo outro. A maioria dos líderes/gerentes imagina trabalhar em ambientes ordenados. Isso é um problema porque as respostas esperadas em cada contexto são diferentes. Ao tomar um pelo outro, as decisões ficam aquém do esperado e produzem desperdício, no mínimo.

No contexto simples e também no complicado, o ambiente é planejado e previsível.

No simples, sabe-se tudo ou quase tudo o que pode acontecer ao processo. Nesse contexto, os líderes sentem, categorizam e respondem, ou seja, eles avaliam a situação, as categorizam e decidem com base nos fatos categorizados. Nesse cenário, os líderes podem não perceber a mudança de contexto, de simples para complicado, complexo ou caótico, e caminham para a falha, já que o contexto mudou e eles continuam aplicando técnicas baseadas em sentir, categorizar e responder, na expectativa de uma previsibilidade que pode ser falsa, e achando que sabem mais do que sabem.

No ambiente complicado, muito pouco é desconhecido sobre o processo e o produto. Sabe-se mais do que não se sabe. Nesse contexto, os líderes sentem, analizam, e respondem, ou seja, é preciso analizar as situações que aparecem, e não só categorizá-las. Essa análise fica a cargo de experts, que precisam informar como responder. Nesse cenário, não os líderes (como no contexto simples), mas os experts é que correm o risco de não perceber a mudança de contexto, e, junto aos líderes, podem aplicar abordagens erradas para endereçar cada situação.

No contexto complexo, o desconhecido predomina sobre o conhecido, sabe-se pouco, e não se sabe o que não se sabe. É preciso levantar os fatos antes de tomar as decisões, e por isso, o processo não começa pelo sentir, como nos contextos ordenados, mas começa com sondar, e então sentir, e só então responder. É o processo empírico tateando a cada passo, porque sabe que não é possível crer no planejamento, já que não sabemos quase nada. Nesse cenário, tentar impor ordem e buscar previsibilidade é caminhar para o abísmo, já que o contexto é naturalmente desordenado; mais vale entender e abraçar a complexidade, adaptando-se sempre que necessário. Aqui o sistema restringe os agentes, devido à sua imprevisibilidade, e os agentes restringem o sistema, impedindo que ele caminhe para o total desconhecido, inspecionando frequentemente e adaptando sempre que necessário.

No contexto caótico, não só não sabemos nada, mas não conseguimos saber. Não adianta sondar, os resultados serão nulos ou inúteis. Causa e efeito não tem relação aparente alguma. Resta agir, e esse é o primeiro passo, seguido do sentir, e então responder. Os líderes agem, e então sondam os resultados, e respondem aos efeitos dessa sondagem, tentando trazer o contexto para algo no mínimo gerenciável, onde também não se sabe, mas pelo menos temos como tatear, ou seja, buscam o complexo. O ideal é atuar de forma rápida, a fim de reestabilizar; imagine um avião em queda, e girando – a primeira coisa que se faz é agir e fazer o avião parar de girar, só depois é que faz sentido buscar nivelar o avião. Buscar ler os instrumentos ou planejar seria absurdo. Neste contexto, o sistema e os agentes estão sem restrições, não há controle ou previsibilidade alguma, e não há como medir. Mas o caótico não é só ruim, ao mesmo tempo que busca agir, o líder tem em mãos uma grande oportunidade de mudança radical, proporcionada pela desordem absoluta e pela total falta de posição. Se o momento caótico passar e a mudança não acontecer, dificilmente ela acontecerá tão facilmente como poderia antes.

Reforçando: o grande erro está em liderar imaginando um contexto, quando na verdade estamos em outro. O mais comum é responder utilizando técnicas para contextos simples ou complicados, quando na verdade estamos no caótico ou complexo, por acaso os mais comuns no mundo de software.

Por exemplo, uma empresa que desenvolve software sob medida, sempre atuando em novos clientes, ambientes, tecnologias, e com pessoas diferentes, vive um ambiente no mínimo complexo e portanto pouco previsível. Aplicar técnicas baseadas em análise e resposta, como as baseadas no modelo cascata, ou atuar como um líder que comanda e controla, é ignorar o contexto em que o projeto vive, além de ignorar o que não se sabe. Pior, assumir que sabe, ou até basear-se em informações erradas, desatualizadas ou ambos.

O mesmo vale para o oposto. Uma empresa que trabalha com um software vanilla, que customiza para clientes sempre de forma semelhante, está sempre atuando no mesmo produto, ou seja, atua num ambiente provavelmente no máximo complicado. Nesse cenário, sondar é desnecessário, e trará um custo extra ao projeto. Basta analizar os resultados das medições e corrigir de acordo com o plano. Um modelo em cascata, baseado em alta previsibilidade, seria o ideal e o mais barato.

E você? Trabalha em qual contexto? As decisões dos líderes batem com o contexto?

Ok, eu ia reportar o evento ao vivo… mas eu também ia dormir 8 horas por dia. Nenhum dos dois aconteceu. Então o relatório do evento segue agora, alguns dias atrasado, mas nem por isso tão desatualizado.

O evento foi muito bom. Já vi diversos relatos em blogs de amigos e de desconhecidos agora, depois que o evento já aconteceu, e só sucessos. Algumas críticas vieram, mas nada demais, só recomendações para deixar o de 2011 ainda melhor. Trabalhamos intensamente no evento vários meses, e o sucesso é a concretização deste trabalho.

O evento abriu com dois dias de cursos, sendo um de XP, onde fui um dos instrutores, um de CSM, um de CSPO, e outro de coaching. Não estive presente nos outros 3 cursos, mas pelo feedback que recebi também foram muito bons. No de XP tivemos nada menos do que seis instrutores (contando comigo) com vasta experiência e conhecimento. Passamos por toda a teoria, e ainda tivemos exercícios práticos e muitas dúvidas resolvidas. Dava pra ter feito 2 dias de curso tranquilamente, e aprofundado mais em alguns assuntos. Na verdade, dava pra fazer 1 semana numa boa, de tanto conteúdo que nós 6 tinhamos pra falar. Considerando que os 6 eram também palestrantes do evento e membros da organização, ou seja, todos adoram falar, nos saímos muito bem, e a dinâmica do curso foi ótima. Com os três cursos somamos mais de cem pessoas.

Algumas fotos (clique para ampliar):

Dúvidas dos alunos para resolver e horário:

Coffee-break:

Times praticando:

Pareando a três:

Parte da turma:

Curso de CSM:

Curso de CSPO:

À noite saímos pra jantar, foi muito legal. Aqui vocês vêem parte dos instrutores e comissão do evento:

No segundo dia do evento, outro jantar, dessa vez bem mais cheio. Muita gente já tinha chegado para participar do evento. A mesa deve ter batido quase 100 pessoas:

Em Porto Alegre é comum esse licor, servido em cascata. Novamente tomamos neste restaurante. Quem foi que disse que agilista não gosta de cascata?

No terceiro dia do evento abrimos com as palestras, onde quase 900 pessoas participaram. A abertura foi feita pelo Martin Fowler, e foi como a apresentação de um Rock Star. O Fowler é engraçado, ele ficou disponível o evento todo no estande da Thoughtworks, empresa que trabalha que também patrocionou o evento e estava lá, mas não tirava foto com ninguém porque dizia que ia parecer um político. Eu já tinha ouvido essas histórias, é engraçado ver que as idiossincrasias afetam todos. A palestra foi ótima, foi na verdade 3 palestras em 1, onde ele abordou, entre outros assuntos, o Scrum Flácido e o débito técnico. Isso foi muito legal, porque foi o Scrum flácido que inspirou a criação do programa Professional Scrum Developer da Scrum.org. Várias outras palestras no evento se relacionaram com a do Fowler, o que foi ótimo.

Fowler palestrando:

Auditório lotado:

Um telão reportou o evento ao vivo no twitter:

Isso foi ótimo porque dava pra ver na hora o que o pessoal estava pensando, além de estimular o pessoal a dar feedback.

Esta é a área onde ficavam os patrocinadores, aqui vocês me vêem ao lado da grade:

Aqui uma visão melhor, em um momento em que não estava tão cheio:

O evento seguiu o resto do dia com break-out sessions, e bastante movimento no open space, com diversas discussões:

Tivemos um workshop com o Philippe Kruchten de Release Planning Game, onde de Mariana Bravo, Samuel Crescêncio, Teresa Maciel e eu servimos de facilitadores, ao lado do Philippe:

Achei o workshop muito legal, principalmente para quem está começando. É um jogo, onde as pessoas conseguem ter uma visão clara sobre débito técnico, planejamento iterativo, entre outros conceitos.

A Microsoft palestrou também. O Igor Abade foi o responsável por mostrar que a Microsoft está abraçando a ideia de apoiar processo ágeis. O Igor parecia apreensivo com a palestra, mas foi muito bem recebido e a sala estava bem cheia, ainda mais se considerar que palestras de patrocinador não costumam ter muita gente:

Eu estava particularmente podre. Como fazia parte da organização estava dormindo muito pouco, e eu já vinha de uma semana fora de casa, ministrando o Professional Scrum Developer em BH, e também dormindo pouco por lá. Na quinta atingi meu limite, estava exausto e com dor de cabeça. E no fim do dia tinha minha palestra. A adrenalina da palestra me reanimou, e apresentei a palestra com toda a energia:

Mas depois eu quase desmaiei.

Mentira, depois fomos para o John Bull, um bar de Porto Alegre onde estava rolando um Rock, para a festa do evento. Mas não consegui acompanhar o resto do pessoal, que esticou madrugada adentro. Eu estava quase morto, voltei pro hotel para descansar. Descansei tanto que perdi o keynote do Philippe Kruchten, cheguei lá para o jogo do Brasil, que todos já sabem, era melhor não ter assistido. Perdemos um slot de palestra, mas imaginem se o Brasil tivesse ido bem? Seríamos crucificados por termos ignorado o jogo. Fazer o que?

A sexta seguiu com mais palestras e no final um keynote que foi um fechamento excepcional! O Klaus Wuestefeld, um dos pioreiros da agilidade no país apresentou sua visão sobre o futuro do XP, onde ele praticamente desconstruiu o XP todo, e criou o Klaus Process, o KP, onde somente dois valores importam: Learning e Coolness. Fui uma palestra muito boa, e serviu para dar uma ótima visão sobre para onde estamos indo. Pode ser que não seja exatamente onde o Klaus espera que seja, mas ele ajudou a abrir os horizontes:

Na sexta tivemos um jantar da organização e alguns amigos, que eu não fotografei porque merecia descansar da câmera um pouco. Depois publico as outras fotos.

Gostei do evento e provavelmente estarei na organização da edição do ano que vem. Vamos ver. Foi ótimo dar rostos aos membros da organização, já que eu só conhecia pessoalmente um ou outro. Aproximar-me de pessoas como o Samuel Crescêncio, Rodrigo de Toledo, Paulo Caroli, entre outros, é algo sem preço.

Aqui o time todo da organização reunida para foto histórica:

Acreditem se quiserem, nossa primeira reunião presencial se deu na segunda-feira, um dia antes do evento. Toda a coordenação foi remota. Quem disse que times ágeis obrigatoriamente tem que estar colocados?

Valeu pessoal!

A Conferência Norueguesa de Desenvolvedores de 2010 (NDC – Norwigean Developers Conference) postou novamente (assim como no ano passado) todos os videos para download. E as palestras foram incríveis. Não dá pra não ver.

A conferência é anual, caríssima, e focada em .Net e Agile.

Vão lá baixar e divirtam-se.

Segue a palestra feita ontem no AgileBrazil 2010:

Depois faço meu relato. Depois que eu morrer e descansar nesse fim de semana.

Estou indo hoje para o AgileBrazil 2010, que tenho certeza será um dos melhores eventos do ano. Faço parte da organização, e vai ser muito legal ver o trabalho finalmente entregue. Vai ser uma conferência incrível.

Estou feliz de reencontrar amigos da comunidade de agilidade que não são de São Paulo e que por isso não vejo com tanta frequencia. O clima neste tipo de evento é muito rico, pessoas com backgrounds muito diferentes e com muito a acrescentar. Comunidades de Ruby, Java, PHP, .Net, entre várias outras, estarão representadas no evento. O .Net Architects, mais uma vez, vai estar lá em peso, estou estimando algumas dezenas de pessoas. O evento vai reunir mil pessoas, e é sua primeira edição!

As palestras estão excepcionais, com assuntos muito diversos e importantes. Eu acompanhei de perto a seleção das propostas de palestras, e foi algo absurdamente profissional e criterioso. Membros expoentes da comunidade de software brasileira, além da organização, avaliaram as propostas, com cada proposta sendo avaliada três vezes. Os track leaders então, baseando-se nas avaliações fecharam várias propostas de agenda, e a organização pesou muito até escolher uma que apresentasse ótimos temas, representasse todo o país, e trouxesse tanto membros antigos da comunidade quanto os mais novos.

Isso sem falar dos palestrantes convidados, muitos deles internacionais. Imperdível.

Vou, como sempre, reportar o progresso do evento por aqui. Espero conseguir fazer isso ao final de cada dia, se eu não estiver morto de tanto trabalhar. Quero ver o evento, mas também vou palestrar, e ajudar na organização local do evento. Vamos ter muito trabalho. E espere uma avalanche no twitter na hashtag #agilebrazil. Se você não vai, pelo menos dá pra ter uma ideia de como foi.

A Microsoft está patrocinando o evento com a cota mais alta de patrocínio. Eu mesmo puxei isso com o Rodrigo de Carvalho da Microsoft, que está comprometidíssimo com a agilidade aqui no Brasil (o Rodrigo também ajudou na ponte para realizar o Scrum Spike Brasil em um espaço cedido pela Microsoft). Teremos uma palestra do grande Igor Abade por lá, falando adivinhem de que?

Vejo vocês lá.

Direto do site da Scrum.org, estou traduzindo aqui (update: agora traduzido por lá também). O evento vai contar com palestras o dia inteiro, com a presença do Ken Schwaber, eu, e outros membros da comunidade. Isso é parte de uma iniciativa que inclui também um curso de Scrum In Depth com o Ken e eu nos dias 22 e 23 de Julho, e outro de Scrum Developer nos dias 26 a 30 de Julho, também com nós dois e mais o Alex Armstrong.

Tradução abaixo:

Scrum Spike Brasil
Você é o melhor Scrummer do Brasil?

Leve o seu conhecimento de Scrum a uma nova profundidade em uma spike de imersão em Scrum. Liderado por Ken Schwaber, os melhores Scrummers no Brasil e América do Sul vão trabalhar juntos para levar seus conhecimentos a uma nova profundidade. Abrangendo temas como arquitetura emergente, definição de pronto, dívida técnica, custo total de propriedade, práticas de desenvolvimento ágil, e "Scrum but".

Somente os melhores do Brasil e América do Sul estão convidados. Depois de participar, eles serão listados publicamente como tendo alcançado tal distinção. 

Qualificação: Para participar, você deve ficar entre as 150 melhores pontuações em uma avaliação de Scrum. A avaliação será realizada até 10 de julho de 2010, e baseia-se no corpo de conhecimento do Scrum. As pessoas que mostrarem maior conhecimento serão convidadas sem custo para um dia inteiro na Spike que acontecerá na Microsoft Brasil em São Paulo no sábado, 24 de julho.

Logística: Você deve registrar-se em ScrumSpike para a avaliação da Scrum Spike. Há uma taxa 20 dólares para fazer a avaliação. Você pode se registrar quantas vezes desejar. Ao se registrar, você receberá uma senha que será utilizada para realizar a avaliação, comece por aqui. Até 10 de julho, os 150 melhores colocados serão afixados publicamente. O melhores 150 ao final receberão convites.

Preparação: Se você quer se preparar para a avaliação, leia o Guia do Scrum (www.scrum.org/scrumguides) e faça a avaliação gratuita de Scrum (Scrum open assessment), www.scrum.org/scrumopen/

Nota: Esta avaliação e o Scrum Spike são em Inglês. No entanto, uma edição em Português do Guia do Scrum está disponível em scrum.org.

Patrocinado pela Scrum.org

Já foi.

Videos:

#1

#2

#3

Já cansei dessa discussão. Já respondi em blogs vezes demais, twitter vezes demais. A resposta é sempre a mesma: não, gerência de projetos feita ao estilo proposto pelo PMI no PMBoK não combina com frameworks ágeis (incluindo Scrum, antes que algum desinformado pergunte). São quase diametralmente opostas na sua essência. Obviamente que há práticas valiosíssimas no PMBoK, mas não é isso que estou discutindo, estou discutindo a essência.

O negócio fica pior se você considerar como a maioria dos PMPs pensam, mas nem vou entrar nesse mérito, todo mundo sabe como PMPs e gerentes de projeto baseados nas ideias propostas pelo PMI se comportam, todos sabem que a esmagadora maioria se expressa através do comando e controle, algo inaceitável em qualquer prática ágil. Coloco no ar apenas se é possível separar a teoria de como ela é aplicada; fica a provocação.

Pra não ficar só no achismo, aqui vão algumas citações diretas do PMBoK, no que tocam o gerente de projetos.

Cap. 1
”O gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto.”
”Um gerente de projetos é responsável pelo fornecimento de objetivos específicos do projeto dentro das restrições do projeto…”
”O gerente de projetos controla os recursos atribuídos ao projeto para atender da melhor forma possível aos objetivos do projeto, enquanto o PMO otimiza o uso dos recursos organizacionais compartilhados entre todos os projetos.”
”O gerente de projetos gerencia o escopo, o cronograma, o custo e a qualidade dos produtos dos pacotes de trabalho.”

Cap. 2:
”Gerente de projetos. A pessoa responsável pelo gerenciamento do projeto.”
”Os gerentes de projetos precisam gerenciar as expectativas das partes interessadas…”
”As organizações por projeto em geral possuem unidades organizacionais denominadas departamentos, mas esses grupos se reportam diretamente ao gerente de projetos ou oferecem serviços de suporte para os diversos projetos.”
”Os membros da equipe do projeto se reportarão diretamente ao gerente de projetos ou, se forem compartilhados, ao PMO.”

Cap. 4
”O termo de abertura do projeto concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades do projeto.”

Parei no capítulo 4. Está bom, né?

Está evidente que essa figura não encaixa bem em práticas ágeis. O gerente de projetos controla e comanda o time gerenciando escopo, prazo, custo e qualidade. Ele diz o que o time tem que fazer, depois vai lá e verifica se eles fizeram. Essa figura, como está descrita no PMBoK, não existe em Crystal, XP, FDD, Scrum ou qualquer outro framework ou metodologia ágil.

Lembro até hoje do Ricardo Vargas, chairman mundial do PMI, fazendo o Keynote do Scrum Gathering Brasil ano passado. Foi super bonito, bem ao estilo Lulinha paz e amor, todo mundo se dá bem, somos todos amigos, até o Juan Bernabó perguntar o que ele achava de times auto-gerenciados, e aí ficou claro que discurso é discurso, prática é outra coisa. O Ricardo falou que, na opinião dele, isso não funcionava, que tinha sempre alguém que ficava enrolando, e que alguém tinha que cobrar. Não que não seja verdade na realidade dele, o Ricardo Vargas gerencia projetos muito complexos, de plataformas de petróleo, e coisas do tipo, e vai ver lá funciona como ele falou, funciona tudo o que PMI propõe. Só que em software não funciona, ele não deve saber porque não trabalha com software (porque se trabalhasse não entregaria nada, assim como os outros GPs que trabalham com desenvolvimento de software). Não que isso seja um problema para estes gerentes de projeto, já que gerentes de projetos à la PMI não ligam que não conhecem nada de software, porque segundo o PMI o gerente de projeto deve ser capaz de gerenciar um projeto de qualquer tipo, de uma plataforma de petróleo a um ERP, de uma reforma à um novo projeto de marketing. Ah, então tá bom.

Esperem ver essa figura perdendo mercado em TI nos próximos anos. Cada vez menos GPs vão ser contratados. Alguns vão “virar” ScrumMasters, outros simplesmente vão para a rua ou vão fazer outra coisa. É inevitável.

E não acreditem em mim, vão lá ler. Baixem o PMBoK em algum lugar, leiam, e confirmem o que está escrito acima (sei lá se ele se vende ou se é de graça hoje em dia, o meu é hard copy). E descubram outras incongruências. E aproveitem para tirar suas próprias conclusões.

Cansei desta discussões. Que venham os flames agora, nos comentários.

Espanto-me com a pouca tolerância à falhas que nossa sociedade tem. Parece que somos todos perfeitos. Acredito que boa parte da resistência à adoção da agilidade nas empresas está na dificuldade em aceitar que o modelo anterior é falho, e que as próprias empresas falham constantemente.

Não que o fato de que somos uma industria que falha mais do que tem sucesso esteja em discussão, já que diversos estudos apontam que, enquanto indústria, enquanto profissionais, somos absolutamente incompetentes. Os números do Chaos Report do Standish Group não deixam ninguém discordar:

De 2006 a 2009 nós ficamos ainda piores, fracassamos mais.

Como você se sentiria se seu médico lhe dissesse que, ao realizar uma operação, haveria 1/3 de chance de sucesso, 1/3 de chance de você ficar inválido, e 1/3 de chance de você morrer? Inaceitável, não é? Esses somos nós, enquanto industria.

Ok, falhamos então. E daí?

Daí que ainda assim, agimos como se não falhássemos. Sempre digo que há uma grande chance de as primeiras iterações de um projeto falhar. Quando falo para as empresas, muitos não se conformam. Quando falo para alunos, muitos não entendem. “Como ele, que apóia, divulga, e ensina sobre agilidade pode dizer que falhamos nas primeiras iterações?”, pensam eles. Não só digo que falhamos, como digo que isso não é um problema.

Quando foi que a sociedade determinou que não podemos falhar? Quando nos decretamos super-heróis, que não erram, estimam perfeitamente (?!), e planejam anos à frente sem errar?

O problema não é falhar. O problema é falhar sempre, o problema é falhar e não aprender com a falha. A falha é um dos melhores instrumentos de aprendizagem que temos. Ela expõe nossas deficiências, e nos dá oportunidade para melhorar.

Vou contra o que dizem XP, Scrum, entre outros: a saída mais importante das primeiras iterações de um projeto não é o produto, não é o ROI. Acho que a saída mais importante das primeiras iterações é o aprendizado do time. É ele que vai habilitar o sucesso futuro, se estamos falando de um time verdadeiramente ágil. Tal time vai ter transparência e feedback imediato, resultado de ciclos curtos, e vai se adaptar. Com projetos ágeis há o risco de falhar a cada 1 ou 2 semanas, e junto com ele vem a oportunidade de melhoria. Projetos waterfall só tem essa oportunidade uma vez: no final; mas aí já é tarde demais.

O produto e o ROI também são importantes nas primeiras iterações, mas eles são resultados de um time bem entrosado. Eles devem ser a meta da iteração, assim como são a razão para a existência do projeto. Mas não são o mais importante nestas primeiras iterações. De nada adianta entregar o produto se o time não aprendeu nada; esse tipo de situação é insustentável, senão impossível, em um time que está em amadurecimento.

Logo após as primeiras iterações o aprendizado do time passa a ficar em segundo plano. Assim que se integra e começa a amadurecer, o time passa a aprender osmóticamente, e o conhecimento habilita a entrega do produto e o ROI, que assumem o papel principal.

Em projetos onde o time é mais maduro e trabalha bem junto, conhece mais o negócio e a tecnologia, esse aprendizado ocorre muito mais rápido, e o time é capaz de entregar valor desde as primeiras iterações. A situação exposta no parágrafo anterior é catalizada, e o aprendizado fica em segundo plano o tempo todo. Mas só uma empresa madura consegue propiciar tal cenário.

A cultura de aprendizagem e a capacidade de reação rápida são duas das maiores vantagens de projetos ágeis.

Do livro Extreme Programming Explained, de Kent Beck:

XP relies on the growth of powerful programmers; able to quickly estimate, implement, and deploy reliable software. These programmers turn over business decision making to the business-oriented part of the team. The appropriate sharing of power and responsibility among the team may seem utopian. This balance is contingent on mutual respect. There is no absolute power. The power of XP evaporates if misused. Each manipulated estimate, each job rushed through without pride, puts the team that much further from its potential power. XP relies on each member of the team; including executives, managers, and customers; to be fully committed and contribute what he can. A team working together can accomplish more than the sum of its members' separate efforts. Sharing power is pragmatic, not idealistic.

Traduzido:

XP se baseia no crescimento de programadores poderosos; capazes de estimar rapidamente, implementar e implantar software confiável. Estes programadores entregam as decisões de negócio para a parte do time focada em negócios. Um compartilhamento adequado de poder e responsabilidade entre o time pode parecer utópico. Este equilíbrio depende de respeito mútuo. Não há poder absoluto. O poder do XP se evapora se mal utilizado. Cada estimativa manipulada, cada trabalho corrido entregue sem orgulho, coloca o time mais longe de seu potencial. XP espera que cada membro da equipe, incluindo executivos, gerentes e clientes, esteja totalmente comprometido e que contribua o que puder. Um time trabalhando junto pode conseguir mais do que a soma dos esforços dos seus membros em separado. Compartilhamento do poder é pragmático, não idealista.

Estimativa manipulada?

Trabalho corrido?

Sem orgulho?

Isso não acontece, não é? É por isso que continuamos trabalhando com gerentes pressionando times para entregar, em vez de tentar entender e se comprometer com a entrega. É porque funciona! É porque entregamos o escopo certo a tempo, com qualidade, dentro do custo esperado. E todos os envolvidos ficam felizes no final, o cliente, o gerente, e os desenvolvedores. Isso sem falar no lucro, abundante em toda a cadeia.

Ok, o momento ironia acabou. Mas falando sério, se tudo dá tão errado, porque será que as empresas lutam tanto contra o compartilhamento do poder entre os líderes e os que realmente realizam o trabalho? Se o comando e controle já se provou fraco e ineficiente, porque insistir? Vou mais além: porque comprar software que sabemos que não vai ser entregue como esperamos, e depois cobrar como se fosse? Porque tanta relutância em se envolver?

Às vezes acho que esses padrões denotam algo de loucura, insanidade.

Me questiono porque somos democratas só da empresa para fora? Da porta para dentro somos ditadores e escravos. Somos religiosos, cristãos, éticos, mas não quando isso afeta o resultado. Essa dinâmica, que supostamente melhoraria a última linha do balancete, está produzindo resultados pífios, além de muito stress e doenças do coração. Ela definitivamente não está melhorando o resultado.

O seu papel, neste cenário, deve ser no mínimo fazer a sua parte. Você tem por obrigação e respeito à profissão o dever de não aceitar abusos, seja de seus funcionários, que não querem se comprometer e se envolver, seja de seus gerentes, que insistem em te controlar como se isso fizesse a menor diferença, ou de seus clientes, que demandam o impossível, sabendo que é impossível, querendo terceirizar um problema. Faça sua parte, eu estou fazendo a minha.

Compartilhamento do poder é pragmático, não idealista. É ele quem vai catapultar seus resultados, e junto sua felicidade. Imagine poder ganhar dinheiro enquanto respeita seus colegas de trabalho e satisfaz o cliente. Milhares de empresas são capazes de fazer isso hoje, através da democracia aplicada ao ambiente de trabalho.

Deixo vocês com essa palestra do Ricardo Semler, da Semco, dada no MIT, intitulada “Liderando por omissão”, de 2005. Vejam como democracia aplicada traz resultados.

Vocês já estão sabendo do curso de Professional Scrum Developer que eu trouxe pro Brasil. Agora a grande novidade é que o Ken Schwaber, o pai do Scrum, o cara que inventou esse negócio todo (com o Jeff Sutherland, é claro), está vindo pro Brasil para dar um curso comigo.

Quando estive em Redmond para o treinamento que me preparou para trazer o curso pro Brasil, quem ministrou o treinamento e nos preparou, foi o próprio Ken e o Richard Hundhausend (da Accentient, que montou o curso de .Net). Depois disso tenho mantido um contato bem próximo com ele e com a Scrum.org, e ele tem também acompanhado bem de perto os mercados do mundo todo, e se interessou em vir ao Brasil ministrar um curso comigo. Um não, dois:

O primeiro é um curso de Professional Scrum Developer, do dia 26 de Julho até 30 de Julho. Esse curso será ensinado por mim, pelo Ken, e teremos também a presença do Alex Armstrong, da Scrum.org. O curso já está aberto para receber inscrições online.

O segundo é um curso de Scrum In Depth, que é uma nova versão do curso original de CSM idealizado pelo Ken. O curso vai ser ensinado pelo Ken Schwaber e por mim, nos dias 22 e 23 de Julho, e também já está recebendo inscrições.

Ambos os cursos serão ministrados em inglês, em São Paulo.

Para aproveitar a viagem o Ken teve a ideia de organizar um encontro com a comunidade de Scrum brasileira, que acontecerá no dia 24 de Julho, um sábado. Estou organizando isso junto com o Alexandre Magno, e teremos notícias em breve. Fique ligado na lista do Scrum Brasil para mais novidades.

Vejo vocês por lá.

Prestem atenção à esse gráfico:

Esse é o gráfico de categorização de complexidade em projetos de desenvolvimento de software. Ele é usado em cursos avançados de Scrum, como o Scrum in Depth, e está disponível gratuitamente na internet, junto a muito material avançado sobre Scrum e agilidade. A informação vem acompanhada de alguns dados:

• Se adicionarmos a dimensão de pessoas, um nível adicional de complexidade é adicionado
• O último projeto simples foi em 1969

(Esse “último projeto simples” deve ter sido a gravação do Abbey Road, dos Beatles – e olha que se isso não foi complexo, pra não dizer caótico, eu não sei o que foi.)

O gráfico não é parte do curso de Professional Scrum Developer, apesar de eu ter utilizado ele semana passada na primeira edição do curso. Eu o acrescentei deliberadamente, e discuti em seguida o conceito de emergência, e como ele afeta software. É isso que quero discutir rapidamente aqui. Adianto que de forma alguma eu vou encerrar a discussão ou cobrir todo o assunto, aliás, eu vou confundí-lo ainda mais, mas eu vou escrever assim mesmo. Quando você me encontrar na rua pode me parar para dizer que não concorda, que eu estou errado, que não entendeu, ou me contar como o conceito mudou sua vida.

A discussão é importante, porque ela está na base da utilização da agilidade. Não é a toa que usamos a agilidade, e sem conhecer um pouquinho sobre complexidade fica parecendo que o manifesto ágil surgiu do nada, que o Scrum é definido pelas suas práticas, e que como os processos ágeis são empíricos, sua base teórica também deve ser. Ainda que muito empirismo tenha motivado os primeiros agilistas (quando esse nome sequer existia) muito estudo também os dirigiu. Estudos humanos, filosóficos, lógicos, matemáticos, físicos, entre outros.

Antes que você desista, já que já se passaram vários parágrafos e eu ainda estou introduzindo o assunto, já adianto que não vou te inundar de conceitos sobre complexidade, você procura na Wikipedia se gostar do assunto, ou assiste o vídeo do Akita, se quiser descobrir que eu nem arranhei a ponta do iceberg e há muito ainda a estudar.

De qualquer forma, vou tocar nos efeitos de um sistema complexo, e isso é muito simples. Primeiro vamos entender o gráfico.

De um lado, no eixo Y, estão os requerimentos, e o eixo vai de com mais concordância a com menos concordância. Quanto maior o número de Y, menos concordância há sobre os requerimentos.

Do outro lado, no eixo X, está a tecnologia, que vai do zero, onde está perto da segura, ao infinito, onde está longe da certeza.

Teríamos um eixo Z, de pessoas, que não aparece.

Projetos simples são projetos com requerimentos consensuais e transparentes e tecnologia segura e certa. Projetos complicados variam uma, e apenas uma, destas variáveis, e só um pouco. Não são muito diferentes, projetos complicados são iguaizinhos projetos simples, só que você precisa de mais esforço para gerenciá-los, mas pode usar as mesmas técnicas usadas com um projeto simples, que vai funcionar.

No outro extremo estão projetos caóticos, que possuem requerimentos sem consenso, e tecnologia incerta ou desconhecida. Este tipo de projeto é mais conhecido como “um projeto comum de software” para a maioria do mercado. Esses projetos são caracterizados pela completa falta de certeza em praticamente tudo, incluindo escopo, prazo ou custo. Nesse tipo de projeto não se sabe se uma mudança vai levar uma hora ou 30 horas pra ser feita, e com frequência se estima um valor, e é o outro. Nesses projetos o escopo está completamente descontrolado, e o papel do gestor, seja ele um GP tradicional ou um suposto time Scrum ou XP, é simplesmente tomar a culpa, já que a gestão não está fazendo nenhuma diferença e o projeto vai sofrer invariavelmente. O “suposto” é porque se fosse um time Scrum ou XP de verdade isso não aconteceria, como você verá a seguir.

No meio está uma terceira área, em cinza. Ela está destacada porque é lá que os projetos ágeis fazem sentido. É lá que eles ficam financeiramente viáveis. Nessa área não podemos usar as mesmas técnicas usadas em projetos simples ou complicados, porque há algo atrapalhando: projetos complexos não são lineares.

Você sabe o que significa dizer que algo é não linear? É algo no mínimo peculiar e ignorado na nossa sociedade que não consegue fazer contas que vão além de uma fórmula de báscara. Então eu vou te contar. É revelador. Mas primeiro temos que entender o que é algo linear.

Imagine que um desenvolvedor, ao iniciar um projeto, desenvolve 10 linhas de código por hora. Essa é a curva de produtividade do projeto:

Se mais ninguém for trabalhar no projeto, esssa seria a curva até o final do projeto:

Se mais um desenvolvedor que produz 8 linhas de código por hora for acrescentado ao projeto no inicio do tempo 2, ele ficará assim:

Até o final do projeto vamos ter algo assim:

Se você acrescentar um terceiro desenvolvedor que faz 14 linhas de código por hora, o projeto ficará assim, com um total de 32 linhas de código por hora (o total do desenvolvedor 1, mais o 2, mais o 3) no final do tempo 4:

Simples, não é? Isso é o que se espera em um projeto linear. Somos capazes de adicionar “recursos” (odeio esse termo quando aplicado a pessoas) aos projetos, e estas movimentações são somadas ou subtraidas linearmente. E é assim que a grande maioria dos projetos de software é planejado: um desenvolvedor faz 10, logo 2 iguais devem fazer 20. E assim se constroem gigantescos cronogramas de centenas de linhas e anos de planejamento. Com base nessa suposta lineariadade vemos cronogramas absurdos, que planejam em detalhes anos à frente. Além do Microsoft Project esses gestores devem usar também bolas cristal. Sabem porque?

Porque isso simplesmente não existe, isso não acontece, não se confirma. É um planejamento inutil. Sabe porque não acontece? Voltando ao exemplo anterior, quando você acrescenta o segundo desenvolvedor, o primeiro vai ter que parar para sincronizar com ele o que está acontecendo no projeto. Além disso, eles podem não se entender e a produtividade dos dois cai. Ou eles se dão muito bem, e a produtividade deles fica muito maior do que o esperado. Ou suas habilidades são perfeitamente complementares e não há nenhum problema que eles não possam resolver, e o projeto fica pronto em um quarto do tempo. Isso é o resultado real das interações entre dois seres humanos; elas nunca são lineares. Nunca. É impossível prever qual vai ser o resultado dos dois desenvolvedores trabalhando juntos.

E eu só estou tocando no item pessoas, que sequer aparece no gráfico do Ken Schwaber lá de cima. Ele toca em outros dois eixos: negócio e tecnologia. E os problemas são muito semelhantes.

Essas características não lineares, estas coisas que “aparecem” do nada devido à interação entre as partes, é o que chamamos de emergência. As partes cooperam positiva ou negativamente, produzindo um padrão muito difícil (senão impossível) de prever.

Quando o padrão fica muito complexo ele fica impossível de prever e portanto de controlar. É nesse momento que ele sai da área cinza do gráfico, que deixa de ser complexo e passa a ser caótico. Ele ainda seria previsível se possuíssemos uma quantidade de calculadoras que tende ao infinito, e se pudéssemos medir todas as variáveis. Infelizmente nós não temos nem um, nem outro. Dessa forma, a impressão que fica é que o resultado das interações das partes é aleatório e imprevisível, mas não é, nós é que não possuímos capacidade pra medir todas as variáveis. Na prática, isso é irrelevante. Apenas aceite que o resultado é imprevisível para todos os fins práticos.

Se o resultado de um projeto de software é imprevisível qualquer esforço de gestão é inutil. Temos então que impedir que o projeto fique caótico, temos que tentar mantê-lo “apenas” complexo.

É aí que entra o processo de controle empírico. Nesse processo estamos reavaliando o status atual a cada passo dado (e isso inclui até mesmo o tamanho do próprio passo). Fazemos isso porque sabemos que precisamos perceber os resultados emergentes o quanto antes para podermos nos adaptar a eles. Isso é feito com inspeção e adaptação constante, e com transparência que jogue luz sobre os acontecimentos. Não por acaso esses são os três pilares do Scrum.

Do mesmo livro citado acima:

“Porque planejar?
Para colocar um conjunto comum de entendimentos a partir do qual emergência, adaptação e colaboração possam ocorrer.”

E porque tanta gente passa reto por essa frase sem tentar entender seu profundo significado?

A emergência e falta de linearidade é também um dos motivo (mas não o único) que os frameworks ágeis colocam sobre o time, e não sobre um gestor único, a responsabilidade de gerenciar o projeto. Um único GP, por mais capacitado que seja, é somente um, e por isso é linear e simples, incapaz de lidar com as saídas de um sistema complexo. Para resolver o problema precisamos de um agente também complexo, materializado no time e suas interações ricas.

Vou parar por aqui, porque já imagino que o assunto deve estar complicado o suficiente. Fica só uma pergunta:

E agora? O que você vai fazer com esse conhecimento?

Há alguma coisas que você pode fazer para passar a lidar com o “problema” da complexidade. Antes de mais nada pare de usar “complexo” e “complicado” como se fossem sinônimos. Não são. A seguir, passe a perceber os resultados das interações ricas que acontecem entre as variáveis de um projeto, e como elas podem afetar o resultado do projeto. Desta forma você poderá compreender e ser testemuna dos efeitos de emergência em projetos de software. Tente então avaliar como um processo de inspeção e adaptação constante, que permitisse entender claramente o que estava acontecendo (por causa da transparência), poderia lhe ajudar a diminuir os riscos daquela interação, lhe permitiria ter virado o barco antes de ele atingir um iceberg, ou talvez aproveitar alguma oportunidade que foi perdida.

Mas não espere resolver esse problema sozinho. Já temos mais de uma década de práticas ágeis acumuladas, e só agora elas começam a chegar na grande maioria. Busque conhecimento que vai além de si próprio. A comunidade brasileira é bastante vibrante e possui diversos exemplos interessantes, com práticas que foram sucesso em um lugar e fracasso em outro. Avalie isso tudo sobre a luz destas teorias, que estão na base. Leia livros para entender isso tudo melhor, participe de conferências e discussões sobre o assunto. E se melhorar for urgente na sua empresa avalie contratar um consultor para ajudar. E cuidado com os que “implantam” Scrum em poucos dias. Isso é impossível. Já encontrei algumas empresas que passaram por esses consultores, e o resultado é um tsunami sobre os projetos.

E se você ainda não leu os recentes posts sobre emergência – documentação emergente e arquitetura emergente, sugiro que leia em seguida. Se já leu e não conhecia muito bem o conceito de complexidade e emergência, leia de novo, vão fazer ainda mais sentido.

Que tipo de documentação eu preciso?

Respondi essa pergunta semana passada no Formspring. Uso User Stories? Uso Diagrama de classe? Uso Casos de Uso? A pergunta, na verdade, é qual a documentação ideal em um processo de desenvolvimento de software. Que tipo de documento é preciso para iniciar o desenvolvimento?

Não existe documento ideal. E você não precisa de nenhum documento pra iniciar o desenvolvimento.

Pronto, dei argumentos para todos os extremistas defensores do desenvolvimento em cascata. Lá vem eles de novo dizer que em projetos ágeis não há documentação. E não foi o que eu disse. Eu disse que você pode iniciar o desenvolvimento sem nenhum documento. Ainda assim, como isso é possível?

Amigos, libertem-se da ilusão do processo em cascata, e de que vocês conseguem documentar antes de executar. Libertem-se da ilusão de que vocês são capazes de prever o que vai acontecer, e prever o que vão precisar daqui a alguns dias. Vocês só vão saber do que vão precisar em projeto de software quando realmente precisarem. Talvez vocês tenham uma boa ideia sobre isso depois de terem feito alguns projetos com o mesmo time, com a mesma tecnologia, e que trate do mesmo negócio (ou com pouca variação nestes itens). E mesmo assim, vocês vão precisar ajustar um pouco em cada projeto, mesmo depois de toda essa experiência acumulada.

Qual documento você realmente precisa para começar? Nenhum. Você até pode começar com algum que a empresa sugeriu, ou algum que algum membro do time sugeriu, mas isso não faz diferença. Inicie o projeto, isso é que interessa. Se você realmente fundamentar o projeto em princípios ágeis, você vai ter um projeto em que a transparência reina, e você vai ter a chance de realizar inspeções constantes no processo, se adaptar quando encontrar algo que não está funcionando e reforçar o que está funcionando. Assim, se começar com nenhum documento, você provavelmente vai perceber que um ou outro documento está fazendo falta, e vai ter a chance de inclui-lo. Isso pode aparecer dentro dos diversos ciclos de inspeção que você tem.

Quando você está programando em par pode perceber que um documento pode ser útil para comunicar melhor um design, ou talvez um cartão CRC. Às vezes na reunião diária pode ser que alguém precise entender melhor um requisito que você conhece, e daí talvez você crie um caso de uso para explicar melhor isso. Pode ser que o arquiteto corporativo demande algum diagrama arquitetural da aplicação, então vocês colocam isso no backlog do projeto e entregam para ele no final de uma iteração.

Mas nada disso importa, nenhum dos documentos mencionados acima importa. O que importa é que seu time esteja aberto a esses feedbacks que inundam qualquer projeto de software, que saiba aproveitá-los. A documentação que você precisa vai naturalmente emergir, vinda da comunicação do time, das interações com o negócio, das necessidades técnicas, e de diversos outros fatores. Isso é o que eu chamo de documentação emergente.

É por isso que desenvolver software é um processo complexo e não linear, e portanto muito além da nossa compreensão total: há variáveis demais. Nosso objetivo é apenas impedir que ele se torne caótico, fazendo o máximo para mantê-lo apenas complexo. E os fluxos de inspeção e adaptação em ciclos curtos vão garantir isso. Isso é a base de um processo empírico de controle. E se aplica também à documentação. Faça apenas o necessário, decidindo sempre no último momento responsável (last responsible moment).

E os padrões corporativos? Devem ser um catálogo. Mais uma vez, padrões sem cenários são completamente inúteis.

Nas consultorias da vida eu já encontrei mais vezes do que gostaria projetos em que os desenvolvedores tem nojo do código. É sério, nojo mesmo, parece que estão olhando para algo pútrido, em decomposição. Porque será que deixamos as coisas chegarem a esse ponto? Você tem nojo do seu projeto atual? Qual a SUA responsabilidade nisso? Qual a nossa responsabilidade coletiva sobre isso? Vamos analisar.

Em um projeto tradicional o seguinte triângulo é usado com frequência:

No meio estaria a qualidade, resultado dos três extremos do triângulo. O triângulo geralmente significa que o cliente deve escolher dois pontos que ele quer fixar, e um ponto que vai ser flexível. Por exemplo, ele quer um projeto para 6 meses, e que custe 1 milhão. Para isso ele vai ter que flexibilizar o escopo. A qualidade é dada como fixa e constante.

No entanto, o que vemos no mercado é que os três pontos são fixos! O cliente do projeto quer um projeto para 6 meses, que custe 1 milhão, e que atenda um levantamento já realizado, ou seja, um escopo pré-definido. Nesses casos, tenho uma outra visão sobre o triângulo, ele não é mais um triângulo de compensações. Ele se parece mais com isso:

Isso é um triângulo impossível.

Mas estou sendo injusto. O triângulo não é impossível. Ele é possível, basta variar o quarto ponto, aquele que não aparece: a qualidade!

E é justamente isso que fazemos. Geralmente, como o escopo é fixo e os recursos também, é no prazo que temos sofremos. Estamos sempre atrasados, fazendo horas extras, dormindo pouco.

E vocês sabem o que acontece quando você pressiona um desenvolvedor por prazo? Ele diminui a qualidade! Isso é um fato! Imagino que se os inúmeros gerentes de projeto por aí tivessem essa informação eles iriam pensar duas vezes antes de se dobrarem sobre os ombros de um desenvolvedor e fazer aquela famosa pergunta: dá pra andar um pouco mais rápido? (ou outras semelhantes, como “já terminou?”, ou “dá pra entregar dia tal?”)

E sabe o que é pior? O desenvolvedor aceita essa pressão. Ele aceita cortar qualidade pra atender o prazo. Ainda pior, ele não conta que está cortando qualidade, e o coitado do gerente de projeto fica em uma situação ainda pior. Ou, mais frequentemente, o desenvolvedor sequer percebe que está cortando a qualidade.

A cada dia mais qualidade é cortada do projeto, mas atalhos são pegos. Em pouco tempo, o que acontece? Temos um código nojento, que ninguém mais quer trabalhar. O cliente, por outro lado, encontra um software nojento, resultado de um código nojento, e entende que o desenvolvedor só faz porcaria. A visão do cliente, não tenham dúvidas, é de que somos um bando de incompetentes. Já imaginou se seu médico cortasse qualidade toda vez que estivesse pressionado por um prazo? Já imaginou como seria uma cirurgia do coração? Mas não, ele não faz isso, ele é um profissional.

Pra resolver isso, há um instrumento vindo das práticas ágeis chamado “definição de pronto”. Vou falar dele semana que vem. Por enquanto, pensem sobre as consequências que sua decisão de aceitar pressão de prazo do cliente ou gerente de projeto, de forma recorrente. Pense que isso vai tornar sua vida miserável, e que você estará contribuindo para piorar a visão que se tem sobre nossa profissão.

Nesta terça (30/Março) fizemos, o Felipe Rodrigues, da Fratech, e eu, um minicurso sobre Scrum para desenvolvedores. O curso foi em São Paulo na Globalcode, que está oferecendo em parceria com a Fratech uma academia de agilidade, incluindo cursos sobre lean, Scrum, XP, entre outros.

O curso foi ótimo, fomos bem avaliados, e depois o Felipe, a Flavia Oliveira e eu fomos jantar e discutir sobre o futuro da humanidade em geral, e da agilidade em específico, além de, é claro discutir que o Windows é melhor que o Linux (eu falando), ou o contrário (Felipe falando). O legal de discutir com o Felipe é que ele e eu discordamos em um monte de assuntos, mas tudo é feito com muita camaradagem e respeito, e as conversas são ótimas. Quem participou do minicurso percebeu que brincamos bastante com essas coisas de forma divertida.

Iniciamos o curso falando do Scrum, explicando um pouco da Scrum.org, falando um pouco da agilidae em geral e explicando os objetivos da academia de agilidade e do programa Professional Scrum Developer. Depois produzimos, com feedback dos participantes (presenciais e online), uma árvore da realidade atual (Current reality tree). Está é uma técnica analítica da Teoria das restrições, e foi utilizada para chegar às causas raíz dos problemas atuais dos processos de desenvolvimento de software tradicionais, em que a maioria dos desenvolvedores, infelizmente, ainda está inserido. Depois demos uma visão geral sobre o Scrum. O tempo todo citamos práticas ágeis que devem complementar o Scrum a fim de evitar um Scrum flácido, afinal, este era um curso para desenvolvedores.

Abaixo estão os slides da apresentação.

Abaixo o resultado da árvore da realidade atual dos processos de desenvolvimento tradicionais, quando aplicados a uma realidade imprevisível, como é a imensa maioria dos cenários de desenvolvimento de software (clique para ampliar):

Infelizmente o tempo não permitiu trabalhar os outros problemas, mas os que puderam ser trabalhados ofereceram bastante reflexão.

Os links:

• Grupo de Scrum no Yahoo
• Scrum.org
• Scrum Alliance
• Site do Ken Schwaber
• Revista Visão Ágil

Espero que quem esteve lá tenha gostado, aos que não estiveram, provavelmente haverá outras palestras, e sempre há os cursos já mencionados. Até lá.