O movimento, se assim podemos chamar, #noestimates tem como fundamento básico a afirmação que “estimativas não geram valor”. Baseado nisso, prega que devamos evitar a todo modo estimar, reduzindo tal atividade ou mesmo a extinguindo. Advoga que devemos bolar métodos alternativos à estimação. Será? Esse caminho serve para a gente?

Vamos começar falando um pouco sobre estimativas. Estimativas são por natureza incertas, i.e., apresentam o valor aproximado de algo que ainda não conhecemos, não dominamos ou não temos como medir. Estimativas são comumente usadas para previsão. E porque precisamos prever algo? Simples: para podermos planejar.

A ideia com o planejamento de uma forma geral é permitir que nos preparemos para o futuro, especialmente no que diz respeito a tomarmos decisões que promovam a eficácia e eficiência do nosso projeto. Nesse artigo Planejando a Sprint: Velocidade e Estimativa, p.ex., falamos do planejamento da Sprint.

Entretanto, adicionalmente, devemos também entender que o processo de estimar envolve a procura de conhecimento sobre o que se deseja estimar. Em projetos de desenvolvimento, seja de software ou de qualquer outro produto ou serviço, isso representa discutir o assunto com o cliente/usuário. Buscar e investigar produtos ou serviços semelhantes ou de concorrentes. Muitas vezes até promover discussões com especialistas. E essa busca por conhecimento traz como efeito colateral um melhor entendimento do que se deseja estimar. Quanto mais sabemos mais acertamos, como discutimos nesse post Histórias bem Descritas, Estimativas mais Precisas.

Assim, chegamos ao primeiro aspecto importante, abordado de certa forma pelo #noestimates. Só devemos estimar se isso for necessário para alguma coisa que nos traga valor. Seja para prever custos, prazos, planejar capacidade, definir escopo de projeto, entender dependências entre requisitos e/ou melhorar o entendimento sobre algo que deveremos fazer.

Por outro lado, sabemos que estimativas são intrinsecamente imprecisas, especialmente se elaboradas pelas pessoas erradas, no momento errado. A literatura relacionada a projetos de software deixa isso bem claro, como apresentado por Robert Glass, aqui sintetizado:

1.  A maioria das estimativas de software é feita no início do ciclo de vida, quando tem-se pouco entendimento do problema.
2. A maioria das estimativas é feita pela gerência ou pelo marketing, não por quem irá efetivamente construir o software.
3. Raramente estimativas são refeitas.

Considerando tais observações, podemos também deduzir para que estimativas não devem ser usadas.

1. Determinar algo com precisão.
2. Estabelecer desafios.
3. Basear cobranças.
4. Premiar desempenho.
5. Curar falta de comprometimento.
6. Estabelecer confiança.

Sabemos que estimativas são muitas vezes utilizadas de forma errada e isso precisa sim ser combatido. Porém estimativas são parte indispensável de um processo de planejamento que, como vimos acima, serve pelo menos para organizarmos esforços para o atingimento de algum objetivo.

Como fazer então? Falamos para o cliente que é impossível planejar, porque não podemos ou devemos estimar nada? Planejamos com detalhes tudo que vamos fazer?

Bem, inicialmente devemos entender que o movimento ágil percebeu esse problema nos processos tradicionais de desenvolvimento e estabeleceu algumas diretivas que ajudam a reduzir os efeitos colaterais negativos de estimativas. Destaco a mais relacionada, ao meu ver, a estimativas: “Responder a mudanças mais que seguir um plano”.  Isso significa, por exemplo, que ao planejarmos algo entendemos que nosso conhecimento sobre o planejado irá mudar e que precisaremos rever nosso planejamento. Tudo a ver com o que discutimos acima.

De uma forma geral, o movimento #noestimates, ou as recomendações do mesmo, segue o mesmo caminho de muitos outros que tem surgido na agilidade: traz diversos insights interessantes, mas não pode ser aplicado de forma absoluta ou em qualquer caso.

Muitos projetos e organizações com  as quais temos contato já, de certa forma, ao utilizar o Scrum, trabalham com #noestimates. Em sua maioria, os times estimam histórias usando pontos de história. Entretanto, a maioria não estima tarefas, limitando-se a estabelecer um timebox para estas. É comum os times  quebrarem suas histórias em tarefas procurando limitar o tamanho de suas tarefas para que possam ser realizadas em um dia, no máximo em dois.

Concluindo, #noestimates é muito válido, mas não significa que deva ou possa ser aplicado indiscriminadamente. Se agrega valor, estimar é preciso. O mais importante é lembrar que estimar por estimar só atrapalha o time.

Como tem sido sua experiência em projetos Scrum? Sua equipe estima ou não? Vocês vêem valor em estimar?

The post Estimar ou #NoEstimates? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

São dúvidas genuínas, mas que denotam que o usuário ainda não percebeu completamente os valores da agilidade, mais especificamente do Scrum. Por outro lado, deixam claro as dores sofridas, a pressão a que vem sendo submetido, e a sua vontade de mudar esse cenário. Uma necessidade que podemos perceber com facilidade no discurso do usuário.

Ele está procurando um caminho, uma forma, para mudar a realidade de sua organização, de seu trabalho. Acredita que os problemas que vem tendo são fruto da sua incapacidade em fazer direito o seu trabalho. Se sente com dificuldade de modificar isso e busca algo que possa ajudá-lo a trabalhar melhor ou ser mais eficaz. Porém tudo dentro do framework antigo, ou ortodoxo, de gestão de projetos e equipes.  Einstein dizia: “Insanidade é fazer sempre o mesmo e esperar resultados diferentes”.

A proposta do Scrum é trilharmos caminhos diferentes. O Scrum, baseado no Manifesto Ágil, introduz novas formas de tratarmos os problemas que encontramos ao gerenciar equipes e projetos.

O primeiro passo para que isso seja experimentado e assimilado é entender que o objetivo é ser eficaz. Vamos exemplificar. Nosso cliente tem um problema qualquer e acaba desejando a criação de um produto que resolva o seu problema. Em função disso acabamos estabelecendo uma série de requisitos que entendemos que o produto deva atender, ou seja, características desse futuro produto. Aí, planejamos como esse produto será criado e, ato contínuo, como a equipe deverá trabalhar para que o que imaginamos seja feito. A partir disso, passamos a controlar o trabalho da nossa equipe na direção desse vislumbrado produto. É evidente que em meio a tantos planos e controles fica fácil perdermos o foco que, na verdade, não deve ser no trabalho da equipe, nem no produto vislumbrado, mas em uma solução para a dor do nosso cliente.

A ideia no Scrum é, ao invés de trilharmos esse caminho “tradicional”, promovermos outros valores e usarmos determinadas técnicas, para chegarmos ao melhor resultado para o cliente.

No Scrum damos valor a transparência. Entendemos que tudo que acontece, do processo ao produto, deve ser visível para todos, para que possamos trabalhar com melhoria contínua – KAIZEN.

Acreditamos que as pessoas são capazes de se organizar e fazer o melhor que puderem. Não pregamos a teoria do caos, liberdade total ou coisa semelhante. Trabalhamos com inspeção e adaptação.

Reuniões diárias de coordenação são conduzidas pela própria equipe. A colaboração é muito mais eficaz e eficiente que o comando e controle dos métodos mais tradicionais.

Acreditamos que mais que seguir planos, o importante é fazer os ajustes necessários para entregar o melhor resultado possível para o cliente. Promovemos reuniões de Revisão e Retrospectiva para percebermos e introduzirmos esses ajustes.

O Scrum é bem diferente do que muitos estão acostumados, mas é simples e fácil de ser adotado. Basta querer. Basta evitar a insanidade. Aliás, adotar o Scrum significa mudar a sua qualidade de vida para muito melhor. Muito mesmo.

Se você ainda não está na agilidade, experimente. Mesmo que você não queira utilizar o ScrumHalf e prefira um dos nossos concorrentes. Escute o Einstein.

The post Insanidade vs. Agilidade – Einstein estava certo? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Assim como as formigas na foto de Yanuar Akbar nosso mundo está sempre mudando e devemos constantemente nos adaptar a estas mudanças. É uma constante da sociedade estar transitando entre mundos, pois as inovações sempre impactaram na forma como nos relacionamos, comunicamos e comercializamos. De acordo com Klaus Schwab, no livro 4a Revolução Industrial, estamos exatamente neste momento de transição para um mundo mais veloz e complexo onde as novas tecnologias nos permitem criar outras ainda mais capazes de facilitar a nossa vida.

Para se manterem competitivos, países e empresas devem estar na fronteira da inovação. As inovações baseadas em redução de custo tem baixo ganho se comparadas as inovações para entregar produtos e serviços de forma diferenciada.

“Uma coisa é certa para os países desenvolvidos e provavelmente para o mundo inteiro: enfrentamos longos anos de profundas mudanças. Estas não são primordialmente econômicas, ou mesmo tecnológicas. São mudanças em demografia, política, na sociedade, em filosofia e, acima de tudo, na visão de mundo. Mas algumas coisas são certas: por exemplo, é inútil tentar ignorar as mudanças e fingir que o amanhã será como ontem.” – Peter Drucker

Conforme Adam Grant, PhD em psicologia organizacional, precisamos de muitas idéias ruins para ter algumas boas, ou seja, precisamos de colaboração para que surjam idéias que possam solucionar os problemas complexos que temos que enfrentar. Em função disso passamos a ver a inovação não mais dentro dos departamento de P&D, mas sim de qualquer fonte. E passamos também a colaborar mais com outras empresas e pessoas gerando novos negócios que antes não eram explorados. Para Henry Chesbrough, no livro Open Innovation, saímos do modelo de inovação fechada para o modelo de inovação aberta.

“Muitas empresas morrem não porque elas fazem coisas erradas, mas porque elas continuam a fazer o que costumava a ser a coisa certa por muito mais tempo…” – Yves Doz – Professor of Technological Innovation – INSEAD

Segundo Tomas Friendman, no livro The World is Flat, as plataformas colaborativas permitiram a sociedade evoluir da globalização 2.0, onde as empresas passaram a comercializar em todo mundo, para o 3.0 onde os indivíduos passaram a globalizar seu trabalho. Vemos cada dia mais pessoas trabalhando remotamente em projetos pelo mundo todo. As hierarquias vem sendo confrontadas de baixo para cima ou estão transformando elas mesmas em organizações mais horizontais e colaborativas. Os negócios serão organizados gradativamente em times distribuídos e coletivos dinâmicos, com uma contínua troca de dados e percepções das questões do trabalho (Klaus Schwab). Neste mundo novo os times tem autonomia para avaliar os resultados e tomar decisões de como melhorar.

De acordo com o Cynefin Framework, nos problemas complexos não temos uma relação de causa e efeito, e a solução é encontrada a partir de um ciclo de tentativas e avaliações, onde as falhas são uma forma de aprendizado para definir os caminhos que não devemos seguir.

Os métodos ágeis, como o Scrum, vieram para nos ajudar a lidar com os desafios desse mundo complexo, veloz e inovador. A partir de suas atividades, como: reuniões de retrospectiva e diárias, os desafios são avaliados em conjunto onde podem surgir diversas idéias inovadoras; ciclos curtos, produto pronto e funcionando a cada ciclo, e que pode ser avaliado pelo cliente nos ajudam a tratar a complexidade e a velocidade.

Na imagem podemos ver os métodos ágeis aplicados na etapa de construção do processo de avaliação construir-medir-aprender criado Eric Ries no livro The Lean Startup. Para Ries, diversas técnicas devem ser aplicadas visando reduzir o tempo do ciclo. Teresa Amabile, psicóloga de Harvard que estuda criatividade e inovação, diz que a entrega com ciclos curtos e contínuos é uma característica fundamental para a motivação. Teresa chama isso de pequenas vitórias e está na percepção de progresso tanto para quem recebe como para quem produz.

Ah! Aquela satisfação de ver o cliente usando o produto!

Como podemos ver os métodos ágeis tem características fundamentais para permitir que as empresas consigam enfrentar os desafios dessa nova revolução e dos que ainda estão por vir. Não é a toa que mais e mais empresas estão adotando. Segundo pesquisa de 2016 95% das empresas pesquisadas utilizam práticas ágeis e 58% utilizam Scrum.

The post Inovar para Sobreviver appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Assim como na dinâmica anterior, o objetivo do Feedback Canvas é promover uma autoavaliação da equipe, onde todos os membros levantam pontos sobre os demais. Essa forma de feedback foi criada por Matheus Haddad e, assim como outras atividades que utilizam um Canvas, ela consegue se beneficiar deste artefato, já que ele direciona e deixar bastante visual exatamente sobre quais aspectos uma determinada pessoa deve ser avaliada. O resultado desta avaliação permite que cada um ouça dos seus colegas como está o seu trabalho, além de levantarem juntos ações que podem ajudar a melhorar comportamentos considerados negativos por todos. Sendo assim, cria-se uma atmosfera onde todos colocam as cartas na mesa com o objetivo de ajudar uns aos outros a desenvolver competências e melhorar, por consequência, a qualidade do trabalho da equipe.

Falando um pouco mais sobre o funcionamento do Feedback Canvas, a ideia é que cada membro da equipe escolha sobre qual competência ele deseja ser avaliado. Feito isso, toda a equipe elenca as atividades consideradas mais importantes para aquela competência e será em relação a essas atividades que a pessoa receberá seu feedback. O mais interessante desta estratégia é que cada pessoa será avaliada em relação àquilo que a equipe realmente julga ser importante e não em relação à conceitos e/ou atividades “pré-moldadas”, que às vezes podem não traduzir exatamente o desempenho de cada um dentro da equipe. Isso reforça ainda mais a ideia de receber feedback dos colegas e permite que o desenvolvimento de competências seja ainda mais focado para o trabalho que está sendo realizado.

Como podemos visualizar no Canvas, a competência escolhida será avaliada por todos de acordo com a escala ali apresentada. Todos os membros da equipe, incluindo o avaliado, colocarão sua opinião sobre em que ponto da escala a competência do avaliado se encontra e, feito isso, conversarão sobre os motivos de essa ser a percepção geral. Essa escala de avaliação pode ser a definida pelo criador do método, com base em outros métodos, ou pode ser definida pela própria equipe. No primeiro caso, o significado de cada número se encontra descrito abaixo.

A discussão sobre pontos positivos, negativos e ações de melhoria finalizam a dinâmica e completam o Canvas. Após esses últimos passos, a pessoa avaliada consegue ter um quadro onde estão mapeadas as principais atividades relacionadas à competência que deseja desenvolver, a visão da equipe sobre o trabalho realizado e quais são as atitudes que ele deve tomar para continuar se desenvolvendo.

E você? Já experimentou o Feedback Canvas na sua empresa?

Em um próximo post aqui no blog falaremos um pouco sobre a nossa experiência ao utilizar o Feedback Canvas com uma de nossas equipes. Conte para nós também como foi sua experiência e fique ligado no próximo post desta série, quando começaremos a tratar sobre feedback de fora da equipe para dentro. Até lá!

Referências: http://gestao30.matheus.eti.br/palavra-chave/feedback-canvas/

The post Feedbacks, motivação e desenvolvimento de competências – Parte 3 appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No primeiro post desta série vimos que, apesar de às vezes não ser o mais buscado, o feedback dos demais membros da equipe de desenvolvimento é um dos mais valorizados por todos. Isso se explica pelo fato das pessoas acharem mais importante saber a opinião daqueles que estão diariamente com a mão na massa, como eles, do que daqueles que estão um pouco mais distantes. Isso não significa que os demais feedbacks sejam menos importantes, não mesmo. A questão é só que os próprios membros da equipe são mais capazes de identificar pontos de melhoria e de auxiliar os outros a enxergar formas de melhorar e aprender outras formas de desempenhar o trabalho em questão.

Visando promover esse tipo de feedback, há um tempo atrás fiz uma atividade na reunião de Retrospectiva em que o objetivo era justamente fazer com que todos falassem de todos. A ideia é que cada membro da equipe, inclusive o Scrum Master, indicasse uma característica positiva e uma negativa sobre todos os outros membros presentes. No caso, nossas Retrospectivas não contam com a presença do Product Owner.

Para tentar avaliar se havia alguma resistência, fiz a atividade Safety Check que comentei no post “Feedback, Motivação e Desenvolvimento de Competências – Parte 1” e sim, havia resistência. Então, comentei que de repente seria melhor deixarmos para outro momento, mas a equipe teve uma atitude legal de conversar sobre o assunto e resolvemos seguir em frente. A atividade foi bem legal e o mais importante foi ver que todos entenderam o objetivo principal daquele momento: o objetivo não é lavar a roupa suja, é ajudar o outro a crescer e se desenvolver! Deixei isso bem claro no início da atividade e gostei de ver que ninguém se desvirtuou desse objetivo. Inclusive, a atividade foi bem aberta para conversas, para cada um explicitar o motivo de levantar determinado ponto e para que cada um pudesse entender o ponto de vista do outro e por que tal característica era vista como positiva ou negativa.

Depois da atividade, cada pessoa recebeu seu feedback para que os assuntos discutidos não fossem esquecidos. Com o tempo, era possível perceber que algumas coisas tinham sim melhorado, outras talvez nem tanto. Mas isso é normal. Não adianta termos a ilusão de que as pessoas mudarão de um dia para o outro. Isso é um processo, que pode ou não precisar do apoio de todos, e que precisa ser acompanhado e motivado sempre que possível.

Uma das coisas mais legais desta atividade foi ver que quem inicialmente mais teve resistência em participar, um tempo depois veio me perguntar quando a dinâmica seria repetida, pois a pessoa queria receber um novo feedback e ver se a opinião dos outros membros da equipe sobre o seu comportamento tinha mudado. Isso demonstra que mesmo que exista um receio inicial, ao perceber que as críticas são construtivas e que existe um ambiente seguro para crescer e melhorar, a pessoa se sente à vontade e estimulada a correr atrás desse crescimento. E isso é algo muito importante!

Infelizmente ainda não conseguimos repetir a dose da Retrospectiva, mas espero que seja possível em breve. Acredito que manter a frequência desse tipo de atividade quando os envolvidos estão abertos a ela, além de provocar melhorias contínuas, ainda mantém a equipe motivada a sempre buscar novas formas de trabalhar e se aprimorar.

No próximo post falaremos sobre mais uma dinâmica. Essa mais voltada para o desenvolvimento de competências em si. Não deixe de acompanhar e contar para gente como as coisas têm funcionado na sua empresa!

The post Feedbacks, motivação e desenvolvimento de competências – Parte 2 appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.