Reflexões sobre o Scrum Parte 3 – Artefatos

Conforme o Guia do Scrum, os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Eles são projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos. Com isso percebemos a importância dos artefatos e o motivo pelo qual eles devem estar claros e visíveis para todos.

Backlog do Produto

O backlog do produto é uma lista ordenada de tudo que já sabemos ser necessário para o produto. Ele é a única origem de requisitos, melhorias ou correções que serão implementados no produto. A responsabilidade de mantê-lo em ordem e com informações suficientes é do Product Owner. Este artefato é dinâmico e evolui junto com o produto, afim de que este se torne mais competitivo e aderente as necessidades do cliente. Isso significa colher feedbacks constantes tanto do mercado quanto dos clientes para realizar os ajustes necessários no nosso produto, além de estar atento a novas tecnologias e oportunidades de negócio que possam interferir positiva ou negativamente na estratégia de evolução do produto.

Um backlog do produto de qualidade é uma lista que está constantemente sendo revisada e refinada, sendo que o topo dessa lista deve ser composto de itens mais claros e detalhados do que os demais, pois são os itens candidatos a serem desenvolvidos. Parece simples, mas é uma tarefa árdua para o PO que, com certeza, precisará de muito apoio do time de desenvovlimento para dar conta do recado. Scrum é sobre transparênca, inspeção e adaptação, podemos ver cada um desses conceitos na prática quando o PO e os membros de um time trocam ideias e compartilham suas incertezas na busca de um produto de sucesso.

O Guia do Scrum cita que atividades de refinamento usualmente não consomem mais que 10% da capacidade do time, mas isso não significa que devemos ter reuniões de refinamento com a quantidade de horas exatas para atender a esse ponto, um processo empírico implica em uma abordagem orgânica de quanto tempo é necessário para realizar essa atividade. Trabalhei com times que faziam duas reuniões de refinamento por Sprint e com times que sequer marcavam uma reunião assim, pois atuavam, time e PO, bem próximos no dia a dia, não sendo necessário um momento formal para essa discussão. Para este e muitos outros pontos sempre recomendo fazer um experimento, inspecionar e adaptar o que for necessário para melhorar, sempre levando em consideração o momento e as características do time.

O refinamento é que garante que os itens do topo do backlog estarão preparados para entrar no planejamento da Sprint. No Guia do Scrum, temos uma definição dos atributos que os itens do backlog devem possuir, são eles: descrição, ordem, estimativa e valor, além disso, geralmente há descrições de testes que auxilirão na hora de veririfcar que o item está realmente pronto. Lembrando que as estimativas sempre devem ser realizadas pelo time de desenvovolvimento. Essa é uma questão interessante, que deixa claro que o Scrum foi concebido considerando a perspectiva do desenvolvedor que, em metodologias tradicionais de desenvolvimento de software, não tinha voz sobre esse ponto.

No encontro do grupo de estudos, fizemos uma dinâmica para exercício da priorização do backlog que incluia discutir os atributos benefício, receita, redução de risco e estimativas. Foi bem interessante, pois tivemos a oportunidade de abordar cada uma dessas informações e como elas afetam a evolução do produto. Devido ao curto tempo do nosso encontro, não exercitamos fatiar e descartar itens que são atividades indispensáveis no dia a dia do PO, mas falamos um pouco sobre a granulalidade do backlog e de como isso deve ser administrado.

Obrigada aos colegas Altamir Dias, Josiel Lilge, Liliane Soares, Cleidi Rocha, Samanta Azevedo, Julia Iense, Vanessa Paes, Alina Melo, Elza de Souza, Victor Fofonca, Cícero Vieira e Marcelo Lora por participarem dessse grupo incrível.

Backlog da Sprint

Este artefato contém um subconjunto do Backlog do Produto, indicando quais funcionalidades estarão prontas ao final do Sprint. Os critérios para selecioná-los são decididos pelo próprio time Scrum. Para ajudar na identificação dos itens que deverão fazer parte desta lista, sempre sugiro o uso de uma definição de preparado, onde constarão todos os atributos essenciais para que um item possa ser promovido do Backlog do Produto para o Backlog da Sprint.

A definição de preparado, apesar de não ter um item específico no Guia do Scrum, é uma prática que apoia na identificação e aprimoramento da qualidade das informações de cada item do backlog, aumentando a fluidez do trabalho do time de desenvolvimento. Não ter uma lista clara de critérios para seleção de itens para compor o Backlog da Sprint pode acarretar falta de entendimento do trabalho, reuniões de planejamento muito longas onde os requisitos chegam com pouca clareza ou com granularidade inadequada, além de desmotivar o time e gerar dúvidas sobre a eficicácia do processo de trabalho.

O Backlog da Sprint também contém o plano de como o time irá atingir o objetivo da Sprint, esse plano pode ser (e provavelmente será) ajustado ao longo da Sprint, pois o time vai aprendendo mais sobre o trabalho a medida que progride nas atividades. Esse é um ponto bem importante, pois vemos muitos times “Scrum” sendo obrigados a definir todas as tarefas da Sprint na reunião de planejamento como se neste momento fosse possível prever exatamente todo o trabalho que será feito. Esse tipo de situação, além de não favorecer em nada o empirismo e auto organização, ainda resulta em plannings muito longas e que não mantém a atenção dos membros do time.

Abaixo, o trecho do Guia do Scrum que menciona claramente esse comportamento:

“Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho
restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são
removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a
Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.”

Vale destacar que é fortemente recomendado que no mínimo um item de melhoria do processo priorizado na retrospectiva seja incluído no Backlog da Sprint. A falta deste item implica em estagnação do time e inutilidade da reunião de retrospectiva, onde as ações são parte essencial para garantir a melhoria continua como já foi citado no artigo Dicas para Retrospectivas Eficazes.

Incremento

O incremento é a soma do itens que foram completados na Sprint, ou seja, que estão prontos. Pronto é uma definição que pode ser diferente de time para time, porém deve ser clara para todos os interessados. Um incremento pronto não precisa necessariamente ser liberado para uso, mas o Guia do Scrum deixa bem claro que ele deve estar nessa condição, ficando a critério do Product Owner decidir a estratégia para liberação do uso dos incrementos.

A definição de pronto garante a qualidade da saída dos itens da Sprint e o alinhamento do trabalho necessário para concluir uma funcionalidade. A falta de uma definição de pronto clara e visível para todos implica em entregas incompletas ou de baixa qualidade, formação de silos, desmotivação e descrédito do processo de trabalho. Tudo isso ocorre porque num grupo existiem diferentes pontos de vista e, a menos que haja um acordo explícito, a conceito de pronto pode ser interpretado de maneiras diferentes.

Reparem que a desmotivação e a desconfiança sobre a eficácia do processo se repentem na falta de uma definição de pronto assim como na falta de uma definição de preparado, pois em ambos os casos falta um vocabulário único que promova o alinhamento e este é justamento um dos pontos mais importantes para promover a motivação e a confiança.

Transparência, inspeção e adaptação são os pilares que sustentam o Scrum e todos os seus eventos e artefatos. Pratique-os, não só nos times Scrum, mas também em outros aspectos da vida.

Reflexões sobre o Scrum Parte 2 – Valores

Dando continuidade à série Reflexões sobre o Scrum, vamos atentar sobre o significado de cada um dos valores do Scrum e como percebemos seus benefícios e as dificuldades de trazê-los para o nosso dia a dia. Vale lembrar que é sempre importante falar sobre valores, pois são eles que definem / orientam nossas atitudes e decisões.

O Scrum é um framework com regras, papéis e princípios que auxiliam as pessoas a descobrirem o que realmente faz diferença pra elas. Quando se fala em Scrum, com frequência, os aspectos mais profundos do framework não são citados, reduzindo-o a apenas um conjunto de cerimônias e papéis. De maneira nenhuma quero desmerecer a importância desses elementos, porém Scrum é mais que isso. O framework se baseia em 5 valores: Compromisso – Foco – Abertura – Respeito – Coragem, através deles entendemos a direção que devemos tomar, mesmo quando precisamos de uma resposta que não está escrita em nenhum lugar.

 

Coragem

Vivemos em uma sociedade que rotula o erro como fracasso, fazendo com que, muitas vezes, seja mais confortável não se expor e aceitar uma situação apenas porque “sempre foi assim” ou porque “foi o fulano que mandou”. O medo de errar, de “demonstrar fraqueza”, faz com que muitas equipes camuflem indicadores e façam entregas de baixa qualidade ou sem valor algum para o negócio.

Em uma breve pesquisa que fiz a respeito do papel do Scrum Master apenas 42% das pessoas que responderam o formulário consideram a coragem como um atributo importante para uma pessoa exercer este papel. Este número me causou muito desconforto, pois, assim como os demais, é um valor imprescindível para atuar como Scrum Master ou como qualquer outro papel em um time Scrum.

Como um indivíduo irá admitir seus erros quando for necessário, como irá enfrentar a necessidade de mudança cultural em uma organização e como lutará pela transparência mesmo quando isso significar admitir que existem problemas impactando o time que ainda não foram tratados se não tiver coragem? Um time sem coragem será apenas um grupo de pessoas cumprindo processos sem entender verdadeiramente o Scrum. Não há empirismo sem coragem.

Se este valor está faltando no time, uma boa tática para praticá-lo é começar questionando o motivo das coisas serem como são, refletir sobre como foi a última Sprint e falar sua percepção na retrospectiva para seus colegas, mesmo que isso implique em ser “o único que fala”.

Foco

Assim como o uso excessivo de redes socias podem abalar nossa produtividade, as muitas interrupções ou mudanças de escopo frequentes durante uma Sprint impedem um time de trabalhar em prol de uma entrega. Essas distrações afetam não só nossa eficiência como também nosso empenho em obter sucesso.

Frequentemente, em um time, a dispersão se dá pela falta de um objetivo de negócio. Entender o que realmente importa, no que de fato traz valor para o cliente e não perder esse alvo de vista é o guia para a inspeção e a adaptação. Um dos benefícios de trabalhar com timebox e ciclos curtos é que eles permitem que o time mire em uma meta terminando o que começou antes da chegada de uma nova demanda.

Existem inúmeras possibilidades para trazer mais foco para um time Scrum, recomendo analisar e discutir os episódios que desviaram o time do percurso para entender a origem deles e como evitar que se repitam. Já precisei, em mais de uma ocasião, medir o impacto do excesso de intervenções externas para demonstrar para a gerência o quanto isto estava sendo prejudicial para o rendimento do time (e comprei muita briga pra blindar um time e provar que assim os resultados são melhores para todos).

Comprometimento

Assim como a clareza do objetivo, o empenho em atingir esse alvo é de suma importância para o êxito de um time Scrum. Ser comprometido implica em fazer mais que o esperado, ir além das fronteiras da zona de conforto de apenas cumprir pontos planejados na Sprint. Um time Scrum demonstra comprometimento quando seus membros concordam em aprender, ensinar e colaborar entre si.

Rotineiramente me deparo com a falta de comprometimento causada por um dos seguintes fatores:

  • Cultura da empresa: ambientes tóxicos onde as pessoas são tratadas como meros peças de uma engrenagem sem vida, falta de reconhecimento e apoio no desenvolvimento pessoal colaboram para que o hábito do “fazer o mínimo necessário” seja a diretriz.  
  • Falta de motivação: a negatividade e o desânimo também influenciam na falta de comprometimento. E não há cultura organizacional que motive uma pessoa que não acredita que é necessário ter força de vontade e perseverança para atingir seus objetivos.

Para ambos os casos, são necessárias intervenções que promovam o desenvovlimento de soft skills, que envolvam as pessoas nas decisões e na construção do propósito. Obtemos muito mais comprometimento das pessoas que possuem o sentimento de pertencimento. É possível aumentar essa consciência dentro de um time, incentivando que seus próprios membros criem e revisem seus acordos periodicamente, a fim de que todos possam experimentar e entender a importância de cada compromisso firmado.

Respeito

Sendo que um time é formado por pessoas e as relações entre elas e que nenhuma relação prospera se não houver respeito, temos argumentos suficientes para colocar o respeito como fundamental, não só no uso do Scrum, como para qualquer outra metodologia ágil. Manifestamos esse valor quando entendemos e aceitamos as diferenças entre os membros do time, seja de opinião, de habilidade ou experiência, quando orientamos nosso cliente para que ele não desperdice tempo e dinheiro em funcionalidades inúteis ou com pouco valor, quando chegamos pontualmente em um compromisso e quando honramos nossos compromissos.

Um time que exibe habilidade em vivenciar esse valor é contituído de pessoas que possuem e valorizam essa virtude. A habilidade de ouvir opiniões divergentes sem desprezá-las pode ser treinada através da técnica de escuta ativa. Respeito é dar atenção às necessidades das pessoas, ajudá-las sem julgamentos e sem vestir a capa do super-herói. Todos tem algo a colaborar.

Abertura

Calaramente, não há como adaptar o que não é inspecionado, porém a melhoria contínua não repercutirá positivamente  se a inspeção ocorrer em comportamentos escusos ou fatos mal esclarecidos . Praticarmos a abertura garante que não faremos adaptações errôneas que dificilmente nos trarão bons resultados.

Empreendemos esse valor quando estamos abertos ao nosso trabalho, nosso desempenho e aos nossos desafios. Pessoas dispostas a colaborar, a ouvir sugestões, a realizar melhorias, a aprender empiricamente e a desenvolver novas habilidades respondem melhor as mudanças. Um time formado por essas pessoas é um time de alta performance.

Como incentivar a reflexão sobre os valores do Scrum?

Abaixo, algumas ideias que já apliquei:

  • Criar um Kudo Cards de valores do Scrum para os membros presentearem entre si durante a Sprint
  • Questionar, na retrospectiva do time, quais valores foram ou não presentes, citando as ocasiões em que foi possível identificá-los e refletir sobre qual valor poderia ter sido empregado para evitar algo que não foi bem
  • Pedir para que cada membro fique responsável por pesquisar cada valor e fazer uma mini apresentação para seus colegas
  • Scrum Game

Esses valores devem ser um guia para o trabalho, comportamento e ações do time Scrum, sendo que devemos reforçar esses valores no nosso dia a dia e em todas as práticas, só assim estaremos de fato vivendo o Scrum e não apenas seguindo um processo. Quando, de fato, entendemos esses valores nossa vida se transforma, se torna impossível não levá-los para o âmbito pessoal.

Leia também:

There’s value in the Scrum Values

https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage

https://www.concrete.com.br/2019/04/23/valores-scrum-no-dia-a-dia/

https://www.ibccoaching.com.br/portal/comportamento/escuta-ativa-entenda-como-desenvolve-la-ambiente-de-trabalho/

 

 

Reflexões sobre o Scrum Parte 1 – Visão Global e Teoria

 

Mês passado eu realizei a prova e obtive a certificação Professional Scrum Master I (PSM I) provida pela organização Scrum.org. De acordo com a instituição, pessoas que obtém essa certificação demonstram nível fundamental de domínio do Scrum, provando que entendem o framework conforme descrito no Guia do Scrum e como aplicá-lo nos times. Segundo o site da Scrum.org na data de hoje (01/09/2019) existem 241.737 pessoas certificadas em todo o mundo (fonte: Scrum.org Professional Scrum Certifications). Como esta é uma prova inicial, existem inúmeras informações sobre ela na internet e, minha intenção aqui, não é dar detalhes sobre a prova e sim sobre minha trajetória de aprendizado colaborativo para chegar nela.  Para os interessados, no final do texto, tem alguns links de onde obter dados específicos sobre a prova.

O conteúdo desse post nasceu das reflexões que tive durante o período de encontros de um grupo de estudos criado para pessoas interessadas em conhecer melhor o Scrum e se preparar para a prova. Foram semanas onde analisamos e discutimos os diversos aspectos do framework que, apesar de estar sendo utilizado em 64% das organizações que adotam metodologias ágeis (fonte: 13th Annual State of Agile Report) , ainda é tão difícil de encontrar pessoas que o dominem. O próprio Guia do Scrum salienta esta dificuldade em sua definição onde cita que ele é leve, simples de entender e extremamente difícil de dominar.Podemos perceber a leveza do Scrum em seus times enxutos, entregas curtas e objetividade das cerimônias. O emprego de uma abordagem interativa e incremental aumenta a previsibilidade, promove entregas antecipadas e melhor gestão de riscos, contrastando com os antigos métodos de desenvolvimento de software que consistiam num processo pesado que exigia um planejamento extensivo e o cascateamento de longas fases para realizar uma grande entrega no final do projeto. Hoje em dia, percebo que não estamos mais lutando contra esse fatigante método de desenvolver software, o que encontro em muitos lugares é a total falta de processos amparada pela distorção dos valores ágeis e pela má interpretação do que é a agilidade.

Ele é fácil de entender pois possui regras, papéis e reuniões bem definidos. Tudo disposto em um documento de 20 páginas (contando a capa, índice e agradecimentos).

Se ele é leve e tão simples de entender, então porquê é tão difícil de dominar? Acredito que essa dificuldade esteja na mentalidade das pessoas e na cultura das organizações. Sua estrutura é fundada no empirismo, o que significa que o conhecimento vem da experiência e as decisões são tomadas a partir do que se sabe. Isso implica em aceitar que é impossível prever e controlar tudo, sendo contra intuitivo para pessoas que ainda acreditam em comando e controle. Um processo empírico evidencia que o que sabemos são suposições e, portanto, precisamos validá-las através de experimentos e feedbacks. A base do framework traz autonomia e responsabilidade para as pessoas que estão trabalhando na construção de um incremento de valor e, com isso, transfere as ações tanto de melhoria dos processos quanto do produto para o time Scrum.

O principal objetivo do empiricismo é prover valor aos clientes apesar das incertezas e mudanças que estamos passando. Para isso precisamos compreender o que é importante para ele, inspecionarmos frequentemente se estamos no caminho certo e nos mantermos flexíveis às mudanças necessárias, tendo em mente que entender o que é relevante para o cliente não é apenas questioná-lo, pois muitas vezes ele não sabe exatamente qual a solução para o problema que possui. O cliente entende bem suas dores, quais são os seus problemas, mas cabe ao time Scrum formular e experimentar as hipóteses sem medo de falhar, aprender e assim encontrar alternativas que atendam as necessidades dos clientes. A transparência, a inspeção e a adaptação são os três pilares que sustentam um processo empírico.Inspeção e adaptação nada mais é do que um ciclo, onde estabelecemos uma rotina periódica de  checagem das nossas atividades visando nos adequar para aprimorar nosso resultado. No Scrum, esses loops de feedback são as reuniões regulares dentro da Sprint.

A Sprint é o âmago do framework. É um período de 1 a 4 semanas onde estão contidas todas as reuniões e atividades necessárias para a entrega de um incremento valioso. No final de cada Sprint temos duas reuniões importantíssimas para a melhoria contínua do produto e do processo: a revisão e a retrospectiva da Sprint (leia AQUI alguma dicas essenciais para conduzir esta cerimônia). Mas este não é o único momento de inspeção e adaptação, no início da interação temos a reunião de planejamento, onde podemos nos adaptar conforme a validação que recebemos do último incremento entregue e, durante todos os dias, temos a reunião diária que é um importante momento de verificarmos nosso caminho em direção ao objetivo da Sprint e ajustá-lo, caso seja necessário. Apesar de ser erroneamente usada como status report ou como um momento de resolver problemas, a Daily Meeting tem como finalidade inspecionar como estamos para alcançar nossa meta e adaptar o que for necessário para atingí-la.

Conforme o Guia do Scrum, tudo que for significativo do processo deve estar visível aos responsáveis pelos resultados, isto significa que todos os envolvidos devem compartilhar de uma mesma linguagem e sabe o que significa que algo está pronto. Rotineiramente vemos equipes trabalhando sem uma definição de pronto, sem conhecer o objetivo da Sprint e sem o entendimento adequado dos itens do backlog que entraram na reunião de planejamento. Atribuo toda esta falta de transparência ao desconhecimento dos pilares desse framework. Os times simplesmente executam um pseudo Scrum mecanicista, pautado apenas em cumprir cerimônias e intitular pessoas com os papéis descritos no guia, sem que de fato vivenciar seus valores: o comprometimento, a coragem, o respeito, o foco, e a abertura.

“O Sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência destes cinco valores.”

Guia do Scrum, 2017 

No dia do encontro do grupo de estudos cuja temática foi a teoria e visão global do Scrum, participamos de uma dinâmica muito interessante conduzida pela Vanessa Santos e pela Julia Salazar, onde cada participante refletiu sobre os três pilares trazendo situações do dia a dia onde pudemos ou não evidenciá-los. Após isso discutimos cada cenário buscando o entendimento das razões de quando não houve transparência, inspeção e adaptação construindo um interessante guia de lições aprendidas. Abaixo os itens mais significativos de cada pilar:

Faltou transparência quando…

  • o Scrum Master, que deveria promover e suportar o Scrum, teve um atuação inapropriada , comportando-se como um gerente de projetos
  • houve comunicação pobre entre time de desenvolvimento e Product Owner, não sendo possível obter o feedback necessário para adaptação do produto nem o entendimento necessário para construí-lo corretamente
  • os papéis e responsabilidades não ficaram claros nem existiu uma definição de pronto compartilhada entre todos

Faltou inspeção quando…

  • o time não definiu ou não compreendeu o objetivo da Sprint e consequentemente não soube o que deveria ser um incremento de valor para o cliente
  • as pessoas desperdiçaram oportunidades de comunicarem um impedimento ou solicitarem ajuda entre uma reunião diária e outra, deixando para citar o problema apenas na reunião seguinte
  • as partes interessadas não comparecerão a reunião de revisão, deixando o time sem receber feedback sobre o resultado do seu trabalho

Faltou adaptação quando…

  • o time não assimilou o motivo de cada reunião e as utilizamos apenas como um momento de compartilhar as dificuldades sem se preocupar em ajustar o processo, por exemplo, saindo de uma retrospectiva sem ações claras e factíveis ou saindo de uma Daily sem nem ter pensado no momento atual e pra onde estamos indo
  • formaram-se em silos, não havendo atenção aos pedidos de ajuda dos colegas

Para evitar esses transtornos, entendemos que é importante estabelecer uma gestão à vista que permita que todos estejam alinhados, promover o estudo do framework para aumentar o conhecimento sobre os papéis e responsabilidades de cada um, além dos objetivos de cada artefato e cerimônia do Scrum, determinar uma meta e uma definição de pronto compartilhada entre todos os envolvidos e trabalhar a construção do time para que não hajam silos e falta de comunicação. Conceber e ter em mente o objetivo da Sprint é fundamental para obtermos transparência, inspeção e adaptação.

Links para saber mais sobre a prova:

 

Dicas para Retrospectivas Eficazes

Já diz o manifesto ágil que em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Considero este princípio ágil como um dos mais importantes, pois através dele atendemos diversos outros princípios. Afinal, se ficamos mais efetivos estamos satisfazendo nosso cliente e entregando cada vez mais para ele, quando refletimos nos tornamos mais preparados para responder às mudanças, melhoramos nossa comunicação e descobrimos o que nos motiva. Quando buscamos otimizar nosso comportamento estamos tendo atenção à excelência técnica e identificando desperdícios e como podemos evitá-los. Isso tudo se traduz em um time auto organizável que entrega mais valor.
Um dos maiores diferenciais dos times ágeis é exatamente a capacidade de aprender e evoluir. Através da constante busca pela excelência, um time ágil está sempre em movimento, vencendo novos e maiores desafios e, por isso, trabalha com paixão e entusiamo. A melhoria contínua deve ser aplicada no dia a dia, porém, ter um momento exclusivo para pensar nela é bastante proveitoso. Apesar disso, há um grande número de times que não praticam retrospectivas regularmente, considerando-as um desperdício de tempo.
Conversando com diferentes times, identifiquei que um dos maiores motivos apontados para a não aderência a esta prática se dá pela falta de tempo do time que, muitas vezes, se vê em uma corrida contra o tempo para ser mais efetivo. Quando me deparo com essa situação, sempre lembro de uma frase que aprendi logo que comecei a estudar metodologias ágeis: um time deve fazer uma retrospectiva a cada iteração, a menos que estejam sem tempo, neste caso, devem fazer duas. Essa frase traduz exatamente a necessidade do time em melhorar seu trabalho para poder entregar mais e melhor.
Porém, mesmo demonstrando para o time a importância de se refletir periodicamente em busca da melhoria contínua, percebi que nem sempre as retrospectivas estavam trazendo resultados e foi aí que entendi que existe uma grande gap na condução deste importante momento, que acaba, em diversos casos, se tornando apenas uma “reunião de reclamações” sem ações práticas, onde as pessoas nem sempre estão preparadas para dar e receber feedbacks construtivos e evitam se envolver com receio de gerar uma situação constrangedora. Abaixo trago algumas dicas para evitar essas situações.
Crie um ambiente seguro
Um ambiente onde as pessoas sintam que podem falar sem medo de serem reprimidas ou julgadas é um pré requisito para uma boa retrospectiva. Quando começo em um novo time sempre gosto de salientar que a coragem e o respeito, valores presentes tanto no Scrum quanto no XP, são essenciais e devem ser utilizados sempre em conjunto. Além de uma boa comunicação, existem algumas técnicas que podem ajudar as pessoas a se sentirem em um ambiente onde estão livres para expor suas opiniões.
Uma ideia muito simples que já usei diversas vezes é a da linha amarela, onde uma fita colada no chão na entrada da sala, divide o mundo lá fora da sala onde acontecerá a retrospectiva, servindo como um lembrete de que ali devemos exercitar a coragem e o respeito.
Outra técnica interessante, e bem divertida, é criar um “reino especial” dentro da sala, trata-se de uma abordagem lúdica na qual criamos novos títulos aos membros do time, algo como “Sir Fulano de Tal” ou “Vossa Excelência o Desbravador de Tasks no Além Mar”. Sempre rende boas risadas proporcionando leveza e descontração, muitas vezes necessária para melhorar as relações entre os membros do time. No entanto, a ideia de criar um “reino especial” só se aplica a times mais descontraídos que curtam uma brincadeira assim, pois é imprescindível respeitar os limites de cada um e não causar constrangimentos.
Deixe claro os objetivos e agenda proposta
Uma retrospectiva não deve ser uma reunião onerosa e sem propósito. Ao facilitar este encontro é muito importante deixar claro que o objetivo é a evolução do time e não apenas reclamar. Não tem problema em deixar um espaço para que as pessoas compartilhem suas emoções, porém é importante que isso aconteça em um momento e espaço delimitado de tempo, evitando que a reunião inteira seja apenas um grande desabafo sem ações e sem melhorias tangíveis. Costumo limitar uma retro a no máximo 1:30 e a frequência a cada 2 semanas, independente se o time roda scrum, kanban ou apenas aderem a algumas práticas ágeis.
Ter a preocupação em manter a retrospectiva dentro de um timebox enxuto e com propósito claro, ajuda inclusive na “venda” dessa cerimônia para quem está mais resistente em realizá-la, afinal com uma duração curta, ela pode representar menos de 2,5% do tempo total de horas trabalhadas em uma interação de duas semanas. Para evitar que a reunião se estenda devido ao excesso de emoções, é possível lançar mão de uma dinâmica específica para isso. Por exemplo, em um momento que entendi que o time precisava falar um pouco mais sobre suas emoções, optei por uma técnica onde cada membro aponta as emoções que sentiu durante a sprint, mas focando em como poderíamos evitar as emoções ruins que tivemos, assim damos espaço para as emoções serem discutidas , mas não perdemos o propósito de evoluir. Manter o foco e a objetividade nos pontos elencados pelo time é um desafio constante, mesmo para um facilitador experiente. Uma técnica que pode ajudar na síntese dos itens a serem discutidos é o agrupamento por contexto, onde itens relacionados ao mesmo tema poderão ser discutidos juntos.
Estabeleça ações efetivas
O ideal é focar em ações de curto a médio prazo e em número adequado ao espaço de tempo. Retrospectivas que geram uma longa lista de ações podem gerar sobrecarga e desmotivação, pois o time terá que trabalhar muito mais para realizar as ações ou sequer tentará executá-las sabendo que não será possível atingir a meta. Para evitar longas listas de ações o ideal é priorizá-las.
A técnica que mais utilizo neste momento é a dot votes que pode ser aplicada com adesivos ou apenas com a caneta mesmo (neste caso, a pessoa que marca deverá tomar o cuidado para não ultrapassar a quantidade de votos estabelecidas para cada um). Outra sugestão interessante, que já apliquei algumas vezes, é a priorização silenciosa, onde os membros do time reposicionam as ações sem se comunicar verbalmente, isso aproxima e melhora a relação entre os membros do time que buscam novas alternativas de se comunicarem e prestam mais atenção as expressões dos colegas.
Acompanhe as ações e demonstre os resultados
Tão importante quanto estabelecer as ações, é acompanhar o andamento de cada uma e quais resultados foram obtidos com elas. Isso irá garantir a eficácia da reunião e ajudará na conscientização da necessidade e dos benefícios que temos em realizá-la. Numa retrospectiva, buscamos, muito mais que elencar os pontos positivos e negativos, entender os relacionamentos entre as pessoas e o processo de trabalho, ferramentas e etc, para com isso, estabelecermos um plano para  a evolução do time e, porque não, criar acordos que ajudem a ter um ambiente saudável e inspirador.
Lembre-se que queremos indivíduos motivados e comprometidos e, para isso, é muito importante dar visibilidade da evolução e incentivar a confiança e leveza nas relações entre as pessoas. Tudo isto pode e deve ser mensurado e demonstrado para o próprio time e também para a organização. Uma técnica interessante para apresentar de maneira visual a evolução de um time, é desenhar uma timeline, salientando as maiores conquistas e transformações obtidas ao longo do período.
Escolha bem a dinâmica
No decorrer deste texto, citei algumas técnicas que utilizei em determinados momentos e essa é a palavra-chave para definir a melhor dinâmica para ser usada na retro: momento. Cada time está em um momento diferente e precisará um olhar acurado para não errar a mão. Há times mais dispostos a realizar atividades lúdicas e brincadeiras, já outros preferirão modelos mais clássicos e objetivos de executar uma retro.
Não existe um jeito errado ou certo, existe aquele que melhor se adapta ao contexto. Errar faz parte, mas não podemos deixar de aprender com os erros e evoluir. Faça uma retro com você mesmo sobre a última retrospectiva e estabeleça uma ou duas ações em que você poderá melhorar para o próximo evento. Faça pequenos investimentos em novas técnicas.
Não considero uma boa estratégia levar uma dinâmica de cantar e dançar para um grupo de pessoas que você nem conhece, o ideal é ser pragmático e ter bom senso, comece pelo simples e vá adaptando e inovando conforme vai conhecendo o time e descobrindo como ele responde melhor. Já atuei em um time em que a má seleção da dinâmica, baseada apenas no gosto pessoal do facilitador, tornou a retrospectiva um momento de irritação para todos, gerando conflitos e ineficiências. As consecutivas tentativas de impor um estilo arrojado de dinâmicas fez com que o facilitador fosse visto como um inimigo que estava ali só para gerar discórdia e atrapalhar o trabalho, o que não é nada bom para alguém que está ali com o propósito de facilitar as reuniões e a comunicação. Na dúvida, opte pelo mais simples, perguntas clássicas como: “o que devemos parar de fazer”, “o que devemos continuar” e “o que devemos começar”, geram bons resultados e são bem aceitas por praticamente todas as pessoas.
Onde encontrar ideias:
 Ferramentas gratuítas para retrospectivas remotas:

O papel do Analista de Negócios na Agilidade

Em junho passado, aconteceu, em São Paulo, o BA DAY 2018  com o tema Agilidade. O evento, promovido pelo capítulo de São Paulo do IIBA contou com especialistas compartilhando suas experiências na agilidade sob o ponto de vista da Análise de Negócios. Não pude participar do evento, mas recebi alguns materiais que me trouxeram algumas reflexões importantes.

Dentre os especialistas convidados, estava Ricardo Peters, que atua como gerente de projetos em uma empresa de consultoria de TI e já foi presidente do capítulo de Brasília do IIBA. Ele palestrou sobre Critérios de Aceitação e respondeu uma pequena entrevista antes do evento que pode ser acessada AQUI.

Um dos fatores apontados por ele como uma das maiores dificuldades em aplicar conceitos ágeis  nas organizações foi a resistência das pessoas, esta é uma situação que eu também enfatizo sempre que falo sobre o assunto, devido a alta incidência deste problema. Muitas vezes, causada pelo medo de não ser mais necessário na empresa, a resistência é um fator que todo agente de mudança irá enfrentar no seu dia-a-dia. Tenho trabalhado com pessoas que estão tendo seu primeiro contato com a agilidade e ainda não confiam na forma como as coisas são conduzidas, fazendo com que a resistência seja muito grande.

Dentre os principais afetados pela mudança de paradigma, estão os analistas de negócios. Muitos tem receios de ser o fim da carreira por acreditarem em conceitos deturpados de que a análise de negócios não tem mais valor em um modelo ágil, quando na verdade, mais do que nunca, a análise de negócios é essencial na busca pela eficácia dos processos ágeis. Entender o que realmente entregará valor para o cliente e onde este cliente quer chegar dará um excelente ritmo em um time ágil. O analista de negócio poderá atuar de muitas maneiras em uma empresa que adota a agilidade.

Uma das formas mais comuns e que eu mesma já atuei foi como membro do time de desenvolvimento. Nessa posição o analista de negócios, utiliza seus conhecimentos em todas as áreas da análise de negócios, para, não só, apoiar o P.O. tanto no refinamento quanto na identificação de novas histórias e critérios de aceitação, como também auxiliar os programadores, garantindo o perfeito alinhamento no time. Apesar de ser uma posição controversa, devido a interpretação, equivocada, de que um time de desenvolvimento é formado apenas por programadores, eu considero uma das formas de atuação do analista de negócios que mais traz resultados. O analista, como membro do time, analisa o estado atual e propõe soluções, recomendando a mais adequada para que se chegue ao estado futuro desejado. Além disso, um analista dentro do time, garante a fluidez das informações entre os demais membros e rapidez na preparação de um novo membro do time.

Outra forma bastante comum, e muito produtiva, de atuação de um analista de negócios é na posição de Product Owner (PO). Muitas das skills de um analista de negócios são úteis para a boa gestão do produto. O conhecimento do negócio e a articulação das partes interessadas são um exemplo disso.  Um PO com experiência como analista de negócios, terá mais facilidade em manter um backlog organizado, adequadamente priorizado, continuamente refinado e alinhado aos propósitos do negócio, além de ter as habilidades necessárias para definir excelentes critérios de aceitação, que mitigarão o risco de dúvidas ou mal entendidos comprometerem o resultado do time. Até mesmo o planejamento das releases, será muito melhor executado por um PO que domine as áreas de análise da estratégia e gerenciamento do ciclo de vida dos requisitos.

Também é bastante comum encontrar o analista de negócios diretamente nas áreas de negócio, atuando junto aos POs dos times. É uma posição que sempre existiu e sempre trouxe bons resultados. O analista, aqui, foca na estratégia da empresa e analisa as necessidades e mudanças necessárias para que a organização atinja seus objetivos. Muitas vezes, para atingir um objetivo, serão necessárias mudanças e melhorias nos produtos existentes ou até mesmo a criação de novos produtos e é aí que o analista faz a interface com os POs. Já ouvi em muitas empresas, esse analista de negócio ser chamado de PO de Negócios, enquanto que os demais POs são denominados POs de TI. Outra denominação comum é chamá-lo de PO dos POs ou simplesmente PM (Prouct Manager). Seja qual for a denominação dada a esse papel, um analista de negócios, atuando dessa forma, tem grande visibilidade e muita possibilidade de crescimento na empresa em que atua.

Além dessas formas, existe uma outra situação bastante comum, principalmente em empresas de consultoria que possuem o time de desenvolvimento trabalhando fisicamente distante do cliente, onde o analista atua como um representante do PO no time. Isto costuma ser necessário para garantir que, mesmo não tendo o PO próximo ao time, as estratégias do negócio e a gestão do backlog sejam presentes no dia a dia do time de desenvolvimento. É uma estratégia útil, porém não descarta a necessidade do envolvimento do PO com o time, ele continua tendo que, sempre que possível, participar das cerimônias e responder as dúvidas do time.

 

Com isso, fica claro que há muito espaço para a análise de negócios em empresas que adotaram gestão ágil de projetos. Espero que cada vez mais analistas de negócios entendam sua importância na transformação ágil e se consolidem como líderes e agentes de mudança nas organizações ágeis.

 

Transformação Ágil

Quando falamos em transformação ágil, é importante entendermos o conceito dessa expressão. Segundo o dicionário Aurélio, transformação é “Alterar, variar, tornar diferente do que era”. Já o ágil, embora muitos ainda pensem que trata-se de uma mera metodologia, está muito além de ser apenas um framework ou um jeito de desenvolver software.

Os valores e princípios ágeis foram estabelecidos em Fevereiro de 2001 por 17 profissionais com experiência em métodos leves, como eram conhecidos na época, que se reuniram em Utah e criaram o que conhecemos hoje por Manifesto Ágil. Esse manifesto apresenta um conjunto de 4 valores e 12 princípios que devem ser a base para uma transformação ágil.

Os 4 Valores Ágeis são:

  1. Indivíduos e interações mais que processos e ferramentas.
  2. Software em funcionamento mais que documentação abrangente.
  3. Colaboração com o cliente mais que negociação de contratos.
  4. Responder a mudanças mais que seguir um plano.

Notem que isso não significa que não faremos mais documentação ou que não existirão mais contratos e planejamento. Os valores estão dispostos em uma balança onde, o mais importante, são os indivíduos e interações, software em funcionamento, colaboração com o cliente e responder a mudanças, mas em nenhum momento diz que só vamos fazer isso. Os 12 Princípios do Ágil podem ser consultados na página do Manifesto, visite!

Mas para realizar a transformação ágil nos deparamos com muitos desafios que poderão nos deixar de cabelo em pé. Um dos maiores desafios é a tão falada cultura organizacional. Há anos trabalhamos num modelo de comando e controle, onde os indivíduos se esforçam para não serem os culpados, para garantir que a sua parte foi feita e que o seu chefe está vendo isso. Essa cultura individualista nos afasta do ideal da entrega de valor, pois ao pensarmos apenas em nossos objetivos, deixamos de trabalhar para que o grupo entregue o que é melhor para a organização como um todo. Nesse tipo de cultura, quando as coisas não dão certo, as pessoas se colocam na defensiva e acusam os outros de serem incompetentes, é aquela velha história de “eu fiz a minha parte, não posso fazer nada se os outros não fazem a parte deles”, ou pior ainda, começam a tentar justificar a sua própria inércia em relação ao grupo com a famosa frase: “eu avisei, não quiseram me ouvir”. Somos responsáveis pelo insucesso de algo quando sabendo que não dará certo, nãos fazemos nada para mudar essa situação.Outro grande desafio é a falta de conhecimento sobre o que é o ágil. Muitas pessoas acreditam que ao utilizar metodologias ágeis deixaremos de ter organização e previsibilidade. Há ainda quem acredite que desenvolvimento ágil é fazer mais rápido, quando na verdade, desenvolvimento ágil é fazer melhor, considerando sempre o valor do que estamos fazendo. Estas são apenas algumas das muitas falácias que encontramos por aí que, muitas vezes, são a principal causadora de outro grande desafio: a resistência à mudança. E como se não bastassem esses desafios, o 11º State of Agile, relatório da VersionOne, aponta que 94% das empresas utilizam alguma prática ágil, no entanto apenas 8% tem todos os times ágeis. Isso significa que em grandes organizações, precisamos aprender a conviver com mais de um processo. Todos esses desafios fazem da transformação ágil uma jornada de superação.

Apesar das dificuldades do caminho, mudar nossa forma de agir e pensar em relação ao desenvolvimento de software é cada vez mais uma obrigação. Vivemos em uma época de profundas transformações, cada vez mais precisamos estar preparados para reagir rápido as mudanças do mercado e novas necessidades, ou então perderemos espaço para as novas empresas e tecnologias disruptivas que crescem exponencialmente. A transformação ágil nos permite criar produtos mais inovadores, entregar com mais qualidade e focar no real valor do negócio. Isso tudo aumenta a satisfação da empresa, dos colaboradores e do cliente.

Precisamos estar atentos ao cenário apontado no Chaos Report do Standish Group que cita que mais de 30% dos projetos são cancelados antes de serem concluídos e que mais de 50% custam muito acima das estimativas iniciais, sendo que apenas pouco mais de 16% dos projetos são concluídos no tempo e no orçamento e ainda sim muitas vezes nem terminam com os requisitos originais. Tudo isso indica claramente que a forma antiga de conduzir projetos gera muito desperdício e não atende a dinâmica necessária para que as organizações mantenham-se competitivas. Temos ainda diversas pesquisas que demonstram que empresas ágeis crescem mais e obtêm mais lucro do que empresas tradicionais.

Com isso acho que sobram motivos para iniciarmos esse movimento agora mesmo. E, para isso, precisamos ter consciência que a transformação ágil é muito mais que a simples implantação de um método ou adoção de um framework. A transformação acontece alinhada aos valores e princípios ágeis, dando um passo de cada vez em ciclos curtos de experimentação e adaptação.

Não existe receita de bolo e cada organização tem suas particularidades, então é de suma importância analisarmos a situação atual da empresa, quais são as dores que ela sente e onde ela quer chegar, quais são seus objetivos e metas. Na maioria das organizações, precisamos trabalhar a cultura organizacional para que tenhamos um ambiente que fomente a autonomia, a confiança e a motivação, focando no empoderamento do indivíduo e não nos processos. Afinal as pessoas são a chave de tudo, ao darmos autonomia e confiarmos que farão o seu trabalho, oportunizamos o desenvolvimento de pessoas comprometidas e com propósito. Ao encontrarmos resistência, precisamos entender o motivo desse comportamento e argumentar mostrando os benefícios da mudança tanto para a organização quanto para os indivíduos. É preciso escutar as pessoas e ser presente no dia a dia delas. Lembre-se que, comprometimento, é um valor essencial para todos nós que acreditamos no ágil.

Surgirão novos papéis, novas responsabilidades, a cultura irá mudar, algumas funções poderão deixar de existir ou apenas se adaptar à nova realidade. A postura de cada um será diferente, afinal, ser ágil é ser comprometido e não apenas envolvido, é buscar a melhoria contínua, é estar aberto a novas ideias, é saber onde queremos chegar, é ter certeza de que o nosso trabalho é importante e está ajudando a empresa a obter resultados incríveis e, acima de tudo, é ter um propósito.

“Ágil é uma forma de pensar e tomar decisões que pode nos levar a atingir qualquer objetivo e superar qualquer desafio. Seu poder é ilimitado.” (Myriam Hamed Torres)

 

Esse tal Scrum

Quem não conhece ou nunca ouviu falar de Scrum deve ter ficado ausente de todas as discussões sobre desenvolvimento de software nos últimos 10 anos. A 12ª edição do State of Agile Report aponta o Scrum como o framework ágil mais utilizado no mundo. Considerando iniciativas Scrum e iniciativas híbridas (ScrumBan, Scrum/XP) corresponde a marca impressionante de 70% das iniciativas.

O nome Scrum é uma referência a uma jogada no rugby,  onde os times se juntam para alcançar um objetivo. O Scrum foi concebido em 1995 por Jeff Sutherland e Ken Schwaber. O Jeff inclusive escreveu o livro Scrum: A Arte de fazer o dobro do trabalho na metade do tempo, leitura obrigatória para todos que trabalham ou querem trabalhar com Scrum.

No livro ele cita os muitos problemas do método tradicional de desenvolver software, onde investimos muito tempo planejando cada detalhe de maneira que tudo pareça perfeito, mas na prática, enfrentamos inúmeros desafios que torna muito difícil senão impossível seguir aquele plano. Ele aponta o que todos nós sabemos, ou deveríamos saber, que a mudança é inevitável, então o melhor que podemos fazer é estarmos preparados para ela e adaptarmos nosso trabalho para que ela aconteça e seja bem vinda.

Sabe o PDCA? Pois é, no Scrum nós Planejamos (Plan), Fazemos (Do), Agimos (Act)  e Verificamos os resultados (Check) e o mais importante, fazemos isso regularmente garantindo que estamos sempre melhorando. Quando encontramos um erro já o corrigimos imediatamente, não é necessário, nem inteligente, esperar até nada dar certo pra ver que precisamos corrigir os erros, isso só vai agravar os erros tornando-os mais difíceis de serem corrigidos.

Os times Scrum são enxutos porém completos, tendo todos os perfis necessários para realizar uma entrega. Esse time deve ser motivado e ter autonomia para trabalhar eficazmente por um objetivo. E para termos um time assim tão motivado e eficaz, precisamos garantir que ele tenha plena capacidade de exercer suas habilidades, isso significa que não dá pra exaurir todo mundo com longas jornadas de trabalho acrescidas de horas e mais horas extras. Trabalhar além da conta nos induz a cometer erros, e erros geram retrabalho, diminuindo a produtividade do time. Lembrando que muitas vezes o trabalho excessivo ocorre devido ao mal planejamento e a definição de metas irreais. No Scrum devemos ter objetivos desafiadores, porém não impossíveis.

A grande sacada é manter um fluxo continuo e funcional. Uma forma de ter esse fluxo saudável e cumprir as metas sem horas extras é refletir sobre tudo que se faz desnecessariamente, quantos documentos, reuniões, e-mails ou procedimentos inúteis estamos produzindo. Vamos planejar apenas o que é necessário e mudar sempre que for preciso, sem apego. Por isso a priorização é tão importante em um time Scrum, uma coisa nova que tenha mais valor pode entrar no lugar daquilo que estava planejado sem problema nenhum, desde que ela exija o mesmo esforço para ser realizada.

E pra organizar todo o trabalho o Scrum conta com algumas caixas de tempo fixas que usualmente chamamos de time boxes. Abaixo teremos as principais time boxes do Scrum e um breve resumo de cada uma.

Sprint

Sprint é um período pré determinado que vai de uma a quatro semanas, sendo mais comumente utilizado o período de duas semanas, onde o trabalho é realizado visando atender uma meta. O tamanho da Sprint deve ser estabelecido e respeitado, sendo possível modificá-lo apenas para uma nova Sprint, ou seja, não tem como incluir uns dias a mais na Sprint para cumprir uma meta, pois ela já não deu certo.

Planning

A primeira atividade da Sprint é o planejamento dela, nessa reunião que deve ter duração de até 5% do tempo total da Sprint, é onde a meta deve ficar clara para todo o time, que fará a discussão técnica e realizará a estimativa de cada item que será trabalhado na Sprint.

Daily

É o momento de comunicação entre o time. Essa reunião deve ocorrer diariamente sempre no mesmo horário e local, para que todos saibam onde e quando ela vai acontecer sem precisar de nenhum convite especial. A duração não deve ultrapassar os 15 minutos e, por isso, pode ser realizada em pé. Na daily, cada membro do time fala sucintamente sobre o que realizou no dia anterior, o que realizará hoje e se há algum impedimento, sendo que todas essas questões devem ser respondidas  pensando sempre no objetivo da Sprint. Uma boa daily normalmente acontece na frente de um quadro contendo todas as tarefas do time, onde todos possam ver como está o andamento da Sprint.

Review

É o momento em que mostramos o resultado da Sprint, a ideia aqui é mostrar a coisa funcionando mesmo e não um conjunto de slides com prints de tela. Vamos ficar atentos ao manifesto ágil e entregar software em funcionamento. A Review ou Reunião de Demonstração deve ser objetiva, tendo a duração de até 2,5 % do tempo total da Sprint.

Retrospectiva

É o último time box da Sprint, é nesse momento que vai acontecer a reflexão sobre tudo o que aconteceu de bom ou de ruim numa Sprint e as ideias de como podemos melhorar para a próxima. É um dos momentos mais importantes do time, pois é através da reflexão constante que corrigimos os erros e evoluímos. O tempo de duração ideal desta cerimônia é entre 2,5 e 5% da Sprint.

No livro encontramos muito mais detalhes sobre tudo que falamos aqui, e também outros conceitos e exemplos bem bacanas sobre aplicação de Scrum, então recomendo fortemente a leitura dele. Também recomendo a leitura do Scrum Guide, onde há todas as informações necessárias para se trabalhar com Scrum de maneira satisfatória.

Um pouco sobre o blog

Sejam bem vindos!

Antes de iniciar o conteúdo do blog, gostaria de convidá-los a me conhecer e saber um pouco mais da minha trajetória profissional através da seção Sobre, onde vocês encontrarão também o link para o meu perfil no LinkedIn, sintam-se livre para me adicionar e participar da minha rede (networking é sempre muito importante para todos nós).

E agora que vocês já sabem um pouco sobre quem sou eu e o que eu já fiz até agora, vou contar como se deu a iniciativa de criar este blog. Há tempos tenho vontade de compartilhar informações e falar um pouco mais sobre minha área de atuação e a importância da Análise de Negócios dentro e fora da TI. Tenho conversado com muitas pessoas e iniciei um pequeno grupo de analistas para troca de informações e divulgação de eventos. Com a criação do grupo percebi que era o momento de ter um blog e falar mais sobre minhas experiências e os estudos que realizo visando crescer como profissional e como ser humano, não só na esfera da análise de negócios mas em tudo que acredito que é importante e relevante para nossa evolução.

Amo muito meu trabalho e procuro sempre dar o melhor de mim em todas as minhas atividades. Vou escrever sobre minhas experiências, eventos que participo e muito mais. Espero, com isso, ajudar quem está começando e aprender com quem já tem experiência e quiser participar das discussões.

Até mais!