The post (Português) Cuidado com o Ciclo da Morte do Produto appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

1 – The meeting is very time consuming and lasts much longer than planned.

After all, it is not anyone who manages to remain 100% focused on a very long meeting. When participants lose focus (or interest) in what is being presented, the review meeting loses its purpose.

2 – The team leaves the review meeting demotivated.

There are times when the P.O. feels the need to "shake" the team a little bit. This is normal, but sometimes these are so frequent or intense that make the team feel demotivated or discouraged. The P.O. needs to be careful here to direct the criticism to the problems and not the people.

3 – Discussions at the review meeting are not productive.

It is extremely easy to make a meeting misdirect with unproductive discussions. For some people, the temptation to just take the time to address an issue on some business rule controversy when a certain story of the same topic is being presented is too overwhelming. The Scrum Master should remind everyone that the purpose of the review meeting is the inspection of what was done and not inquiries on requirements.

4 – The team leaves the meeting without the understanding of why the stories have been reproved.

The P.O. should be able to explain to the team why a story was rejected and the team should be concerned about what will be needed to correct it. Without this understanding, the necessary corrections will not be possible, and the story can be rejected again.

5 – People in the meeting pointing out whose fault is that the story have been reproved.

A failed story is not the fault of a specific individual, but the team as a whole. The purpose of the review meeting is not to point out who is guilty of what. This kind of discussion should happen in the retrospective meeting, if appropriate.

6 – People are not aware of what is happening in the sprint.

If any team member arrives at the sprint review meeting without knowing that a story wasn't finished, why a decision has been taken, or other significant events that occurred, this person will not be able to actively participate in what is being presented, nor will pose relevant questions and will thus not benefit from the discussions.

The post 6 signs to show that your review meeting is inefficient appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Este é o primeiro da série de posts que tratarão o tema da implementação do MPS.BR com o framework do SCRUM. Serão apresentados os resultados esperados e RAPS presentes no guia de implementação do MR-MPS-SW, e como estes podem ser traduzidos para o contexto da agilidade.

É importante frisar que estes posts tratarão de idéias e dicas e não como a implementação é feita integralmente.

Uma breve introdução sobre o MR-MPS-SW

O MR-MPS-SW, ou Modelo de Referência do Software Brasileiro, é um programa mantido pela SOFTEX que tem por objetivo arquitetar uma indústria brasileira de software competitiva nos cenários nacional e internacional. Isto é, utilizar as práticas de Engenharia de Software para aperfeiçoar seus processos organizacionais no intuito de desenvolver produtos com padrões de qualidade aceitos internacionalmente.

O modelo de referência define níveis de maturidade para as organizações que vão do G ao A e estão descritos nos Guias de Implementação, que podem ser encontrados no site da SOFTEX. Cada nível possui processos específicos a serem implementados, sendo estes descritos por meio de resultados esperados.

Nível G

No nível G, Parcialmente Gerenciado, são dados os primeiros passos no sentido da mudança da cultura organizacional no que se refere ao aperfeiçoamento dos seus processos. Neste nível é dada importância na definição de alguns padrões dos projetos da organização.

O nível G trata dos processos de Gerência de Projetos e Gerência de Requisitos, que serão tratados a seguir e no próximo post, colocando-os frente a frente com o SCRUM.

Gerência de Projetos

Resultados Esperados do nível G:

GPR 1. O escopo do trabalho para o projeto é definido.

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

O GPR 1 trata de definir o que há de ser feito no projeto, suas restrições e limites, já o GPR 2 trata da complexidade do que há de ser feito. Trazendo estes para o mundo SCRUM, podemos implementá-los através do Product Backlog. Se no início do projeto forem inseridas as histórias a serem realizadas, mesmo que sejam macro-histórias, há uma definição de escopo, e ao realizar estimativas, utilizando, por exemplo, o planning poker, a complexidade individual destas está sendo definida.

GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos.

Aqui está sendo definido, de fato, que será utilizado o SCRUM com suas cerimonias etc.

GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

Mantendo-se registros dos Product Backlogs e Sprint Backlogs antigos é possível estimar com algum nível de precisão o HH necessário para a realização do novo projeto. É uma boa prática guardar informações de contexto sobre estes, por exemplo: datas de início e fim, quantos desenvolvedores seniors, juniors participaram, quais suas cargas horárias, horas extras, quantos pontos foram planejados, aceitos e reprovados. Isto ajuda o seu especialista analisar o que ocorreu para evitar que possíveis problemas venham a acontecer.

Este foi o primeiro post da série da união do MPS.BR com o SCRUM. No próximo post darei seguimento ao processo de Gerência de Projetos – GPR.

The post (Português) Implementando o MPS.BR com SCRUM – Nível G (Parte 1 – Gerência de Projetos) appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

According to Edward De Bono, people tend to approach these situations always in the same way, for example, emotive persons are guided by instinct, while logicians often use logic and stick to the facts. The idea of the Six Thinking Hats is that the target of the decision should be approached from different perspectives, and this is done using the metaphor of the hats.

• The blue hat is worn by the Scrum Master or some other meeting facilitator. This person will direct the order of the thinking hats.
• “Wearing” the white hat, the team sticks to expose all the available data on the problem or decision. Here, all the information is gathered and explained to everyone.
• The red Hat leads us to look at the problem or decision using our intuition. Here individuals are brought to use their instincts.
• When you “wear” the black hat it’s time to be pessimistic. It’s time to analyse everything that can go wrong.
• With the yellow hat it’s time to be optimistic, rising the positives things and benefits of the decision.
• Lastly, It’s time for the green hat. It’s time to be creative and explore different solutions. The idea is to make a mini brainstorming without being critical.

The order of hats is very important and should be carefully considered by the Scrum Master who shall take into account the knowledge he or she has of the team. A suggested order for problem solving is: blue, white, yellow, black, green and red.

This is a simple and easy technique that can save countless hours of meetings and avoid those meaningless discussions that do not lead anywhere.

Source: MindTools.com

The post De Bono Hats: A tool for helping the team decision making process appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Another problem related to this topic is when it is known that measurement is important, but it’s done without any planning or a clear goal. Remember that even if the cost of performing a certain measurement is low, if it is not used for any purpose, in the end it becomes expensive because it meant wasted team effort.

To solve this problem, the GQM (Goal Question Metric) was created. It’s a simple method to plan measurements so that they’re based on specific organization/project goals. In this post we propose the use of the GQM method with the SCRUM framework.

As one of the roles of a Scrum Master is to monitor and look after the team work process, the measurement should be an important ally for his work. A good practice would be to analyze the negative and positive points raised in retrospectives (especially the recurring ones) and identify the weak points in the process. For example, a negative recurrent point in the latest retrospectives may be that many bugs are being found by the client in the production version. It shows that the activity of automated testing in the work process is not performing well.

Based on this identification, it is possible to apply the GQM in planning a measurement process. For this purpose it should be defined:

• The GOAL of the measurements. E.g. improve the efficiency of the automated tests.
• The QUESTION that should be answered. E.g. what is the efficiency of the automated tests?
• The METRICS that can answer the question. E.g. number of bugs found by the client, interval between failures etc.

With these definitions it is possible to initiate the measurement program that will be followed by the team. It is also important that the Scrum Master schedule regular meetings for data analysis, where the measured data is displayed so that it is possible to draw conclusions for corrective actions (e.g. graphs, tables, etc.).

The GQM, showed in this post, is just one of many methods that can be used to plan measurements. Others may be found in guides, such as MPS.BR, CMMI and some ISOs. The important conclusion of this post is: Measurements should be planned.

The post Using the GQM method with the SCRUM framework appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.