Lean thinking comes from Toyota Systems. It is defined as elimination of all non-value-added activities, also called waste. Most people associate lean with factories and production processes, but lean can be used in many different parts of the organization. The goal of lean thinking is to find areas of waste and to permanently eliminate them. It connects directly with managing and continuously improving the organizational processes. But in order to identify the waste we need to understand what value is, and what activities in our process are necessary to create this value. Once this is understood, the identification of waste becomes easier.
Lean thinking can be applied to a business analysis process as well. It may be needed too. Research from the Standish Group states that 60 percent of features implemented in products is never used. This is waste, isn’t it? A part of this waste lies in requirements. Why produce requirements for something that will never be used? Does this situation sound familiar? As a business analyst you are confronted with many situations like that; for me it was checking myself and the process I had to follow as a business analyst for possible improvements. Sometimes you know that something needs to change, but you cannot get a grasp on what it actually is. Lean principles help you discover what the issue might be.
Lean recognises eight types of waste. An easy way to remember them is to use a mnemonic – TIM WOODS – where each letter represents one form of waste:
• T – Transport: Moving people, products and information
• I – Inventory: Storing parts, pieces and documentation ahead of requirements
• M – Motion: Bending, turning, reaching, lifting
• W – Waiting: For parts, information, instructions, equipment
• O – Overproduction: Making more than is IMMEDIATELY required
• O – Overprocessing: Tighter tolerances or higher grade materials than are necessary
• D – Defects: Rework, scrap, incorrect documentation
• S – Skills: Underutilising capabilities, delegating tasks with inadequate training
Waste of transport is related to the movement of people, products and information from one location to another. Transport adds no value to the product. Why would a customer (or you for that matter) want to pay for an operation that adds no value? In terms of business analysis passing a requirements document to a number of company officials with no clear goal, only because the process says so, is an example of transportation waste. Travelling to speak with your stakeholders about something small, when you could use the phone to get the answer, is transportation waste.
Inventory costs you money; every piece of product tied up in raw material, unfinished work or finished goods in a warehouse has a cost and until it is actually sold that cost is carried by you. This is waste. In business analysis the unfinished work – an abandoned requirements document or domain diagram nobody updates anymore, for example – is inventory waste. We can also think of a requirements document as waste. The requirements document without working SW is worth nothing. Producing requirements documents with lots of models and without transforming them into a product is an inventory. It is a partially done work. We don’t want too much of it.
Motion waste is related to unnecessary movements of man or machine which are not as small or as easy to achieve as possible. In terms of business analysis you may think about excessive distance between agile team members, who should work together, or working with offshoring or geographically dispersed teams. Offshoring agile teams may introduce this waste as well as working with them may introduce additional overheads. Quite often motion waste introduces waiting waste as well, because the performed task will take more time to complete. Motion waste is also related to seeking information. If you don’t know sufficiently well who your stakeholders are, so you are forced to do extra interviews with stakeholders you overlooked at the beginning of the project, is a form of motion waste. Also, think about bad review preparation where you call a stakeholder on many occasions for extra information that you just forgot to ask for during a meeting.
Waiting relates to delays due to waiting for an answer or availability. It can be waiting for a stakeholder’s input or waiting for a management decision. It can also mean that a development team has to wait for requirements because a business analyst wants to be sure requirements are complete. We should ask the question of whether we need these details in requirements; whether we need these requirements to be reviewed by 40 stakeholders. What value does this add to the development process? Do requirements need to be that perfect before the team can start working on them? Does the way we do business analysis stand in our way? Perhaps an agreement and setting out boundaries are sufficient to get the job done? When others wait, they are not doing activities that are adding value. And this is waste.
The waste of overproduction is making too much or too early. In other words it is violation of the “just in time”/“just enough” principle of agile. In business analysis it is about producing an extensive requirements document describing features stakeholders requested and not checking requirements’ feasibility. The feasibility check done later in the project may reduce the amount of requirements by 30%. This means that writing those infeasible requirements is waste. But overproduction also has another side. When a stakeholder requests that you change something during sprint execution and you agree to that, it is overproduction waste. You jeopardise the results of the team to accommodate additional needs. The stakeholder might think he can do it next time without consequences. Also, unproductive meetings or involving too many people into a problem or situation fall into this category of waste.
The waste of overprocessing is where inappropriate techniques are used, too much detail added or processes are performed that are not required by the customer. A frequent complaint about business analysts is that they provide too much or insufficient detail. If a business analyst provides a lot of details and already defines a solution, and then the development team might say that the prescribed solution is not okay, a discussion starts during which a proper solution gets defined. This is waste. Often people ask “How do I know what’s needed?” The answer is by asking the receiving party what they want from me as their business analyst. Define how you can add value to this process, the required level of detail, give it a try and ask for feedback about whether it works. By doing so you will discover how to work effectively together. Overprocessing waste is also organising too many reviews on a requirements document or as simple a thing of making notes on paper when you could do it on a word processor immediately.
This seems to be the most straightforward form of waste. Every defective item requires rework or replacement; it wastes resources such as people’s time and materials e.g. paper you used to unnecessarily print the documents for a review. In business analysis, every time the stakeholder does not understand what a business analyst has produced (either a requirement, diagram or similar) is a waste. Every time a diagram does not make sense, and the stakeholders of a team have to come back to the business analyst to check what he meant with his work, is a defect: the business analyst didn’t do just enough, just in time.
Underutilisation of people’s skills and knowledge is an additional waste form, which was adopted by lean. In our knowledge-based economy, effectively developing and applying intellectual capital is the key to creating value. This waste form expresses itself in not learning from each other, lack of involvement or participation by project members, or not knowing skills of others so not using them to the advantage of the project. As business analysts we suffer from this waste when we are involved in the politics of having to deal with stakeholders with short-term thinking. Sometimes you take part in it. Being aware of your environment, and putting effort in to discover and use other people’s skills and knowledge to the advantage of the problem you are trying to solve, are key here.
Being aware of waste forms can help us, as business analysts, to think critically about the process we follow and our role in it. It is never too late to change our practices, to make small adjustments here and there that allow us to become better in what we do. I must say it was quite confrontational for me in the beginning: to check myself and to dedicate some time explicitly to analysing how my practice contributes to adding value in the process. But it was worth doing. It made me aware of how I work and allowed me to improve for the good of my project team. If you want the same for yourself, check yourself against these different waste forms and start working today on your better, lean existence.