Essential Skill of a Leader
One of the most underrated skills of a leader is keeping his mouth shut. When thinking about leaders, charismatic people who give good speeches often come to mind. When people enter the room, others listen. In one’s own world of thought, an equally valuable skill is keeping one’s mouth shut, in many situations. It’s hard to listen if you’re talking at the same time. That’s why it’s good to focus on listening and it happens best when you’re quiet. In challenging situations, it is not always worth jumping in to solve the situation yourself. Instead, give space and voice to others. Sometimes it’s good to calm down for a while and give the brain time to process. All solutions don’t have to come from the pharmacy shelf when you ask for them. I myself have thought that if I talk constantly, the meaning of a single word loses a little of its value. When you’re not speaking all the time, then maybe the recipient’s senses are a little more sensitive to what’s going on there.
Ackoff and Systemic Thinking
When it comes to Systems Thinking, Russell Ackoff’s name pops up to my mind quite quickly. 6 years ago I heard about him first time. I watched his talks on YouTube and ended up reading one of his books (Systems Thinking for Curious Managers: With 40 New Management f-Laws’). As an attempt to summarize what I had learned, I wrote a blog post. Then years flew and I didn’t pay much attention to Ackoff. That changed few days ago when I managed to find a new (to me) talk from Ackoff. I watched it on my TV earlier this week and it was ABSOLUTELY BRILLIANT. Even from Ackoff whose talks are usually very entertaining and full of insights. I couldn’t just leave it there after seeing the talk. Hence the blog post where I try to summarise what the talk was about. Because the talk was over one hour long, I’ve left some of the things out. There’s also interpretations involved. Just keep these in mind when reading my notes. Which is why I advice you to watch Ackoff’s talk yourself also. Mechanistic Thinking Ackoff started his talk from Middle Ages. Describing how the life expectancy was only 27 years. Or that 95% of people didn’t travel more than 4 miles from their place of birth during their entire life. And life itself was quite miserable. Which raised the question of what’s the purpose of life if it’s such painful experience? According to Ackoff, Catholic Church provided the answer by reassuring people that life is preparatory for death. If you live correctly, you have infinite sojourn in paradise or heaven, so why the hell worry about 27 years. As a result Middle Ages focused on spiritual life and after life. Not this life. Things started to change though for few reasons. First was Peter The Hermit’s crusade, which led thousands of men in contact with other cultures in Europe. Who became curious for example why other people have different sets of values? Or different habits? Or trades? Similarly merchants who traveled for example from Italy to India and China, observed differences in cultures. They became curious of what cause those differences? As an outcome of many of these kind of events came Renessance. Completely new view of the world was formed. This included Complete understanding of the universe was possible Understanding of the universe would only be possible when we had understanding of the elements of which it was composed and therefore we first had to identify them and understand them All relationships between things were reducible to one single simple relationship. And that relationship was cause and effect. Our commitment to ‘cause and effect’ -thinking led to three very fundamental doctrines which permeated our thought almost 400 years. If I want to explain phenomena, all I have to do is find its cause. But how do I explain the cause? Well, I treat it as effect and find its cause. But then I have another unexplained cause. Is there any end for the causal regression? If you believe that universe can be completely understood, there had to be first cause. And this cause was God which was seen as first cause. It had enabled us to develop a theory of explanation that excluded the environment. We didn’t need the environment to explain anything. Actually all the fundamental laws of physics tell us what will happen when there is no environment (vacuum). Universality doesn’t derive from that they apply in any environment, but that they don’t apply in any. Does anything ever happen by chance? Spontaneously? No, if complete understanding is possible. Everything that occurs must be an effect of a cause. This doctrine is called determinism. Ackoff continued by discussing about Isaac Newton and how it was asserted that universe is a machine created by God to do God’s work. We are here to serve his will. Now whatever the concept of God was or universe was, people believed that. If we combine that with something that goes back to Genesis. It was said that man (people) was created in the image of God, which means we are more like God than anything else on Earth (not surprising as we wrote Genesis). When you both together both of those, you’ve got the premises of a very interesting syllogism. Universe is a machine created by God to do God’s work Man is created in the image of God What should man be doing then? Creating machines to do his/her work And that was the origin of Industrial Revolution. Industrial Revolution Industrial Revolution was about mechanisation of work. There are two fundamental concepts. Work and machine. Work was defined as application of energy to matter in order to transform the matter. If I move a chair, I have changed the location of a chair. That’s work. If I burn coal and create heat, that’s work as I applied energy to the coal to transform it. Machine is any object which can be used to apply energy to matter. And there are three elementary machines from which all other machines are derived. Lever arm Pulley wheel and axle Inclined plane For example a screwdriver. You got the wedge at the end. That’s the inclined plane. You got the handle, which is the wheel and axle. And if you think the length, you got the lever. Problem was to deal with work so we could mechanize it. To apply machines to it. How do we do it? First thing you do is to analyze it. So we took it apart. How far do you break it? If you read Frederick Taylor, he will tell you. You reduce work to its elements. In other words, task so simple that no two people can do it at the same time. It can only be done by one person at a time. Ackoff remembered his father to try to tighten the same screw as he was working on. Tightening the screw was a work element. As two only obstruct it. So using work analysis we reduced the work to elementary tasks. Next job was to mechanize those tasks. Simpler the task, the easier it was to mechanize it. But we couldn’t mechanize all of them. Either we didn’t have the technology for some of the tasks. Or it was cheaper to use human labor than machines. When you combine a network of tasks being performed by people or machines, what do you call that network today? That’s the modern (talk was recorded 1993) factory. The production line and the assembly line is simply the result of analysis of work and its mechanisation. Direct consequence. And that has two very important implications. If there turns out to be another way of thinking, other than analysis, then there must be another way of organising and designing work. And there is. It doesn’t look anything at all like Ford’s assembly line or production line. In the process of mechanizing the work, we reduced work to elements that were simple enough to mechanize. Those that we couldn’t mechanize, we gave to people. And therefore we made people behave as though they were machines. We dehumanised work. Industrial Revolution was the technological manifestation of Machine Age thinking. What happens with any age is the appearance of certain problems challenge the validity of world view. Those problems are called the limits. The limit is a problem which cannot be solved within the prevailing view of the world. Hundreds of them appear over time and you have to develop a critical mass before anything really occurs. Toward Systemic Thinking In 1947 appeared a book that shocked everybody, at least in academic circles Ackoff was in. Something fundamental was being challenged. That book was Norbert Wiener’s Cybernetics. But it wasn’t known what was changing. First insight occurred 1954. It came with book by Ludwig von Bertalanffy, according to Ackoff. Content wasn’t that important, but the concept around which it was built was. And that of course was systems. Because the book was called General Systems Theory. Now why? That’s the critical question. Why did systems break the back of the Machine Age thinking? We first need to though understand what a system is. It’s a whole which consists of a set of two or more parts. It’s not an item, it’s not an irreducible thing, it’s not an element. It can be divided into parts. Three requirements are imposed on parts. Each part can affect the behavior of the whole The way each part affects the behavior of the system, depends on what at least one other part is doing. In other words, no part has an independent effect on the system, it depends on other parts. Or if you’re a logician, parts constitute a connected set. If you take the parts of a system and line them up in any order at all, doesn’t matter how you do it. And then divide it up into groups, subsets. The subsets, no matter how you create them, will have same properties as the parts. That is, every subsets of parts can affect the behavior of the whole. And no subsets of parts has an independent effect on the whole. When you take these different requirements and add them up. It’s a whole which cannot be divided into independent parts. Which sounds almost trivial until you reflect. Because the system, following from its definition, has certain very critical characteristics. Essential properties of any system. The properties that define a system, are properties of a whole that none of its parts have. That’s not obvious. Ackoff was using as an example an automobile. If you break it into parts, none of the parts itself have property of moving you from one place to another. For example engine can’t do that alone. Or a steering wheel. From previous follows that you cannot understand the nature of a system by analysis. And that was a fundamental revolution. Another method was required and that was developed 1950’s. This another method was, not so surprisingly, called synthesis. It’s exactly the opposite of analysis. When in analysis you break a system into parts, in synthesis you view the system as a part of a larger system. Ackoff used a university as an example. In analysis you break it into parts (colleges, departments, students faculty, etc.). Using synthesis you try to understand university as part of educational system, which it is part of, and what role university plays in educational system. Machine Age began to die when we gave up the principle of understandability and when we substituted synthetic thinking for analytic thinking when we try to understand. Not when we try to know. Systems thinking is the fusion of analysis and synthesis. Depending whether our objective is knowledge or understanding. There’s one problem though with synthesis. If you want to understand educational system, you need to understand the system it is a part of, society. Now what if you want to understand society? You need to pick the system it is a part of. And we are facing reductionism in reverse. Everything we try to explain, depends on larger system. Is there one system that contains everything? We’ve given up the notion that universe can be fully understood. Now given that universe cannot be fully understood, if there were one whole that contained everything, you could never know it. If you did, you would understand the universe and if there isn’t, how would you ever prove that there isn’t? Ackoff discussed next few minutes about how Zen Buddhism became popular in 1960’s as it reflected better the systemic thinking of that generation. From there he got to doctrine of expansionism, instead of reductionism, which says to understand anything you have to get to larger systems. You will never reach a complete explanation or understanding of everything, but your understanding increases the larger the system you comprehend. The knowledge increases the smaller the element you comprehend. Producer-product relation The transformation from cause and effect was an interesting story. The man who was first responsible of that, was Edgar Arthur Singer Jr. He graduated 1896 from Harward and had been the assistant of professor William James. Edgar was unusual young man as he got his first degree in Civil Engineering, second in Psychology and doctorate in Philosophy. Edgar Arthur Singer Jr. showed that science had been cheating for hundred years. How? He said, consider an acorn and an oak. Is the acorn cause of an oak? Clearly it isn’t as it’s necessary but not sufficient. That’s easy to demonstrate. How? Throw an acorn in to ocean. You don’t get an oak tree. Throw it in desert. You don’t get an oak tree. It’s necessary but not sufficient. Science knew this. This was not a discovery of Singer’s. In late 19th century science began to be concerned with that type of relationship and gave it a special name. They call this relationship either probabilistic causality (this was the foundation of statistical mechanics) or non-determenistic causality. What Singer did was that he showed these are contradictions. If a cause is defined as something which is sufficient for the effect and if the cause occurs, what’s the probability of the effect? One and it can’t be anything else. Therefore non-probabilistic causality is a contradiction. It is to say that the causes are not sufficient so it’s not causality. Non-deterministic. Causality implies determinism. First law of logic, according to Aristotle, is if in an implication you deny the consequence, you must deny the precedence. Therefore non-determinism implies non-causality. It’s a fundamental law of logic. Singer said this is a different relationship and gave it a name. He called it producer-product. Producer is necessary but insufficient for its product. This was written in 1898 and was completely ignored. Nobody saw the significance of it until 1954 when the context of cybernetics, ‘Analytical Biology’ book was published where exactly the same thing was rediscovered. In a different name, directive correlation. When you look the world through product-product instead of cause-effect, many things happen If you want to explain an oak, you look for the acorn that produced it. Do you have the complete explanation for the oak? Of course not. It’s not sufficient. What else is necessary to become sufficient? You need moisture, certain soil with nutrients, and so on. In other words a list of other necessary conditions. The sum of the list is called the environment. We have an environment-fault, not environment-free, explanation. Nothing can be understood independently of the environment. Every law is constrained by the environment within which it applies. There’s no such thing as a universal law. They’re all environmentally relative. This was the first consequence of producer-product thinking. Second consequence can be boiled down to cause-effect being a way of looking at reality. There are an infinite number of ways. Because reality isn’t 2-dimensional, it’s multi-dimensional. Producer-product isn’t an alternative to cause-effect. It’s complimentary. We’ve come to recognize that even the machine is a system. But it’s a particular kind of a system. Machine is a system which has no purpose of its own. It has a function. Which is to serve the purposes of something external to it. Its God. Universe was earlier seen that way but so was early businesses. Who was the God of the early business? The owner who created it. He was present and all-powerful. He could do any damn thing he wanted. There were no labor laws, no restrictions, no registration. He was God. And the business existed to serve his purposes. It had no purpose of its own. And his purpose was what? To make a profit. So Milton Friedman, who was always behind times, comes out and says the only legitimate business is business. That’s complete mechanistic view of the business. It’s a machine. As a machine the business is an instrument of its owner’s and the only responsibility of business is to maximise the value of the machine to its shareholders. So Rappaport and Friedman go off on maximising shareholder value. Machine as a system has no purpose of its own and therefore neither do its parts. Ludwig von Bertalanffy came along and began his papers in 30’s but they were written in German so they didn’t get known on US side of Atlantic until the 50’s. He said the organism is very different kind of a system. It’s a system but it’s different because organism has purposes of its own. What’s a principal purpose of any organism? Survival. In order to survive, it must grow. So we now have a system which survival seeking and growth is seen as necessary for it. What about its parts? Its organs. They don’t have any purpose, they have a function. Up until World War I most enterprises were in United States owner-managed. And they were only by an individual or a family and he was God. Unions were just beginning to appear to challenge the power of the owner. But several important things were occurring. Like the education of the workforce. In 1900 the average educational achievement of an American worker was three years. They were barely literate. By World War I they had gotten up to eight years because of public education. But the critical thing that occurred that produced this transformation (from machine to organism) the way we looked at an enterprise was the fact that our economy was so healthy but the opportunities of growth exceeded the amount of growth an enterprise could achieve even by reinvesting all of its profits. If an enterprise took all its profits and reinvested it in its own growth, it still could not grow as fast as possible. And therefore the fundamental problem confronting the owner of enterprises in United States in 20’s was Do I retain exclude control? Do I remain God and constrain growth? Or do I share control with other contributors or capital and unconstrained growth? Corporations that survived went public. In the process God dissappeared. Transformations In the World War II United States went through another transformation for a series of reasons. The principal reason was this. The bulk of the American workforce was drawn into the military, they were drafted. Voluntarily or not. This happened at a time that demanded greater productivity from industrial machine than ever had in the past. Which means substitutes were required. So who do you get as substitutes for the men who were drawn into the service? Elderly people and the young. This was the first time in the history of enterprise that the workforce was not primarily motivated economically. Why? When men were inducted in the Army, they were paid twenty one dollars a month. Now you couldn’t support a family on twenty one dollars a month even in 1942. You didn’t have to because you got an allowance for each dependent. So your dependents could live above the poverty level but not luxuriously while men were in service. You didn’t have to worry about them and they didn’t have to worry so the people who went to work in the workforce did not have to work in order to survive and it was the first workforce that didn’t. Therefore it had different attitude towards work. They said, “If you want me to work you’re gonna have to pay attention to me. I am NOT a machine that you can use as you see fit and discard when I don’t serve your purposes. Because I’m here because of patriotism and loyalty to national cause and you better pay attention.” And for the first time management had to begin to think of the workforce as human beings. Also two movements happened. Parts (people) of systems began to organise to protest the way that the system was affecting them. The system which they’re apart. They said that they had purposes of them own and demanded to be paid attention to. This was the race movement, where minorities protested the way society was serving their interests. It was women’s liberation. It was the generation gap problem. It was the alienation from work problem. Series of problems that go under the name humanization which had to do with the fact that society was becoming aware of the fact that the employed people are human beings with purposes of their own. Simultaneously groups were forming outside. They were protesting the way that the organization is affecting them and saying “You start to serve my purposes better or I’ll mess you up.”. That was the ecology movement. The Consumer movement. Suddenly systems were being confronted with three different levels of purpose. The purpose of the organism itself. The enterprise. The purposes of its parts. The purposes of a larger system of which its apart and the other systems in that environment. Nature of management went through a fundamental change. And we haven’t caught up with that yet.
Coping With Reality
I got an email a year ago. A friend of mine was asking what I thought about happiness. He was especially thinking if we should pursue happiness? Or not? I wrote back a lengthy email that covered different revelations that have helped me in pursuing happiness. Or perhaps not pursuing happiness, but coping with reality. What’s my meaning in life? When it comes to happiness (or success), I’ve followed Viktor Frankl’s words Don’t aim at success. The more you aim at it and make it a target, the more you are going to miss it. For success, like happiness, cannot be pursued; it must ensue, and it only does so as the unintended side effect of one’s personal dedication to a cause greater than oneself or as the by-product of one’s surrender to a person other than oneself. Happiness must happen, and the same holds for success: you have to let it happen by not caring about it. I want you to listen to what your conscience commands you to do and go on to carry it out to the best of your knowledge. Then you will live to see that in the long-run—in the long-run, I say!—success will follow you precisely because you had forgotten to think about it His book The Man’s Search for Meaning had profound impact on me several years ago, as I realized what truly matters in my life and organize it according to it. He who has a why to live for can bear almost any how (Nietzsche) Those of you who haven’t read Frankl’s book, the part that resonated the most with me, is where he goes through different types of whys you can have for your life Love Work Dignity in suffering Of these love and work are the ones that provide meaning for me. They give me a reason to wake up every morning. They also give me a reason to overcome whatever challenges I encounter in my life. I love my son and wife, who I provide my physical and mental presence as much as possible. In case of work, my journey to create software development approach of the next century, is a cause greater than myself and which I’m approaching by trying to understand as much as I can on how we (should) develop software. It’s also something where my passion meets the needs of other people and I truly believe I can make a difference. Managing your life according to your meaning(s) The first step years ago was recognizing what provides me a meaning in my life. The second step was to reorganise my life based on those. If my son and wife gives me a reason to live, I can’t spend majority of my time to work or hobbies. I wouldn’t act according to my values. What helped me in reorganizing my life, was a video of big and little rocks. It’s just a demonstration of how you can fill more rocks and sand to a jar by filling first the big rocks to the jar. Regardless of the science behind filling the jar, it was thought-provoking metaphor. I decided to make sure I give enough time to things I value Family Work (not over 40 hours per week) Sleep (minimum of 7 hours per night) Physical exercise (I don’t own a car so I bicycle to work every day around the year, we also have floor ball session once a week at work during the work day - so it doesn’t take time away from my family or sleep) These were the big rocks. After that came small rocks (sand) if it had space to fill in. Sand was for example Reading articles, listening podcasts, watching conference talks Attending conferences that required me to be away from home several days (or evenings) More time consuming physical exercise (for example going to gym or playing badminton with a friend) Watching Netflix I’ve kept this approach several years now and it has felt good. I think there’s a good balance in my life and I dedicate my time to something I truly value. Besides just managing my time, I also changed other habits during the past few years. I wanted to increase the probability of living healthy as long as possible. In order to accomplish that I Quit drinking alcohol completely Increase vegetarian food in my diet Reduce weight (from 90kg to 78kg) & lower cholesterol (from 6.5 to 4.5) Eat everyday walnuts Empathy toward yourself Years ago I didn’t have good ways to handle moments where things didn’t go as I hoped they had. Especially if I thought I had failed, I used to be really hard on myself. This would affect my mood for a long time and in the end it didn’t do any good for anyone. I was fortunate to find someone who helped me in becoming more empathic toward myself. That person was Jerry Weinberg. Through the books, email and face-to-face discussions with Jerry, I’ve been able to stop being too hard to myself. Instead there’s couple sayings that help me over difficult moments There’s no failure, only feedback Accept what is and build on it Whatever happens, only thing that matters, is what you do next. What do you take from the moment of frustration and build on it? How do you use the observations and feedback for becoming a better version of yourself? We all face moments where someone is being hard on us. Let’s not do that by ourselves. There’s no need for that. Empathy toward others Besides being empathic toward myself, I’ve done my best to be empathic toward others also. Here I’ve followed another advice from Jerry No matter how it looks, everyone is trying to be helpful I used to get frustrated on what someone said or did. At some point though I started to, regardless of how sure I was to believe otherwise, assume that people were trying to be helpful. That they were acting the way they did because that’s the only reasonable way to act. Considering what they’ve gone through and what their current situation is. While there certainly can be situations where someone is deliberately trying to hurt you, I also many times got to a point that the other person showed a sign of vulnerability after me being sympathetic. There’s been many email conversations where I’ve got a response that could be interpreted as ill-intentioned. Instead of attacking against that response, I’ve noticed that sympathetic face-to-face conversation or response from my part, has often solved the situation. This has led to much more humane further responses from the other person. I just mentioned communication. That’s a skill that has actually helped a lot in maintaining my empathy toward people generally. Mainly because it’s how I’ve managed to solve those tricky situations where I’ve felt someone is hostile toward me. If I had to highlight few things that stand out from my approach to communicating with others, those would probably be Emphasize your feelings when communicating to others Observations over interpretations Express empathy Solve disagreements as soon as possible Don’t assume you know what other person is thinking
Remembering Jerry Weinberg
I learned today that Gerald “Jerry” Weinberg passed away yesterday. Despite being deeply sad by the news, I still wanted to use this moment for remembering what Jerry meant for me. It took me quite a while to learn who Jerry Weinberg is. I think it was such late as 2012. Eventually I ended up reading - like many others - The Secrets of Consulting and Are Your Lights On?. And I rarely read books. There was just something on how those books were written. My thoughts were provoked and I wanted to learn more. Not just what Jerry had written, but who is Jerry Weinberg? The Past Besides Jerry’s Wikipedia page, one of the first steps on learning about Jerry’s past was to listen This Week in Software Testing podcast that had Jerry as a guest. It was recorded on 2010 by Matt Heuser and Michael Larsen if my memory serves me right. On that episode I learned how Jerry had been involved with Project Mercury late 1950’s Because of the complexity and worldwide nature of the system. I (Jerry) decided that we need to have a group of people dedicated to quality, including testing of the system. We created such a group, which is as far as I know, had never been done before. They lived through the whole project, unlike a lot of testing groups today. They were involved right from the very beginning. So, for example they could comment on whether the software we were building, was in fact testable, by then. Which wasn’t sure at all to just automatically happen. Because this was, not only first human life system, but it was the first worldwide online system, ever build, and presented many unique problems in testing. That’s how we got into this. It was after that that other people began to realize they needed separate testing groups. But it became different. Our testing group was composed of experienced and talented software developers. Later on, managers began to see testing groups as a way to hire cheaper people and put them in testing, because they didn’t have to know how to develop software. I’m thinking a lot of managers thought all they needed to do is sit in there on terminal and bang on keys, like monkeys. Of course that’s simply not true, but it’s taken us a long time, for many people in industry to realize, that testing is as professional, a job, as we realized it back, literally half a century ago. And many managers today still don’t understand that. I ended up writing a blog post later about Project Mercury and Death of Testing as I felt we were coming back to where we started from with current modern testing teams. Not to forget development practices which Jerry discussed on Iterative and Incremental Development: A Brief History. I was fascinated about the history of our craft what role Jerry had played in it. Thanks to Twitter, I was other times fortunate to ask where for example test cases came from But the more I searched information on Jerry, the more I also faced PSL (Problem Solving Leadership) course being mentioned. I especially remember Let’s Test 2013 conference where Griffin Jones told me that I have to go there. Years passed and I read more Jerry’s books, but that comment from Griffin never went away. Fast forward to 2015 when I decided it’s now or never. Because I was changing the company I worked for, I wasn’t able to get my employer (well I didn’t felt it was right thing to do) to pay the course, even though they promised to pay it before I announced I’m leaving the company. I decided though to pay the course myself, despite it costing me 5000 euros. It was an investment to myself. If you’re interested of Jerry’s past, there’s absolutely brilliant series of articles by Danny Faught. First post can be found from his blog by the name of First Interactions. From there on you can find the others. There’s at least 7 of them. PSL 2016 In March 2016 I flew to Albuquerque in New Mexico, US. Those 6 days in Albuquerque were full of learning and I still carry those with me this day. But that’s not I wanted to cherish today. It was the moments I had opportunity to learn to know Jerry as a person. Like playing Scrabble (with interesting rules, to say the least) Or when we visited Jerry’s home and saw his wife Dani and their dogs Many who come to PSL usually probably look answers that are related to our professions. Naturally that was one of the main reasons for me to come there also. But in the end I noticed that almost all our discussions were related to something else. And that something else was mainly Jerry’s relationship with Dani. I wanted to understand how Jerry has been able to develop such a loving relationship with his wife. Through our discussions I found wisdom that has helped me on my own marriage and I feel great gratitude to this day. It also reminds me of the intolerable sadness that Dani must feel at the moment. I just hope she finds a way to carry that grief with her. While it doesn’t probably help, at least there’s many of us around the globe that are thinking of you Dani. Maybe someone is also wondering what I learned from Jerry related having a healthy marriage? There were many things I learned and the first one wasn’t a secret at all as it was communication. Courage to communicate feelings. Simple and such a hard thing in the heat of the moment. Other thing I took from those discussions was the understanding on how we don’t know what state people are in. Not even our loved ones. Pax Et Bonum Jerry’s influence on me is right there after my loved ones. I can’t emphasize enough his impact on me as a person. How much I’ve gained empathy toward myself and those around me. How much I’ve developed my ability to observe. The list goes on and on. I’ll keep reading his books and sharing his wisdom. In that sense Jerry will continue to live for decades if not centuries. When we visited Jerry’s home, there was a sign above his front door. It said Pax Et Bonum, which basically translates to “Peace and the Goodness be with you” - I’m wishing that to Jerry and especially to Dani
Manager's Mindset
I’ve had many managers during the past decade. Some of them have enabled a safe and supportive environment. And others haven’t. I realized one day that there’s at least one nominator that is common to people who have relied more on micromanaging and not being able to create safe and supportive environment. It’s how they see failure in work being more people driven than systems driven. Most supportive managers I’ve had, have never blamed anyone when things go in ways that we didn’t want them to go. Instead they gather data, reflect on what happened and find ways to improve. Less supporting ones have found people to blame on and increased their level of micromanaging.
Task Analysis & Test Automation
I noticed few days ago that it’s over a year from my last blog post. While it’s been hectic year (working on developing autonomous ships), that’s way too long break for my writing here. Which is why I’ve tried to catch on idea that I’d like to think about through writing. And I managed to find one, it’s how we approach automating something and how that relates to test automation. Automating Say there’s a system being operated by human and you want to automate that such far that system can accomplish its tasks without human interaction and human intervention. In order to accomplish this you need to have deep understanding on what is the role of the human(s) in the loop. Role covers naturally operational tasks, but also the situations when things go wrong and automation fails. One of the approaches for figuring out the role of human is to do a task analysis. Here’s an example of such done for car turning left on green light. It was introduced on a paper called Task Analysis of Intersection Driving Scenarios: Information Processing Bottlenecks Needless to say, it’s getting rather complicated when we are talking about automating a car, ship or an airplane - in multiple different contexts. Choosing what to automate When the amount of tasks performed by humans is high (and contexts those are performed in) and they are challenging to automate, you ask yourself: “What tasks do we want to automate? To what degree? And in what context(s)?” Perhaps not everything needs to be automated. It might be that some of the performed tasks don’t provide value. Or perhaps they do. You make the decision based on your understanding of them and their significance. How is this related to test automation? If we consider the approach of automating something through task analysis and having a deep understanding of how human intervenes with the system, I think it makes sense to consider similar things when building a test automation approach for a product. How does a tester (person performing testing) intervene with the system while testing? What tasks does (s)he perform? What kind of reasoning (s)he is using for making decisions? Which of the tasks we want to automate (to what degree)? And which of the tasks we don’t want to or can’t automate? Not to forget human ability to learn and adapt through experiences.
User Story Mapping Talk
This is first blog post where I’m publishing notes from a conference talk that I’ve watched. It’s mainly for me that I can in future find these more easily. But it might be useful for others too. I’m summarizing this time Jeff Patton’s User Story Mapping talk. “Our job is not to build software, it’s to change the world.” Stories are meant to solve 2 problems in software development Documents don’t work (Use storytelling to build shared understanding) Too much to build (Minimize output – understand who, what, why!) Kent Beck’s idea: “Stop it. Stop exchanging documents. Tell me your story.” Use the card for facilitating a conversation Shared documents aren’t shared understanding Stories help people remember things that weren’t written on the document. The best documents use words and pictures to help recall our conversations, they don’t replace conversations. Stories are an antidote to “requirements”. Most challenging problem is not what to build next, it’s who to pay attention to. Rachel Davies was struggling at Connextra (late 1990’s) with feature ideas on cards. It was hard to figure out who had written them and what they were about. Very often when Rachel discussed about ‘Who, What & Why’ related to idea with a person herself, it turned out that the feature wasn’t needed afterall. Therefore, Rachel and her team decided to create story card template that required people to put a bit more thinking BEFORE writing a feature suggestion. Stories aren’t a different way to write requirements, they’re a different way to work. Story Mapping A story map is a simple way to tell a story and break it down into parts. Use story maps to understand your whole product or feature’s experience. Use mapping to break down big stories without losing the big picture. Instead of prioritizing stories, prioritize outcomes. Slices of outcomes form delivery strategy that is aiming at maximizing learning. Change the way you work: tell stories, don’t just write them Use simple visualizations to anchor the stories you tell Map the whole story to find the parts that matter most Think things through: minimize output, maximize outcome and impact Build minimum viable product tests to find what’s minimum and viable in market Build your product up iteratively and incrementally Story mapping helps in having the conversation about the stories. What to build Harvard Business Review article: The Big Lie of Strategic Planning Where you’ll play (target market, customers) How you’ll win (how is it better, how will it help) Strategic refers to risk, guess, gamble and bet Stories are too big Card (story itself) Conversation (discuss e.g. in backlog refinement in front of whiteboard) Confirmation (How do we know we succeeded?) Splitting the stories into smaller is the responsibility of the people who are having the discussion (e.g. PO, UX, Dev, Tester). Shared understanding when not collocated Utilizing for example Google Docs, Mural.ly, cardboardit.com, stormboard.com, Ipevo Asking people to reply how they understood something There’s was a great example of team creating a story map and leaving the backbone on the wall and ripping rest of the notes of the wall. Then they would create the story map couple times again. This way everyone got good understanding of overall solution when it was created several times and people had to focus on whole flow instead of only what they were going to be working with later on.
Shared Understanding Doesn't Exist
I just wrote a blog post about how Cognitive Biases Trick Us. Which highlights many of our challenges in understanding the information provided to us and making decisions based on it. What is shared understanding I’ve been in many meetings where the goal has been to reach shared (or common) understanding. Usually it has been about essentially complex requirement that has caused misunderstandings. But not only restricted to requirements. Some of the meetings have been about informing a new way of work. More or less anyway about clarifying something that could be easily misunderstood. It’s just that shared understanding itself hasn’t been defined on places where I’ve faced it. I’ve got the impression that it has meant in past meetings something like this Each person perceives the intended meaning similarly I wasn’t able to find any apparently credible definition for shared understanding, but the ones I found were something different than what I’ve (shallowly) understood myself Shared understanding represents a “collective way of organizing relevant information” (Hinds & Weisband, 2003: 21) and lets a group collaborate more effectively. This is different from perceiving meaning similarly as it’s more about enabling the group to collaborate by having some degree of common understanding. Shared understanding doesn’t exist I personally approach this by saying myself that shared understanding doesn’t exist. Let me explain. When we are discussing with group of people about any work related subject that we want to have better understanding as collective group. We are firstly affected our biases. Secondly our mental engagement tends to differentiate depending on the person. Thirdly culture and the system itself affects to how questioning and general candidness is valued. And I could go on and on. Point being, we have no idea how much we have (mis)understood each other. That’s when I assume that we have misunderstood. At least to some degree. Instead of shared understanding, we are having more like a shallow understanding. And that’s fine. We will do our best to catch those misunderstandings (in cases where risk requires it) as soon as we can. Like Richard Feynman said “We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.”
Cognitive Biases Trick Us
I’ve lately read couple interesting articles about our minds and how they fail us in many different ways. First one is Cognitive Bias Cheat Sheet, which is based on Wikipedia’s list of cognitive biases. Biases can be organized into four categories, based on where they arise from (with few examples): Too much information We notice things that are already primed in memory or repeated often. We are drawn to details that confirm our own existing beliefs. We notice flaws in others more easily than flaws in ourselves. Not enough meaning We find stories and patterns even in sparse data We fill in characteristics from stereotypes, generalities, and prior histories whenever there are new specific instances or gaps in information We think we know what others are thinking Need to act fast In order to stay focused, we favor the immediate, relatable thing in front of us over the delayed and distant In order to get anything done, we’re motivated to complete things that we’ve already invested time and energy in We favor options that appear simple or that have more complete information over more complex, ambiguous options What should we remember? We discard specifics to form generalities We store memories differently based on how they were experienced We edit and reinforce some memories after the fact These problems in our minds won’t go away. But it helps to recognize that we have these kind of challenges with our cognitive abilities. Other article I read, was The New Yorker’s Why Facts Don’t Change Our Minds, which goes through how these different biases have affected to decision making in studies by researchers. There’s one particular concept I wanted to raise from the article – that being illusion of explanatory depth. It can be summarized as: “Most people feel they understand the world with far greater detail, coherence, and depth than they really do.” You might feel that you understand how toilet or freezer works, but what if you would had to write down detailed explanation of how they work? You would most likely notice that you don’t understand them as deeply as you thought. Similar applies to our work. We talk about many concepts daily. Like testing, Agile, Scrum, daily standup, product owner, scrum master, value, programming, etc. Could you easily write their definition and purpose in your own words?
My Respect Toward Agile Testing Days
Today there was an announcement where Agile Testing Days USA announced that they will cancel their conference that was supposed to be held June, 2017 - in Boston, US. To make it worse - from personal perspective - it was supposed to be my first abroad conference as a speaker. This is what they had to say: I feel the pain behind their decision. I also feel that they act based on their beliefs and values - which seem congruent from my perspective. That’s a positive sign these days. Regardless of how depressing the development in US otherwise is. That’s not all There’s also another thing that raised my respect toward AgileTD organization. I had already paid my flights before the announcement about the cancellation. That’s nearly 1000 euros of paid money. That’s a huge amount of money for me personally. Which is why I was worried what will happen to that money I already paid. I discussed that with organizers and Jose announced that they will pay either the cancellation fee or if that’s not possible - then the whole amount I paid. I discussed with flight company today and unfortunately I wasn’t able to get any money back from Icelandair. Nevertheless, Jose promised that they will pay the whole money back to my bank account. That tells something about their way of handling these kind of cases. After all this I will continue to support AgileTD also in the future - in whatever way I can.
I Don't Have Time
I used to say I don’t have time when I noticed that I couldn’t do something that I would’ve like to do. This didn’t felt like a huge problem, but it did trouble me a bit. Every now and then I would feel stressful that I wasn’t able to find time for example to educating myself on something I was interested of. One day I read a blog post from Michael Bolton where he told a story of how he had to hurry home from a conference. This is when Jerry Weinberg pointed out that he has chosen to go home, instead of needing to go home. Here’s an excerpt from the blog post: “Hi, Jerry,” I said, offering and accepting a hug. “Great to see you! And I’d really like to hang out with you as much as I can for all four days of the conference, but I have to go home.” “No you don’t,” said Jerry. I was taken aback. “Huh?” “You don’t have to go home.” “No, Jerry, I really do. My family’s there, and I’ve been away a lot lately.” “You don’t have to go home. You don’t have to do anything.” “Well…” “You don’t have to go home. You want to go home, and you’ve chosen to go home. And that’s fine.” It might seem trivial to realize that you choose to do things instead having to do things. But it’s actually something that has give me a lot of inner peace and clarified purpose in my life. It’s a choice I have two main priorities (purpose you could say) in my life (in this order) Family (wife & son) Career (my effort on understanding more and more deeply testing and software development more generally) I also have 24 hours every day that I can choose to spend as I want. While you could see going to work and spending time with your family as something you’re not choosing - that’s exactly what you are doing. For me it has been liberating to realise that I choose where I will put my time. And as my family goes to top on my priorities, I’ve chosen to dedicate the majority of my time to them. Then there’s also approximately 40 hours per week that I put to enjoying my career in software development. What’s left goes to sleeping, exercising, out-of-the-work-development and so on. Without jeopardising my main priorities. Knowing your priorities and acting according to them, gives you congruence. Which in the long term has made me much calmer and peaceful. You do have time It’s not actually true if you say that you don’t have time. You have all the time in the world. 24 hours every day. And you choose where to use them. Perhaps it’s easier to say to someone (or yourself) that you don’t have time than I have more important to do. Wherever you choose to spend your time, realize that you could choose otherwise. And you can also be totally happy with the choice you’ve made. Especially if it’s based on what matters to you.
Writing Test Notes To User Stories (in JIRA)
I participated couple times for sprint planning meetings that one of our development teams is arranging. One thing that bothered me, was that there wasn’t much discussion about how the next sprint stories will be tested. This discussion came later when domain experts gave feedback after familiarizing with implemented story. I felt that the feedback came too late this way and that it would help to improve the quality if we could diversify the discussions before we start to implement a story. Writing test notes So I came up with an idea (which I’ve tried out earlier when I was consultant and originally learned it from an Atlassian blog post) that we would explicitly think about testing during the sprint planning. Then we would write down separate test notes for the story in our JIRA. It could look then something like this: At the moment I have a separate meeting on the same or next day than our sprint planning. Developers, PO and domain experts (domain experts are the testers in our case) participate to this meeting. We go through all of the stories that we are going to implement on next sprint. While doing that we ask How are we going to test this? We also think what kind of test data is needed. Or what kind of cases could introduce problems to this implementation. In many cases the developers have come up with good ideas on what kind of special cases might be troublesome. Moving forward So far these sessions have provided value by being able to catch troublesome cases before the stories will be implemented. There’s also been occasions where we’ve realized that additional requirements need to be specified because we haven’t considered a scenario that could take place after story has been implemented. I’m planning to continue making these kind of sessions as a habit for this team. Future retrospectives will give also ideas on which kind of modifications are required to further develop these to suit this particular team better.
Follow-up Testing For a Bug
I participated to a BBST Bug Advocacy online course a while ago. It focused on bug reporting – including investigating bugs and reproducing hard-to-reproduce bugs. Related to investigating bugs, there was one useful approach on follow-up testing after you’ve found a bug. It consists four (4) types of activities: Vary my behavior Change what I do as I test Vary the options and settings of the program Change settings of the application under test Vary data that I load into the program Different startup files or other data not directly involved in the test Vary the software and hardware environment E.g. operating system, peripherals, external software that interacts with this application I’ll give an example of applying this in my current context (insurance company). I noticed a while ago that I got an error with our mobile phone claim form, when I tried to send a claim. As I didn’t know what information on the form was causing a problem or if it was configuration issue, I first tried to Vary the software and hardware environment I was using Google Chrome, so I tried out if the problem reproduces with Firefox and Internet Explorer. It did reproduce, so it didn’t appear to be configuration issue. Next I tried Vary the options and settings of the program I was trying out our Swedish form, when problem occurred. So I tried out if it also reproduces with our Finnish form. It did. So language of the form didn’t appear to be the critical condition. After this I decided to Vary my behavior I started to modify how I fill the form: Change city from Åbo to something that doesn’t have Scandinavian characters (didn’t help) Change the money to go to own bank account, and not have beneficiary details filled (didn’t help) Remove one damaged mobile device as I had more than one (didn’t help) Shorten the address as I had maximum [60] characters in it (went through after this! – and further investigation revealed that it let through 50 characters through integration, even if you could type 60 characters to the field) Conclusion This can be useful approach for further investigating bugs that you’ve found. As long as you don’t forget to also utilize for example logs in your investigation.
Brainstorming Test Ideas With Developers
A couple of months ago I was asked to help one development team with their testing approach. Team has a long history but they’re working with new technology and adapting new patterns (like TDD, code reviewing or automated acceptance tests) for their development approach. They’re also helped by a consultant who has a good understanding of modern development approaches. But when it comes to diversifying their testing approaches, they felt that they needed help. Considering though the complexity of the system they’re building, they felt that help is needed in diversifying their testing. This is something I’ve tried to help with. How to gather test ideas? As this team has a lot domain and technical knowledge, I wanted to utilize this by giving them a chance to brainstorm test ideas. Fortunately they’re co-located, which gave me more options on how to facilitate a brainstorming session. I decided to use Me We Us (https://www.thekua.com/atwork/2011/10/coaching-tool-me-we-us/) facilitation technique for generating the ideas. After that we could organize, prioritize and further plan them. One challenge with brainstorming is that you usually need some guidance. I mean, if I try to brainstorm “anything” - I’m going to be having a hard time with coming up with ideas. Scope is too wide. Which is why I - personally - prefer having some overall ideas that can be used for coming up with more concrete and context specific ideas. For this team I picked some pointers from James Bach’s Heuristic Test Strategy Model (https://www.satisfice.com/tools/htsm.pdf) and Elisabeth Hendricksson’s Test Heuristics Cheat Sheet (https://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf). I flavored those with something I came up with after familiarizing with architecture and use cases. That gave some guidance for people who wanted some pointers. I tried to emphasize though that you didn’t have to use them. Arranging brainstorming sessions After I managed to figure out the format for the sessions, I booked three 45 minute sessions. In the first session we wrote to post-it notes test ideas 7 minutes individually 7 minutes with pair After that pairs introduced the ideas and we categorized them the best we could (e.g. security, database, services down, etc.). Then I took pictures and collected the notes. In the second session we further prioritized the ideas to NOW - LATER - EVEN LATER on a whiteboard. Prioritization was affected mainly how mature the system was for particular tests and how badly developers wanted to know the result of the test. In the third session we created tasks for the backlog from the ideas that were on NOW. We also wrote some high level notes on what would be actually done in case of each idea. Test sessions When we had put all the ideas from NOW column to JIRA as tasks - then we performed the testing as a group for first ideas that we included to sprint. One person had a computer and acted as a driver during the whole session (120 minutes in our first session - later ones where one hour). Others engaged by commenting and observing how the system behaved. Everyone, except one person, managed keep themselves (from my perspective) mentally engaged. But it was also a good learning experience on how rotation (as in mobbing) might be useful to amplify learning and engagement. That’s something that is good to introduce later after they noticed downsides of having one driver during the whole session. We had in total 3 test sessions as a group, where we managed to learn quite a lot how the system behaved and didn’t behave. Through those sessions we’ve managed to add diversity to testing that developers do by themselves as part of the development. We still need to figure out how to make these kind of sessions - when needed - part of the development process.
Feedback and Needs
Couple of months ago Eric Proegler mentioned on a PSL related Slack discussion something he learned from Jerry Weinberg: In my session, I asked a question about how to communicate feedback, and Jerry countered that people “providing” feedback were essentially communicating their needs, not really “helping” the person receiving the feedback This has been brewing in my head since then. In order to dive a bit deeper with it, I decided to write a blog post. “Don’t cut in line” I was watching my son (just turned 6 years old) trying out floorball a while ago couple times. That didn’t turn out to be something he wanted to continue, but there was one incident that I still remember. They formed a queue while practicing and one by one moved the ball to center of the field and tried to shoot to goal. My son isn’t always listening (or acknowledging) that carefully instructions. Which is why he couple times cut the line and went straight to middle of the queue or first. Quite quickly one of the other kids said to him “Don’t cut in line” and that pretty much ended that session for my son as his mood went down. We ended up going once more to trying out the floorball but he didn’t want to play it anymore. Difficult to say if he would’ve wanted to even if that incident had not happen. While floorball didn’t end up being something my son got interested about, I personally thought it was also a good experience for him as he faced a situation where someone is giving feedback. This will definitely happen in future and he needs to find ways for handling the feedback. Related to this particular incident, I mentioned that he shouldn’t take that feedback in a way that he did something wrong. I explained that he hadn’t participated that much to those practices that it was inevitable that he would do things differently from others. But the biggest “Aha!” moment I got when I realized that that situation was similar to what Eric said. Based on my understanding, other kid wasn’t trying to help my son, he was trying to communicate his needs. Don’t cut in line could translate to I want to move the ball and shoot it This doesn’t mean naturally that this is only reason for providing the feedback. It could be also affected by history where other kids have often cut in line in case of this kid. Feedback from a colleague In working context, colleague once mentioned that I’m leading meetings we were having, despite him being the facilitator there. That’s something that could’ve ended up into a debate – but I understood that he had a need of being able to contribute to the meeting and I was taking it a way by jumping in and leading the meeting when there was a bit of silence. It did help me. But only after I shook away the defense mechanism and focused on understanding the person giving the feedback. What’s funny though, I was also trying to contribute. But when I did contribute (in a way I knew the best), colleague wasn’t able to. Different perspective While I acknowledge that there can be situations where this thought doesn’t apply, I also think that perhaps the biggest benefit comes from being able to cope feedback better. In past I’ve struggled with receiving feedback. You get that awkward feeling in your stomach when someone is giving feedback related to your performance. The risk of being defensive is present and it’s hard to handle the situation in a way that meets better the needs of the person that’s giving the feedback. Or to improve yourself as a person based on the feedback. These days when I receive feedback, I’m not being that defensive anymore. Instead I (try to) listen carefully to understand what’s the difference between expectations and reality. And more importantly, I try to understand what pain is the person, providing the feedback, experiencing. How could I reduce that pain?
Heart Rate In a Simulation
As I’ve mentioned in previous blog posts, I participated to Problem Solving Leadership (PSL) course earlier this year. Out of the many things that I learned there, there’s one that I wanted to write about this time. Heart rate in a simulation The course lasted about 6 days. On one of the days there was quite long (6 hours) simulation. It was basically a group problem solving simulation which required people to choose roles and if you didn’t have any particular role, you had to find other ways to provide value for the whole group (24 people). Personally it was challenging for me as I didn’t have any particular role. Instead I helped when I saw an opportunity. Like asking if people had consider specific scenarios in their plans. These moments didn’t occur that often though during the first half of the simulation. This led to me being an observer numerous times. Which felt uneasy. Fortunately around middle of the simulation I was able to find a role in which I could provide value constantly until the end of the simulation. I was wearing my Fitbit Charge HR activity wristband during the simulation and it recorded my heart rate on that day. When I afterwards reviewed it, I was a bit surprised. It looked like this: Time is represented as 24-hour clock, where for example 15 is 3pm. We had several observers (4 or 5) for the simulation. They were focusing on observing us and making notes. Afterwards they gave an overall report of what they had seen. In my case one of the observers mentioned that: 3:15pm Aleksis starts to participate to groups with Sergei If you look at the heart rate, you can see that the heart rate starts calming down close to 3pm (15) and pretty much keeps stable until the end of the simulation (18 which would be 6pm). What could this mean? My personal conclusion is that being able to find your place on a group can affect on your heart rate. On the other hand not being able to find a way to provide value for your group, can cause your heart rate going up and down. It’s always possible that Fitbit wasn’t measuring correctly, observer recorded the time incorrectly or perhaps I was just nervous about the simulation regardless of had I found my place on the group. Or perhaps this is the effect that, not being able to provide value (constantly) can have on our heart rate.
Maybe We Should Focus On Essential Complexity
Fred Brooks wrote his famous paper No Silver Bullet - Essence and Accident in Software Engineering 30 years ago. I think I personally heard about the paper first time when listening a talk by J.B. Rainsberger. He talked about the concept of essential and accidental complexity. Where essential is the complexity of the problem we are trying to solve. The part that we can’t get rid of. Space X and Hyperloop are good examples for cases where there exists a lot essential complexity. Accidental complexity on the other hand is complexity that could be avoided. It’s about us. People developing the system. And the lack of skills (or discipline or whatever reason) to develop the system in a way that doesn’t cumulate technical debt in the long term. How essential is essential? This is a good question though. Is essential that essential in the end? Let’s see what Brooks also wrote in his paper: Hence we must consider those attacks that address the essence of the software problem, the formulation of these complex conceptual structures. Fortunately, some of these are very promising. …Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements. Even Brooks discussed in his paper about attacking the essential complexity. Considering that it’s 30 years since he wrote the paper, I don’t know how far we’ve come since then. If we put Space X & Hyperloop aside and consider our everyday essential complexity, which would be what client / customer is asking from us and that we end up building. Every feature you build will increase the complexity of your overall solution. If you’re really good at your work, then perhaps you will be able to keep that complexity not increasing too quickly. But how large proportion of all of those features that you’ve added (or changed) to the product, will cause a verified impact to the behaviour of the people whose life the product touches? Considering the increase in the complexity (e.g. code, tests, documentation), we should aim at maximising the probability of having a real desired impact to the lives of people who use our product for solving their problems. Even more important - we should have some kind of hypothesis when we are coming up with idea about a feature to add. What kind of impact will it cause? How can we conclude that it was worth building? We should widen our scope of focus Based on my short experience in this industry I’ve seen focus being mainly something like this. We are getting really good at turning those ideas into more realiable and closer-to-goal solutions. While cutting down the lead time and tightening the collaboration. But I still think there’s a lot room for improvement. Especially before we start building and when we deploy those ideas into use. Before we start building I asked people on Twitter if they know approaches that help people explore ideas when trying to figure what to build. With the help of my fellow tweeps, I was able to list several approaches for potentially cutting down that essential complexity when people are just coming up with ideas on what to build. Here’s a list of these approaches (I would appreciate to hear if you have something to add): 7 Product Dimensions https://www.youtube.com/watch?v=x9oIpZaXTDs https://www.discovertodeliver.com/index.php https://www.ebgconsulting.com/Pubs/Articles/StrengthenYourDiscoveryMuscle(Gorman-Gottesdiener).pdf Impact Mapping] https://github.com/impactmapping/open-impact-mapping-workshop/tree/master/educational-workshops/concerts-online Example Mapping https://lisacrispin.com/2016/06/02/experiment-example-mapping/ **Validate Your Ideas (experiments) with the Test Card** https://www.youtube.com/watch?v=cW46ySJmLD8 Story Mapping https://www.thoughtworks.com/insights/blog/story-mapping-visual-way-building-product-backlog Lean Canvas https://leanstack.com/lean-canvas/ Elephant Carpaccio Elephant Carpaccio facilitation guide Product Tree https://igoprod2.wpengine.com/prune-the-product-tree/ https://www.agilealliance.org/resources/videos/awesome-superproblems/ When we’ve deployed ideas into use This is a more challenging one and depends on what kind of technology stack you are operating with. Nevertheless, if we don’t investigate in anyway how the features that we deploy, impact to the lives of people who use our product - how will we know that we have deployed something that was actually valuable? Another aspect comes from our ability to come up with ideas that provide value for people who use the product. If we don’t validate those ideas, how do we know if we’re any good at coming up with ideas on what to implement? Awareness comes from having visibility. I recently had a lunch discussion about this topic and we were pondering about what to do if feature wasn’t useful? This is where it depends on what kind of technology you are operating with. In the end you would need to have a possibility to take away features that were not valuable. And this could be couple months after it was deployed to production (if it takes time to validate the hypothesis). What next? The point I was trying to make was that don’t take essential complexity as a law of nature. It’s a terrain that isn’t fully explored yet. Whether it’s about exploring those ideas before we start iterating them or validating them afterwards in production. This subject and those pink colored areas on the picture are something that I’m planning to especially (not forgetting the middle part) focus on my current employer. Let’s see where it will take us.
Scrum Is Not (Anymore) Software Specific Process Framework
Lately I’ve seen tweets (like above) about Scrum and how it appears to lack software development specific ingredients. Which I do agree - at least to some degree. It depends on what is Scrum. Few words about origins of Scrum Scrum (Jeff Sutherland & Ken Schwaber in other words) was influenced a lot by The New New Product Development Game article by Hirotaka Takeuchi & Ikujiro Nonaka in 1986. I don’t want to dive into the history of Scrum in this post, but if you’re interested, you might want to check out The History of Scrum and Lessons Learned from the First Scrum. I want to mention though, that first experiences with Scrum involved utilizing Extreme Programming (XP) paradigm. And also ideas from James Coplien related to daily Scrum meetings. So that was roughly 20 years ago. And it’s hard to say if the way that Scrum is applied in companies these days, reflects on what Jeff Sutherland had on his mind early 90’s. Because if you check Scrum Guide - the word ‘software’ is not mentioned even once. Which is one indication, that Scrum is these days higher level process framework that is by no means tied to software development. Scrum requires context specific software development patterns I’ve personally seen it mentioned many times that Scrum requires XP, in order to be truly useful software development process approach. And in a sense I can agree with that. Except that it doesn’t have to be necessarily XP. Whatever patterns suit your context and help you in meeting stakeholders needs most effective way. If XP is only thing you can come up with, then that’s perfectly fine. There’s an effort though also from Scrum Pattern Community for coming up with patterns that amplify the current superficial process framework of Scrum toward something that can truly make software development teams hyperproductive. I guess in the end any tool can be misapplied. It’s the same with Scrum. You need to first be aware of what you’re doing at the moment. Then one by one question the purpose of roles, workflow and artifacts of Scrum. By doing that you can better understand their usefulness to your context. After that you can think what else you need to make it a software development process framework that suits your context. But how many goes through that instead of blindly following the default approach? And is that then the fault of Scrum or people trying to blindly apply it without considering modifying it to their unique context?
The Future of Testing, Part 3
This is a three part blog post, where I will focus on first part summarizing a panel discussion about the future of testing. On the second part I will mention what is already out there. On the third and final part I will share what other people from software testing and software development community think about this topic. In this third and final part of my series of blog posts about future of testing, I will share what many of the people I respect thought about this topic. It’s good to mention though that I guided their responses a bit. While giving them also an option to approach it in the way that they personally consider the best for them. In order to give you enough context, I’ve copied below the email I sent to everyone (there were slight differences - because later I added the comment about having the freedom of responding to questions or whatever way (s)he prefers). Then you will have better understanding what people knew when they responded. The content of the email was: I’m participating 25th of May (my birthday actually) to a conference in Helsinki and joining a panel discussion there, where we will be discussing: What will software development look like in 1, 3 or 5 years How will that impact testing approaches Generally to get an understanding what’s going on now and in future and how that will shape the testing approaches we have. I planned to make a blog post about that discussion. It occurred to me though that it would be great to get couple comments about the subject from people I respect and feel have something to add to this subject. It would be even better if you would be able to share your thoughts and allow me to put them to my blog post later (mentioning your name of course - https://aleksistulonen.com) That’s it. Thanks! Before I will reveal the responses, I’ve mentioned the people here in alphabetical order. Responses are also in similar order. There were also couple people who haven’t yet answered, so I might add them later. James Bach (@jamesmarcusbach) James Coplien (@jcoplien) Lisa Crispin (@lisacrispin) Janet Gregory (@janetgregoryca) Anders Dinsen (@andersdinsen) Karen Johnson (@karennjohnson) Alan Page (@alanpage) Amy Phillips (@itjustbroke) Maaret Pyhäjärvi (@maaretp) Huib Schoots (@huibschoots) Sami Söderblom (@pr0mille) James Thomas (@qahiccupps) Jerry Weinberg (@jerryweinberg) Let’s cut the crap and get to what you came for. James Bach ([@jamesmarcusbach](https://twitter.com/jamesmarcusbach)) Software development is a big world. Some part of it will look exactly like it does today. Some part of it will look like it did 20 years ago. And some part will look a little different, but not much different. One thing I’ve found in 30 years is that deep changes are slow in coming. Context-Driven Testing seems to be gaining greater acceptance (I am very busy the past few years) but it will always be a small part of the pie. It’s too easy to sell dumb ideas from 40 years ago, and it’s too hard to sell skilled testing. James Coplien ([@jcoplien](https://twitter.com/jcoplien)) Things move slowly and I doubt we’ll be able to notice any trends in a year or three, and maybe not in five. What we do know is that children are starting to be taught programming in schools in a formal (i.e., they get a grade) way and on an unprecedented scale. I suspect they are being taught badly (anyone who knows enough about software to teach it at the elementary level is probably programming kids to have all the same mistakes that your generation has, and they probably didn’t get to be elementary teachers by being great programmers or testers). And while they may not be on the streets in five years, there will in any case be more and more autodidactic programmers — I was seeing this already 12 years ago. There will be more and more programmers developing more and more code. There will be more and more emphasis on basic programming (because it’s fun) and less and less on testing (because it’s not fun, and most grade school assignments will be, by most measures, too trivial to be worth any savvy testing effort). The average number of developers working on a given product will drop, though the standard deviation will greatly increase at the same time. More and more software will be developed by individuals (a rough study of GitHub found that about half the projects there have a truck factor of 1, another 25% of 2). So I think we’ll see more and more software developed with a cowboy heritage. How much of that affects the commercial sector is uncertain, but I haven’t seen any mass software vendor take quality seriously. Some of the EDA, telecom and aerospace people do, but I suspect we’ll see slow erosion in those areas as real testing domain expertise retires, never to be backfilled by the university-educiated (or grade-school-educated) new hires. This domain expertise grew as the first and second generations of programmers bootstrapped themselves into the workable techniques — techniques arcane enough that they never made it into academia. The next generation of programmers cut their teeth on code before faced with the grim reality of real customers, let alone real customers who needed the reliability of a financial system, an aerospace system, or a system supporting social infrastructure. If there are still testers, and if testers are still a profession, they’ll become increasingly removed from the autodidact-driven efforts and will also, as a community, suffer from the brain drain at the hand of the retiring pioneers. The one-person dev shops won’t want to double their costs by hiring a good tester in the local market. Software quality broadly will suffer. Companies will become embarrassed, and the go-for-the-quarterly-result effect will cause companies to throw more and more outsourced “monkey testers” at software. Knowledge of scripting tools and management tools will be what defines the tester of the future; the current dearth of statistics mastery and economics knowledge among testers will only grow worse from its current sorry state. Geez, maybe we’re already in the future… Lisa Crispin ([@lisacrispin](https://twitter.com/lisacrispin)) What will s/w development look like in 1-5 years? Continued innovations in languages (elm, for example) and tools will bring change. It seems to me that there is some focus in using tools and languages like these to help prevent defects and build quality in. I hope I see more and more cross-functional teams collaborating together, with skills and capabilities trumping roles. I hope people will be less locked into a role. For example, if a tester pairs on writing some production code, or a programmer does some exploratory testing, nobody should think that is unusual. How will that impact testing approaches? I think we’ll continue to see delivery team members shift to a more agile mindset and get better at collaborating across the team and with the business to build quality into their products. I think (or hope) delivery team members will value learning domain knowledge more. I hope more teams will adopt techniques such as story mapping to build shared understanding of their product and features, and identify the valuable slices to build first. I see more adoption of practices such as ‘Power of Three” or “Three (or four or more) Amigos” approaches, using techniques such as example mapping, and I think this will continue. I hope we will see more companies valuing a learning culture and allowing teams to self-organize. I’m seeing more diversity on my own team, and I hope we will see more of that in our profession in general. These things are all critical to innovation. Amazing automation of CI and deployment and practices such as github flow to allow teams to manage delivery is a reality already. As a tester, this takes away so much time I used to waste either deploying things to a test environment that I had to maintain myself, or putting my detective hat on to see if the CI passed for a particular commit and what environment it might have gotten deployed to. On my own team, developers are doing better and better at TDD and BDD, they are starting to do effective exploratory testing, they have such good clean coding practices that other testers and I have a lot of time for exploratory testing. We do so much as a group, for example, doing exploratory testing charters as a group on a new feature before we deliver it to beta. Mob programming and mob testing are catching on. Testers will continue to add value as “big picture” people, helping to build the shared understanding among the amigos before we write code, helping to explore and learn more about the features as they are delivered, helping to get fast feedback from our customers and translate that into new features and new tests. I see a future of lots of collaboration, all of us getting to learn in many areas, and being proud of the valuable software that we deliver frequently at a sustainable pace! (to borrow from Elisabeth Hendrickson a bit). Janet Gregory ([@janetgregoryca](https://twitter.com/janetgregoryca)) A couple of my ideas on the future of testing. First, I hear the term “shift left” a lot, especially in Europe. I have a blog post coming with more detail, but my opinion about it is that it is too linear. I know it is meant to get testing earlier in the process, but what I’m afraid it might generate is more “big up-front” design. Where is the stopping point? Instead, let’s think of testing early and often, and keep it more of an infinite loop of feedback vs a linear line. I also do not think testing is a service – anymore than programming is. It is, and should be treated as part of the development process. I don’t like that teams are looking only for tester’s with programming skills – it shows me that those organizations still don’t value testing skills. That said, there are contexts where it does make sense. For example, if your team was creating an application that was going to be delivered to another development team – such as a web service, or message handling system. I do think that testers need technical awareness though. They cannot live in a bubble without being collaborate with programmers. Lisa Crisping and I wrote a whole chapter on this in “More Agile Testing”, and it is available as an ebook from Test Huddle. Applications are changing so rapidly, that testers need to keep up to date. I think there will likely be much more specializations – such as testing mobile apps, or concentration on security. We will learn to work closer with programmers to consider performance and load and scalability within the applications themselves rather than thinking about that as a separate and late testing activity. Anders Dinsen ([@andersdinsen](https://twitter.com/andersdinsen)) I’d like to introduce two metaphors for types of testing: Supermarket testing and hospital testing. In many projects we test things that are built and implemented rapidly, developed incrementally and very often in direct response to the needs of users. Thanks to better and richer platforms, software increasingly does not need to be developed from the ground up. Instead standard solutions are adapted and customized to fit to the needs of the customer. Small teams can now build systems that were previously very difficult to implement and required thousands of people. Further, the borders between what used to be complex and is now simple are continuously moved. Testing in such projects is often agile, rapid, informal, and highly value and user driven. The type of testing taking place there is what I call “supermarket testing”: Because what we test is simple, comes in a limited number of categories, skilled testers can rapidly and efficiently test almost anything without much knowledge. Testing performance depends on individuals’ performance. Hospital testing is at the other end of the spectrum and I call it so because hospitals are very complex organizations. They involve a great deal of logistics, and the organization is both very hierarchical, processes oriented and formal - and at the same time a knowledge organization. This apparent paradox creates tension that keeps the hospital in an excited state. It is moving. Always awake. A lot of testing is taking place in similarly large, complex organizations, where products are developed both by vendors and in-house. Products may be simple or are very complex, but they are nearly always very mission critical. For this reason processes, standards, metrics and measurements are used extensively in these organizations to manage and control processes in the organization. Including testing. The performance of the hospital is based on the organization. Not the individual. Hospital testing is in a crisis and needs to develop. Despite processes, standards, metrics and measurements, hospital testing does not find and report the important problems in the projects. We experience frequest delays and losses, even scandals. People are loosing confidence in what large solutions we can build today. Supermarket testing may seem to be the solution. It seems not not to be in crisis, but the truth is that it fails to help solving the problems of many organizations: For despite the rapid, agile and value and user driven testing taking place in super market testing, this type of testing does not deal with the complex systemic risks that haunt the large organizations and their critical systems. Further more, being based on the performance of individuals’ and small teams, it scales horribly. In this perspective, testing is not living on a burning platform. Testing is on multiple burning platforms and things need to change. The future of testing will address this problem. We will see new structured testing approaches emerge which take the systemic risks seriously and qualifies them. In the future, testers will no longer look for root causes of problems, but look for properties of the components for the systems being tested that indicate that something, somewhere can potentially develop out of control. We will test to look for fragility and appreciate when systems (including the humans being part of them) have anti-fragile properties. Only that way can we keep helping build a safer, more sustainable and better world. Karen Johnson ([@karennjohnson](https://twitter.com/karennjohnson)) The field continues to evolve and will, of course, continue to do so. If I look at software development and testing in the past three decades, I see an emerging field that practically needed “all hands on deck.” By this “all hands on deck” expression, I mean that many people joined the computer field whether they had a background or education in the field, and the industry quickly consumed (and needed) those people. Many people in the field (myself included) were self-taught. Now as the computer industry matures – as well as the programming languages, tools, and practices – the field is changing. Software development in the next 3-5 years may increase in some areas such as mobile development but may slow in other areas such as website development. Also, where people are physically employed is shifting from North America to other countries. Overall, I don’t see the field “booming” as the field did in the beginning. As part of that slowdown, facing a future in computers may become more difficult to achieve without the computer science education or background. No longer does the field look for “all hands on deck” as much as getting the “right hands at the best price.” (And of course sometimes those two goals are in conflict.) This means opportunities may slim, education and background may be required; and the majority of the work may take place in countries outside of the United States. A current hot topic is test automation and whether the future holds a place for manual testing. This topic has been a hot topic for some years but has surfaced again with more strength and more argument. With the increased use of Agile development and automated testing, there will be less opportunities for manual testing. That does not mean that there is no space for a self-taught manual tester, but those opportunities will be less in abundance than in the past. In discussing this topic at several testing conferences domestically (in the United States) as well as internationally, I’ve said that if you want to be a manual tester in the future, the pressure to be a “rock star” tester is increasing. Simply put, the positions will be fewer and the need to be excellent at the craft will be essential. If I look at the industrial revolution – and certainly this period will be seen as the computer revolution – there were many jobs in the beginning ,but as the field matured, the number of jobs decreased. The same will be true in testing – the number of jobs will decrease. For some companies, particularly those companies that don’t value testing, they will continue to look for the cheapest labor available and may forever fail to realize that skilled testing cannot always be automated and that cheaper is not always better. Alan Page ([@alanpage](https://twitter.com/alanpage)) What will software development look like in 1, 3 or 5 years How will that impact testing approaches Nothing super-different from me here. I expect that more companies – even those not shipping weekly or more often, will still move toward more agile-ish engineering approaches (smaller iterations, smaller batches, build->measure->learn). Data collection and analysis will also continue to grow in importance and use. To me, it means more teams forget about what to call people and integrated / unified engineering teams become more of the norm, and dedicated test teams become rarer and rarer. The good testers will do fine on these teams, as I expect that as more teams move in this direction that they recognize the need for a quality specialist among an “engineering” team. I don’t know that any of this changes testing approaches. Software developers are certainly capable of writing good unit, functional, integration tests and more – and they’ll be doing a lot more of this. The testers who do well on these teams will concentrate on risks to customer experience, and let the developers take care of functional correctness Amy Phillips ([@itjustbroke](https://twitter.com/itjustbroke)) What will software development look like in 1, 3 or 5 years I don’t think software development is going to change too much over the next few years. Agile will continue to be around, and continue to add value to teams who succeed in opting it. Others will continue with Waterfall/Agile attempts and continue to fail, or succeed. I hope to see more teams adopting DevOps approaches (Get Ops teams collaborating with Dev teams), and with this maybe making releases becomes less problematic and maybe more frequent (for some teams). I think the biggest change is going to be in the type of software development taking place. Mobile will continue to grow, and APIs will continue to lead to connected applications. I hope we see a rise is AI, blockchain, and IOT. How will that impact testing approaches Testers are going to need to become more comfortable with new technology. Frequent releases and improved automation tools are make web easier to release and therefore patch fix. As this continues the need for thorough testing will reduce (for most projects). That doesn’t mean testing is dead, it just means we’ll need to focus on the things that are higher risk/more unknown. For example Testing self-driving cars is going to be a huge, and largely unknown challenge. On a very personal note I hope testing becomes more of a collaborative role. I would love to see an end to the us vs. them conversations in testing and development. I hope that as more teams see the value DevOps brings to developers and ops people we’ll start to talk more about joining testers with developers. Other things that are going on Awesome testing communities are emerging (thanks to people like Rosie Sherry, Tony Bruce, AST, Let’s Test, etc). I hope this will encourage testers to reach out to others, learn new skills, and stay enthusiastic about the craft. Maaret Pyhäjärvi ([@maaretp](https://twitter.com/maaretp)) I don’t think much will change yet in 1, 3 or 5 years, other than that our approaches continue to diversify: some companies will embrace the devops-style development and continuous testing, while others figure ways for releasing in small batches that get tested, and others do larger and larger batches. Esp. in the bespoke software sector, the forces of how to make money are so much in favor of waterfall that it takes decades for that to change. But if there is a trend I’d like to see in testing, it’s towards the assumption of skill in testing. Kind of like this: - black-hat hackers are people who learn to exploit software for malice. - white-hat hackers are double agents who exploit software for malice and then give their information to the companies for good - exploratory testers are white-hat hackers that exploit software for any reason and give that information for companies. From compromise to more dimensions like “hard to use”, “doesn’t work as intended”, “annoys users”. - because exploratory testers are more generalized version of hackers, exploratory testing will go away at the same time as software hackers go away. You get AI that write programs, but will need exploratory testers to figure out if programs that are produced are what you want. Huib Schoots ([@huibschoots](https://twitter.com/huibschoots)) I don’t think software development will dramatically change the next 5 years. Many companies are doing agile already and more will start doing agile. I do hope they will get better at it, since I see a lot of “fake” agile around. More and more companies will start implementing CI and CD. Also more companies will try DEVOPS. This has an impact on testing. This means that more stuff will be automated, also many checks will get automated. Scaling agile will be important, since many companies have implemented agile development and will now try to scale it to the whole company. Impact on testing will be minimal. I think some companies will try to get rid of testers, but they will find out that they need testing skills in their teams. I have seen this in the Netherlands with several companies. They misunderstood testing and thought that developers could do the testing easy (BTW this was also motivated by the many “old school” functional testers they employed). As started when agile came around, the need for testers to do excellent testing will continue to grow. Testers do not need to be programmers to be able to automate checks, but they will need to become more technical. By that I mean that they have to get involved in unit testing, TDD, etc. They also need to make sure the right checks get automated. So deep understanding of automated frameworks, understanding of software development, insight in how coding works, being able to perform code reviews, etc. Sami Söderblom ([@pr0mille](https://twitter.com/pr0mille)) Q: What will software development look like in 1, 3 or 5 years? A: I think the hype around DevOps will grow and reach even the most resistant places within 1 to 3 years. I’m not that keen on hyping about the culture and activities around it, because that was something we were doing when I started in IT over 12 years ago. A lot of it falls under common sense (whatever that may be :). The technology is however something worth hyping about. Tools in modern build and deployment pipelines, containers, higher abstraction levels in coding, etc. are closing the gap between programmers and people who focus on other things. They lower the bar of us mortals joining development work and being useful at it. And I’m not talking about just testers, but everyone who has a stake at delivering company’s products and services. Technology that enables this kind of teamwork is worth hyping about. But 5 years ahead… I have no idea. Whatever quess I’d make would probably be wrong, so let’s move on. :) Q: How will that impact testing approaches? A: From what I’ve seen, testing will be and actually already is done faster and more tools will be used to aid it. What happens in development already and especially what will happen within the next years will put us testers into a test. We will be stripped down from our comfortable life of fiddling around with nonsense, and driven into a chaos. But this is not a bad thing. I welcome the idea in a sense that, because everything moves so quickly and with less and less resources, we cannot afford to build and maintain massive test case libraries, uphold cumbersome ceremonies, and ultimately focus on something other than testing itself. Skill becomes imperative. Skill to master testing itself, and the tools used in it. Chaos is cakewalk to the skillful. :) Of course there is always the discussion whether we need testers or not. I think that the more we have to explain our relevance, the more we become irrelevant. We can point out our relevance through our actions. By joining development teams and through hands-on work we can matter. Even though our co-workers may know a lot of things from the realm of software testing, they choose to focus on other things. They live by other incentives. Digging for information (which is the ultimate goal of testing) often requires going “against the grain”, asking the hard questions and looking into directions no one else is looking. We are the masters of that, because we choose to focus on that. Skillful in testing. And where as our primary focus is on risks, we can also find information about new technologies and possibilities altogether. Just yesterday I kept a workshop to a group of 20 developers, who were doing marvellous things, but who - due to the reason they focused on something else - had very little knowledge about certain crucial quality dimensions and techniques that could help them to pinpoint certain risks with minimal effort. I could also share my experiences on deploying tools and approaches that are widely used in DevOps environments, because I’ve had the luxury of working with some of the best in that field. At that point I wasn’t just a tester. I was a part of the development team. A relevant part. What I’ve done in testing and as a tester for these 12+ years helped me in that. James Thomas ([@qahiccupps](https://twitter.com/qahiccupps)) [1] What will software development look like in 1, 3 or 5 years? If I was answering this kind of question for a panel discussion, these are some of the kinds of things I’d be thinking… “Software development” is a big topic. It’s has been in the past, and is now, an extremely diverse discipline and I would be surprised if that changes in the short or medium term. Its diversity comes in many flavours. For example; the applications being developed, the technologies used to develop them, the methodologies used to service that development, the people selecting and working in those methodologies, the companies in which those people work, the needs and desires of the customers of those companies, … So, a glib answer: I doubt the big picture will change very much. If we want to look for smaller pictures, though, I might ask what factors of software development we could consider. Some I’ve mentioned above; others might be: practices, roles, gender differences, thought leaders, the positions put forward by thought leaders, perception of success vs failure for development projects, public perception of success vs failure, skill levels of software engineers, roles and role titles and role separation, attitudes towards certfication, … If we want to predict change (including no change), I might ask what kinds of metrics (formal or informal) I would consider worthwhile comparing between now and then. These would naturally differ with each factor and for each I would wonder what data I could find to analyse that would give me some basis on which to establish a view of “now” and form a view on how it would be reasonable to project forward to a “then”. I would take a view on whether to actively look for the predictions of others. I believe there’s a tendency of predictions to converge towards a norm if the predictors see each other’s predictions because people tend not to want to be outliers or to suggest radical change is likely. (Similarly with experimental results in science.) I would want to be clear about the extent to which I think that any predictions I made were general and how much they are biased towards my own relatively narrow view of the industry (I have been at the company that I founded for 15 years and had no commercial software development experience prior to that). Having said all that - and given that I’m not on the panel, am only serving a provoker of ideas for you, and so feel that I can be less rigorous in my research and more off-the-cuff in my predictions - here’s a few things from what I’ve been reading and hearing and from thought experiments: continued trend towards what we might call “disintegration” … more and more dependencies will be distributed and outside the control of the creator of any piece of software. … my application will rely on third-party libraries, on third-party APIs, on third-party hardware, … … none of which is directly under my control and much of which is pulled in at /runtime/ continued trend towards faster and faster roll-out of product in smaller and smaller increments continued trend towards a profusion of devices (including Internet of Things) and platforms in which users expect products to run … and ways in which they expect their data to “just” be available on and synchronised across them security - at small and large scale - will continue to be a major headache. … new devices and software will be vulnerable at the consumer level; new services and software will be vulnerable at the corporate level. software will continue to become “self-learning” and consequently less-understood by anyone. ** [2] How will that impact testing approaches? So, in the same vein, here’s some possible outcomes: the disintegration of “the product”, platform profusion and faster roll-out … is likely to lead to increased pressure to automate combinations of configurations … but in turn might call for smart ways to decide what to test and how to test it and when and where … and prompt questions about what the boundaries of any product are: where does “our stuff” stop and “their stuff” end? … and for whose benefit will we be trying to draw that distinction: ourselves, our company, our customers? … and will the decision be the same in each case, context, time? (Answer: no) security problems will put pressure on testing teams to provide “certainty” and reassure stakeholders that “this will never happen again” … when big, public projects fail, this pressure will be even greater … perhaps there will even be public debate about what testing means and should be … and if there is, perhaps also public debate about what software development is and looks like, so that the public might understand it better … as most people probably have some idea what factory work looks like these days, but probably little about what a software house does. “self-learning” systems will provide hard questions about what “expected behaviour” is … and testers (and the people they serve) will need to decide the extent to which they care to /understand/ vs /observe/ Jerry Weinberg ([@jerryweinberg](https://twitter.com/jerryweinberg)) Jerry’s response requires a bit explanation because I went through this subject in a lunch conversation with him. I regret of not having for example voice recorder or making notes during or after the discussion. But the key point of the discussion, and what Jerry thought about the future of testing, is summarized in following quotation from one of his books (Change Planned and Unplanned): For an engineering discipline, though, forty years is not a very long time to mature. One difference, then, is that we’re a very young engineering discipline, and maturity tends to mean reliability. In steam boiler engineering, for instance, on a capacity basis, the safety of boilers increased by a factor of 1013 in the 110 years between 1850 and 1960. Put another way, if the safety of boilers had not increased by a factor of 1013, we would all be dead, many times over, killed in steam boiler accidents. Of course, we would not actually all be dead, for without great increases in reliability, the boiler industry would never have grown to the enormous size it enjoys today. Even so, in 1955-63, 29 explosions occurred, with 32 deaths and 31 injuries. Like software engineers, mechanical engineers don’t think that’s good enough, and many of them study successes and failures to improve their record. I’ll leave it for you to figure out how this metaphor is related to future of software development and furthermore, future of testing.
Weight Loss and UX
Roughly year ago I decided to change my diet after realising my weight had gone close to 90kg. Which was almost 20kg more that what I weighted in army 12 years ago. But this wasn’t actually first time my weight had gone this high. Same had happened gradually before the army. I managed to drop it though in 6 months from 90kg to 69kg just before I went to army. I didn’t add any exercise to my daily life, instead I switched to Montignac Method. Now 12 years later, I decided to take the same approach, as it worked before. Difference being that this time I would stick to it rest of my life. It’s been now, as I mentioned, roughly a year since I changed my diet. I’ve lost 15kg and my weight has been pretty much the same (around 75kg) for past 4-5 months. And I’m satisfied with this weight. Nevertheless, weight loss is still rather big. It was interesting though how a colleague of mine hadn’t noticed the loss, until I mentioned it to him. Mainly because we work together on daily basis. Then again people I see rarely did notice it more easily. Or at least commented about it. How weight loss is related to UX? I was involved with testing of a e-commerce solution for past couple of years. In the early days of it, the usability of it wasn’t that great. Then again we were more than busy with testing integrations, performance and for example core functionalities of the solution. There’s just that when time goes on, it’s easy to get to a point where you are ignoring all those little usability issues. You say to yourself: It’s just one small issue. It’s not a big deal. But. When you add a lot of nothing, you get something. After a year a tester joined our team. And she was a type of tester who wouldn’t tolerate poor usability. One issue after another she started reporting and raising up those issues she observed. We let her do it and little by little developers fixed those issues. Then one day, after a release, I realised that the usability of our product had went from poor to good enough. One bug at a time our new tester had got us to improve the product. And the improvement was certainly something. Instead of nothing. This reminded me of my weight loss. It was difficult to notice the weight loss for people who were working daily with me. But on longer time scale, the difference was evident. It also had lesson for me. If you want to see a change, start now All that time we were avoiding bringing up those little usability issues (of course a lot of issues missed also because it’s a skill of its own to recognise usability issues) because they were so small compared to many others. But in many cases, major changes come from several small accumulated changes. Same applies to a diet and weight loss. Through numerous little daily decisions you can get significant results in long term. It just requires discipline, knowledge on what to focus on and willingness to start now.
Problem With Failure
Every now and then there comes a tweet, blog post or article about failure and learning. And there’s always something that is bothering me. Which is why I wrote a blog post long time ago. This time I will tackle it from a bit different angle. Let me explain. Failure & Root Cause When you will mention that from failure comes an opportunity to learn. What is it that you will learn? I would say that there’s often a hidden assumption related to recognizing how you need to change your behaviour. In other words, finding a root cause. It’s just that I don’t believe there is THE root cause. There can be a cause. And many others besides that one that you have found. Which was something that Matti agreed also. Simon though provided interesting opinion related to root cause and its usefulness. Heuristic being (according Oxford dictionaries): Enabling a person to discover or learn something for themselves Which brings us back to learning. Let’s try to wrap this up. What are you actually learning when you fail? This is a good question to ask from yourself. Before we go to that, is the world full of only failures and successes? We, humans, have a habit of thinking in binary. That there’s only two ways to label an observation. It’s either failure - or success. Is that the only way to look at it though? As Jerry Weinberg said: There’s no failure, only feedback. You could add to it: There’s no failure or success, only feedback. Point being, you’re pretty confident of yourself if you’re able to say what’s a failure or success. And in the end - how useful is that labeling for you? So perhaps the biggest learning in the end is that you labeled something like this as a failure? What does that tell you about yourself? Why is this important enough to be labeled as failure? And that could be important.
The Future of Testing, Part 2
This is a three part blog post, where I will focus on first part summarizing a panel discussion about the future of testing. On the second part I will mention what is already out there. On the third and final part I will share what other people from software testing and software development community think about this topic. In this second part I will briefly list some of the articles, videos, blog posts and podcasts I found while familiarizing myself with this subject (I dropped few away from the list as they required registering to a site). I’ve divided them to ones that focus on software development generally and ones that focus on testing specifically. Let me know if there’s something out there that should be on the list. Future (and related: current challenges) of Testing Simon Morley - Some Software Development & Testing Challenges 2016 Valerie Silverthorne - Facing the future of software testing one change at a time Joe Montvelinsky - Testing in 2020 Patrick Prill - Reinventing Testers and Testing to prepare for the Future Kishen Simbhoedatpanday & Alan Richardson - Future Of Testing And Automation: The Role Of The Tester In 2020 Joris Meerts - The Real Future of Software Testing Matthew Heusser - The future of software testing: How to adapt and remain relevant James Bach - Test Jumpers: One Vision of Agile Testing International 2016 State of Testing Asaf Yigal - How DevOps is Killing QA Paul Gerard - DevOps is killing QA. Really? Rich Rogers - Opportunities and Threats Part One: Prophecies of Doom Colin Garlick - The Impending Extinction of Testers Future of Software Development 9 predictions for the future of programming Bret Victor - Future of Programming [talk] Leaked transcript of censored Bret Victor talk a16z Podcast: The Future of Software Development Alexander Tarlinder - The Future of Software Development Ben Gilbert - This could be the future of all software development Steven Pemberton - Moore’s Switch, and the future of programming Software Engineering: The Next 50 Years Grady Booch - The Future of Software Engineering [talk] Grady Booch - The History (and the Future) of Software [talk] Uncle Bob - The Future of Programming [talk]
The Future of Testing, Part 1
I participated 25th of May on a panel discussion at Ohjelmistotestaus 2016 Conference in Helsinki, Finland. Our theme was testing trends and related to that, the future of testing. Besides me, there was also Erkki Pöyhönen (Lead Test Manager from Tieto) and Virpi Mehtälä (Test Manager from Prove Expertise). I dropped some topics from my blog post (e.g. one related to open source development and couple questions from audience) as I wanted to keep the content more compact. But otherwise this summarizes quite well the conversations we had. Current trends in software development This is where we started from and from my point of view it was logical to start from. Mainly because software development approaches affect to testing approaches. We were all given our opportunity to express our thoughts and this pattern repeated on following topics also. Virpi mentioned that risks are being focused on more these days (compared to what it was before) and that agile approaches are slowly affecting also contexts that she is working at currently. I personally tried to emphasize that contexts vary. In some domains (like medical devices) current trends (e.g. Continuous Deployment) can be challenging to apply. Also there’s much differences how sophisticated the software development approaches in companies are. In some teams, the approaches were more modern in 1950’s than they are today in some organisations. It can also take decades for many companies to achieve what has been achieved now in companies like Netflix or Amazon. Considering that it’s an approach that companies should strive for in their context. Nevertheless, out of frustration for not getting users needs met and taking too long, many different solutions have come to speeding up the time from idea to need being met. And to be able to keep that reliability (of producing high quality working software) on long term. Some of these examples are Scrum, Agile, BDD, TDD, Microservices architecture (in longer term perhaps systems that resemble biological organisms - see e.g. Wunderlist & Chad Fowler and Conscientious Software by Richard P. Gabriel), DevOps and Automation in Testing. Erkki talked how we’ve grown as industry out of silver bullet approaches and have these days several approaches for software development. Also these days it gets harder and harder to focus on doing something really technically specific thing. Or as a consequence you might find your company being bought and your skills not matching the new context anymore. He also emphasized how testing is a service and needs to follow what is happening around us. Virpi continued with saying that these days companies are focusing more on testing and the company she is working at, gets more and more clients because of this. This though requires constant development of personal skills. What trends cause excitement on panelists Erkki mentioned first containers and Docker. He emphasized how it is enabling DevOps actually being reality in daily life of development team. I personally raised Mob Programming and generally all the effort on improving the collaboration between members of the team. Related to this I mentioned cross-functional teams and a wish for breaking the silo between IT & business. Which would mean considering if organisation and physical locations could be more of a mixture instead of being separated to different locations. In other words, taking Conway’s Law into consideration more, as Maaret Pyhäjärvi (who hosted the session) brought up. Virpi was herself excited that testers are part of the team these days, instead of being separated to different place. She felt that she is being listened more these days and able to show her value. What kinds of trends are there in testing Virpi highlighted how these days (and in future) software is being released more quickly and there’s less time for testing it. Related to this she mentioned that more focus has to be put into thinking what’s the most wisest way to do your own work. I mentioned that these days there is not much testing related jobs that don’t require technical (usually programming) skills. Hard to say though how far this trend will go as it’s getting close to hiring just another programmer. And when you focus on programming, that’s mostly away from specializing in testing. Besides technical skills being demanded from testers, I also raised how I would personally hope to see that BDD kind of approaches get more common, where there’s more questioning happening before anything is actually implemented. I didn’t mention but it’s basically decreasing essential complexity (see Fred Brooks & No Silver Bullet). Erkki mentioned from his own context how there’s hypotheses being measured in production (related to Lean Startup) and this way own assumptions being verified, instead of just releasing features to production and moving on. He also emphasized that testers need to be these days able to question even the priorities of features that will be done. Besides these crowdsourcing (uTest) was also mentioned, which is one the trends that is good to know about. Skills of Full Stack Tester Not so seriously we collectively threw some ideas on what kind of skills should Full Stack Tester have. Some of these were Mobile testing (including automation) Automation generally (UI, API, Unit) CI, CD (including relevant tools: e.g. Jenkins, TeamCity, Docker) Cloud services (e.g. Azure, AWS) DBA, SysAdmin Performance, Security and Usability testing What should not-so-experienced tester focus on I interpreted this as joining a new company and understanding basics of testing. Then what should you focus on. Which is why I explained how one should try to understand how the team works and what kind of workflows there exists. After this one can start to consider what to focus on as tester (e.g. adding API checks, improving requirements, having heuristics to support exploratory testing). Virpi disagreed with me and told that basics of testing needs to be understood first, which is fair point as it wasn’t known how well this person knew about testing. She suggested BBST Foundations course which is a brilliant course for someone who hasn’t been in industry for a long time, or even if has been in industry for a long time. Erkki added to conversation by commenting that it’s good that people face different contexts and situations as it gives person perspective which can be valuable. How should companies prepare for the trends I tried to highlight on my answer that companies should first focus on recognizing what problems they are trying to solve. If you recognize that you really need to speed up the lead time - from idea to need being met - then you might pay attention to adding checks, DevOps, TDD, flow of work (e.g. WIP) and so on. But you need to understand which problems you are trying to solve with those. Virpi mentioned herself curiosity. And maintaining that in long term. After Virpi I raised self-awareness. Know where you are at the moment, before moving forward. As it’s often more valuable to understand what you are doing now than implement something new. We might have all kinds of diagrams for explaining our processes, but is that truly what is happening? Erkki tackled this topic by talking about focusing on answering what am I as individual able to provide for others. What is good enough? That you are not ending up spending too long hours at office while trying to keep up with changes in your work environment.
EU Data Protection Regulation
EU Data Protection Regulation has large impact on majority of companies in Europe (and abroad) on next few years. As far as I know, it shall apply from 25th of May, 2018. I don’t know nearly enough about the regulation yet, but decided to summarize information sources for myself on this page and perhaps they will be useful for others too. I will intend to update this in future, when needed. Summarizing the changes European Commission web page (see: Reform of EU data protection below on Information sources) had factsheets that covered the changes. Especially one that explained how citizens’ rights will change, was quite useful: Information sources Reform of EU data protection rules The EU General Data Protection Regulation is finally agreed EU data protection rules affect everyone, say legal experts A guide to your rights 10 things you need to know about the new EU data protection regulation Data Protection Handbook - (a bit outdated, but might be useful) Heuristics When it comes personal information, some things to consider What Name Street address Email address Phone number Vehicle registration number Location information Photograph IP address Phone recordings Video recordings Credit card number Bank account, salary or financial details Education Medical details or health information Fingerprints or blood type Religious or sexual preferences … and so on How (consider what is done to that information) Collecting Saving Organizing Using Moving Giving Storing Modifying Combining Securing
Why Did Not Testing Find This?
I’ve heard this question being asked several times in the past. When there’s a problem in production, one of the first questions often is Why did not testing find this? To be honest, that’s fine. I don’t see that being a bad question as it’s good to consider if we should change our testing approach in some way. What I don’t like about this is though that this is as far as it often goes. I’ve rarely seen people asking What is wrong in our development approach? or perhaps even better What will we learn from this? Because each problem in production is asking each of us look into mirror and consider how to grow as a team. As we are responsible of the quality of the product. Each. Of. Us.
Learn To Observe
Teams and organizations these days are focusing on continuously improving their way of work. Trying to adopt new development approaches, tools or ways to organize their companies. One crucial aspect is being forgotten often in the heat of the effort. That’s self-awareness and especially observation skills that can help you in achieving better self-awareness. Because, if you truly want to continuously become better at what you do, you need to be aware of what you are doing at the moment. What to observe and similarity to testing I recently wrote a blog post about Observation & Interpretation, where I discussed about the difference between observing and interpreting. I suggest reading that before going further in this post as I will continue writing from the perspective of that post. One challenge with observing comes on not knowing where to focus on. It’s a similar problem that you have if you are testing an application. I mean whole application. There’s so much to focus on that as a result you can end up wondering around without being able to gather enough concrete data about what you’ve learned. In testing you can try to structure your testing with heuristics. Using James Bach’s Heuristic Test Strategy Model, you could structure your testing to focusing on Function (Everything that the product does), Data (Everything that the product processes) or perhaps Time (Any relationship between the product and time). By structuring and focusing your approach, you will be able make more detailed observations. At the same time it’s good to note that skilled tester might explore freely an application without focusing and would still learn (a lot) about it. I would argue though that there’s some kind of structure often behind even that kind of exploration (e.g. focusing on what the product can do). What to observe when it comes to how people work with each other If you want to be aware how your team is working with each other, you need to be able to observe what’s actually happening. As with testing, you can structure your observations in several different ways. I learned couple interesting ways of doing that in Problem Solving Leadership course a while ago. MOIJ Model Jerry Weinberg introduced in the Problem Solving Leadership course (and I think in his book Becoming a Technical Leader) a model that consists of elements that are needed for a team to be able to solve problems effectively. This model can be used also for structuring you observing. Letters come from: M = Motivation Focus on your observations to notice e.g. supporting, encouraging, energizing, facilitating or peace-keeping O = Organization Focus on your observations to notice e.g. procedures, physical environment or time-keeping I = Information Focus on your observations to notice e.g. time to live of new ideas, summarizing, decision-making or clarifying J = Jiggling Focus on your observations to notice e.g. solving problems by going outside of boundaries of the rules or using jokes to defuse tension Other things to observe Besides MOIJ Model, there’s a ton of other things that you can focus on while observing. They are partly related to MOIJ Model, but approach from a different perspective. Styles of talking Are people using I, You or It statements? Questions? Declarations? Quotations? The way people talk to each other Do they wait that speaker has finished what (s)he has to say? Is subject being changed? How often? Do people answer to questions? Are everyone treated equally when it comes to listening and answering? Roles Who is being proactive? Who is being relied to? Who is being interrupted? Who is interrupting? Whose voice isn’t heard? Spacial observations How are people sitting? Do they change their place? What kind of furnitures are there (e.g. square table vs. round table)? How far are people from each other? Is there someone that is not close to anyone else? Are there noticeable groups formed? Who is sitting next to whom? Does it change? Non-verbal communication What kind of facial expressions people make when talking? How about when someone else is talking? Can you notice differences in tone of voice depending on whose question or comment is being responded to? What kind of posture people have? Do you notice laughter? Loud voice? Gender differences? Ethnic differences? Other differences? (e.g. consultants vs. in-house) Be careful when reporting observations Reporting observations is a delicate matter. Mainly because we haven’t got used to it. But also because people tend to give feedback that includes mind reading (read my blog post Observation & Interpretation) As a thumb rule, I would recommend not inflicting observations. Instead ask first if others would like to hear your observations. And then offer them if they want to hear them. That way there’s optionality which brings psychological safety especially in the future. Simple approach to structure your ways of reporting (one that I learned in PSL) is to divide it into Description (“This is what I observed…”) Interpretation (“This is how I interpreted what I saw…”) Significance (“This is how I felt about my interpretations…”) I haven’t asked from Jerry (Weinberg), but one can see similarity to Satir Interaction Model on those reporting styles. Knowing a bit about Satir Interaction Model, you realize that you need to be aware of the possibility of interpreting incorrectly what you have observed, which will lead to interpretation being incorrect. Or perhaps you observed something that just wasn’t there. That’s why it’s often really important to check the intake (What did I see or hear or smell or taste or feel… - also known as Data Question). As I mentioned on the blog post that I kept referring earlier, this is a skill that takes lifetime to hone. Perhaps the first step is though to acknowledge that we are not aware of what we are doing. That’s why we need observation skills to uncover what we are not aware of.
Purpose of a Tool
I think Bret Victor is among 5 people whose thoughts and work I pay close attention to. He has written several beyond great papers related to e.g. interaction design, climate change, designing programming systems or future of programming. There’s though one idea that has resonated with me lately. Mainly because I’ve been part of discussions about which tools to use as part of software development process. Bret talked about what a tool is in his paper A Brief Rant On The Future of Interaction Design. He defined tool as: A tool addresses human needs by amplifying human capabilities. Bret Victor https://worrydream.com/#!/ABriefRantOnTheFutureOfInteractionDesign A Brief Rant On The Future of Interaction Design That is, a tool converts what we can do into what we want to do. A great tool is designed to fit both sides. Many layers of needs When it comes to needs though, it’s good to note that needs can have many layers. If we think our example of using the hammer to hit a nail. Perhaps we are doing it to put a painting hanging on the wall. Based on the picture(s) above though you might think that getting the nail on the wall is our need. But if we want to hang a painting on the wall, I think our need would be at least to get that painting on the wall. It’s not stopping here though as it might be that our need is not putting the painting on the wall. It might be instead that we want to be inspired by watching the painting. Regardless of how many layers of needs there are, the important thing is to consider which needs we want to address and if the tool is even needed for addressing the needs that are on deeper layers. Whose capabilities? If we want to amplify our capabilities, we need to think whose lives our tool will touch. If the capabilities of the people vary a lot, whose capabilities will we prioritize when deciding which tool to use? It might be that specific tool is good for one group of people, but not for another who need to use it also. Take into account the capabilities of both when you’re deciding which tool to use. They will not be static In case of needs and capabilities, we also need to remember that they tend to evolve as time passes. This is also something that one needs to consider. How well does the tool adapt to users whose needs and capabilities change? Also if one day users will want to start using another tool, how painful will that be? Or how painful it is even to start using this particular tool?
Observation & Interpretation
Observation & Interpretation I participated to Problem Solving Leadership course a month ago in Albuquerque, New Mexico, US. You could write several blog posts about the course but there’s one particular learning that I want to write about. That’s the difference between observation & interpretation. Before going further, let’s define what I mean by those words. Oxford Dictionary can handle the definitions this time: Oxford Dictionary https://www. oxforddictionaries.com/us/definition/american_english/observation Observation A remark, statement, or comment based on something one has seen, heard, or noticed Oxford Dictionary https://www.oxforddictionaries.com/us/definition/american_english/interpretation Interpretation The action of explaining the meaning of something In our everyday life these to tend to get mixed. When we comment what we have seen, we have a habit of jumping to interpretations. We see a colleague closing a door in such a way that there’s a loud noise. And perhaps later we mention to him: I noticed you were angry. For me this comment would have been an observation earlier. But not anymore. Because you need to be able to read minds to make such a comment. And as far as I know, we can’t read minds. You don’t know what goes in other persons head. Even if that person is a person who you have lived with 30 years, you still don’t know. Sure. You can be right often, but that’s still different from actually knowing and making an objective observation that someone is angry. You cannot not interpret @jcoplien https://twitter.com/jcoplien/status/715885126681542656 @al3ksis You cannot not interpret @JerryWeinberg I felt after PSL that I will focus more on observations instead of jumping into interpretations. But then James Coplien tweeted that one cannot not interpret and it put my thoughts spinning again. We exchanged couple tweets but I moved the conversation quite quickly to email discussion between me, James & Jerry. This was one of those discussions I didn’t want to have on Twitter because of the character limitations. Based on our email discussion, I think James was trying to emphasize that our mind has a habit of interpreting, even when we are trying to focus on making observations instead of interpretations. Satir Interaction Model was also tightly integrated to our discussion as observations (Intake) and interpretations (Significance) are part of it. Jerry mentioned Virginia Satir on his own reply and how she had always pointed out we could not “not do something”. Don’t think of an elephant. Don’t tell me you thought of an elephant? That’s fine. As Jerry pointed out how Virginia always talked about accepting what is and building on it. We are humans. It’s normal that we jump to interpretations. We can still choose our response. Which is what I think Viktor Frankl has also spoke about: Viktor Frankl, Man’s Search For Meaning They may have been few in number, but they offer sufficient proof that everything can be taken from a man but one thing; the last of the human freedoms - to choose one’s attitude in any given set of circumstances, to choose one’s own way Interpretations will happen, but you can build on that as Jerry mentioned. Asking the Data Question can help: What did I see or hear or smell or taste or feel that led me to those interpretations? or you can open yourself to possibility of other interpretations existing: What other interpretations I could make based on what I saw or hear… What next From now on I will still focus on making observations (which I need to write a separate blog post about) instead of interpretations. But I will not blame myself of jumping into interpretations. Instead I will try to slow down the process between seeing or hearing something and responding based on that. Asking the data question. Trying to come up with several interpretations. And being patient with progress. I’m never going to be perfect in it.
New Site
New Site It’s been ages since my last blog post. One of the reasons has been that I created new homepage for myself but struggled with getting a blog there. Now after an year or so, I finally managed to shape this new site (with the help of my friend) to such that I can continue writing my blog on my own site. You can still find my old blog from the link on this site (top right corner). Otherwise I will be writing here my future posts. At least now I don’t have excuses anymore for not writing new posts.