A look at non-obvious wastes and “needed” wastes in software development

Waste reduction and elimination is a well-known process in lean implementation. PM Power’s latest book “A Practitioner’s Guide to Enterprise Agility” ( https://www.pm-powerconsulting.com/a-practitioners-guide-to-enterprise-agility/ ) examines this practice and its application in a customer context.

Toyota’s Production System (TPS) pioneered this concept as part of their lean manufacturing process. The one thing they did was to look at their manufacturing process from a customer perspective. The key aspect considered was the value delivered to the customer – whether internal or external – at every step in the process and retaining only value-adding steps at every stage, eliminating the non-value-adding steps along the way, as needed.

When we look at a software development life cycle, there are obvious non-value-adding activities that you will be familiar with, such as:

  • Re-work due to defects discovered while testing the product
  • Waiting time between activities – such as waiting for requirements or design or prototype approval by the customer or a concerned stakeholder
  • Dependencies (both internal and external) that cause delays
  • Staff attrition – that leads to loss of knowledge, new member induction/ramping up efforts etc.

In addition to the above, consider the following situations:

  1. Individuals in your team work on two (or more) stories in a sprint to complete their goals. They are working on them in parallel. In addition, they are also responsible for fixing defects that come from final testing and provide support for customer-reported issues, as needed.
  2. Your developers are trying to fix defects on an existing product during their sprint and find that defect fixing is very time-consuming due to the complexity of the code they are dealing with
  3. Your customer asks for a new feature that involves changes to the design of the product. Given the complexity of your product design, this involves a fairly significant effort and schedule for implementation

In the first situation above, multi-tasking by individuals leads to frequent context switching, which, in turn, leads to a loss of productivity. In the other two situations, the code and design complexity lead to extra effort every time you are making a change. With a simpler product design and low code complexity, that do not compromise on product goals, substantial efforts could have been saved. All these three are examples of situations where the waste involved is less obvious. You could also think of a similar situation where developers start gold-plating requirements as they are implementing code.

Let’s look at a few different examples:

  • Requirements and design for features that take a long time to implement – so by the time some features are implemented, they are no longer relevant to the user or suitable for optimal product performance
  • The team is stuck with a manager who is very demanding and task-oriented and does not know how to motivate or guide them for performance
  • There are too many silos in the organization – which contribute to poor cross-team and cross-functional working. This, in turn, delays the delivery of value to the customer

These, again, are examples of wastes that are not obvious at first, but need to be eliminated or minimized if customer value delivery is a paramount consideration for the organization.

Having looked at obvious and non-obvious wastes, let us look at a few examples of “wastes” that are not so bad. And these, in a sense, are needed to deliver timely value to the customer.

  1. The product team is working in an agile mode, delivering features incrementally to their customers. Teams work in two to four-week sprints to deliver potentially shippable product increments. As part of every sprint, engineers who do the testing run tests that not only test features delivered in the current sprint but also run tests to ensure the earlier delivered functionality does not break. As a result, number of tests needed to run is growing significantly with every sprint.
  • The Product Management team is in constant touch with the market and customers. The product needs identified are changing very frequently due to market and competition landscape and dynamics. Here again, if the team is working in an agile mode, to adapt to changing needs, the team will use (re-)prioritization and (re-)planning on an on-going basis to ensure the highest value gets delivered to the customer at any point in time.

If you look at the above two situations, there may be extra effort involved that seems like “waste” for most people. The questions from many engineering teams are often on why requirements cannot be clearly stated and finalized in the beginning and again on why testing cannot be reduced to just one or two cycles in the end, when the product is fully ready for testing. If you end up doing these, you are more likely to deliver a product that does not provide value to the customer when they need it. Which, in turn, leads to some of the non-obvious wastes we discussed before.

So, what are some things you can do to avoid non-obvious wastes and promote needed “wastes” – and in the process deliver higher customer value?

  1. Getting the team to be “agile” and adaptive to the changing needs of the customer on an on-going basis. Ensure planning and implementation processes are aligned for being adaptive to changing needs. These have a lot to do with the culture and mindset of the people involved in delivery.
  2. Promoting effective cross-functional and collaborative working between teams and functions involved in delivery, and improve motivation levels in teams. The leadership team at various levels has a huge role to play in facilitating this process.
  3. Automating your testing as much as possible – especially regression testing and testing of frequently used functionality, as well as, non-functional testing. This could be a progressive exercise over several iterations/releases of a product and not necessarily a one-time exercise
  4. Re-factoring designs and code – to constantly reduce complexity and improve maintainability
  5. Use of Lean principles and techniques such as Value Stream Mapping (VSM) to identify potential wastes and address them

You may have many more things to add to this list and we would love to hear from you on that.

What do you think?

Leave a Reply

What to read next