The 7 wastes of Contemporary Agile Software Development Teams

This is a summary of my presentation at Ágiles 2021 for those who weren’t there and don’t want to watch a 40’ video.

I learned about the meaning of waste from Mary Poppendieck back in 2008, when she came for the 1st Ágiles conference. When I found out that Mary was coming to this Ágiles conference again, I started thinking about the wastes I see more frequently in Contemporary Agile software development teams.

I will try to describe the particular situations in which I saw the wastes in the best possible way. It’s difficult and very particular. However, I want to see if it rings any bells with similar things on your teams. If you don’t remember the wastes, I suggest you read this post so that you have them fresh in your mind.

1. Base our Agility in Agile Management Tools

I have been using Jira and other tools for many years. I believe they provide value in many contexts. However, in others it doesn’t. And lately, I have become a bit uncomfortable with the importance Jira acquired for many Agile teams. In some cases, it seems we have to use it to be Agile. Let me tell you a story. Not long ago, I was working with a team in which we did a Product Discovery using Miro. We created a lot of really useful and visual information. When we felt comfortable to start our delivery, I started thinking if we needed to ‘transport’ (waste, remember?) the stories to Jira. I had the impression that it wasn’t necessary because we could add a Kanban board to manage the tickets pointing to the images, diagrams and maps we had inside Miro. The waste in copying this information to a medium where all this information looks worse (visually) wasn’t worth it in my opinion.

2. Build experiments that are too big

Has it happened to you that you build an MVP to discover that very few users actually use it? Or add a complex feature only to realize that it doesn’t add any value to the current users? It certainly has happened to me. There’s a question you should always ask yourself before starting any experiment: How much money would you be willing to spend? The answer depends on the uncertainty. The higher the uncertainty (the risk), the cheaper the experiments should be. In spite of this, I realize many times we end up doing big experiments (overproduction, remember?) for the incorrect reasons: we have the money, there’s a good team that can deliver it, we have a lot of faith, etc. It’s safer and more cost effective to do a sequence of smaller experiments. My advice: Be wary of overproduction! Expedite the build, learn and validate cycle! Be careful of building big experiments when there’s too much risk.

3. Technical Quality when doing Discovery

I saw this tweet and this post while I was thinking about the waste generated by adding too much technical quality in the early stages of discovery. There’s always the question of how much technical quality is worth at a particular moment in the life of a product. Some people reckon you should always build something of great quality. Some others don’t care, even when it’s a consolidated, viable product where new features are added continuously. As in the previous point, the amount of technical quality is related to the degree of uncertainty, to how much you are willing to pay and to the chances that this codebase keeps growing. For the 1st experiments, when we need to elucidate if this product actually solves real user problems who are willing to pay, it might not be worth spending so much money on the robustness of the code as this could be waste (overproduction again). If things go well and the business uncertainties decrease, we might have to think about the technical side and pay the acquired technical debt. I know this kind of waste is really controversial. As good engineers, we always want to do things in the best possible way. I also know that if you have this in mind, then the next question would be: when is the moment that we think we must work on the technical side of the product? This question is part of the many trade off decisions product teams need to make.

4. Lack of Technical Quality when doing Delivery

As I’ve seen too much technical quality in Discovery, I’ve seen teams doing Scrum with no automated testing strategy, no continuous integration and no time for refactoring. Teams rushing through sprints to build a very big MVP with no technical quality. The waste in this situation is a combination of overproduction and defects. Keep adding functionality this way is not sustainable. There’s waste in the extra effort/cost to add more functionality. I don’t want to repeat something that everyone says all the time but doing Scrum with no technical quality creates an enormous amount of waste.

5. Switch from Discovery mode to Delivery mode too early

As it has happened to me to build an MVP or feature that nobody uses, it also has happened to build something that is not viable, that can’t be used (for technical or legal reasons). What happened? We knew there were too many uncertainties doing the Discovery, but we took the leap of faith anyway. We started working with the hope that those uncertainties would disappear as we learned. But they didn’t, and we ended up with software that couldn’t be used (partially done work). In hindsight, I realized that we started working too fast, we switched from discovery mode to delivery too early. We should have removed those uncertainties before committing to delivering it. Iterative and incremental development enables you to start with uncertainties still existing. However, sometimes it is not worth it.

6. Pull Requests opened for a long time

I’m sure this happens to many of us. We see pull requests that remain open for 1, 2, 3 days, even a week. Of course, this brings more work as we need to keep bringing the changes from the main branch. Why do we have this delay? There may be multiple reasons that vary from human reasons (developers not doing the reviews or blocking the PRs) to technical reasons (unavailability of environments). This apparently easy to eliminate waste is really common among many Agile teams. We have had many conversations during many retrospectives which had led to slight improvements, but the delays persisted. One thing that caught my attention during Nico Paez talk in Ágiles is that if this happens, we are not doing continuous integration. Bear in mind the impact that this may have on other XP practices and the impact it has on the cycle time.

7. Develop solutions without understanding problems

Last but not least, the worst source of waste in Contemporary Agile teams. Teams that build features from a Backlog, without participating in the Discovery, without understanding the problems, the users and the desired outcomes. There’s great waste when solutions are designed only by business members because a very important perspective is missing: the technical, the feasibility of the solution. I wasn’t sure in which category I should put this type of waste. Talking to a few colleagues, we concluded that it could be mapped to extra features, as the designs lacked the technical details and were made without knowing if this is the best solution.

That’s it. These are the 7 most important wastes in Agile software development teams nowadays. Of course, the number is arbitrary (nobody will ask why 7, right?). I hope I was able to describe them clearly in this post (and in the talk!). If I wasn’t or these wastes don’t ring any bells, try to identify yours. Make your methodology lighter, “barely sufficient” as Jim Highsmith told us. This was the objective of the talk (and this post).