From my experience, the two main reasons a team gets stressed and pressured are lack of visibility and lack of predictability.

Visibility

First of all, what is visibility? Visibility is the transparency of your team’s process. It means allowing all stakeholders to know what you are doing, how you are doing and why you are doing. It doesn’t mean giving every smallest detail of your process, but they need to have all necessary information to drive their goals according to your team’s progress.

When stakeholders don’t have the appropriate visibility, they might underestimate the team’s capacity and input pressure to see more results. On the other hand, when they have it, it is easier to agree on a sustainable development

To improve visibility on your team, you can:

• Have your kanban board always updated.
• Retrieve process metrics, so you have numbers when talking to a stakeholder.
• Build Cumulative Flow Diagrams so you can show where your team lacks efficiency and stop pressuring the wrong people.
• Avoid common errors when using metrics.
• Try to keep your work items as similar as possible regarding size and complexity.
• When the latter is not possible or when complexity changes due to discoveries during development (or blocks, as well), make sure this information is somehow visible.

Predictability

Predictability is knowing when you are going to finish a demand, or what you’ll produce until a specific date. Without that information, you might find yourself always running against time, because you’ll never know if you are on the right track or not.

Fear of missing a deadline is the most famous cause of pressure in a team, but if you gather the right information throughout the process, you can negotiate:

• More time, and you’ll have the numbers to say how much time you need;
• Less scope, and you’ll have the numbers to say how many stories you can actually deliver by the deadline;
• A larger team, and you’ll have the numbers to say how many people (and their roles) you need to match the deadline. (Disclaimer: this should be your last resource. Changing the team size has different impacts, such as increasing cooperation complexity. I explain some of it on this blog post about the Law of Diminishing Returns)

In order to achieve that level of predictability, you will need a very good process in place:

• Have an efficient Story Mapping to know your backlog.
• Break the epics in similar-size stories, using complexity and uncertainty analysis.
• Start measuring the Lead Time of your team, and do it from the very beginning of the process until the end, also registering the amount of time spent in each step of the process.
• Start measuring your team’s throughput and try to have a cadence of delivery, through managing or limiting WIP.
• Build useful predictions based on the metrics you gathered using statistical analysis and Monte Carlo Simulations.

Conclusion

If you have visibility and predictability in your process, the pressure is easily tunable. You can adjust it in order to improve the overall and long-term performance of the team, without having to deal with hypertension in the future.

Can you say you have a predictable and visible process? Leave your comments below!

The post Two motives why your team is feeling pressured first appeared on Plataformatec Blog.

Here I compile the most common mistakes that teams are committing when using metrics, so you’ll know what not to do when adopting them.

#1 – Being reactionless

If you collect metrics, you need to use them somehow. Therefore, one of the most common mistakes is doing nothing about the metrics you are seeing. Metrics can give you process improvement insights and, to react, you need to understand how they work and what they mean.

For more information on how to use them, check these blog posts:

• Cumulative Flow Diagrams
• Throughput and Burn-up Charts
• Lead Time

#2 – Using metrics with few data

Another mistake is to use metrics without enough data to support them. At the beginning of a project, or when you just started using metrics, we are often anxious to start gathering results from them. However, with a low amount of data, metrics aren’t that trustworthy. A good hint is seeing if they are still changing over time or if they are steadier… When the latter happens, you are probably ready to start analyzing them and act based on results. More on how to act can be found on our metrics blog posts.

Another hint would be to try daily metrics, check our blog post on them: Pros and cons of using daily metrics

#3 – Using metrics without considering their context

This is a very common mistake, not only in software development but with every statistically built conclusion. Numbers alone are used just for algebra or calculus. You need the context in which they are inserted to understand them. With that in mind, to say if your throughput is healthy or not, to understand if your lead time variance is big or not, look. at. the. context.

#4 – Comparing metrics between teams

This problem is related to number 3. It doesn’t make any sense to say something like “team A is doing better than team B because they have a greater throughput”. What if team A has 10 people and team B has 3? What if team A is working in an easy website development while team B is working with complex deep learning stuff? Be careful.

#5 – Having individual metrics

This is a micromanaging problem. People, when trying to improve as much as possible the process, end up measuring individual metrics. This problem is related to #3 and #4. You cannot compare different people. Just don’t. If you do it, you’ll be harming your team’s environment and will even decrease their productivity. Moreover, the process’ metrics should be used to understand the health of the process.

#6 – Simplifying metrics reading too much

Still related to context, but now the numbers context. If you tell other people that a team delivers on average 4 stories a week, you are saying nothing. Maybe its delivery data is {0, 0, 0, 0, 0, 24}, maybe is {4, 4, 4, 4, 4, 4}. So, be sure that you are not simplifying your metrics reading. Make sure the whole toolset builds the image that you are trying to draw.

#7 – Using only the metrics you want

Related to the error before, sometimes we see people having to report their metrics to higher management showing only “good numbers”. So, if your throughput increases, you only show your throughput increase. If your backlog decreases, you just show that. Be transparent. Otherwise, they will be living a lie and, when the truth comes up, you won’t be able to explain yourself.

#8 – Using only the data you want

Another related problem is using metrics with only the data you want. Cropping your data to get only relevant results, like in a 10-month project consider only the last 2 months, may make sense since the context of the project changes with time and you wanna make sure you are getting the right context in your results. However, be very careful when doing that because you may actually hide a lot of useful information from yourself.

#9 – “Cooking” metrics

This is by far the most common thing I see. People are afraid of showing bottlenecks or problems and end up masking their results. People group stories into one to diminish their backlog, break stories into more to increase their throughput or even change story points to keep their velocity. With that, you are only fooling yourself and not improving your process.

#10 – Having metrics-based goals

This is a controversial topic. Metrics weren’t made to be goals. They were created to help the team understand the process and try to improve its flow. Metrics-related goals may put too much pressure on the team and have the opposite effect on them, making one metric reach the desired goal but affecting others. Therefore, before defining a metric-based goal, consider if it needs to be that “low-level” and, if it does, confirm with the team if it is actually possible to reach that goal or if there’s some process inherent impediment to it.

#11 – Trying to decrease lead time at all costs

Lead time (LT) is a metric used to understand how long an item takes to pass through your process. So, there are two different questions you can ask the data:

• Is the LT too big?
• Is the LT variance too big?

The second is often much more important to a team than the first. Having an LT distribution of {0, 5, 2, 8} is usually worse than having one like {4, 4, 4, 4}. That because, in the first, your data is not reliable enough to make predictions, while in the second you have a better probability of getting it right. However, don’t forget to look at your context.

#12 – Trying to increase throughput instead of being more efficacious

Being efficacious is doing the right thing. Throughput is not important if you are not doing the right thing. So, focus on your product, on what is best for it, before caring about how fast you will deliver it.

What do you think of these mistakes? Have you ever made one of them? Leave your comments below!

The post 12 Common mistakes when using Process Metrics 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.

Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

• How long will the story C stay in the same stage?
  • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
  • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
• What is the value story C will generate after being done?
  Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

• $ spent with initial development + $ spent with rest of the development < story C $ return
  • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
• If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!

Therefore, based on those, you can possibly do four things:

• Leave it on the column and restart it when its priority arrives
  The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.

• Take it back to the backlog, and restart it when its priority arrives
  The pause will be long and the card will need more refinement.

• Finish it first, before getting another card
  The card is almost done, and if you stop it, it will not generate value anymore.

• Cancel the card
  The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below

The post The user story in development was deprioritized, what now? first appeared on Plataformatec Blog.

Your product starts to get fancier, and your clients begin to subscribe… That is just amazing! However, your team is feeling a little unmotivated. You start participating on their retrospectives to check how you can help and you see a pattern: people are complaining, in other words, the Agile Specialist is micromanaging everyone.

You decide to closely follow the team during a month, investigating what are the things happening there that are discouraging them. Suddenly, you see yourself in a daily meeting, in which everyone talks about what they did and what they’ll do. Soon enough you spot the problem: they are using the daily meeting to report work instead of spreading knowledge and removing blocks. But what now? How to achieve those goals without the reporting feeling?

The feeling of a micromanaging daily ceremony always caught me while working in the industry as a developer. I always thought people wanted me to report what I was doing, with the intention of knowing exactly how efficient I was. That caused different kinds of behaviors, the most common was to do more things at once, to show I was working more.

However, doing more tasks at the same time might slow everything down, make your work less valuable and affect the rest of the team. More on that subject can be found in these blog posts:
* Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits
* The Hero Syndrome and how to deal with it

Therefore, to overcome that situation, we at Plataformatec started using a different approach in the daily meeting. We saw that the problem of the “old way” was that teams were focusing on what each person did instead of on the progress of the project itself. With that in mind, we just changed the focus. Instead of asking people what they did, we started asking cards.

No, we are not going mad (I guess)… And of course, we didn’t talk to a post-it either (even though talking to inanimate objects may help on development, like rubber ducks). However, we changed the way we asked things. Here is how we do it:

We go over the board, from right to left, asking the whole team how is each card’s development:

• How is its development? Any technical difficulties?
• Is there anything blocking its development?

You may say that it is not that different from what a usual Daily Meeting looks like. However, let me point out the differences and their importance:

• We look at the cards on the board, from right to left. By looking at the card further in the process, we are looking at the feature that will most likely bring value in the short term.

• The questions are directed to the team, not to a person. Asking the whole team about a card brings back the team sense that we lose asking individuals. It shows that we don’t care about who is working on it, and how much. We care about that project’s development.

• The questions’ subject is not “you” anymore, it is “it”. We used to ask things like “What have you done the past day? What are the blocks that you had?” etc. By changing the subject, you reinforce that the focus is on the feature development, and you also make the team talk only about what is important to the project, and not about peripheral topics.

• Extra: We simply look more at the board. Yes, that simple. You probably experienced that, with time, people start to not spend as much time as they did at the beginning of the project looking at the board. The simple fact that we are using it to run the ceremony, brings attention to it and we can easily spot when someone is overworking, when a card has been at the same column for too long or other related issues.

Conclusion

What we suggest here is not a big change, actually, is pretty subtle. Instead of focusing on what people did, focus on what is being developed. You’ll see great improvements in people’s feelings, everyone will be in touch with the process everyday through the board and, as the famous Lean quote states, people will stop starting tasks and start finishing them.

What do you think? Would you use this method? Leave your comments below!

The post Bringing continuous improvements into your agile process: A different Daily Meeting first appeared on Plataformatec Blog.

Esta ação é mais indicada antes de começar um projeto ou nas primeiras semanas de desenvolvimento, pois é quando normalmente há mais flexibilidade para mudanças de prazos.

Na nossa experiência, já vimos diversos motivos para uma definição de prazo imprópria em um projeto, no entanto a mais recorrente é a falta ou falha de comunicação entre o CTO e o CEO. Com isso, vamos focar em como melhorar essa comunicação para que seja possível alinhar as decisões de negócio com as decisões de tecnologia.

Sabe-se que a área de desenvolvimento de software segue processos que diferem não só do resto da indústria mas muitas vezes difere também das outras áreas na mesma empresa. A quantidade de incertezas são, geralmente, maiores e faz com que o tempo para terminar um projeto seja altamente variável mesmo quando, aparentemente, tenha natureza conhecida. E essa diferença precisa ser entendida por ambos CTO e CEO.

As causas desse desalinhamento podem ser:

1. Falta de comunicação quando decisões de negócio e tecnologia são tomadas. Essas duas decisões precisam estar em constante harmonia pois uma é o que impulsiona a outra.
2. Falta de priorização das demandas. Às vezes existem muitas features para serem desenvolvidas de uma vez, sem qualquer priorização. Isso faz com que o processo de desenvolvimento fique saturado e demore para dar vazão a toda essa demanda.
3. Conflito de mentalidade. Devido aos diferentes backgrounds dos envolvidos e, portanto, diferentes visões sobre a empresa, a relação entre CTO e CEO pode se tornar deficiente e conflitante. Isso impede a evolução do processo por não haver acordos.

Por mais que seja possível dar um manual com um passo-a-passo do que se deve fazer para melhorar essa relação, tudo se resumiria a uma ação: melhorar a comunicação.

Quando você se encontra em posições de alta responsabilidade, você precisa ter um entendimento maior dos seus pares e o trabalho que estes exercem para que consigam, juntos, traçar o futuro da empresa. Por isso, para melhorar a comunicação, é necessário entender melhor como funciona a tomada de decisões do CEO, quais são as estratégias da empresa para os próximos meses e anos e porque elas são importantes.

Com isso feito, é necessária a explicação de como um processo de desenvolvimento de software difere de outros processos, e como lidar com isso da melhor maneira possível. Com ambas as partes a par dos caminhos que precisam ser tomados, é possível alinhar prazos de modo mais fácil.

The post Definição de prazo em projetos de software first appeared on Plataformatec Blog.