For tailored clothes we take measurements. The model is chosen based on the body type of the person. When picking a color the complexion is taken into account. And last, but not least, the clothes are fitted before completed.
When it comes to processes we often ask for a copy of the suit. In his paper “Standing on the shoulders of giants” Goldratt states “What we have to bear in mind is that the application makes assumptions (sometimes hidden assumptions) about the environment. We should not expect an application to work in environments for which its assumptions are not valid. We can save a lot of effort and frustration if we bother to explicitly verbalize these assumptions.” This is from a discussion on the Toyota Production System. Other companies tried to copy it, but never did as well as Toyota.
Toyota Production System is like the suit. Making the assumptions explicit is as having measurements added to prefabricated items of clothing. But you can only get the best results with something carefully tailored. That is why I think that learning how to evolve an organisation and its processes is far more important than adapting the correct pattern or method. Get your organisation “tailor-skills”, practise measuring and fitting.
An organisation can use retrospectives, system wide measurements and the “thinking processes” that Goldratt developed as measuring tape and a dressmakers ruler. By looking at what others do we can get a starting point, a base pattern for a cut we like. But just copying what someone else is doing will never bring excellence.
Just as a piece of clothing will always look best on the person it is tailored for, only the organisation that invented a method can get the most out of it. So get the skills to tailor your own organisational model!
ps. When your body changes a tailor can help with altering the clothes. An organisation with skills for adapting processes is prepared for change.
]]>That is a bold statement and it comes from recognising three different levels of limitations to our productivity.
In 1956 the cost of 30 hours of console time was the same as for a full year of a software engineer. That has shaped our entire industry since then. In Production of large computer programs Benington describes one of the first software projects big enough to need a team. At this time the limitations in hardware defined how we wrote our software.
Some methods presented are very modern at their core. Benington describes both predefined tests for small units of code, parameter tests — today unit tests, and tests for the entire system, assembly tests — today system tests. To automate them and run them for every change of the code was financially impossible. Instead every test is clearly documented, not only to enable retesting but also to improve test design. The parameter tests were defined for every combination of inputs and outputs before starting to code.
In other words, a programmer must prove that he satisfied his specifications, not that his program will perform as coded.
(Actually, test specifications for one subprogram can be prepared in parallel with the coding.)– Benington in Production of large computer programs
You could stretch it so far as calling it Test Driven Development in spirit. Benington also describes the seed of our modern Integrated Development Environments (IDEs). The paper states about their development tools that its present size 40,000 machine instructions is indicative of the importance attached to its role. It really hit me how limiting it was to not have access to processing power when developing software in 1956. They knew what they needed, but the hard limitation in the technical tools made them take compensatory actions instead, like having designated teams for testing and operations.
In his Theory of Constraints Goldratt explains that we can not gain advantage from a technical advancement before we get rid of the compensatory actions we took to manage without it. I illustrate it with a story about a Sunday steak and a pot. The steak got its end cut off before it was put in the pot, since the recipe originated from an ancestor with a pot so small that no steak would fit without trimming it first. This waste was discovered first as one of the children asked the grandmother the magic word “why?” and the origin was uncovered. The limitations originating in our old compensatory actions can be tricky. How do we know what things that used to enable us, actually hinder us today? We need to find and discard them before we can benefit from new and better ways of working.
When we rid ourselves of old ways of working, no longer needed with new tools, how do we gain proficiency in the new technology? Not everything has such an intuitive interface as a slightly larger pot. I use IDEs that the developers in 1956 could only dream of, but they are only useful if you learn what they can do. Modern version control systems create an opportunity for collaboration that turns silos into networks and enable us to explore and experiment in a way not possible before, if we know how to. Test driving software for evolutionary design is a skill needed, now that developers can be trusted with using a computer. So is continuous delivery a capability required as software changes faster for longer, now that updates are no longer delivered with a person traveling to install it for you.
Developers need to utilise the technical advances we have made since 1956. For a long time we have stuck with the practises Benington and others developed to survive in an era where computing was extremely expensive. Instead of holding on to processes they adapted out of necessity, I want us to look at the dream that shines through the lines in that paper. There I see test driven development, continuous delivery, static code checking, code in high level languages that is easy to read and then optimised by compilers, powerful IDEs and a lot more that we have today. This generation has the tools to get all the smart people working together on hard problems, while letting the computers do the boring repetitive stuff. But the DORA’s devops report shows that far from everyone make use of the technical advancements. I believe that all the listed limitations have a hand in that. The world needs better software, and I somehow feel that I owe it to those who walked before me to use the tools I have, but they only dreamed of.
To recap, look around you and see if you spot the same limitations as I do:
Next time your are frustrated over your working environment consider where we are and how we got here. There is a lot of prestige related to proficiency in the software industry. We can’t keep the old limitations just to avoid admitting our need to learn new skills. Instead, take an action to change it for the better. Remove something compensatory that is not longer needed, or learn a new skill to leverage the tools available. No individual developer is to blame that it ended up like this. We need support each other to get out of it.
A version of this text was previously published on LinkedIn.
]]>Objective is a thing presented clearly to the mind. Sub in subjective is the same sub as in submarine and subterfuge. In the subjective, there is something hidden. Something is present beneath what we see. It can be called context or a person’s world view. The problem is that it is not explicitly stated.
When we try to solve a problem, or adapt to the present situation in some other way, it is important to know what is really there. In NVC there is an unfulfilled need that might be hard to state explicitly if we are allowed to be subjective or even judging. In TOC we need to find a conflict that can be challenged or a false dichotomy. That might be hard if causes and effects are hidden in assumptions. Mindfulness is the practise of seeing things as they are so that they lose their power over you. Things hidden beneath the subjective are hard to see. In acceptance therapy we have mindfulness, but also acceptance through acting. We can not act correctly if we do not know, and accept, what is going on.
So trying to fix a problem that is described in subjective terms is like debugging a system we have no access to. The best we can do is to guess, and perhaps restart a server.
If we learn to break down the subjective statement into objective statements, by making the implicit explicit, we can finally see the entire puzzle we are trying to solve. When figuring out what to do, we need all the information on the table. That is why subjective statements are dangerous, they hide information from us.
]]>Theory of Constraints (TOC), created by Goldratt, has a thinking process called a Current Reality Tree. It is build to figure out the root problem in a system. It is about gathering information and then question assumptions to find a really good solution. TOC is used, among others, to optimise production and increase sales.
The two frameworks might seem to have very different purposes and target groups. NVC is about people and communication. TOC is about money and logic. To me that is a false dichotomy. As I learn more about both TOC and NVC I see a lot of similarities. Empathy driven development shows that empathy is a technical skill. The parallels between NVC and TOC that I list below is in agreement with that. Hopefully that can make both communication and logic feel more accessible.
One of the fundamentals in NVC is to create such big understanding between people that fulfilling others needs become easy and pleasant. (That is also directed onto oneself, by knowing my inner motives for doing a task, it becomes easier to do it.) By looking at the need, rather than at a specific request, finding something that will fit everyone is easier. In TOC this is called “no compromises”. Goldratt claims that no-one should ever compromise. Compromises are giving up on finding the solution that will benefit both. And, according to TOC, there is always a solution that will make both parties happy. The only thing you need is a thinking process that help you find the real issue to solve and what assumptions to question to find the answer.
To increase performance of a system with TOC you need to know what to measure. That is the origin of the title The Goal for the first TOC book. If you do not measure outcomes for the entire system there will be local optima that decrease the system performance. And you will get what you measure, so you better measure what you want to get. In NVC the conflict between parts has to be distilled down to our needs and what emotions are connected to those needs. Focusing on how we think that those needs should be met are not helpful. That is the same thing as creating local measurements in a factory.
When it comes to gathering data TOC and NVC are using almost the same wording. We need to look at how things are now. And there is no judging. We only want to know where we are right now, and it should be objective. Worth noticing is that the phrase “I am angry.” is as objective as “This machine has a maximum output of ten units per hour”. While “you make me angry” and “this machine is too slow” are both subjective. In TOC this is structured in a Current Reality Tree, with a handful of undesired effects connected with “if this is true, and this is true, then that is true” as a directed graph. In NVC the giraffe has taught us the formula “When W happens, I feel X, since I have a need for Y, I would rather have Z happening”.
TOC has bottlenecks. NVC has needs that are not met. In a current reality tree, assumptions about other participants are challenged. Look at the problems. Then look at your counterparts problems. Try to find a solution that fixes both your and your counterparts problems. In NVC we listen with compassion and try to really understand our counterpart. That enables us to give with joy. To me that sounds the same.
TOC then create a future reality tree, while NVC can create a suggestion to the solution. In both cases this is discussed and evaluated further.
Ifs and then’s can be spoken or drawn as a tree. Having a clear picture of what is going on is powerful regardless of how. Emotions carry information, and can be treated as information. It is hard to know what the real problem is. We can not guess what other people are thinking, or the needs of a customer we seldom talk to. All of this, and more, can we get help with from both NVC and TOC. And since it is hard work to learn how to communicate and think better it is good that we can practise it in almost all we do. But then it helps to see that what we practise with a friend is also valuable at work.
We need logic, even if not everyone likes directed graphs. Emotions are valuable data, and I wish that more people would feel comfortable with using it as such.
If you are comfortable with NVC or TOC try to explore the other system. If you are new to both I would recommend TOC as a start, but focus extra on the parts in the books that are about relationships.
]]>This is Test Driven Development (TDD) explained with Theory of Constraints.
]]>In the analogy with a factory our groomed backlog items can be seen as work in process. Throughput in a system is limited by high work in process. Backlog items do not take up floor space. But they can get old and irrelevant, or stress the team by being a metaphorical mountain of waiting work. The buffer before a machine is calculated by using the throughput and the time to replenish. Therefore I suggest that the meetings for grooming the backlog should be scheduled in proportion to the team velocity and the current size of groomed items. A rule of thumb is
time to next meeting = work in groomed backlog / (velocity * 2)
This is not precise, so you do not have to measure velocity, just get it about right.
Going through backlog items is hard cognitive work, and we are not very good at doing this for long periods of time. So having shorter, more frequent meetings, will help us stay fresh and focused. Pick a time in the morning, when the brains are fresh, or after lunch and some rest where the brains have gotten new energy. Then keep it short, preferable under one hour, and focus. That way you will make better decisions and stay engaged.
We get better at things that we do often. Things that are painful, but important are good things to get better at. Hence, do painful things more frequent. For Toyota this was setup for the machines. For me it is time reporting. For some software teams it is grooming the backlog. Do a short retrospective after each meeting and focus on the improvement of the processes. Then we will get really good at preparing our work, and well prepared work is more fun to complete.
]]>They go to the quality assurance team that tests finished products. There they find a lot of things that passed through a bottleneck, but got discarded. since they had shortages in quality. By moving parts of the QA before the bottleneck, they save the limiting station from working on things that are already broken.
What is the equivalent to this in software?
I do TDD and BDD! you might say. If we assume that the developers are the bottleneck I would say that it is rather like making sure that the products are not broken during or after they are at the bottleneck.
My suggestion is that we see user research and design sprints as our way to make sure that we do not have products that are already broken taking up valuable time at the bottlenecks. Every feature, that is not tested against a real user, risk being waste in process instead of work in progress already when it reaches the development team.
The best way to increase the capacity of a bottleneck is to find what it should not do. By doing design sprints and user research you can try a lot of ideas that do not have to go though the full development cycle. (It has other advantages too.) By investing in usability and design a lot of redo and undo can be saved.
Make sure that all tasks that get turned into code has first been checked that they actually should be implemented. That is how user research limits waste in process.
]]>So what if we made all time touch time with total disregard for individual productivity? If we instead optimize for the groups productivity, making sure that a feature never has to wait for information needed to be completed.
With a batch size of one and only one workstation, where would we end up?
And people are surprised that using ensemble programming can be a competitive advantage.
]]>