TMap was modernized for several reasons. One of them is to embrace Agile. In my opinion, and I know not everyone will agree, Agile is the umbrella term for all kind of short-cycled ICT-development, including DevOps and Continuous 'Anything', while Agile, as I see it, is based on Lean principles applied to software development.
In this column I will outline the consistency between Lean, Agile and TMap HD.
First of all, let me admit that there is an important difference between Lean, as we know it from industry, and Agile. Agile is, on the one hand, a reaction to unwieldy projects: 70% not in time, not within budget, not delivering what was promised, and 70% of the predefined functionality is never used. Apparently we are poor predictors. On the other hand agile is an answer to the need to react faster in our disruptive, fast changing world. Entire companies have to become agile, not only IT. Lean in industry is more efficiency driven. Both are quality driven, because if you don’t have the time to do it right the first time, you wouldn’t have time afterwards to fix it. Let me remind you, in Lean, fixing errors afterwards is waste.
Quality has to be build-in and cannot be tested in afterwards. This statement seems to be introduced in TMap HD, but in fact it is an old Lean statement and can already be found in the first (blue) TMap book. As I understood from the founders, TMap is the application of Lean principles to software development in the 90’s, as a reaction on the entry of Lean in Europe, in the 80’s. The history of Lean shows that testing afterwards can be eliminated. Agile is a step in that direction.
So, yes, there are differences between Agile and Lean, but also many similarities. I will explain this based on the five steps to create a lean organization and culture.
1. CUSTOMER VALUE
It all starts by defining customer value. This value statement guides all following choices. A typical Lean company, like Scania, defines it as “offering transport solutions to our customers”, which is not the same as selling trucks. In Agile customer value is defined as “working software”. Primarily as potential working software with the focus on development, but real working software is fully operational software, so DevOps, continuous delivery etc is a logical next step to real value.
In TMap HD it is addressed in the element Confidence, as test will demonstrate the value. That gives a shift in focus and purpose of final testing: from finding errors to demonstrating value.
2. VALUE CHAIN
The second step is to determine the value chain: the end-to-end process that lead to customer value, from raw material to final product. In case of milk: from grass to glass. In case of ICT: from idea to working IT. Part of this step is the elimination of waste. Lean is well-known for this part. In my opinion that part is often misused for sub-optimization. In administrative companies, like insurance firms, it leads to fully fixed work instructions, set in stone. Not very agile.
Waste is definied as “everything not contributing to customer value”, so without the first step, it is impossible to determine waste.
In Agile the end-to-end process starts in “the business” (users and other direct stakeholders), is expressed in user stories, and ends in working software. Waste is eliminated by shortening the chain, leaving out documentation stacks (global design, detail design, etc), valuing direct communication.
In TMap HD this step is addressed by two of its basic elements: Simplify: only testactivities that really contribute to customer value. Integrate: from independent testing to integrated testing. Cooperate in and with the team, work T-shaped.
3. PULL
The third step is the change from push to pull. The essence of a pull system is to limit the work in progress. In waterfall projects all work is first architectured, then all work is designed, than all work is build, then all work is tested. In an Agile environment only one userstory is designed, build and tested. And only when it is done, the next user story is started. The work in progress is limited to one user story per team member. That shortens the value chain, making is possible to build the most valuable stories first and to work short-cycled, making the system more agile. I combine this step with the next step.
4. FLOW
Creating flow is the fourth step that introduces cadence, a heartbeat. In a pull system it is possible to organize all work by creating mechanism, automatisms that reduce the failure rate fundamentally. If you do something for the first time you have to consider every step you take. By creating flow, you create regular returning activities that can be “automated”.
The Agile manifesto explicitly mentions cadence. In Agile there is a flow of ‘sprints’. Especially in Scrum there are many flow-elements. Daily standup and a cadence of sprintplanning, daily standups, demo, retro. A sprint of 2-4 weeks appears to be a period that is short enough to oversee, to minimize risks to eliminate the need for a specific risk management process and to make a reliable planning. It is long enough to minimize the effect of overhead activities (waste) during sprint changeovers. By choosing fixed moments for stand-ups you eliminate the need to organize meetings over and again, etc.
In TMap HD this step is addressed by the element Industrialize. Industrialize is more than using tools to automate tests. It is also standardizing your way of working. Tooling is the final step in standardizing processes, methods, techniques etc. In testing there are hundreds of test techniques, types, levels, phases, stages etc. that can be simplified and automated.
The need for chain testing can be reduced by standardization of interfaces. As long as an interface isn’t changed, there is no need to (re)test the whole chain.
Design for testability can add functionality to simplify testing, e.g. to set the “thing”_under_test in a specific state with one command. And many other measures are imaginable to reduce costly chain- and other tests afterwards.
5. CONTINUOUS IMPROVEMENT
The last step is to repeat all above steps regularly to improve continuously. Always in pursuit of perfection. Toyota, who invented Lean, is improving since world war 2 and state that, even after 70 years, there is still at least 30% potential for improvement. The fact that Toyota has the most recall actions, is partly because Toyota has a focus on customer value and embraces a culture where recall actions are no loss of face. And many recall actions are related to software issues. Software is apparently a relative young and immature component of a car, with quality issues. Apperently, compared to other car-components, the current way of testing software (afterwards) has a bad coverage, resulting in insufficient confidence.
In TMap HD the elements People (denoting culture and attitude) and Confidence address this Lean step. Every error found afterwards is an indication that the process is not fully under control and should be improved. In such cases Lean will analyze the root cause and take measures to ensure that such errors can never happen again. That should be the extended role of a tester: no longer independent design of tests, parallel to the development, but integral participating in the development, monitoring every step in the development process, testing every decision while it is made. Focussing on prevention, test driven, design for testability. To quote a respected colleague: “Test is a quality measure, but not the only one and certainly not the best one”.
So, TMap HD is consistent with from the current emergence of Agile and explainable from a Lean perspective. I expect that Agile will play a significant and permanent role in the development of systems. Not for everything, but structural, improving and maturing. And it will definitely change the role and nature of testing and the tester.
Published: 21 July 2017
Author: Aldert Boersma
