The act of Software Development essentially produces two things, value and waste. Value can be rather vague when you don't understand the context. According to +Gerald Weinberg, Quality is value to some person. +James Bach then extended that definition to, Quality is value to some person that matters. That is the value that this talk was referring to.
For any software development group to be successful, value should be maximized and waste should be minimized.
According to Lean manufacturing concepts, there are seven types of waste:
Overproduction is essentially creating features that has no users. This is waste because no one is willing to exchange something valuable for something that you've built.
As an example of overproduction as waste: In the past few months, I've assumed a role as a product owner of an in-house automation tool that my team uses. When we started, we had limited information on how this tool will be used so we built in "generic" features. As time progressed, we noticed that out of a total of 200 or so functionalities that we've baked into this tool, only a handful of them are being used.
The next type of waste, Waiting, is technically the amount of time that is spent by tickets/issues/requests while waiting for someone work on them. Another type of waste is unnecessary context-switching. In this case, time is also being spent when a developer is forced to switch between contexts when trying to fix a feature that the developer was working on in the past. Testing and Programming needs to be tightly coupled in order to minimize this particular waste.
Transport is waste when it comes to movement. This is usually defined as your delivery flow. How long does it take you to deliver an idea into a stable and usable feature in the hands of your customers? How long is your build-measure-learn loop?
Inappropriate Processing is waste as a result of bad design which forces extra activity. An example for this would be investing in a record-playback tool as a long-term investment. In the long run, maintenance can be a nightmare. Just because something is cool and new, it doesn't mean we should adopt it. Another example would be when you are developing a metrics program where nobody ever uses the information from those metrics in order to make a decision.
Excessive Inventory is waste when we produce more than the demand. In software, this can be reflected in over subscribing third party services without effectively measuring what you need. Most of this waste is usually shown as a knee jerk reaction to scaling. Bloated servers that are only used at 10% capacity even at maximum peak, or over subscribing to maintenance support costs. The one example that Thomas pointed out were Unreleased Features. You have to understand that your context is changing, your consumers preferences are changing. Every day a feature is not in production, devalues the feature to a point of uselessness.
Unnecessary Motion is when you are doing more than what you need to. In software development, this waste happens when you are misusing your resources and people. Is your company asking people to do the things that they are not good at? i.e. asking testers to focus on documentation rather than test design. What are your testers and developers doing? is there unnecessary friction? are there repetitive manual steps to get a build to an environment?
Personally, I think Defects are the mother of all wastes. If you don't fix an issue right away where multiple modules are dependent on, and you release that to your customers, fixing all downstream dependencies tend to take longer because you are not only fixing one thing, but everything else that's dependent on it. Imagine that waste in an iOS app submission workflow.
When software developers have appropriate detection tools, some defects can be instantly fixed provided you don't ignore the warning. For example, your IDE can give you instantaneous feedback if you missed a semi-colon when writing javascript code. Of course, static analysis or these sophisticated IDE's can't catch everything. There's a need for redundant ways to check for problems brought about by new changes and these ways should all include properly thought of test design.
As a part of the leadership team in my software development group we've been looking at how to minimize waste in our current processes. The good thing is that my company doesn't think of testing as waste. I would readily admit that there are things that our testing team is doing that seem wasteful. Writing acceptance criteria and automation of testing scenarios that somehow doesn't make it to production is waste, or atomically testing feature details that doesn't necessarily bring value back to the customer.
Not everything in the development process has return value. There are also wasteful activities done by programmers. Code comments don't inherently provide value to the customer, or maybe even documentation since not all documentation are created equal. Creating a tag that doesn't get released can also be considered as waste.
The fact of the matter is that waste is an inherent byproduct of creation. Our goal is not to eliminate, but to minimize.
Do you look at testing is part of your waste reduction efforts or is your approach to testing producing more waste?
Note: This post is based on one of the sessions that I attended during CAST by Thomas Vaniotis about The Context-Driven Tester in a Lean Startup.
No comments:
Post a Comment