Porém, para isso é necessário fazer uma transição na organização que às vezes pode ser muito traumática, em alguns casos, uma revolução.

Quando Scrum é usado digamos de forma canônica, onde existe um produto, uma equipe (fulltime), um demandante (po) realmente a coisa funciona bem out of the box. Porém quando a organização tem demandas com características diferentes (diagnósticos, consultoria, bugs, suporte, e desenvolvimento), quando existe mais de um produto, ou existem em etapas diferentes do seu ciclo de vida um em produção outro em concepção ou desenvolvimento, quando existe mais de um demandante e simplesmente não pode ser reduzido a um de forma artificial ou quando temos partes das equipes trabalhando em mais de um produto simultaneamente ou tem outro tipo de atividades Scrum by the Book não nos da as ferramentas necessárias para fazer o melhor com o que temos naquele momento, e ai tudo começa a virar um impedimento ou simplesmente as organizações acabam institucionalizando um ScrumBut.

Existem ScrumButs e ScrumButs, as melhores equipes que eu tenho visto tem passado por um Scrum purinho, porém algumas delas também tem deixado algumas coisas de Scrum de lado, como reuniões diárias ou Sprints, eles tinham um ambiente e um hábito de continuamente trabalhar juntos e se sincronizar, ou seja uma daily contínua, ou entregas contínuas de valor sem iterações, já que as iterações acabavam atrasando a entrega de valor mais rapidamente.

Também tenho visto organizações onde as reuniões diárias deixaram de ser feitas, não porque as equipes se falavam o dia todo, mais porque nínguem queria trabalhar junto, e porque as reuniões diárias eram usadas como um instrumento de microgestão pela organização e também deixaram de fazer Sprints, não porque entregavam valor o tempo inteiro, mais porque os Sprints deixavam claro que nada funcionava, e também deixaram as retrospectivas porque eram muito dolorosas, e também os reviews porque deixava transparente quão mal as coisas estavam.

Tenho visto Designers, Caras de UX, Arquitetos, Especificadores, Analistas de Sistemas, Gestores de Projeto, Testers, Coordenadores, Lideres Técnicos, Gestores Funcionais, não encontrar direito o seu papel numa transição com Scrum e passarem a ser um peso para o novo modelo de gestão, simplesmente porque se tratava de um novo jogo que não tinha claramente definido qual era o papel de cada uma dessas pessoas e elas não conseguiam se enxergar dentro do modelo como definido por Scrum.

Também tenho visto que na maioria dos casos as empresas redefinem o papel de Scrum para “Desenvolvimento de Software” e da equipe para “Equipe de Desenvolvimento”  e deixam pessoas e atividades fundamentais fora do ciclo de Scrum, assim redefinindo o que significa “pronto” no final de um Sprint ao invés de ter um incremento de produto potencialmente pronto, muitos tem algumas features esperando homologação.

Temos que lembrar que Scrum nunca foi “a meta” e sim o desenvolvimento e entrega de produtos com alto valor agregado com alta qualidade, basicamente deixar todos os stakeholders felizes, profissionais orgulhosos com o produto entregue, gestores satisfeitos com os resultados alcançados, clientes e usuários com suas expectativas superadas, ou seja uma situação win-win-win.

Lamentavelmente tenho visto um failure pattern acontecer uma e outra vez, quando trocamos os fins pelos meios, ou as estrategias pelas táticas, ou mais claramente, quando o martelo é mais importante que o trabalho pronto, acabamos alinhando a meta com caminho especifico ao invés de alinharmos a meta com um destino esperado. Na minha opinião é isso uma das coisas que contribuem com o declínio e fracasso de soluções quando é mais importante a solução (metodologia) do que o problema (resultados).

Com a experiencia que temos ganhado nos últimos anos com o uso de Kanban, ele nos tem permitido auxiliar a clientes a enxergar “o todo”, o sistema, e identificar gargalos que são completamente contra-intuitivos, e ajudar a todas as pessoas que “colaboram” no value stream a sair de uma postura nos vs. eles que Scrum acaba criando, saindo de silos funcionais para silos de produtos, e passar a adotar uma postura reconhecendo e se identificando com o sistema maior onde eles estão inseridos.

Para quem já esta usando Scrum, e tem vivenciado alguns dos problemas que comento neste post, o Rodrigo de Toledo e o Alisson Vale, desenvolveram um treinamento chamado Do Scrum ao Kanban, em algumas das turmas também eu, Juan Bernabó, estarei ministrando este treinamento. O objetivo de Kanban não é substituir Scrum e sim ambas ganharem com a sinergia, como acontece com XP, já que cuidam de aspectos diferentes.

Nesta semana dias 30 e 31 de Março estaremos em São Paulo, e dias 19 e 20 de Abril estaremos no Rio de Janeiro ministrando o treinamento  Do Scrum ao Kanban.

O que me motivou foi que nele fica claro um dos problemas que vejo mais e mais nas organizações que tentam adotar Scrum porém o fazem sem mudar o modelo motivacional e o modo de operação dos processos.

Porque acredito que + comprometimento causa – produtividade?

A lógica nas organizações de buscar mais “comprometimento” nas pessoas, tem criado problemas de produtividade, ou digamos, oportunidades perdidas de obter mais produtividade.

Na verdade esse é o ponto mais sutil e menos entendido de Scrum, Lean e Agile, e é o que faz que a maior parte das equipes trabalhem a 50% do que poderiam, na verdade tem estudos onde se fala em diferenças em produtividade de ate 3000% em pontos de função per capita com a media do mercado alguns anos atrás.

Administrar equipes e organizações é interessante, eles podem ser entendidos como Sistemas Complexos Adaptativos (CAS) onde muitas das suas variáveis são não lineares, isto deixa os Gestores 1.0 totalmente desnorteados, é quando escuto falar sobre as “pessoas são complicadas”, na verdade deveria ser “as organizações são complexas” e realmente o são, por isso precisamos mais de novos conceitos de administração do que nunca.

Uma forma de entender os loops de causas – efeitos – causas

Caso de para entender que existe um conflito, ou uma situação que não se estabiliza, onde o processo fica flutuando, e parece que existem tensões entre duas partes, uma coisa que gosto de fazer para ajudar outras pessoas a entender é uma árvore de realidade atual para conseguir consensuar entre vários agentes de um mesmo sistema, quais são os ciclos que mantém o sistema na condição atual gerando mais efeitos indesejáveis.

Para entendê-lo é simplesmente ir lendo ele de baixo para acima verbalizando com a leitura de cada entidade, SE “o texto da entidade” ENTÃO “o texto da entidade de cima” o que nos ajuda a explorar situações de causa e efeitos que tem muita profundidade.

A mesma situação no mercado financeiro

Digamos que você é um corretor de ações e você seja forçado pelos teus clientes a se “comprometer” em entregar um determinado lucratividade na compra de determinadas ações que eles irão fazer, teu  cliente insiste em querer que você se “comprometa” em alguma “meta”.

Você cederia a pressão e se “comprometeria”?

Qual é a implicação deste compromisso?

Ele garante o retorno?

Bom, no mercado financeiro já sacaram, quem faz “promessas” de retorno alto em investimentos de alto risco talvez esteja jogando outro jogo

Quando alguém assume riscos, ele cobra por isso. Investimentos que não tem praticamente riscos tem rendimento de “poupança”, ou seja assumir risco custa, e custa caro.

Quando é requerido a uma equipe que assuma o “risco” e se “comprometa” com um retorno especifico, sem variância, sem risco, você esta pedindo para ela te dar “retorno de poupança”.

O que isto causa é que o risco fique embutido, ao invés de ele ficar exposto e gerenciado, as equipes estimam pra cima, e puxam menos pontos do que poderiam porque tem “risco”, isso é manifestado em reuniões de planejamento onde o PO tem que “entubar” histórias na equipe, e cria um ambiente de baixa confiança, onde claramente PO e equipe tomam postos contrários numa dinâmica de “negociação”, onde tudo que uma parte ganha é resultado da perda da outra parte.

A mesma situação nos esportes

Se você fosse um atleta, e tivesse que melhorar teus tempos, porém cada vez que o teu tempo não fosse atingido você recebesse um choque elétrico, você se colocaria uma meta que teria risco de não atingir?

Maestria, Propósito e Autonomia

A única forma que vi Agile funcionando bem como realmente deveria, foi quando fizemos um trabalho em organizações para abandonar o paradigma de motivação de “chicotes e cenouras” e substitui-lo pelo que Daniel Pink chama de “Autonomia, Propósito e Maestria”.

Neste momento a tua equipe se torna uma banda de jazz, que não precisa se “comprometer” eles gostam da música, eles gostam do ritmo, eles estão engajados.

Porém isto não é para qualquer tipo de organização e líderes, a maior parte das organizações só consegue resultados através da coerção, do chicote e da cenoura, porém perdem o melhor que as pessoas poderiam contribuir.

Equipes tem a obrigação de fazer o seu melhor, esse é o compromisso que eu busco neles, mesmo perdendo, se eles fizeram o seu melhor esta ok.

A distinção no Guia de Scrum, é uma advertência, assim como fazem corretoras quando anunciam novos investimentos, que o risco, a incerteza e a variância continua existindo e que é necessária co-gerencia-la, e não repassa-la.

Qual é a meta?

Goldratt falava no livro a Meta, “Diga como me medes e te direi como me comporto”. Medir uma equipe, mesmo que implicitamente, cria um abismo do comportamento quando ela é regulada duas estruturas de metas diferentes:

• Se comprometer com uma quantidade X de pontos no Sprint, ou pior com uma data de entrega futura de um escopo fechado.

• Se comprometerem a se esforçar para fazer o seu melhor,  a entregar um trabalho de alta qualidade e a melhorar continuamente

Em que estas metas diferem?

Na primeira situação podemos observar que:

• O risco tem sido repassado para a equipe
• O papel do gestor passa a ser “pedir mais comprometimento” quando não se atinge a “meta” e desconfiar que esta muito fácil quando atingida continuamente.
• As coisas vão bem se a equipe entrega o que se “comprometeu” e vão mal se não conseguem entrega-lo
• O trabalho é empurrado no ritmo do “forecast”, independentemente se esta rápido ou lento, se para cumpri-lo tem que fazer longas horas extra ou abaixar a qualidade.

• O risco continua com a gestão, que a gerencia com a ajuda da equipe e dos clientes.
• A equipe passa a se orgulhar pelo trabalho bem feito, são os primeiros sinais da Maestria.
• A equipe tem autonomia para implementar melhorias no processo, motivação pela Autonomia.
• A gestão criou uma urgência através da resignificarção do trabalho, motivação pelo Propósito.
• O papel da equipe é entregar na maior taxa sustentável possível do processo, sem descuidar a qualidade e melhorando continuamente
• O papel da gestão é cuidar que nada interrompa a agregação de valor, e procurar que exista tensão de operação no processo, exista “puxada” suficiente.

Parece naif, porém tenho presenciado com meus olhos equipes que triplicado sua velocidade, simplesmente porque ao invés de ser cobrados pelo “compromisso” passaram a ser cobrados “pela sua  a meta do Sprint, e entender que os pontos são simplesmente uma previsão.

O trabalho é empurrado ou puxado?

Scrum deveria ternos revelado a fantástica revolução que a Toyota fez, quando fez uma coisa impensável para a industria naquele tempo, ao invés de governar os seus sistemas de produção por um plano baseado em previsões empurrando o trabalho no sistema, passou a governar o seu sistema de forma sincronizada usando um mecanismo simples, a disponibilidade do processo seguinte, ou seja o processo seguinte passou a puxar na velocidade que ele conseguia entregar e assim conseguir determinar a velocidade na qual o trabalho deveria fluir, e caso existissem defeitos se faria parar todo esse fluxo, automaticamente parando todos os processos.

Qualquer implementação de Scrum/Agile/Kanban, que não tenha um fluxo puxado, e que baseie o seu ritmo de produção em planos derivados de “previsões”, esta subvertendo a lógica, e tera problemas de baixa velocidade, desincronização, dificuldade de melhorar os processos, falta de slack necessário para aumentar a produtividade, falta de moral, e baixa qualidade, incapacidade de  pagar as suas dividas o que ira trazer baixa produtividade futura.

Se esta ruim, não esta bom

Chegar nestas conclusões não foi nem barato nem fácil, o custo com 10, 50 ou 500 desenvolvedores que funcionam a 50% do que poderiam e que geram divida para a empresa para os próximos 5 a 10 anos e complicado.

Seguir metodologias é complicado, por isso é necessário que possamos adquirir o hábito como organização de ficar Continuamente Insatisfeito, este é o assunto que me esta deixando acordado até tarde.

Muitos amigos e conhecidos também participaram, e tivemos a sorte dos nossos amigos da BlueSoft filmar a palestra que eu ministrei, alem deles também o pessoal da GoNow fez um outro vídeo bem legal. O nosso muito obrigado a ambos.

Nesta palestra falo um pouco do paralelo entre Agile e Desenvolvimento de Software, com Lean Startup e Desenvolvimento de Novos Produtos ou Negócios. Já na Agile Brasil 2011 o Joshua Kerievsky falou da importância e de como ele entendia Lean Startup sendo um tsunami frente ao que Agile é.

Porque o teu novo produto vai fracassar? from Bluesoft on Vimeo.

No final de junho tivemos a Agile Brazil 2011, que é uma conferência nacional organizada por representantes das principais comunidades ágeis brasileiras. Este evento teve como objetivo promover a comunicação e a colaboração entre seus integrantes visando à disseminação coordenada da cultura Ágil por todo o país.

Nesta conferencia estivemos presentes, e foi talvez o marco onde Lean Startup deixou de ser um conceito conhecido por poucos e passou a ser conhecido pela comunidade mais ampla de Agile no Brasil.

Como sempre, gosto de fazer perguntas nas palestras dos outros e perguntei para o Joshua quais eram as implicações de Lean Startup para quem é Agil ou para a nossa industria, e ele respondeu muito animado que consideraba Lean Startup um movimento muito maior e muito mais profundo que Agile, ele metaforicamente falando comparou a primeira com uma onda e a ultima com um tsunami.

Neste video, disponibilizado pelo Luiz Parcianello, o Joshua Kerievsky da Industrial Logic, fala sobre “Priorizando a Felicidade” na sua jornada adotando conceitos e praticas de Lean Startup para o seu negocio de eLearning.

Também estão disponíveis os slides de esta apresentação que junto com o Henrique Bastos ajudamos a traduzir para o português. Eu não entendi porque todo mundo riu quando viu o meu nome nos agradecimentos pela tradução…. tiveram que me explicar que eu não era realmente uma referencia no bom uso do português, talvez do portunhol.

Outra apresentação sobre o assunto de Lean Startup esteve a cargo pelo Alexandre Gomes e o Matheus Haddad que juntos fizeram um show sobre este assunto.

Outra apresentação interesante foi a do Henrique Imberti Jr. da Yahoo onde falou sobre Lean Startup sendo usado no projeto Meme e como se manter uma Startup dentro de uma grande empresa.

Finalmente tivemos um Open Space sobre Lean Startup organizado por mim (Juan Bernabó) que foi super concorrido e participaram amigos como Henrique Bastos, Renato Willi, Alexandre Gomes, Sylvestre Mergulhão, Manuel Pimentel, Rodrigo Toledo, Joshua Kerievsky, Flavio Ianagui Diniz entre muitos outros que não vou conseguir nomear aqui.

Foram mais de 2000 profissionais, aproximadamente 130 CIOs e Diretores de TI presentes neste evento, que teve como tema “A TI Como Diferencial na Estratégia Corporativa”.

A Teamware esteve presente junto com a InfoGlobo apresentando um case de sucesso do uso de praticas e metodologias que permitiram melhorar o desempenho do grupo responsável por suportar, manter e evoluir o sistema SAP na InfoGlobo.

Recompensas extrínsecas tornam equipes que trabalham com conhecimento mais burras e baixam o desempenho delas. Esta é a conclusão de Daniel Pink um especialista e autor do livro Motivação 3.0 nos mostra neste video.

A maior parte do trabalho atualmente tem a ver com resolução de problemas complexos bem diferente que o trabalho do século passado onde o trabalho era basicamente simples e repetitivo. Velhos hábitos são difíceis de mudar, e ainda hoje, mesmo não fazendo mais sentido, continuamos usando praticas para motivar as pessoas que são contra-producentes.

Este desalinhamento entre o que a ciencia sabe e o que as empresas fazem deve estar custando muito caro para a sua empresa e para toda a nossa economia. O melhor caminho e partir para valorizar as recompensas intrínsecas e a Autonomia, Maestria e o Proposito como instrumentos para criar organizações mais vivas, mais felizes e mais produtivas.

Fonte: www.cabecadagua.com

Na terça feira 19 de julho, em São Paulo,  estivemos na Expo Y, “festival de negócios da geração Y”, nas palavras do criador do evento, Bob Wollheim, sócio da produtora SixPix.

No dia 19 de julho ocorreu um dos mais significantes eventos de TI da América Latina, promovido pela ASUG (Associação de Usuários SAP do Brasil), reunindo profissionais envolvidos na implementação de suas soluções de tecnologia.

Foram mais de 2000 profissionais, aproximadamente 130 CIOs e Diretores de TI presentes neste evento, que teve como tema “A TI Como Diferencial na Estratégia Corporativa”.

A Teamware esteve presente junto com a InfoGlobo apresentando um case de sucesso do uso de praticas e metodologias que permitiram melhorar o desempenho do grupo responsável por suportar, manter e evoluir o sistema SAP na InfoGlobo.

Tenho visto muitos abusos sendo cometidos em nome da “Melhoria de Processos” e realmente não tenho visto muito sendo feito para que os projetos sejam mais eficazes, agreguem mais valor com menos esforço.
Por muito tempo tenho liderado equipes e tenho um jeito muito especial de tratar a coisa, como sócio de empresa de desenvolvimento e desenvolvedor também, tive que alinhar o trabalho que era feito para produzir o melhor resultado com o menor esforço, e o que encontrei era que nada do que fisesse modificava fundamentalmente o resultado a menos que incluísse na mistura o ingrediente fundamental que era tratar das “Pessoas”.

Quase todos os gerentes de projeto que tenho conhecido, tratam o lado humano da equação como aquela complexidade desnecessária, o “problema de trabalhar com gente”, “pessoas são complicadas”, “o pessoal não entende”, “o pessoal não esta motivado”, “tem que ficar fazendo de baby sitter”, bom aquela baboseira toda.
Os gerentes de projeto, realmete sofrem todas estas coisas, mais eles não são problemas em si, são simplesmente sintomas de outros problemas mais fundamentais, as pessoas não estão comprometidas porque talvez quem esta acima também não esta comprometido, ou esta comprometido pela razão errada, ou esta tão comprometido que esquece de tratar as pessoas com respeito e paciência e acaba colhendo braços cruzados e pouquíssimo feedback.

Para mim era um desafio trabalhar com gente, errei mais do que acertei, mais depois comecei a errar menos, quando finalmente descobri que trabalhava com “Pessoas” e que para que eu pudesse colher o tipo de resultados como qualidade, motivação, produção, eficiência, eficácia, criatividade, tolerância, paciência, talento, inovação e tantas outras qualidades humanas era necessário começar a semear outro tipo de semente.
Foi aí que descobri a Liderança Servidora, ao invés de investir em planejamento, gerenciamento de atividades, criação de regras, cronogramas detalhadíssimos, definição de processos, incentivos monetários ou ascensão política, comecei a investir em conhecer melhor as pessoas que trabalhavam comigo, ouvir, sim ouvir mais, e ahi sim explicar mais da nossa missão, qual era o objetivo que tinha que ser atingido, pensar de que forma poderia auxiliar eles a fazerem melhor o seu trabalho, me tornar um servo, um exemplo, a serviço de uma causa, um projeto, um objetivo comum.

Quando mudou meu foco, de tratar as pessoas como coisas e passei a trata-los como pessoas integrais, isto é não só queria a mente deles para produzir software, mais também queria as outras partes deles, seu coração e sua consciência. Apartir desse momento tive um despertar, já que podia não só estimular estas pessoas a se tornarem mais eficazes, elas o faziam porque elas queriam, porque estavam de fato comprometidas, envolvidas, não havia manipulação, nem falsas promessas, começou a haver cooperação, porem era necessário um sacrifício da minha parte, era necessário compartilhar com estas pessoas o planejamento e a avaliação do que era feito.
Não mais eu definia eles executavam. Agora se tratava de nos, nos definíamos, e meu objetivo era formar equipes capacez de eles definirem de forma eficaz, já que entendiam exatamente qual era o objetivo, e quais os limites, assim eles poderiam tomer este tipo de decisões, já que eles mesmos se avaliariam, a sua consciência seria o seu guia.

Não da para gerenciar “Pessoas” existe somente uma forma de lidar com elas de forma eficaz no trabalho e se chama “Liderança”, que permite que a sua paixão, inventiva, pro-atividade, criatividade, excelencia sejam liberados e alinhados com a missão a frente, porem em desenvolvimento de software não tenho visto isto muito frequentemente, alias sempre que vi alinhadas liderança e tecnologia sempre vi produtos e equipes fantásticas, porem não é isso que estamos vendo na industria, e sim uma tendencia a tratar o a organização do trabalho de desenvolvimento de uma forma cada vez mais industrial, atraves da separação do trabalho e especialização.

Hoje vejo que se faz cada vez mais fundamental, mais necessário entender como equipes e organizações de desenvolvimento de software que estão adaptadas para o paradigma do trabalhador do conhecimento fazem seu trabalho, porque elas estão sendo mais eficazes, no curto, médio e longo prazo.

Algumas das lições aprendidas estão sendo capturadas em processos de desenvolvimento que estão adaptados para este tipo de paradigma, são processos chamados ágeis, muito vamos a ouvir no futuro próximo sobre eles.

Por isso me responda: Você é uma “Pessoa” ou um “Recurso”?