Em seu livro Management 3.0 [2], Jurgen Appelo, explica que a confiança sempre se dá em duas direções: eu posso escolher confiar em você, e você pode escolher confiar em mim, mas ambos não necessariamente coexistem. Nessa linha de raciocínio, podemos identificar quatro grupos básicos de relações de confiança em uma ambiente de desenvolvimento de software: Confiar no time, ganhar a confiança dos membros do time, ajudar os membros do time a confiar uns nos outros, e confiar em si mesmo.

Shore ressalta a importância de a organização confiar no time, mas lembra que a confiança, não surge em toque de mágica, você precisa conquistá-la.

Para Appelo a formula secreta para conquistar a confiança das pessoas é muito simples: “Cumpra aquilo que Promete”. As pessoas confiam em você quando sabem que podem contar com você. Quando sabem que podem acreditar no que você diz.

A falta de confiança sempre vem acompanhada de diversos outros sintomas prejudiciais a saúde da organização tais como a centralização das tomadas de decisão, a falta de delegação, a micro-gestão, e a falta de motivação das pessoas.

Em seu livro Coaching Agile Teams [3], Lyssa Adkins, afirma que “confiar, não significa dar férias ao seu cérebro”, mesmo confiando você pode estar atento ao que ocorre no time e ao redor do time. Confiar não é o mesmo que negligenciar, assim como delegar, não é o mesmo que abandonar suas responsabilidades, existem diferentes níveis de delegação que devem ser aplicados de acordo com a competência e preparo das pessoas.

No artigo Accountability in Software Development [4], Kent Beck, criador do método XP, argumenta que a confiança tem uma relação direta com a responsabilidade e a coragem que cada um de nós deve ter em nos esforçamos para sermos sempre o melhor que pudermos ser em tudo aquilo que fazemos.

Como anda a confiança na sua organização? Os membros dos times confiam uns nos outros? A gestão confia nos times e vice-versa? Seus clientes confiam na sua organização? Quais os efeitos indesejáveis que a falta de confiança está trazendo a sua organização?

Referências

1. James Shore – The Art of Agile
2. Jurgen Appelo – Management 3.0
3. Lyssa Adkins - Coaching Agile Teams
4. Kent Beck - Accountability in Software Development

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!

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.

O Conversa Rápida é um evento que tem como objetivo tirar as pessoas da zona de conforto. É um conjunto de 10 palestras de 5 minutos, seguidas por 5 minutos de perguntas. E os temas das palestras só são conhecidos no momento das palestras. Se quiser saber como foram as edições anteriores, dê uma olhada em nosso canal no youtube.

Nessa edição, os palestrantes confirmados até o momento são:

• Alexandre Magno, da AdaptWorks
• Cecilia Fernandes, da Caelum
• Fabiano Milani, da AdaptIdeas
• Giovanni Bassi, da Lambda3
• Jonas Abreu, da AdaptWorks
• Leonardo Andreucci, do Apontador
• Paulo Siqueira
• Plínio Balduino, da Gusworks
• Simone Pittner
• Victor Hugo Germano, da Lambda3

Se tiver interesse em assistir às palestras, envie um email para jabreu@adaptworks.com.br para confirmar sua presença, pois temos poucos lugares.

Assim, as novas regras são:

• O Content Outline and Learning Objectives — a base para a estrutura e conteúdo do novo exame de CSM — está disponível para download no site da Scrum Alliance.
• Todos os candidatos que prestarem o exame até o dia 31 de Março de 2012 serão automaticamente aprovados.
• A partir de 1º de Abril de 2012, os candidatos serão aprovados ou não de acordo com o seu desempenho no exame.
• A partir de 1º de Abril de 2012, os candidatos terão 60 dias para duas (2) tentativas gratuitas de aprovação. Após este período de 60 dias, o candidato deve pagar US$25 por tentativa. Após três (3) tentativas sem aprovação, é recomendado que o candidato faça um outro treinamento de CSM antes que sejam permitidas novas tentativas.
• O novo exame terá 35 questões, sem limite de tempo. Os candidatos poderão marcar questões, mudar as respostas das questões e até mesmo interromper o exame, retornando a ele posteriormente dentro do prazo de 60 dias.
• Ao final do exame, o candidato verá as questões respondidas incorretamente. A lista de opções não será exibida. Isto para encorajar os candidatos que não passarem na primeira tentativa revejam o conteúdo do curso antes de uma nova tentativa.
• Candidatos que não sejam aprovados na primeira tentativa podem refazer o teste imediatamente (não é necessário um período mínimo) ou a qualquer momento dentro do período de 60 dias.
• Depois de aprovado, o candidato pode renovar sua credencial a cada dois anos. A Scrum Alliance criará até Janeiro de 2013 o programa de Professional Development Units (PDUs). Os CSMs deverão obter estes PDUs para manter suas certificações. Maiores detalhes sobre o programa de PDUs serão informados em breve.

Boa sorte para quem ainda vai prestar o exame e um feliz 2012 para todos!

Os “jogos de inovação” são alguns jogos elaborados por uma consultoria do Vale do Silício, The Innovation Games Company ®, criada pelo canadense Luke Hohmann, que cria jogos que estimulam o engajamento de clientes, colegas e parceiros no desenvolvimento de produtos/projetos.

Por sua informalidade, a técnica de jogos permite que pessoas de diferentes níveis hierárquicos, com diferentes papéis na empresa no ou na equipe de desenvolvimento de produto/projeto, sintam-se a vontade para expor suas visões sobre o que está sendo feito.

No treinamento nos fizemos alguns dos jogos, que nos ajudaram a aplicar diferentes técnicas para priorizar atividades no desenvolvimento de um projeto/produto, a entender melhor aspectos que estimulam ou atrasam o ciclo de desenvolvimento e a relacionar recursos existens a fim de se chegar a novas idéias através da associação destes recursos.

Aqui vai uma breve descrição dos jogos que praticamos:

- Speed Boat – ajuda a entender o que seus clientes gostam ou não gostam em seu produto ou serviço, quais são os aspectos que estão ajudando a acelerar ou a desacelerar seu projeto ou ainda a entender quais são os fatores de motivação e desmotivação que sua equipe percebe no projeto. A técnica garante que reuniões de retrospectiva / avaliação fiquem sob controle e não se transformem numa avalanche de reclamações em que só aparecem os aspectos negativos do projeto, sem se pensar em como resolvê-los e avançar. A técnica é bem simples, você precisa apenas desenhar um barco num quadro branco ou folha de papel pendurada na parede, e as pessoas devem marcar, com post-its, as coisas que “ancoram” o barco, e as coisas que o fazem andar com maior velocidade. Os itens podem ter peso (marcado nos post-its), ou simplesmente estar em posições diferentes no quadro (as coisas que mais atrapalham ficam mais fundas, como se fossem as âncoras mais pesadas).

- Buy a Feature – ajuda a fazer com que seu cliente (ou CEO, ou Diretor, ou Gerente de Produtos, etc) consiga priorizar melhor o desenvolvimento de features que realmente irão agregar mais valor ao negócio. Geralmente o cliente quer o projeto todo pronto, para ontem. Mas nem todas as features serão usadas, nem todas são críticas para o lançamento e nem todas precisam de fato ser feitas (isso vai acabar sendo descoberto com o uso do produto). O jogo consiste em ter uma lista de features, e a dar um preço para cada uma delas (na vida real, o preço pode ser a estimativa e o custo de desenvolvimento, por exemplo). Cada cliente receberá um certo valor para poder comprar as features, mas, obviamente, não terá dinheiro suficiente para todas. Portanto, para algumas features, ele terá que negociar com outros clientes para que os dois juntos tenham recursos suficientes para comprá-las, e terá que abrir mão de outras. O resultado deste jogo é que o conjunto de clientes de seu produto terá priorizado o que realmente lhes traz valor.

- Remember the Future – o que você precisa fazer em seu produto para que daqui a 1 ano ele tenha trazido determinado benefício ao seu cliente? Partindo do benefício, a idéia deste jogo é pensar de traz para frente o que é necessário fazer com o produto para que ele traga tal benefício, e o que precisou ser feito imediatamente antes para que ele chegasse até este ponto. Dado o prazo para o produto atingir o objetivo, este jogo faz com que as pessoas pensem no que é realmente necessário para partir do ponto em que se está hoje, para se chegar ao ponto em que o produto trará o benefício esperado.

- Prune the Product Tree – todas as features são importantes e precisam ser entregues ao mesmo tempo? Isso não é verdade, e com este jogo você e sua equipe poderão montar o roadmap de seu produto pensando nos diversos aspectos do produto. A metodologia consiste em desenhar uma árvore, e ir colocando, com post-its, para dar o formato desejado à copa da árvore. Assim, os galhos da árvore representam os tipos de funcionalidade, as funcionalidades em si são as folhas, as features fundamentais são o tronco, e a base da aplicação são as raízes. Assim, as pessoas vão colando as folhas nos devidos galhos, sendo que as funcionalidades já prontas ou mais desejáveis ficam mais perto do tronco do que as menos importantes. A metologia deixa vísivel quando, por exemplo, algum aspecto de seu produto está ficando de lado (ex: muitas folhas no ramo que diz respeito ao front-end de sua plataforma de comércio eletrônico e poucas no raml que diz respeito ao back-end), para que você possa avaliar se está é mesmo a melhor opção.

- Product Box – Desenhando a caixa que venderia seu produto ou serviço num supermercado, os jogadores terão que identificar quais os aspectos mais importantes do produto, como comunicá-los melhor e quais problemas de fato seu produto resolve. As limitações de espaço exigirão que o grupo pense no que realmente são as principais características do produto, e tenha criatividade para comunicar da melhor forma.

- Spider Web – Este jogo, que funciona através do desenho de uma rede que relacione todos os produtos, serviços ou usos que podem ser feitos com seu produto na forma de uma teia de aranha. Com isso, percebe-se novos usos que podem ser feitos do produto através das conexões que aparecerão.

- Start Your Day – Descreva como seu cliente usa ou se relaciona com seu produto ao longo do tempo (pode ser um dia, uma semana, um mês ou qualque período, depende do seu produto). Pense em todas as situações em que seu produto é necessário para o cliente, e como seu produto pode ajudá-lo em cada caso. Com isso você entenderá melhor como seu produto é usado, para quais aspectos você tem que dar mais importância, e obviamente, ajudará a pensar na experiência do usuário, sob todos os aspectos.

Sempre que possível envolva também o cliente, afinal, é importante ele estar engajado com o projeto e totalmente alinhado com sua equipe.

Estes e outros jogos criados pela The Innovation Games Company (R) estão disponíveis no livro Innovation Games: Creating Breakthrough Products Through Collaborative Play, que todos os participantes do treinamento receberam como cortesia.

Para vários dos jogos há versões onlines, para que times remotos possam participar, mas obviamente o ideal é a equipe estar toda reunida, uma vez que a colaboração e o debate são fundamentais para que os resultados esperados sejam alcançados.

Se você já aplicou alguma destas técnicas em alguma empresa ou cliente, aproveite o espaço de comentários do blog para contar sua experiência!

Se não aplicou, lembre-se, a técnica de jogos é simples, mas exige uma preparação prévia da sala e dos materiais a serem utilizados para que funcione bem e envolva a equipe de jogadores!

No geral, a conferência foi excelente! Talvez a melhor que eu tenha participado desde o London Scrum Gathering 2007, que foi bem pequeno, quase um grupo de estudo reunido para aprender mais sobre Scrum. Abaixo vou listar os pontos fortes e um resumo das principais palestras e trilhas que participei.

No-chilique

Em tempos onde praticamente todos os lugares que se fala sobre Agile estão infestados de chiliques em volta de Kanban versus Scrum, só Lean Startup Salva, e coisas do tipo, a LESS foi exceção. Em cada roda de discussão que você entrava, era perceptível que ninguém queria ficar “degladiando” em volta de processos, mantras, e afins. Salvo raras exceções, tudo foi em volta de aprendizado e todos abertos a ouvir opiniões diferentes de suas “crenças”.

NOTA: Eu não participei de nenhuma roda de discussão onde o David Anderson estava presente…e, veja, o Ken Schwaber não estava lá. Eric Ries também não. Rs…

Organização

A organização do evento foi fantástica e totalmente community-driven. As instalações e localização do Clarion Hotel eram perfeitas e tudo funcionou muito bem – ou praticamente tudo,  já que como em quase todos eventos a internet foi sofrível.

Keynotes

Gostei muito do Keynote de abertura do Bjarte Bogsnes. Beyond Budgeting é um tema que me chama a atenção já há alguns anos e, por mais que eu já tenha feito o curso “Implementing Beyond Budgeting” com ele, a palestra apresentou insights interessantes e práticos, como os exemplos de Ambition to Action. Também gostei de ouvir as idéias de James Sutton em volta do tema Complexidade Organizacional e Lean. Simples, leve, mas que foi ótima para reforçar alguns conceitos de ligação disto com o mundo organizacional.

Infelizmente não posso falar o mesmo dos keynotes do segundo dia. Peter Middleton fez bastante confusão com alguns conceitos de Agile e Lean e, por mais que tenha contado histórias interessantes da evolução de Lean na BBC, deixou a platéia insegura quanto às reais razões para algumas aplicações e “mudanças” de Agile para Lean. Já Steve Denning, no keynote de fechamento do evento, fez o esperado: aquela apresentação onde todos damos risadas de piadas sobre nós mesmos ou de nossas organizações ou de outras organizações. Os conceitos que Denning apresenta são bem legais, mas, ao fim de sua palestra fiquei com a mesma sensação de quando terminei de ler seu livro “Radical Leadership”: muita história contada de forma inspiradora, mas que não nos ajuda muito e de forma pragmática a mudar a gestão nas organizações. Não muito diferente de você ler um livro com a história da Apple ou do Steve Jobs; ou da Google; ou da Amazon; ou <coloque aqui o nome de uma empresa que HOJE seja admirada pelo marcado>. Algo muito proveitoso que tirei deste keynote foi a colocação de Denning de que muitas empresas “optarão” por morrer ao invés de encarar de verdade a mudança. Forte mas real.

Trilha Transforming Organizations

Nesta trilha participei das palestras do Ari Tikka (Organizational Allienation) e do Francisco Trindade (Subject to Change). Ambas geraram bons insights para lidar com situações que esbarram na estrutura e cultura organizacional. O Frank citou a conhecida democracia da brasileira Semco e da indiana HCL para construir alguns bons conceitos para um processo de mudança organizacional, fugindo dos famosos “programas de mudança” com cartazes na parede, etc.

Trilha Complexity and System Thinking

Aqui assiti ao Jurgen Appelo falando de uma forma extremamente direta sobre a complexidade por trás das teorias relacionadas a sistemas complexos e pensamento sistêmico (complexo complicado, não?)…o conteúdo foi extraordinário, pena que para pouco tempo de palestra. Logo em seguida Karl Scotland falou da ciência por trás do Kanban, relacionando algumas teorias à forma de trabalho das organizações e de como o Kanban se encaixa ali…gostei bastante desta palestra.

Trilha Beyond Budgeting

Não tenho como negar que era a trilha que eu mais esperava e, felizmente, não sai decepcionado. Peter Bunce foi magnífico com “The Leaders’s Dilemma” abordando diversos exemplos negativos relacionados ao alinhamento de incentivos às metas. Bunce foi também crítico ao mostrar práticas mentirosas de Forecasting e de suas consequências nas organizações.

Na sequência Kajsen Hannson falou de como Beyond Budgeting é praticado no Handelsbanken, um dos bancos mais estáveis da União Européia e o mais rentável da Escandinávia. A organização do banco por branches que possuem total autonomia na gestão e no relacionamento com os clientes foi um dos maiores exemplos de empowerment que já ouvi falar. E veja, não estamos falando de empresa de mídia, mas sim de um banco.

Brian Hawkes (Driver-based forecasting and Dynamic Growth Management) fez uma palestra mostrando alternativas para o processo de forecasting em organizações. Usou exemplos de forecasting em vendas, com estrutura em rolling sem foco em “acertar” o que vai acontecer mas sim em “estudar” o que pode acontecer. Palestra bastante avançada para o público do evento, mas que forneceu pontos importantes a serem estudados.

Para fechar Paul Gooderham falou sobre motivação e o que realmente motiva os funcionários. Foi uma chuva de números baseada em pesquisas feitas em diversas empresas e com uma estrutura que na minha opinião soou um tanto quanto acadêmica. Foi o ponto fraco da trilha.

Workshops

O terceiro dia do evento foi reservado para diversos workshops apresentados por nomes como Jean Tabaka e Alan Shalloway. Eram temas bem interessantes, mas…a minha quarta-feira já estava reservada para uma visita que eu havia agendado bem antes de partir para o evento – ir conhecer Beyond Budgeting no Handelsbanken. A visita foi fantástica, mas os detalhes ficarão para um próximo post.

Mais informações

Segundo a organização do evento os slides das palestras estarão disponíveis no site da LESS 2011 ainda esta semana. Além disso, você ponde encontrar um excelente materil no Twitter procurando pela hashtag #LESS2011

Conclusão

Aprendi bastante nas palestras, nas conversas de corredor, nos almoços e na visita ao Handelsbanken. O LESS com certeza já é um evento reservado para o meu calendário de 2012.

A ideia em si era muito boa — afinal, teríamos a oportunidade de discutir com nosso público local e obter informações que de outra forma, ficariam perdidas no meio de tantas outras de pessoas no mundo inteiro.

Depois das parabenizações, dos comentários entusiasmados, das possibilidades e oportunidades, pedi um pouco de atenção para alguns detalhes (na época, era, entre outras coisas, responsável por nossa rede interna, o que incluía o link com a internet): nossa conexão com a internet não era boa, e isso poderia aumentar o problema; teríamos que solicitar autorização para a matriz para podermos alterar as configurações dos roteadores… antes que eu pudesse dizer qualquer outra coisa, meu gerente me interrompeu e disse: dá para parar de ser tão negativo?

Por muito tempo evitei dar qualquer opinião sobre qualquer coisa. Era assim que as pessoas me viam, negativo? Eu errei em chamar a atenção para algumas coisas que poderiam impactar no resultado? Infelizmente, sou franco e transparente, mas pelo visto, estava fazendo um de-serviço.

Hoje, muitos livros, palestras e tempo depois, consigo me sentir um pouco mais aliviado. Afinal, Jeffrey Liker no livro “O Modelo Toyota” comenta que é função de qualquer um, quando apresentado a uma nova ideia, atentar aos pontos que precisam ser trabalhados para que a pessoa consiga refina-la antes de apresenta-la aos superiores.

E Jurgen Appelo, em seu excelente livro “Management 3.0″, fala sobre feedbacks positivos e negativos: ciclos de feedbacks positivos causam desequilíbrio, acelerando o sistema para longe do equilíbrio. Ciclos negativos de feedback causam estabilização, mantendo o sistema longe do caos.

Mas e você? Acha que fui negativo e estou achando justificativas? Qual a sua opinião?

Em treinamentos, consultorias, conversas de bar, etc., sempre que falamos sobre ambiente de trabalho para times, sugerimos que seja um ambiente que propicie muita interação. Programação em par. Conversas. E criar este tipo de ambiente nem sempre é fácil.

No caso do “salão comunal”, a interação é muito maior, inclusive com pessoas que não sejam membros do seu time de desenvolvimento, você pode ter a opinião de muito mais pessoas, sem contar a flexibilidade que um local assim proporciona. Mas por outro lado, por ser um ambiente compartilhado por muitas pessoas, fica muito mais difícil satisfazer a todos – questões como temperatura, som, iluminação podem ser bastante controversos.

Um ambiente assim, para mim, seria o caos. Barulho em excesso ou de forma contínua fazem com que eu perca a concentração e até conseguir retoma-la levo um certo tempo e exige uma boa quantidade de esforço de minha parte. No meu caso, o ambiente que temos na AdaptWorks funciona bem melhor: uma sala com uma mesa enorme, onde cabem até 8 pessoas tranquilamente. E muitos quadros brancos.

E você, qual o ambiente no qual melhor se adequa?

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?