this is the second article about Value flow – last time I gave a short introduction in Value Stream Mapping.
With Value stream mapping you can find obstructions to your value flow and then work on them one by one until the value flow improves.
But one question that you might have had when reading the last blog is still open.
What is value in software development?
For some companies value is easily defined by their total turnover per year. The higher the better.
So everything that generates revenue is value.
Then there are different companies. I’m reading the book “The Toyota Way” right now.
Kiichiro Toyoda the founder of Toyota Motors Company once said to his son:
“Everyone should tackle some great project at least once in their life. I devoted most of my life to inventing new kinds of looms. Now it is your turn. You should make an effort to complete something that will benefit society”.
That is one of the value principles in Toyota. Everything that they do is not oriented at total profit but should also benefit the society that we live in.
Certainly there are different philosophies depending on the company but one thing is common to all of them.
Value is defined by the customers that pay for products. Only when customers like a product they will pay for it. So this defines value as:
The properties or factors of a product that a customer is willing to pay for.
For the further discussion let’s call the customers that in the end pay for a product: end customers
As software development especially in enterprise environments is normally no simple task but requires some advanced engineering skills you more then often have several steps that you need to undertake to create the “final product”.
This is why it’s also normal to have “internal customers” inside a product development chain.
If you have a “test at the end” strategy for example your Quality Assurance department would be a customer of your development department or maybe of your build & deployment department.
So for the following discussion about waste in software development we distinguish between internal customers and the end customer.
Wastes in Software development
The following wastes are also taken out of The Toyota Way, but I try to translate it to the world of software since making a car is not exactly the same as software development.
- Overproduction – parts of your product that haven’t been ordered by your customer. In software development often generic classes or “building for the future to be flexible”. Most often it means to make things more complicated than they really need to be. “Gold Plating” would also be considered overproduction
- Waiting – The tester waiting for the developer to end the implementation part so that he or she can finally start the (manual) testing. The developer that waits for the build pipeline to finally give feedback if the automated tests were broken or not. The team that waits for the PO to decide that important decision so they can start using the new tool.
- Unnecessary transport or conveyance – Having to move the needed material long distances. In software development this is needed information. And the fastest way of getting to this information is if the team is collocated and sits together with their respective PO. Any form of “EMail, telephone, walking over to the next building” can be considered as unnecessary transport.
- Overprocessing or incorrect processing – Doing extra work or processes due to usage of bad tools or poor product design (architecture) often causing unnecessary motion and producing defects. Waste is when your product is higher quality than it actually needs to be.
- Excess inventory – too high WIP (work in progress) which causes delays and in the end leads to a hiding of the problems because problems often only surface after they reach the end customer. In software development the most typical form of excess inventory is working on too many projects in parallel.
- Unnecessary movement – all extra movements that a worker has to to at the production line such as walking and longing for tools. In software development I’d consider every extra step during the normal work e.g. filling out form xy before checking in to source control or clicking 4 times with your mouse in the UI instead of just using keyboard shortcut “cmd + alt + p” as unecessary movement.
- Defects – Finding bugs, rework and fixing of the bugs, extra releases or patches that need to be shipped together with all accompanied extra work
- Unused employee creativity – By far the worst waste in my eyes. Most often ingenious middle managers which are 10 years out of development decide on environment and tools for their development teams instead of delegating these important decisions to them.
Not listening to the improvement ideas of the employees and not providing an environment of learning and continuous improvement. In many companies employees even have to beg to get books paid for self studies.
Now what does this all have to do with Value Stream Mapping?
You know how to create a Value Stream Map. You learned it in how to create a Value Stream Map.
But what do you do with it?
How can you read a Value Stream Map?
Do you remember the Value Stream Map from last example?
What you would start with in your analysis of the Value Stream Map (VSM) is the biggest waiting phase. Then you can use the list of the different wastes from the previous chapter to categorize where the problem is coming from.
When doing this always consider the internal customer as the next step that is following.
For example a developer would be an internal customer of Analysis and Prio and the value he or she needs to have is the priority of what to do first. Just the information not a fancy System, it could even be post-its.
In the example above you’re kind of building piles of “excess inventory” (fixed bugs) that has to wait for a release to be scheduled and deployed. Also this long time of waiting will hide if a bug really has been fixed, since the customer could have a similar problem but not exactly the same thus creating some defects in itself.
You can start your root cause analysis with asking “Why” 5 times:
- Why do we only release every 3 months?
Because it takes us 2 weeks to do a full regression test
- Why does it take us 2 full weeks to do a full regression?
Most of the tests that are done in a regression are done manually and we only have limited resources to do the tests
- Why do we have so many manual tests?
Our skills in writing automated tests are lacking and we couldn’t create automated tests for our legacy code base
- Why couldn’t we create enough automated tests for our legacy code base?
We’re asking for the time to do it for several months now but we’re always under pressure to deliver the next release
- Why are you under constant pressure to deliver the next release?
Between releases we would need some time to “wrap up” and refactor some of the things we had to do for the previous release, but since we’re not given that time we’re working extra hours to get things done in time
From there choose one of the things that you want to work on.
Then you go into the Deming Cycle that you might remember from last post.
Plan – Hypothesis: “With one sprint after a release to wrap up and refactor we would be able to take care of tests for our legacy code base to shorten the time for regression tests by automating manual tests.”
Do – run one sprint after a release with the measures that you deem necessary
Check – compare how much time you saved by automating regression tests compared to doing them manually
Act – if you achieved the anticipated results then consider adding a sprint for working on refactoring and dealing with legacy code to your release planning (standardizing it)
From here on it’s on you.
What are the WASTES that hinder you the most? Identify them using Value Stream Mapping.
How would you start working on them by doing a root cause analysis and then use the Deming Cycle to improve and standardize your findings?
If you used this method please share some of your findings with us so we can all learn from it.
Thank you for reading this lengthy post 🙂