 Okay, so the next bias we'll look into is the so-called availability bias. Availability bias is the tendency to focus on information that is readily available, that is easy to recall, and sort of ignore more complicated things that take a bit of effort. For example in software engineering what this means is again that we ignore unfamiliar parts, for example in the code or in the documentation or in the requirements, whatever we might have. So we tend to focus on the things that we know anyway, and then we base our decisions on that. And that of course is a quite dangerous tendency if you are the person that has to make the decisions, and that's really why the solutions to this or the ways to address this are for example any kind of participatory approaches. So participatory decisions, you make the decisions in a group, it's not an individual that decides for example how long the project takes. And that makes it more likely that for example you have more people familiar with different parts of the overall project and that can lead to a better decision. So this is for example one of the reasons why in agile teams you typically do everything together, it's not one leader, it's not for example the scrum master that says this is how we'll do it, you decide this together. Similarly as with confirmation bias we should rely on traceability, so we should have traces that link things together so that for example if you want to have information on where a requirement is implemented you don't just look into the part that you know anyway, you look into the code that is traced that is linked from the requirement. So that can be another way of addressing this. And then finally another agile practice, we have the retrospectives. So meetings, communication where you explicitly exchange information so that people get more familiar with what's going on and they're not just in their bubble focusing on their function or their class or whatever they're implementing right now. So this can be a good way of actually sharing information about what is done but also what is problematic or what is working really well. So that's availability bias, then we have the framing effect. And that's another one of the examples I gave in the beginning, so framing is this kind of way of for example posing a question in a certain way that leads to you reacting in an accordingly way. So I gave the example of how long do you think this little project will take and the little keyword is a way of framing my question that the person answering will think okay this is a small thing I have to answer with a low estimate. So that's framing. What's for example known in software engineering that is a difference if you tell people that you have some great ideas of what they could do in the project or you say that you have some requirements. And if you have signed a contract for example these requirements might not even be in the contract so it's not like people have to implement them. But still if you rather say it's a requirement that an idea people will react in a completely different way. They'll have in their head much more this idea of we have to implement this, it has to be exactly like this, it can't be anyhow different. So just by phrasing it differently the same request essentially can lead to a completely different outcome just by people reacting in different ways. So the solution to this here is really I would say mainly awareness that you need to be really careful with how you phrase things and what you ask people for because you can ask the same question in slightly different ways and the reaction will be rather different. How long do you think this little project will take compared to how long do you think this huge project will take us to implement. You will get very different estimates just with changing a single word. So please be aware of this that there is a lot of detail in how you frame questions, how you frame answers and so on. Finally in our list of cognitive biases is the bandwagon effect. So that's the effect that in a group people will adjust to the majority opinion or whatever they think is the majority opinion. So it's kind of this group thing that is known sometimes that there are a couple of people that have a very strong opinion and then the group maybe perceives this as that's what the majority thinks and they will adjust to this. So that is known as the bandwagon effect and that's problematic because for example people often tend to agree with the leader so there is a person that leads. Important here is leader does not have to be the manager, it's not necessarily the person that has most power but it's some kind of person that is leading that as for example very strong in communicating their opinions or very experienced and people might tend to agree with that person. Similarly they're related, very common I think all of you have probably at some point done brainstorming in a group and there is this effect which is the bandwagon effect that someone starts going in a certain direction and you might be sitting there thinking okay this is not at all what I was thinking but you probably start aligning yourself. You start going maybe that's the right direction, let's also go. So suddenly your brainstorming which is supposed to be really creative exercise is not that creative at all because the person or the first couple of opinions that are voiced basically direct the brainstorming in a certain way. So that can be very problematic if you actually want to be creative, if you want to have very diverging ideas and in the end it's the same thing a couple of people kind of lead the group in a certain direction and the others tend to align with that. Now what can we do here in general it's maybe again a good idea to have these participatory approaches so it's not just a couple of people that decide but then of course they will still align with their leader so sometimes we have these kind of parallel approaches so we had earlier with the estimates with anchoring we discussed that you can do parallel estimates so this will avoid this kind of brainstorming effect no one is first no one is saying I think it takes six months if you do it at the same time you get different opinions you can discuss them. Brainstorming in particular this is a creativity technique there are publications on this and there is usually a recommendation to start with what is called individual brainstorming so the way this is published in the literature is usually that you recommend that if you're a group of whatever a group of ten people each person individually starts thinking what kind of requirements could we have what kind of features could we have and then after five to ten minutes or however long you might think it makes sense you get together and you share the ideas and then you already have them written down they're already documented somewhere and it's more likely that you will actually voice your opinions and not just say I know I didn't have anything else it's just the same as everyone else so that might be similar to the parallel estimates and might be a good choice to get a certain diversity in opinions which you want to have in many cases so this concludes the small part on cognitive biases it's important for me that you get to know them of course I am not a psychologist and you are not getting an education in psychology but nevertheless this is exactly what I mentioned in the introduction video you can have brilliant people you can have really good technology but these in particular the other two we have discussed can be really really strong forces that pull you in a really bad direction so it's important to know about them it's important to not underestimate them and think that you are immune to these biases and essentially try to counter them in the real world so next video will continue with ethics in software engineering