How Agile can help you to avoid the 7 Software Development Wastes?

How Agile can help you to avoid the 7 Software Development Wastes?

If you have been working in the Software Development industry, most likely, you have already heard about the 7 Software Development wastes. These issues appear in every product and project, so it is very important to tackle them using the right approach. The purpose of this article is to explain how smoothly you can avoid them using Agile concepts in your teams. So let's get started.

Waste #1: Undone Work. Definition: all tasks/ user stories that your team starts and do not finish. Simple like that. The question is: what is leading your team not to finish what they have started?

Agile in Action:

  • If your team is not completing it due to deprioritization, you should talk to your Product Owner and understand what is fostering him to change his mind during the Sprint. You can check what prioritization techniques he is using and help him to choose the best one for that product. It will help him to prepare better the product backlog and even manage the expectation and pressure towards to the stakeholders. 
  • If your team is not completing it due to the lack of capacity during the sprints, you can foster them to check out whether they are doing the refining session properly and if the items have a clear Definition of Ready and Done. At the same time, you can check out whether the team is collaborating with each other in order to accomplish the items in the sprint (have we been really cross-functional during the last sprint?)

Waste #2: Extra features. Definition: all features our team deliveries and are not or rarely used by our customers. This means we may be putting such an effort into something that did not have any value for our customers at that moment. This represents a waste for us.

Agile in Action:

  • We should explain to our Product Owner that every Feature, at the very beginning, is an Assumption that needs to be validated, and the best way to do it is testing it ASAP with our real customers. In this scenario, we can talk about MVP, POC, A/B Testing or even some Design Thinking strategies to understand if we should develop that feature in that way or not. As a result, we have got that it is worse to develop the feature wrongly than developing rightly the wrong feature.

Waste #3: Relearning. Definition: every time a team member needs to relearn how to solve a problem or how to edit a specific component, we are talking about some waste. The question in this situation is the following: What has been leading us to spend time to relearn it again

Agile in Action:

  • We can tackle it using Agile by adding more effort and attention in the Review Session; so the Developers can explain how they solved the challenges during the Sprint and also encourage them to keep our technical library (usually in confluence) updated.
  • We can also motivate the team members to ask for help whenever they know that issue happened in the past and someone in our team has already solved it (this will improve the team communication).

Waste #4: Handoff. Definition: this waste happens when a software engineer can not develop a full capability by himself, so he asks another developer to complete that feature. This usually happens to not full-stack developers, which means, some of them work in front-end and others on the back-end side of the item. It leads the team members to explain what needs to be finished, and this transfer generates some waste for our process. It also happens to full-stack developers when they need to start a new feature or project, but before it, he needs to get information from other people.   

Agile in Action:

  • As a cross-functional team, we should foster our team members to share learnings and be able to perform as many activities as we need in our sprint. It means, the more people know about our stack in our team, the more they can develop end-to-end features avoiding the hands-off. The Scrum Master should foster this knowledge transfer and explain some techniques to achieve it.
  • At the same time, a high performing team will always enjoy the refining and planning sessions (or even the daily meetings) to understand important points that will help them to perform a better development. In Agile and Scrum, the events are important for syncing and planing. Strong teams realize this situation and really enjoy these moments to maximize their development or execution time at the right moment.

Waste #5: Context Switch. Definition: before writing any line of code, it is necessary to understand what needs to be created and where we need to edit the stack (and how). Every time the developers start a new user story, they need to understand the code context prior to apply or create the changes. It means, if we constantly ask developers to change their activities due to the urgency or the new prioritization (for example), they will be investing more time understanding contexts rather than having enough time to apply the changes in the stack. This is definitely a waste for us.

Agile in Action:

  • As Scrum Masters, we need to educate people to respect the team’s work. That means, to guarantee the Product Owner (or even the Scrum Master) will not say how the developers need to work during the sprint, for example, pushing the order of activities or when they should start a new one.
  • And among the team, people should also respect when other developers are concentrated. If we keep stopping people with doubts or questions during introspective/analysis moments, they will be constantly “loading context” and will not have enough time to execute or create the change during the sprint. 

Waste #6: Delays. Definition: Everything that increases the time of the flow and does not add value to our customer. It can be time spent with a feature that will be rarely used by our customers, or it can be hands-off time among team members or even stakeholders changing their minds before enabling an MVP in production.   

Agile in Action:

  • As Scrum Masters, we need to understand the areas where delays could happen and mitigate them by mentoring the teams on how to avoid it. Some of the delays can be avoided by a proper Definition of Ready; good communication and sync among team members or even with a good dependency mapping.

Waste #7: Defects. Definition: not expected behaviors of the delivered software that affects, on different levels, the main purpose of it. Usually, defects bring hard times to teams as they are associated with financial loss, unhappy customers and compromised service offers.  

Agile in Action:

  • Bugs or Defects represent flaws in our Engineering Process during the sprint. They make clear that, as a Team, we missed validation points of even communication opportunities in order to guarantee a good level of quality to our customers. As Agile Coaches, we need to encourage teams to have a clear definition of what Done means; what kind of tests and development environments we should have in place and also what kind of technology we can use to support this area, for example, CI/CD Pipelines, automated builds, and tests.
  • We need to introduce all of these techniques to the teams and foster them to use part of their time to really set up and take advantage of it. In a practical way, every time we are solving bugs, we are not generating value, but only paying a debt in production. So avoid bugs is much better (and cheaper) than solving them.

I hope you really enjoyed all these tips. I will be very happy if it helps you to keep improving your teams to avoid wastes. Please, let me know how it goes and your feedback in the comments. 

Peace and Hugs for all.

Eduardo Rodrigues Sucena. Passionate Enterprise Agile Coach in the Dubai area.

It includes very good examples to keep your project agile.

Russell P.

Global Executive | Technology-Driven Firms ~ Business Development ~ Customer Success ~ Partnerships & Alliances ~ P&L Leadership ~ Startups ~ IT Staffing & Outsourcing

5 年

The most important thing is for the business analyst to understand the workflows to be incorporated / customized and features required by the actual users of the system.? The end users representative must be involved right from the initial requirement study stage. Lot of projects fail at the UAT stage as the system developed doesn't meet the? actual users requirements and as rightly mentioned in the above article, some features developed may be of no use to the end user. If the intended users of the system don't see it as a tool to enhance their productivity and ease their job, the entire project is a failure, period...

Absar K.

Innovating with technology, transforming with agility, empowering with empathy.

5 年

Interesting Eduardo, covers more or less overall ideas of Agility! :-)

要查看或添加评论,请登录

社区洞察

其他会员也浏览了