The idea with planning in a general way is to allow us to prepare for the future, especially with regard to making decisions that promote the effectiveness and efficiency of our project. In this article Planning a Sprint: Velocity and Estimation, eg, we talk about Sprint planning.

However, in addition, we should also understand that the process of estimating involves the search for knowledge about what one wants to estimate. In development projects, be it software or any other product or service, this means discussing the subject with the client / user. Search and investigate similar products or services or competitors. Often even promote discussions with experts. And this search for knowledge brings as a side effect a better understanding of what one wants to estimate. The more we know the more we agree, as we discussed in this post Well written Stories, more accurate estimations.

So, we come to the first important aspect, addressed in a way by #noestimates. We should only estimate if this is necessary for something that brings us value. Whether it is to forecast costs, deadlines, plan capacity, define project scope, understand dependencies between requirements and / or improve understanding about something we should do.

On the other hand, we know that estimates are inherently inaccurate, especially if wrong time. The literature related to software projects makes this very clear, as presented by Robert Glass, Here summarized:

1. Most software estimates are made early in the life cycle when there is little understanding of the problem.
2. Most of estimates is made by management or by marketing, not by who will actually build the software.
3. Rarely estimates are redone.

Considering such observations, we can also deduce for which estimates should not be used.

1. Determine something accurately.
2. Set challenges.
3. Reward performance.
4. Cure lack of commitment.
5. Establish confidence.

We know that estimates are often misused and need to be addressed. But estimates are an indispensable part of a planning process which, as we have seen above, serves at least to organize efforts towards the attainment of some objective.

How then? We tell the client that it is impossible to plan because we can not or should not estimate anything? Do we plan in detail all that we are going to do?

Well, we must first understand that the Agile movement perceived this problem in traditional development processes and established some policies that help reduce the negative side effects of estimates. I highlight the most related, in my view, the estimates: “Respond to changes rather than following a plan.” This means, for example, that in planning something we understand that our knowledge of what is planned will change and that we will need to review our planning. Everything to do with what we discussed above.

In general, the #noestimates movement, or the recommendations of it, follows the same path of many others that have arisen in agility: it brings several interesting insights, but it can not be applied in any way absolute or in any case.

Many projects and organizations with which we have contact already, in a way, when using Scrum, work with #noestimates. For the most part, teams estimate stories using story points. However, most do not estimate tasks by simply setting a timebox for them. It is common for teams to break their stories into tasks by limiting the size of their tasks so that they can be accomplished in a day, at most by two.

In conclusion, #noestimates is very valid, but does not mean that it should or can not be applied indiscriminately. If you add value, estimate is accurate. The most important thing to remember is that estimating by estimating only disrupts the team.

How has your experience in Scrum projects been? Does your team estimate it or not? Do you see value in estimating?

The post Estimate ou #NoEstimates? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

É com frequência que chegam ao ScrumHalf novos potenciais clientes interessados em usar o produto, com dúvidas do tipo: Como posso controlar rigorosamente o trabalho dos indivíduos da minha equipe? Ou, como planejar detalhadamente vários meses de trabalho da minha equipe?

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 (Português) Insanidade vs. Agilidade – Einstein estava certo? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 (Português) Inovar para Sobreviver appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) Feedbacks, motivação e desenvolvimento de competências – Parte 3 appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) Feedbacks, motivação e desenvolvimento de competências – Parte 2 appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.