Coaching

Disseminação do Conhecimento

Somos trabalhadores do conhecimento. Ponto final. Esse texto poderia se encerrar aqui e que tudo que estou escrevendo a seguir perderia o sentido porque o foco aqui é esse: somos trabalhadores do conhecimento. Nós manipulamos dados, escrevemos rotinas, organizamos mares de informações em pequenas ondas suaves que as torna compreensíveis. É importante entender, não somos os detentores do conhecimento, essa era já passou. Houve um tempo em que minha família possuir uma Enciclopédia Britânica de 1979 fez toda a diferença nos meus estudos. Não estamos mais na busca de bibliotecas ambulantes mas de pessoas que saibam organizar e processar a informação. É aqui que começa a nossa conversa.

A informação deve fluir. Organizações não podem depender de pessoas, por mais impessoal que isso possa parecer. Se a falta de um membro pode fazer a organização como um todo ruir a fragilidade é sem precedentes. E acreditem, várias estão nessa situação e já tive a oportunidade de encontrar algumas por aí.

Na sua equipe hoje, existem super heróis? Qual o seu “bus factor”?

Sempre quando vou falar do conceito de super herói eu me lembro do filme Tróia, aquele com o Brad Pitt sendo o Aquiles. Mas não quero falar de Aquiles e sim de Boaglius. Logo no começo do filme acordam Aquiles para enfrentar o campeão do exército inimigo, numa disputa um a um. Boaglius usa os seus melhores golpes e toda a sua habilidade mas acabou por cair para um único golpe de espada de Aquiles. Esse era o herói. Um herói puxa a responsabilidade para si, defende o seu grupo e no final acaba por morrer por ele. Parece bonito para as histórias românticas mas eu prefiro viver para continuar escrevendo novas histórias. O herói corporativo é importante, todos se lembram dele como a referência daquele assunto, ninguém sabe mais daquilo do que ele. Isso leva sempre que ele e apenas ele é capaz de resolver problemas daquele assunto, afinal, ele o faz em menos tempo e com mais qualidade. Me lembro de um amigo de equipe que certa vez pegou dengue, algo comum aqui no Brasil. Foram três semanas de repouso e na segunda semana o coordenador da equipe estava cogitando mandar o desktop para a casa dele para que ele continuasse o trabalho. É assim que o herói vive. Sem férias, descansos, sem o direito à ficar doente. A fragilidade desse time pode gerar problemas enormes no futuro próximo.

Qual o tempo de treinamento de um novo desenvolvedor?

Em quanto tempo ele está apto a trabalhar sozinho em demandas menores? E quanto tempo para trabalhar com as mais densas?

Li uma charge interessante que falava algo como: nossa e se treiná-los e eles forem embora? No outro quadro um gerente mais sábio respondia: e se nós não os treinarmos e eles ficarem? Hoje empresas têm diferenças bem sutis, ao menos no tocante aquelas que observo. Ter uma salinha de descompressão, vídeo games, frutas e outros mimos já não é diferencial. Bem como outros benefícios do modelo padrão também não o são. Os profissionais hoje buscam local para destaque, onde possam crescer e ser mais. Assim, se uma empresa não oferece treinamentos, capacitação e faz o profissional melhor dia após dia ela corre em sérios riscos de perdê-lo. Eu sempre digo que você não tem muita influência em motivar seus funcionários, mas sim para desmotivar.

São ofertados treinamentos no começo do trabalho? Quais são? Como é medida a eficiência desse treinamento?

As pessoas têm em si mesmas as habilidades para se motivar, é algo intrínseco que pode ser fomentado com a trinca do Dan Pink: autonomia, maestria e propósito, mas sobre isso cabe um texto separado. O foco aqui é apenas na maestria. Como podemos tornar os nossos profissionais os mais completos do mercado? Como podemos capacita-los dentro de suas aptidões para garantir explorar mais as suas potências? Essas são perguntas que um líder servidor deve se fazer o tempo todo, para o funcionário que entrou semana passada e para o que está com 10 anos de empresa.

Treinar é uma arte, a arte de passar conhecimento de maneira direcionada, levando um conteúdo pré determinado para outras pessoas. Longe de ser a única ou melhor maneira, mas é uma das mais tradicionais e a mais valorizada nas organizações. Apesar de ser tradicional e tudo o mais o problema não é necessariamente no treinamento em si, mas como medir o retorno do investimento. Se avaliar o quanto foi aproveitado, absorvido de conhecimento num treinamento é um assunto polêmico é difícil, se imagine em cima disso descobrir em quanto tempo o valor investido no treinamento lhe trará o retorno esperado. É um desafio e tanto e não há uma resposta aqui. O importante é estabelecer entre ambas as partes, colaborador e organização, qual será a meta e como ela será atingida.

Conhecem o conceito de pair programming? Com que frequência costumam colaborar (do latim, trabalhar juntos), não apenas ajudar-se, uns aos outros? Existe algum tipo de cadência para isso ou é feito apenas sob demanda?

Embora o nome me apareceu pela primeira vez em programação, o conceito é aplicável em várias áreas. Já vi até mesmo ser aplicado até mesmo em manufatura de carros, portanto temos evidência de sua aplicabilidade em outros meios diferentes de software. A ideia básica é bem simples, ao invés de ter um único profissional realizando uma tarefa, temos dois, alternando em intervalos regulares quem faz as vezes de piloto e de navegador, numa analogia ao rally e outras atividades do gênero. Embora a princípio pareça ser mais caro para o empregador a longo prazo a coisa se paga. Se medido no intervalo de dias e até semanas, o custo pode realmente não valer, mas com um período maior ganha-se em foco e principalmente em qualidade de entrega e redução de retrabalhos. Vou explicar isso melhor num post separado e quando o fizer, deixo linkado aqui.

Ao final do projeto, o time é mantido? Como o que foi aprendido nesse projeto é passado para os demais times?

A última etapa da evolução de um time é passar o seu conhecimento adiante. Em vários modelos que lemos, Tuckman por exemplo, mencionam algo semelhante. Se formos mais além, encontraremos o famoso artigo dos professores Takeushi e Nonaka mencionando como times de alta performance realizavam o que foi chamado de transferencia organizacional do conhecimento. Assim, é de se admirar que ainda existam empresas que não investem em reter a informação gerada em seus projetos, que não investem em ter uma memória viva daquilo que foi aprendido e mais ainda, evitar a tornar as variáveis que levaram aos problemas do passado estejam presentes de novo em projetos futuros.

O conhecimento é o novo ouro. Precisamos ser sábios em mantê-lo, dado que seu custo de manutenção é baixo, mas o de aquisição bem elevado.

A necessidade da visão externa

Fico feliz quando visito algum cliente, novo ou antigo, e encontro um ambiente no qual eu invejo.

Experiências centradas no usuário, foco nas pessoas, alta capacidade técnica são só algumas características que vejo por aí nessa galera.

Por isso sempre me causa espanto por que eles precisam de mim ou de meus colegas. Está tudo ali, todas as ferramentas necessárias para melhorar aquele ambiente. Até mesmo a vontade de fazê-lo está presente. Mas ainda assim, precisam de alguém que lhes aponte a direção certa.

O meu palpite é que nós estamos tão imersos em nossos problemas do dia-a-dia que não deixamos um tempo para melhorias. Mesmo times com bons conhecimentos de agilidade esquecem de deixar um tempo para se melhorar, se aprimorar. É a eterna luta para continuar cortando árvores e nunca amolar o machado.

Eficácia versus eficiência.

Bom, tem muito assunto aí. Numa próxima oportunidade falaremos mais sobre isso.

Como avaliar a agilidade da sua empresa?

Essa semana meus colegas e eu entregamos mais um trabalho de assessment ágil em uma grande empresa em SP. Foi muito interessante como sempre poder olhar para um outro ambiente diferente do seu, sem as paixões do dia a dia no intuito de ajudar outro a não cometer os mesmos erros que você já fez. Esses momentos sempre me fazem pensar em coisas que vi e coisas que vivi. Vou comentar algumas nesse texto.

Ah, como é bom fazer esse tipo de trabalho! Você se torna um avaliador, passando para aquela empresa contratada a sua visão sobre o seu processo atual. O quão legal é isso? É fantástico! Afinal é sempre mais legal ajudar os outros a resolver os seus problemas do que resolver os seus próprios. O modelo de avaliação que usamos eu criei baseado em outros que vi por aí, juntando um pouco de cada um que vi, colocando um pouco de meu próprio estilo e passando para o resto do time ágil validar. Considero um bom modelo, pois avalia quatro aspectos que considero importante para uma empresa possa ser considerada ágil: cultura, organização, técnica e negócio. O número quatro não é a toa e tem forte influência do manifesto ágil e como a empresa endereça cada um dos quatro valores ali presentes. Em textos futuros pretendo escrever um pouco mais sobre cada aspecto.

Um diferencial que a Objective tem sobre as demais empresas do mercado parece até meio contraditório porém depois que eu conto a história toda passa a fazer sentido. Não somos uma empresa de consultoria. Ou ao menos não éramos. A empresa nasceu como desenvolvimento e assim se mantém até hoje. Porém temos resolvido muita coisa, tivemos muitas dores no caminho é isso nos tornou mais fortes. Contando essas histórias de guerrilhas para os amigos, esses nos pediram para contar mais e então passamos a palestrar. As palestras nos aproximaram de pessoas que queriam saber de como resolvemos nossos problemas e então passamos a oferecer-lhes consultorias e assessments. Veja, todo esse empirismo não quer dizer que não estudamos e não buscamos conhecimentos de fontes externas. Muito pelo contrário. Estamos buscando conhecimento a todo tempo, lendo livros, blogs, conversando com outras referências e participando ativamente de eventos. Nós mantemos em constante evolução e gostamos disso. Porém, somos desenvolvedores como a maioria de vocês (eu particularmente trabalho com iOS) e compreendemos os problemas que vocês passam pois passamos por eles também em algum ponto da estrada. O Agile que falo não é algo que simplesmente li num livro ou vi numa palestra, mas sim algo que vivi e vivo a todo tempo, é como solucionei os meus problemas e como sanamos nossas dores. Enfim, falar de agilidade é um enorme prazer, contar meus casos é algo que realmente me fascina. Ser pago para isso é melhor ainda.

O processo de assessment é relativamente simples. Vamos até a empresa, conversamos com pessoas chaves no processo, observamos algumas evidências é baseado no que vimos e ouvimos redigimos um relatório mostrando os principais pontos de alavancagem, aqueles que com o menor esforço geram o maior resultado. Isso é extremamente pessoal e depende da avaliação de cada agilista. Tento ser imparcial e para isso sempre busco um par que me complete nesse trabalho. Minha visão pessoal busca sempre aspectos culturais e de negócio, por isso preciso de alguém técnico para me ajudar. Esse meu par tem o trabalho de olhar para onde eu não olhei, fazer as perguntas que eu não fiz, olhar os aspectos que eu deixei passar. É belo ver que o mesmo princípio do pair programming são aplicáveis aqui também. Já escrevi algo sobre isso por aqui, recomendo a leitura.

Após essa avaliação inicial vamos até a empresa e de posse do relatório, explicamos ponto a ponto da nossa visão sobre o processo para os membros da equipe e discutimos as diferenças de visão. Expomos então um plano de ação que consideramos ser o mais interessante. Esse é um aspecto que julgo ser um dos mais legais. Normalmente, quem trabalha com consultoria já faz isso como parte do processo. Você não chega numa empresa e joga um modelo pronto. Você avalia os pontos em busca da onde se pode atuar. A diferença é que numa consultoria isso funciona como uma venda casada, você coloca essas horas dentro do seu trabalho de consultor e as vende num pacote só. Gosto mais de como fazemos porque se você se sentir capaz de implementar essas melhorias propostas vá em frente! Se sentir que precisa de ajuda com alguma delas estamos aqui de qualquer forma. Nem precisa nos contratar para ajudar em todas, somente para os aspectos que sentirem que precisam de apoio. Isso sai muito mais barato para o cliente e logo estamos livres para pegar um próximo projeto e aprender e ensinar mais em um novo contexto.

Você pode estar pensando nesse momento que serviços assim devem ser caros e contratar profissionais de uma empresa de consultoria pode ser um passo grande em direção à melhoria contínua portanto, podemos deixar para depois. A parte legal é que caso queira começar com um modelo mais simplificado e auto aplicável o meu amigo Klaus Wuestefeld escreveu um template chamado os 9 registros da agilidade. Nesse trabalho, disponível aqui, você encontra uma planilha para compartilhar com sua equipe e tem 9 aspectos que vocês devem dar notas entre 1 e 5, dependendo de como a equipe se avalia. É importante que se visualize o modelo como sendo um grande cano é que os nove registros estão ao longo desse cano. Com esse modelo em mente pode se ter certeza que a vazão desse cano se limita pelo registro que está mais fechado. Assim se em vários aspectos a sua nota for 4, mas em colaboração por exemplo a sua nota for 1, então a nota final do seu processo é 1. O seu sistema se limita pelo elo mais fraco e esse é o ponto de alavancagem, pois ele desobstrui o seu sistema para crescer.

Querendo conversar sobre avaliações de sua equipe ou querendo conhecer um pouco mais sobre os modelos da torneira, me procure que terei o maior prazer em explicar.

Como ensinar?

Uma das coisas que mais aprendi ao longo dos anos foi como ensinar. O legal disso é que ensinar me levou a aprender, o que é um círculo virtuoso que eu quero manter pelos próximos 50 anos ou mais. Nesse humilde post vou contar como foi a minha história com aprendizagem, como comecei a ensinar e finalmente hoje treino todo o tipo de pessoas, CEOs de grandes organizações até universitários ávidos por conhecimento que os diferencie no mercado.

Sou filho de uma professora e isso foi muito impactante para essa carreira. Minha mãe, como criou a mim (e a meu irmão) sozinha fez o melhor que pode dentro dos seus recursos para nos prover uma ótima educação. Desde de muito jovem eu via como um educador fazia a diferença na vida das pessoas. Ela foi por alguns anos professora na zona rural da cidade, quando ia todas as manhãs pegar um ônibus que a levava para a fazenda, passava o dia em uma turma multiseriada (acho que era de 1º à 4º anos) e no fim do dia regressava para casa. Aquelas pessoas sentiram na educadora alguém que se importava, que lhes oferecia bem mais do que conteúdo mas valores que pautaram suas vidas. Quem não ia querer ser essa pessoa.

Eu mesmo comecei a ensinar já na infância. Na escola, o nerd/gordo/zarolho/filho da professora não tinha como ser mais zuado. Não tendo mais o que fazer na escola, com pouca interação social, me restava então me dedicar às aulas e isso eu fazia. Acompanhava as aulas e como não me distraia aprendi sempre com relativa facilidade os conteúdos. Obviamente os caras mais sociais da sala, como estavam ocupados em ser populares não tinham o mesmo desempenho. Aí que eu me tornei “popular“. As pessoas com dificuldade me buscavam querendo aprender sobre os conteúdos. Isso se dava por algumas razões. A primeira e mais óbvia: eu sabia e eles não. Simplesmente eu tinha um conhecimento que mesmo com a mesma oportunidade de aprendizado foi melhor aproveitada por mim. A segunda razão, um pouco mais sutil é: eu sabia falar a língua deles. Era mais simples perguntar ao colega de mesma idade do que para outra pessoa com 20, 30 ou 40 anos a mais que você. Fora a intimidação que a figura do professor passava, que gerava um certo temor em perguntar e ser repreendido. Outra vantagem em aprender comigo e não com o professor eram as metáforas. Eu conseguia fazer paralelos, explicar usando outros exemplos, trazer aquilo para uma realidade mais simplificada do que o conteúdo formal da sala de aula.

Em um determinado ano o diretor da escola resolveu trazer um curso de informática para a cidade, algo inovador em 1989. A minha mãe, como trabalhava na escola sugeriu colocar o filho para ajudar na parte burocrática do curso em troca de um desconto nas mensalidades. E assim eu ajudava com as matrículas, com o recebimento das mensalidades, organizava a sala entre as turmas, essas coisas que uma criança pode fazer. E assim eu consegui fazer meu primeiro curso de informática. No ano seguinte o curso se renovou e então eu pude continuar trabalhando, mas agora com uma pequena renda. Foi então que aconteceu de um professor faltar um dia. E faltou outro. E mais outro. E então eu comecei a buscar novos professores de informática sem muito sucesso, afinal, era o início dos anos 90 e informática não era tão trivial como é nos dias de hoje. Consegui alguns, mas poucos se mantinham no curso. Foi então que me vi obrigado a tomar uma decisão. Levantar a bandeira branca e dizer ao diretor que não tínhamos como continuar ou ousar dar uma aula seguindo o conteúdo que eu já conhecia, mesmo que obviamente sem a profundidade de um professor. Acabei optando pela segunda. Saí petrificado da primeira aula, nervoso como um adolescente no seu primeiro beijo (sim, sou velho o suficiente para crer que isso deva acontecer na adolescência, mas enfim…) mas consegui. E a medida que os dias iam passando e os dias se tornando meses, os meses se tornaram anos e aquilo realmente ficou fácil para mim. Estudei programação nessa época, com uma apostila que um colega de classe tinha me presenteado por te-lo ajudado a concluir um software. Era em Clipper. Bons tempos. Estudei o suficiente para então começar a desenvolver meus próprios softwares e então poder ensinar a programar.

Nesse momento eu tinha entendido uma coisa interessante. Se você sabe fazer de fato, sabe o que você está ensinando na prática, o ensino se torna leve. Você não está mais ensinando um conteúdo formal vindo de um livro ou treinamento. Nada contra conteúdos formais, nem tudo dá para praticar. Mas ter vivência naquilo que se ensina te dá bagagem, exemplos, te permite ter alternativas para aquelas perguntas mais inesperadas. E assim, ensinando um curso após o outro, uma aula após a outra, eu pude ir entendendo os pequenos meandros dessa arte.

Quando eu finalmente concluí um curso universitário (iniciei 4, papo para outra conversa) eu pude perceber o valor daquele modelo de formação. Não pelo conteúdo, já me considerava um programador experiente naqueles dias (pra minha sorte o mercado também) mas pelo ambiente. É um local de estudo, um ambiente focado em aprendizagem, com pessoas que também exercem funções no mercado durante o dia, que buscam se atualizar, criando atalhos para um conhecimento que existe, está ali solto no ar, mas que eles já fizeram a coleta, processaram e te entregaram prontinho. Veja, não estou elogiando o modelo de ensino que muitos criticam por aí. É só a impressão que deixou em mim. Fiz amigos para a vida toda por lá e sempre fui humilde e respeitoso com meus professores, mesmo os mais jovens que eu. Eles deram inputs interessantes para a minha melhoria como profissional.

Após a universidade eu voltei dar treinamentos, agora ensinando como as pessoas poderiam melhorar o seu jeito de trabalhar utilizando as tais práticas ágeis que tanto falo aqui no blog. Via os discursos inflamados e cheios de paixão desses caras e os diferentes tipos de treinamentos. Alguns eram mais formais, com projeção, flip-charts e apostilas. Outros eram mais dinâmicos, com práticas, papéis coloridos, bolinhas e dinâmicas que movimentavam, divertiam, mas ainda assim ensinavam. Nesse momento eu entendi que ensino não é sobre transmissão de conteúdo, mas sim sobre levar o educando a entender um conceito. Isso significa que eu posso até te contar sobre algo, você pode entender a minha mensagem e isso seria muito bom. Agora se eu te fizer sentir, provocar a surpresa, a sensação, o sentimento que te conecte ao conteúdo o resultado é muitas vezes mais efetivo. É como se o aprendizado formal se formasse no cortex e o informal se desse no límbico.

Já havia lido sobre Teaching from the back of the room e achava suas ideias interessantíssimas para ligar aluno e conteúdo ensinado. Usei muitas delas em meus treinamentos, mas sentia que poderia fazer melhor, dar um certo polimento naquilo. Seguindo nessa linha, nesse último ano tive a grata oportunidade de me juntar com outras pessoas que assim como tinham entendido que aprender tem que ser algo que venha de dentro dos educandos e fui apresentado ao conceito de Learning 3.0. Nessa maneira de entender o aprendizado, o treinador é um mero maestro, orquestrando seus alunos na construção do conhecimento. A ideia é que, usando técnicas de aprendizagem emergente, os alunos construam um conteúdo próprio, em conjunto, que provavelmente será muito mais retido do que num modelo tradicional de estuda-decora-prova.

Hoje eu sinceramente não sei como definiria meus próprios treinamentos. Uso projeção (sem vergonha alguma de dizer isso) porém poderia talvez dar um treinamento sem ela. Uso flipcharts porque os treinandos gostam de ver que você pode construir seu próprio material sem depender de recursos como o PPT. Dá a elas a sensação de que existe um domínio forte do que está sendo apresentado. Uso o máximo de dinâmicas que posso para esclarecer o conteúdo e levar os treinandos a sentir mais do que saber. Enfim, talvez não é um estilo que se encaixe em uma descrição, mas é o meu estilo. O que sei é que os feedbacks têm sido positivos, melhorando a cada classe e cada dia que ensino aprendo um pouco mais sobre essa arte.

Portanto como se ensina algum conteúdo? Não ensine. Promova o sentir, fomente a interação e permita que eles construam o conhecimento sob sua regência. Bom aprendizado/ensino e até a próxima.

A culpa é sua!

É interessante como esse texto ficou em rascunho por quase um ano! Refleti muito antes de escrever algo que realmente fosse de valor para nós desenvolvedores.

Eu pensei quando estava escrevendo esse artigo em falar de modelos de arquitetura sustentáveis, que funcionam mesmo. Aqueles que ajudam empresas, equipes e clientes a ter uma boa entrega de valor. Mas achei que isso seria irrelevante.

Também pensei em falar sobre alguns patterns e sua importância, como isso ajuda a se focar somente naquilo que ainda não tem solução. Os problemas conhecidos já têm uma solução proposta e basta aplicar. Embora isso seja mega importante, acho que é um assunto já bem batido e tem pessoas extremamente mais bem qualificadas para falar sobre o assunto.

Eu poderia continuar falando aqui das ideias que me passaram pela cabeça quando estava pensando nesse post mas vou direto ao ponto. Você! Você é o elemento que faz a diferença no desenvolvimento de software. Não adianta você ser excelente tecnicamente e não ser um ser humano legal. Parece papo de psicólogo (nada contra psicólogos, adoro vocês) ou ainda de livro de auto-ajuda (tá, esses eu não gosto mesmo, diferente dos psicólogos) mas é o ponto central de fazer software de qualidade.

Quando escreveram o tão citado manifesto, colocaram como valor primário “indivíduos e interações entre eles”. De novo, não é porque isso é bonito ou todos os caras que assinaram eram “paz e amor”. Não! Eles só perceberam que não é meu empregador que vai usar o software, não é a empresa cliente que vai usar o software, não é o departamento de suporte que vai usar o software. É a Maria, mãe de uma filha pequena, sem marido; aquela analista de suporte que precisa preencher rapidamente (e sem erros) uma chamado para o Jorge, funcionário público, de meia idade e pouco entende de software ou informática em geral, aquele cliente dela que está com problemas e precisa da ajuda da empresa na qual a Maria trabalha. Sacou a diferença? São pessoas! Seres humanos! Da sua própria espécie! Gente como eu ou você!

E por favor, não coloque a culpa na sua empresa ou no “sistema”. Sim, entendo o que o sistema quer dizer e o quanto ele influencia no comportamento das pessoas. Mas se o sistema te obriga a agir contra seus princípios e valores, o que você está fazendo aí? Busque um novo sistema ou crie o seu próprio! Médicos não pedem se podem lavar suas mãos antes de um procedimento, faz parte da sua profissão. Sua profissão supera o que o sistema lhes impor. Por que desenvolver software seria diferente?

Sim, amiguinhas e amiguinhos, quando falamos que as pessoas são mais importantes que tudo, é sério. Em última instância, estamos escrevendo software para as pessoas. Se você coloca isso na cabeça e começa a se importar com elas, dar um nome para elas, pensar em quais problemas delas você está resolvendo eu duvido que a solução que você está desenvolvendo agora não sairá de qualidade. Ou no mínimo muito mais preocupada com aquilo que a Maria e o Jorge precisam.

Como classificar a agilidade?

Certa vez um programador de uma equipe que eu estava treinando me perguntou “O que é ser ágil?”. Eu fiquei surpreso que depois de tanto tempo pensando dessa forma eu ainda não sabia como descrever a minha maneira de pensar em poucas palavras. Aqueles segundos correram bem longos na minha cabeça quando finalmente me veio a resposta que eu costumo dar em eventos e palestras. É buscar a excelência no seu campo de domínio, o desenvolvimento de software. Mas isso acendeu uma luz em minha cabeça que precisava de atenção. Foi então que percebi que esse ponto precisava ser melhor trabalhado.

Eu costumava dividir os aspectos da agilidade em dois somente. Existem ferramentas muito ricas para a área de gestão. Gestão de projetos, de processos, de métricas, de fluxo de atividades. Não vou nominar para não ser injusto com nenhum, além do que nem é o meu objetivo aqui. Existem outras que são para o trabalho do desenvolvedor, que eu chamo de arquitetura. Ali temos especialmente as práticas do Extreme programming, a entrega contínua só para citar algumas. Resumindo, no meu entender haviam apenas duas grandes áreas, gestão e arquitetura. Isso atendia bem minhas necessidades e me ajudou a fracionar aquela resposta. Assim, se depois dessa divisão na minha cabeça alguém me perguntasse novamente sobre o que é agilidade eu diria que existem a agilidade para a gestão, que é a melhoria dos processos, reduzindo o tempo de feedback e aprendizado sobre o produto da empresa e existe também a agilidade para desenvolvimento que seriam o conjunto de práticas e ferramentas que usamos para nos permitir atender essa necessidade da gestão.

A parte legal é que sendo ágil, eu posso até criar uma definição que me atende hoje, mas se aprender uma melhor eu não preciso me apegar na minha ideia original. Posso usar a nova com seus devidos créditos, obviamente. Eu vi isso acontecer bem recente no Gathering do Rio de 2015. Participando da sessão de ScrumMaster 3.0 do Rodrigo de Toledo (o cara!) vi que ele, junto com seus amigos/sócios criou uma classificação de Agile em quatro grandes áreas. Isso é certo ou errado? Não sei, mas faz sentido em seu contexto e provalvemente tem funcionado para ele desde então e pode ser que também funcione para você. Basta que você experimente e valide a ideia em seu contexto.

O segredo da agilidade é o seu pensamento. Pensando de maneira ágil e evoluindo esse pensamento conseguiremos chegar à um novo patamar e quem sabe até a um novo pensamento que substitua o ágil. Domine o pensamento ágil a ponto de, um dia, poder criar o seu próprio modelo que atenda as necessidades, sem perder os valores iniciais.

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.