Let me start saying that I’m not a hater. But I’m the devil’s advocate that likes to bring some discomfort into the room. I just believe that sometimes we stay in our comfort zone thinking that everything is working fine when it isn’t.

A little history

Story points were developed because human beings lack abilities to forecast the future. Our bosses were saying “ok, ok… you wanna use this ‘agile’ thing, but I still wanna know at least when you are gonna finish this new feature!”, and we had to improve our forecasting beyond the “well it will be ready when it gets done” phrase.

Then, we realized that we were actually good at checking whether something was the same size, bigger or smaller than another thing. With that in mind, we created one of the hardest concepts to explain to anyone new to agile: story points.

Comparison or forecasting?

Now we have a comparison tool that does not intend to forecast deadline. Right? Right. It wasn’t supposed to have a one-to-one relationship with time, right? Right. So how does that help to foretell when we will finish a project?

Ok, so you’ll tell me that you use velocity, which is a sum of the comparison values of all the stories you’ve finished in a sprint (which already seems kind of odd). But now, tell me, how many times do you actually finish the entire backlog for a sprint in a sustainable manner (which means QA people not getting stressed and pressured, developers not building tons of technical debt and POs not accepting anything just because they don’t have time)? I’d say none or few. So, why is that?

Well, for starters, we are able, as aforementioned, to see if something is larger, smaller or equal to other things (not so sure about the equal part, but let’s continue). However, we are not good at saying how bigger/smaller it is. Is it double the size/complexity? Is it triple? Who knows?!

Another thing is that if you compare stories with the same points, you’ll see that they will take different times to be completed. And they should because, again, it is a comparison value, not a time-related one.

Based on the last two paragraphs we can deduce that:

1. A 1-point story will probably not take half the time a 2-point story takes. So how do we say our velocity is 3, if these two sets will not take the same time to be completed: {1,1,1} {1,2}?
2. If we can’t even say that two 1-point stories will take the same time, how can we say our velocity is 3, even if we use the same sets: {1,1,1}, {1,1,1}?

Likewise, it is difficult to compare sprint velocities of a team, another common mistake is to compare velocities between teams, or even have a metric for how many points a person can do in a sprint!

We are just creating a false sense of control over our demands and, instead of helping the team, it might actually harm it.

What now?

Ok, Mr. Know-It-All, so when should I use them? Well, they were invented for comparisons! So, use them to compare! Points are not the only tool you have to compare stories. You might also use t-shirt sizes, which are a little bit easier to define than points. In this blog post about complexity and uncertainty analysis, we show a chart that could easily use t-shirt sizes or points in its axis!

Besides that, the moment developers talk and compare stories is great for spreading knowledge among peers and aligning the whole team technically. Another meeting that does basically the same is what we call Task Breakdown, in which some developers get together and try to break a story into technical tasks. But exactly how to do it is a subject for another blog post.

But what about forecasting! How can I answer my boss’ question? We use throughput and lead time, with some statistics behind our answers… They work like a charm and, besides that, they also give us powerful tools to improve our process as well! We have a ton of posts on those topics if you are interested. Here are some of them:

* Throughput and Burnup charts

* Lead Time

* Don’t use average to forecast deadlines

* Use Monte Carlo!

* 12 mistakes you should avoid when using these metrics

Conclusion

The story points concept is useful. Comparing stories is needed, however using that concept to forecast delivery rate and deadlines is not the best option. So, open your spreadsheet, add your metrics to it and let’s start a sustainable development!

What do you think? Do story points work for you? Leave your comments below!

The post Do we need Story Points? first appeared on Plataformatec Blog.

Introduction

When we use WIP limit, we limit the number of concurrent tasks. It could be a limit to each column of a Kanban Board; it could be a limit to the whole system; or even a limit to a set of steps of the process.

The idea behind limiting the work in progress is to work side-by-side with Little’s Law and try to improve the flow of the system, diminishing the lead time (LT) of a work item. And that works like a charm for machines. For software development? The relationship between WIP, LT and throughput is not that straightforward.

People are different

When we have a chain of machines linked together, in which the output from one feeds the input of other, everything is easier to predict. Now, imagine a situation in which:

• Items entering the first machine are not always the same size. And the machines don’t follow a linear relationship between size and time to complete a task.
• Each machine can, unpredictably, change its behavior. One week, it may receive an input of size x and generate its outcome in 1 hour. In another week, it will, unpredictably, take 3 hours to produce the same result.

Things start to get tricky, right?

WIP Saturation Chart

From my experience, some readings and even the way I work, I saw that different people work best with different workloads. I believe that a chart of WIP by the throughput of a person follow something like this:

This chart was taken from https://www.infoq.com/articles/how-kanban-works.

Some people work best with more than one task at a time. For different reasons. They might get unmotivated with few responsibilities, or it might be easy for them to rapidly change focus between tasks, for example. On the other hand, other people have a really difficult time changing focus and handling many tasks at once.

Other than depending on the person, it also depends on the project: it might involve third-parties that regularly block their work, it might have a testing process that takes weeks or months to finish, etc.

So, how can we come up with a single number that will magically fit all those curves under the same process? You can’t. But that doesn’t mean you shouldn’t.

So what? Should I just go crazy and forget limits?

As I said, it is just impossible to get a number that limits the work of everyone in an optimal manner. But that doesn’t mean you shouldn’t use one. I see, until the time of this post, two options for two different contexts:

1. You have someone looking at your process. If you have a Project Manager, an Agile Coach, a Scrum Master or other person that takes care of your process, you don’t need WIP limits. You need WIP management. This person can better understand how each person works and alert people to the amount of WIP according to each individual necessity as well as the type of project. I’d only use WIP Limits here to give process ownership to the rest of the team. This means that the person looking at the process would be actually temporary.
2. You don’t have a process guru. In this case, limiting the WIP with numbers and trying to tune it with time will give you a better process. It will not give you the optimal outcome, but it will unquestionably give you a better result.

Conclusion

WIP limit works. It will improve your process. But it is not a silver-bullet (I feel like a parrot repeating this). Look at your context (people + project) and use whatever delivers a better outcome.

What do you think? Do you believe in WIP Limits or not? Leave your comments below!

The post WIP Limit – A further study first appeared on Plataformatec Blog.

Quando estamos lidando com prazos, famosos deadlines (não poderiam ser successlines?!), essas perguntas provavelmente irão surgir em vários momentos do projeto antes da entrega, e com certeza muitas outras vezes se o prazo inicial não for atendido. Independentemente do período em que esteja o projeto, você já pensou que muitos problemas relacionados com essas perguntas são causados por falta de alinhamento na expectativa da data de entrega?

Aqui na Ptec estamos trabalhando com uma dinâmica chamada Reality Check, ou verificação de realidade. É uma dinâmica muito eficaz para quando há um prazo de entrega bem apertado. Meu amigo Lucas Colucci contou um pouco sobre como esta dinâmica funciona em seu blogpost Desenvolvendo melhoria contínua em seu processo ágil: A cerimônia de Reality Check. Nós testamos esta dinâmica e a evoluímos e, com isso, encontramos algumas novas práticas que podem agregar valor para esta ferramenta. Nos exemplos que serão apresentados a seguir, os resultados foram muito positivos! Vamos conhecer?

Salvando o prazo do seu projeto!

Arrisco defender o seguinte: na maioria das vezes, é mais relevante para o projeto deixar as expectativas de data de entrega bem alinhadas do que efetivamente cumprir um prazo inicialmente empurrado para a entrega do projeto. Defendo isso porque, no início do projeto, ou de alguma parte dele, dificilmente conseguimos prever uma data precisa de entrega, pois as diversas variáveis que interferem nessa promessa de data influenciam demais no que efetivamente irá acontecer, como, por exemplo, ausências diversas, feriados e as deliciosas emendas de sextas-feira, desmotivação, problemas novos não existentes no início do planejamento, mudanças de escopo não controladas, férias de colaboradores não programadas com antecedência, entre tantas outras. Entretanto, todos esses pontos não significam que não podemos mostrar o que realmente está acontecendo. Prazo não deve ser uma restrição, mas sim uma meta!

É possível trabalhar a questão abordada de uma forma bem simples: deixe claro, de forma explítica e antecipada, quando a entrega irá efetivamente ocorrer. Dessa forma, seu cliente sempre terá o controle da situação, caso a equipe descubra antecipadamente que o prazo inicial não será atingido.

A ideia é muito simples: mostrar a realidade do que está acontecendo no time, concedendo visibilidade quanto ao prazo! Apresentar a real situação ajuda a deixar as expectativas de data de entrega muito bem alinhadas, e de forma antecipada. De quebra, em um formato colaborativo, o Reality Check tem a capacidade de empoderar a equipe sobre a apresentação da data de entrega e, dessa forma, cria um vínculo de parceria e responsabilidade com seu cliente. A mensagem é que somos um único time, e estamos fazendo o melhor!

Explica como funciona?

Primeiramente, tenha o seguinte cenário: um escopo e um prazo. Bem simples, não? Segundo passo: obtenha o detalhe do escopo de alguma maneira. Isso pode ser feito via Story Mapping, decomposição do escopo para obter os pacotes de trabalho de uma EAP (Estrutura Analítica do Projeto), grupos de tarefas de um cronograma, etc. Enfim, tenha um conjunto de itens que, juntos, somam todo o escopo de sua entrega. É importante também que esses itens sejam, mais ou menos, de “tamanhos” semelhantes ou de mesma natureza técnica, evitando misturar demandas muito grandes com as muito pequenas, por exemplo. No nosso caso, usamos histórias de usuário de um Backlog de produto, todas oriundas de um Story Mapping e, na medida do possível, já priorizadas no contexto da próxima entrega do projeto.

Em seguida, escreva todos os seus itens de escopo em post-its (existe algo melhor do que esses papeizinhos que grudam?). Depois, em um quadro branco, por exemplo, ao lado direito de todos os seus itens de escopo, desenhe faixas verticais de períodos iguais que representam a evolução temporal do projeto, ou, em outras palavras, faça várias faixas que mostrem cada semana até a data de entrega do projeto. A última faixa poderá corresponder à data de entrega. Não recomendo dividir esses períodos em dias ou meses, pois são distâncias curtas e longas demais, respectivamente. Depois, trace uma linha horizontal quase no topo do quadro e, em cada espaço de faixas verticais, declare qual é o respectivo período que aquele intervalo representa no projeto.

Para facilitar, você poderá fazer essa dinâmica no primeiro dia de trabalho de uma semana. Não recomendo que o Reality Check seja feito para um período muito longo. Entendo que, no máximo, um trimestre (entre 12 e 14 semanas) seja aceitável para que a dinâmica funcione corretamente. Um período maior do que este fará com que a equipe não consiga ter uma visão adequada e acabe estimando o trabalho futuro de uma forma muito relativa. Quanto mais distante, menos assertivo. Dessa forma:

Feito isso, reúna o time, apresente o desenho e peça para a equipe mover os itens que estão no Backlog para dentro das faixas semanais, declarando em qual semana cada item irá ser finalizado, e não quando começam (faremos isso de outra maneira). Se o mesmo item for durar mais do que uma semana, não é necessário duplica-lo, mas somente coloca-lo na semana de término. O objetivo é distribuir todos os itens na linha do tempo, estimando o quanto de trabalho será feito em cada semana e, principalmente, descobrindo se é possível encaixar todo o esforço do projeto dentro do prazo solicitado pelo cliente. É extremamente importante que a equipe tenha a autonomia de distribuir seus respectivos trabalhos no quadro, e que o gestor do produto / PO esteja presente durante essa parte da dinâmica.

A equipe não precisa buscar ser extremamente assertiva quanto a essa distribuição, mas sim tentar encontrar um volume de trabalho semanal que seja condizente com a realidade. É interessante que, neste momento, a equipe perceberá se será possivel atingir o prazo do projeto e quais são as dependências entre cada item do escopo. Vários outros debates podem surgir e, de repente, você poderá ter a primeira oportunidade de negociar o prazo do projeto ou, se este for inegociável, tentar reduzir o escopo para que ele se encaixe dentro do período mostrado no Reality Check.

Ao final, para finalizar essa primeira parte da dinâmica, distribua um post-it para cada membro do time e, de forma individual, cada um (exceto o facilitador e o gestor do produto / PO) escreverá um valor de 1 a 4, sendo a menor nota representando que a data de entrega não é factível de ser atingida e, à medida que a nota aumenta, o prazo é plausível de ser atingido. Depois, o facilitador da dinâmica calcula a média dessas notas e apresenta para a equipe. Se a nota for 1 ou 2, é interessante rever o planejamento colocado no Reality Check. Se for 3 ou 4, é possivel entender que todos estão confortáveis quanto ao prazo da entrega do projeto. Também é válido conceder a oportunidade para quem colocou notas extremas (1 e 4) comentarem suas posições, visto que essas pessoas podem estar enxergando pontos que os demais membros do time deixaram passar despercebidos. Algum plano de ação poderá surgir neste momento, com o objetivo de melhorar alguma nota baixa, por exemplo.

Na segunda semana, no primeiro dia de trabalho, todos se reúnem novamente para atualizar o Reality Check. É interessante que o cliente esteja presente nesses momentos de atualização do quadro. Agora, a equipe irá deixar os itens que foram concluídos na semana anterior e, caso todos não tenham sido concluídos, o time deverá pensar como irá realocar os itens remanescentes na semana corrente e/ou nas próximas e, portanto, movendo algo que estava nessa semana para a próxima, e assim sucessivamente. Repetindo isto em todas as semanas, a equipe conseguirá alocar os trabalhos do projeto nos períodos e, dependendo da situação, visualizará que a entrega não conseguirá ser desenvolvida até a data estipulada, ou que será necessário a alocação de mais pessoas para o projeto, ou reduzir o escopo, entre outros. Ou seja, o cliente terá visibilidade sobre o andamento do projeto e conseguirá apoiar a equipe a encontrar opções viáveis para solucionar a questão. A foto abaixo, tirada de um exemplo desta dinâmica, reflete a situação do projeto em uma sexta semana:

Para complementar a dinâmica, a equipe poderá adotar alguns mecanismos visuais para ajudar a interpretar cada item do Reality Check. Como sugestão, colocamos:

• Um adesivo azul, no canto superior esquerdo do post-it, para mostrar quando aquele item (no nosso caso, histórias de usuário) estava em desenvolvimento;
• Um adesivo vermelho, no canto inferior esquerdo do post-it, para representar algum bloqueio naquela história de usuário (algo que esteja atrapalhando o andamento do desenvolvimento, ou algum impedimento que precisa ser removido);
• Um adesivo retangular, no canto superior direito do post-it, para declarar em qual semana aquela história de usuário tinha começado a ser desenvolvida (somente para quando a semana de início não era a mesma de término da história);
• Um post-it amarelo menor, no canto inferior direito do post-it principal, que representava alguma pendência daquela história (com um pequeno texto explicativo).

Além disso, quando havia dependências entre os itens, como, por exemplo, a história de usuário B somente poderá começar após o término da história A, a equipe desenhava uma seta de ligação, a fim de representar esta dependência. Post-its de cores diferentes também podem ser utilizados para que haja uma identificação de tema, como, no nosso exemplo, uma cor para representar histórias de desenvolvimento de código e uma outra cor para demandas relacionadas com layout. O “tamanho” de cada item também poderá ser declarado, evitando que a equipe planeje desenvolver demandas muito grandes na mesma semana, por exemplo. Para ajudar no entendimento de tudo isso, crie uma legenda ao lado do quadro, semelhante a esta foto:

Portanto, a dinâmica de Reality Check tem o potencial de agregar valor de gestão para toda a equipe, minimizando problemas de alinhamento quanto às expectativas de entrega dentro de determinado prazo, bem como mostrando como está a realidade do desenvolvimento do projeto.

Dicas extras

Algumas práticas podem facilitar a utilização dessa dinâmica:

• O facilitador do projeto pode manter o quadro atualizado durante a semana. Depois, no início da próxima, o time poderá focar em distribuir os post-its. Para isso, sempre tenha por perto todos os utensílios necessários (adesivos, caneta de quadro, etc.);
• O facilitador precisa apoiar o time em momentos de debates quanto a prazos, pois é normal que o cliente queira a entrega dentro do prazo inicial. Logo, conversas sobre horas extras, por exemplo, podem surgir, caso a equipe não consiga encaixar todo o escopo dentro do prazo. Cabe à equipe decidir se vale a pena esse esforço adicional, pois, talvez, é melhor tentar negociar um novo prazo, ou mesmo “quebrar” partes do escopo e encaixar o que for possível dentro da data desejada;
• Evite identificar a pessoa que está desenvolvendo cada item do escopo. O Reality Check não pode se transformar em uma ferramenta de cobrança, ou mesmo que exponha algo irrelevante para o projeto/time. O quadro, o progresso e as decisões são do time, e não de atores individuais;
• Tenha outras ferramentas para a gestão do projeto. O Reality Check é um item adicional e funciona muito bem quando sincronizado com um quadro Kanban, por exemplo. Ele também poderá agregar valor quando seu projeto ainda não possuir dados históricos para a utilização de métricas, sendo uma potencial ferramenta para conceder, no início do projeto, previsibilidade sem dados;
• O Reality Check não precisa ser utilizado em todas as entregas do projeto. Talvez ele seja naturalmente demandado quando o contexto do projeto (um prazo apertado, por exemplo) justificar sua utilização, ou mesmo quando os membros da equipe encontrarem alguma motivação;
• Se você estiver trabalhando com Scrum, o Reality Check poderá ajudar o time durante a Daily. O próprio time poderá identificar essa oportunidade.

E você, gostou dessa dinâmica? Fique à vontade para comentar, feedbacks e opiniões são sempre bem-vindos!

The post Alinhando expectativas de prazo com o Reality Check first appeared on Plataformatec Blog.

Society is defined not only by what it creates but by what it refuses to destroy. – John C. Sawhill

Before we start, if you are not familiarized with the terminology, here is a short explanation:

• Soft Skills: personal attributes that enable someone to interact effectively and harmoniously with other people (Google).
• Hard Skills: specific, teachable abilities that can be defined and measured, such as typing, writing, math, reading and the ability to use software programs (Investopedia). In this case, we are using the analytical part of it.

The rise

Before the agile mindset, project managers used to apply the classical engineering style to handle software projects. The PMBOK (Project Management Body of Knowledge) was, and still is, the source of very good practices and tools for project management. And most of them work in regular industries, the ones that are not as organic as the software area.

However, the software industry misused the PMBOK. They thought all the practices that are mentioned in it were too hard-skilled and wouldn’t work in a fast-paced environment as the software industry. And yes, it has all those hard-skilled practices (and some of them do not work with software development), but they were all glued together by team-building actions that people ignored at the time (some of which can be seen in the Human Resources chapter). But, as I presented in the aforementioned blog, a revolution took place, and made the industry crucify and bury those practices, without even look if they were all really that bad. As a result, they saw themselves tool-less and decided to react and build their own tools.

The death

With that, came all the Agile methodologies and their toolsets. Moreover, since the industry lacked soft skills at that time (the trend was to act like bosses: telling other people what, when and how to do stuff), a natural path for the revolution was clear: improving soft skills.

And it happened! At least the new practices facilitate that… if people apply it or not on a daily basis, it’s another story. With that mindset in place, the boss image was abandoned and leader figures were created. Focusing on the code quality and not so much on documenting everything. Letting developers get much closer to product stakeholders than before because that communication between them needs to be proxy-less (in a perfect world at least).

But things were still not smooth. Most companies started using Scrum, improved their process, but reached a stagnation point in which something was wrong, but they didn’t know what. The team felt better, working this way, but it was more difficult to spot problems in the process. Talking about deadlines with clients became taboo. And scrum masters would basically annoy the business area of the companies, which wanted predictions to improve their plans.

Basically, the process improved inward: the development team was happier and more effective. But they forgot to improve the technical communication outward: with other areas, with business, marketing, clients, etc. These areas need more data about the software in order to build their plans. And with that in mind, some hard skills, that got lost years ago, came back.

The rebirth

At Plataformatec we embraced hard skills, as most of our agile blog posts show it. We think that having good and advanced hard skills is not a sin, we can and should have as many metrics as possible. However, with metrics, comes great responsibility (this is somehow familiar… ).

Metrics serve as a way to ease the conversation between areas (or with an external client) and to improve our processes inside the team as well. For both, we need to be cautious and not present loose metrics (showing them without the proper explanation and contextualization). If that happens, they can become a way to demand more work and to micromanage the team’s deliveries, which, usually, is not healthy. (Another post on the common mistakes when using metrics is on its way…)

If you wanna take a step further and improve your hard skills toolset, you can take a look at our free Monte Carlo spreadsheet, which uses Monte Carlo simulations to inform you the probability of finishing your project in each of the next weeks!

So… Which one is more important?

Both are extremely important. Soft skills without hard skills make the team happy at work but probably inefficient. Hard skills with no soft skills make the team aware of their problems but with no motivation to change. We need to balance both. I’ve already heard questions like: Oh but should it be like, 50/50? 80/20? And I answer with this question: How would you even measure how much soft skills and hard skills you have?!

So, the conclusion is: have both, improve both, care for both. If you think you already have enough of each, you are likely wrong. This should be the mantra of all project managers/Agile coaches out there… You must have a motivated team and enough data to facilitate communication and improvement.

What about you? Do you prefer one skill over the other? Leave your comments below!

The post Hard skills on project management first appeared on Plataformatec Blog.