Det går troll i mjukvarulitteraturen

 Gamla "sanningar"

Jag har läst en hel del mjukvarulitteratur och märkt att en del exempel är återkommande och anges med referenser till forskning. Jag minns inte att jag någonsin tidigare ställt mig frågan Kan det här verkligen vara sant? och börjat gräva i referenser. Till exempel läste jag "Facts and Fallacies of Software Engineering", en bok med en förtroendeingivande titel och en inledning som hyllar forskning, vilket invaggade mig i nån slags tro att den här författaren, han har gjort sitt undersökningsjobb. Men nu verkar det inte bättre än att han ramlat i samma grop som så många andra.

Om det är nån mer som är lika "lättlurad" som jag så skulle jag vilja rekommendera en bok som är något av en ögonöppnare "The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it", för där har författaren verkligen följt referenser och försökt hitta källan till flera av de här återkommande exemplen. Du kanske har hört talas om att forskning visar att det finns en stor skillnad, upp till 28 gånger, i produktivitet mellan olika programmerare? Eller sett The cone of uncertainty, som sägs beskriva osäkerheten i projektestimat vid olika tidpunkter av projektet?

Bilden tagen från https://www.construx.com/books/the-cone-of-uncertainty/

Vad tror du att författaren Laurent Bossavit hittar när han följer spåren av referenser för nyss nämnda exempel, och ett par till, allt djupare? Jo, till exempel att:

• the papers are not really empirical research
• the papers support weaker versions of the claim
• the papers don’t support the claim directly, but only cite research that does
• the more recent papers are not original research, but only cite older ones
• the papers are in fact books or book-length, and you’ll be looking for a needle in a haystack
• the papers are obscure, hard to find, out of print or paywalled, and thus hard to verify
• the papers are selected only on one “side” of an ongoing controversy

Som en som läst om de här exemplen återkommande gånger så tyckte jag det här var en riktigt intressant bok! Och jag har börjat bli lite mer ifrågasättande av författares referenshantering och även av forskningsresultat och försökt gräva själv några gånger. Slarv med källor och referenser verkar inte bara vara nåt som görs i mjukvarulitteratur, det förekommer nog överallt. Till exempel det här med hur juridiska domare dömer vid olika tider på dagen.

Med lite referenser så verkar allmänt kända sanningar kunna skapas :)

Early results were often criticized, but decades of research have now accumulated in support of the incontrovertible fact that bugs are caused by bugproducing leprechauns who live in Northern Ireland fairy rings. (Broom 1968, Falk 1972, Palton-Spall 1981, Falk & Grimberg 1988, Demetrios 1995, Haviland 2001)

Ger domare oftare en fällande dom när de är hungriga?

Välkänd studie

Du kanske har hört talas om studien som tittar på mönstret hur juridiska domare dömer under olika tider på dagen, att de oftare ger fällande domar när de är hungriga före sina måltider? Den är citerad i flertalet böcker, bland annat i:

• Thinking, Fast and Slow
  Delar upp hjärnan i två system, System 1 som är snabbt men slarvigt och System 2 som är korrekt men energikrävande. Studien passar in i tankarna i boken om att när energinivåerna är låga så sätter inte System 2 igång och System 1 tillåts ta slarviga beslut.
  
  
• Black box thinking
  Handlar om förbättringsarbete och hur det försvåras när berörda personers självbild krockar med fakta, t ex en domares självbild som ofelbar. Studien används för att påvisa behovet av förbättringar inom rättsväsendet.
  
  
• Life 3.0, Being Human in the Age of Artificial Intelligence
  Tar upp studien som ett exempel på var en AI skulle kunna göra ett bättre jobb, en robot-domare.

Jag tycker att det låter både troligt och otroligt på samma gång, men är studien tillförlitlig?

Om studien Extraneous factors in judicial decisions

Tre forskare, Shai Danziger, Jonathan Levav och Liora Avnaim-Pesso ville undersöka om det fanns någon sanning i talesättet justice is what the judge ate for breakfast. Är domare rationella eller påverkas de av yttre juridiskt ovidkommande faktorer som hunger eller mental utmattning när de dömer.

Deras forskningsartikel publicerades 2011 och handlade om en 10 månader lång studie där data samlats in under 50 dagar och täckte 1 112 domar, dömda av åtta domare. Domarna presiderade i två olika rättegångsnämnder för villkorlig frigivning som nyttjades av fyra större fängelser i Israel.

Dagarna delades upp i tre sessioner, med två måltider emellan. En domare dömde från 14 fall upp till 35 fall per dag, där ett fall i medel tog cirka 6 minuter.

Det de upptäckte var att andelen friande domar i början av varje session började på cirka 65 procent, för att sedan sjunka under sessionens gång och i slutet komma ner till nästan 0 procent friande domar! 

En fånge skulle ha 35 gånger större chans att få villkorlig frigivning om denne kommer först istället för sist i en session, enligt Andreas Glöckner.

Proportion of rulings in favor of the prisoners by ordinal position. Circled points indicate the first decision in each of the three decision sessions; tick marks on x axis denote every third case; dotted line denotes food break. Because unequal session lengths resulted in a low number of cases for some of the later ordinal positions, the graph is based on the first 95% of the data from each session.

Kan siffrorna stämma?

Studien har blivit populär och välkänd, men att "hungereffekten" eller "utmattningsseffekten" skulle ha så stor påverkan är det flera som har reagerat på. En motreaktion som inte alls fått samma genomslag.

Keren Weinshall-Margel och John Shapard har besvarat forskningsartikeln med ett brev, Overlooked factors in the analysis of parole decisions, där de - efter att ha intervjuat tre försvarsadvokater, en domare och fem fängelseanställda - tar upp några faktorer de tänker har förbisetts som kan ha påverkat utfallet.

Studien gjorde gällande att fallens ordning kom i slumpartad ordning. Men under intervjuerna framkom att det fanns flera saker som påverkade fallens ordning. Till exempel att alla fångar från ett fängelse skulle hinnas med innan man tog rast och efter rasten fortsatte man med fångar från ett annat fängelse. Inom varje session så var det vanligt att fallen med fångar som hade advokat hanterades före de som saknade advokat. Att företrädas av en advokat ökar sannolikheten till bifall från 15% till 35%.

En annan faktor var att både fall med avslag och fall som sköts upp räknades som avslag. Uppskjutning av fall förekom oftare senare i en session. Forskarna försvarade det med att för domaren innebar beslut om uppskjutning samma sak, att status quo bibehölls, ett lättare beslut att ta om man är trött. Totalt avslogs 64,2% av fallen, varav 48,4% var uppskjutningar.

Andreas Glöckner har också ifrågasatt studien och gjort simuleringar som påvisar att effekterna är övervärderade. En orsak han lyfter som påverkar de sjunkande kurvorna är att olika många fall hinns med i olika sessioner, vilket leder till att gruppstorleken minskar ju senare i en session de har hanterats. Så de domar för de senare fallen i en session med många fall får högre genomslag. Lägger man ihop det med att fall för fångar utan advokat kommer sist och att de fallen oftare får avslag så blir det i sig en sjunkande kurva.

Danïel Lakens avfärdar resultaten baserat på den orealistiska storleken av effekten med:

If hunger had an effect on our mental resources of this magnitude, our society would fall into minor chaos every day at 11:45 a.m. Or at the very least, our society would have organized itself around this incredibly strong effect of mental depletion. Just like manufacturers take size differences between men and women into account when producing items such as golf clubs or watches, we would stop teaching in the time before lunch, doctors would not schedule surgery, and driving before lunch would be illegal. If a psychological effect is this big, we don’t need to discover it and publish it in a scientific journal—you would already know it exists. Sort of how the “after lunch dip” is a strong and replicable finding that you can feel yourself (and that, as it happens, is directly in conflict with the finding that judges perform better immediately after lunch—surprisingly, the authors don’t discuss the after lunch dip).

Ja, vad ska man tro? Forskning och statistik verkar iallafall komplext :)

Referenser

Forskningsartikeln

Extraneous factors in judicial decisions 

https://www.pnas.org/content/108/17/6889

Brevet

Overlooked factors in the analysis of parole decisions

https://www.pnas.org/content/108/42/E833.full

Forskarnas svar på brevet

Reply to Weinshall-Margel and Shapard: Extraneous factors in judicial decisions persist

https://www.pnas.org/content/108/42/E834

Andreas Glöckners simuleringar

The irrational hungry judge effect revisited: Simulations reveal that the magnitude of the effect is overestimated

http://journal.sjdm.org/16/16823/jdm16823.html

Danïel Lakens bloggpost

Impossibly Hungry Judges

http://nautil.us/blog/impossibly-hungry-judges

Kanban for Software Development consists of three rules only (my memory told me anyway)

The three rules (in my head)

Kanban used for software development has in my mind been built on the three rules below.

• Visualize the workflow
• Limit Work In Progress (WIP)
  
• Measure the lead time

And depending on the situation the team exists in, the rules can be narrowed down even more. Like, if the predictability isn't a big concern, the rule about measuring lead time can be left out. 

And also, if team members are conscientious enough about not starting too much new work before finishing already initiated work, the WIP limits don't seem to add much.

In that case, the only thing needed is to visualize your workflow. But if you don't do that either, then I find it hard to get anything out of Kanban.

So, that's the reason that one day when it became obvious that the tasks on my team's Kanban board was out of sync with reality, I told the developers:

- "If we don't keep the Kanban board in sync with reality, we follow none of the three rules only of Kanban!" 

One of them responded teasingly:

- "Well, what do you expect from a bunch of we'll-do-as-we-pleases?"

(The word used was "rättshaverister", but I can't translate that into a word that describes what I think the person meant).

There was no further discussion and the board was adjusted after a while. But having referred to rules brought up from my memory, I also remembered that when reading about them a few years ago I hadn't got a good grip on where they come from, what their original source is. So, before banging them in anyone's head again, it was time for a bit of research :)

The closest source: Kanban and Scrum, making the most of both

I remembered that I read about the rules in the book Kanban and Scrum, making the most of both by Henrik Kniberg and Mattias Skarin. 

So I began with trying to find more info there. There they were, with a short explanation for each rule. But I lost the word "rules", because the only thing the book says about them is "Kanban in a nutshell" and then lists the three points. Not a word about "rule".

Next up: Crisp's homepage

Both Henrik Kniberg and Mattias Skarin works at Crisp, so I took a look at Crisp's homepage. And yes, the same points are mentioned there, with just a touch of more context: 

"There are many flavors, but the core of Kanban means:"

Ok, so there are different flavors?! Like "Standards are good, everyone should have their own."?

On the page I also found this:

At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean Production system. Most agile m­ethods such as Scrum and XP are already well aligned with lean principles. In 2004, however, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a ”Kanban system for software development”, and which most people now simply refer to as ”Kanban”.

Wow, a pioneer, David Anderson seemed as a promising track to research further!

David Anderson, a pioneer

Crisp's homepage linked to the book Kanban: Successful Evolutionary Change for Your Technology Business by David Anderson. 

"If there is any book that will bring clarity to this, it will be this one!", I thought. 

What I found was:

Kanban uses five core properties to create an emergent set of Lean behaviors in organizations. These properties have been present in every succesful implementation, including the one at Microsoft described in chapter 4.

The five properties are:

• Visualize Workflow
• Limit Work-in-Progress
• Measure and Manage Flow
• Make Process Policies Explicit
• Use Models to Recognize Improvement Opportunities

Ok... so "Properties", not "Rules". 

But five instead of three? The first three properties maps well to the ones mentioned before, but what do the two extra mean and why did Henrik and Mattias drop them? 

What the two "new" Kanban properties means

Make process policies explicit

This can be done by agreeing on and writing down the "Defintion of Done" policies you use between the different stages in your process. and perhaps putting them up on your board for good visibility.

Use models to recognize improvement opportunities

Your process can probably be improved by reducing "waste" or finding and act on bottlenecks. There are models for doing that, as David says:

Common models in use with Kanban includes the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming, and the concept of muda (waste) from the Toyota Production System. The models used with Kanban are continually evolving, and ideas from other fields, such as sociology, psychology, and risk management are appearing in some implementations.

Why were they dropped?

David's book predates Henrik's, why has the number of properties gone from five to three? I asked that question on Crisp's Facebook page. None of the original authors answered me, but another author did, he pointed me to the next book, Kanban in action.

Others have been pondering this too in Kanban in Action

At first, reading the book Kanban in Action by Marcus Hammarberg and Joakim Sundén made it even
messier! But also revealed interesting info.

There is a section titled

Three principles? I thought it was five properties. Or was it six practices? 

which indicates that others have had a hard time finding their way to getting clarity about this. That section contains the text below.

The three basic principles we describe in this section make up the foundation that kanban is based on. Recently, David J. Anderson and others have extended the three basic principles to five properties and later six practices; these are now referred to as the core practices.

Anyway, this info and Google led me to David Anderson's latest defintion, called Principles and General Practices of Kanban.

A blog post about Principles and General Practices of Kanban

In March 18, 2020, David Anderson added a post on his blog, from where I've copied the text below. In his post he also examines each point a bit deeper.

In my book, Kanban – Successful Evolutionary Change for your Technology Business, I identified what I called the “5 core properties” that I’d observed to be present in each successful implementation of Kanban.

Since the book was published, we’ve expanded this list and they are now known as the Principles and General Practices of Kanban.

Principles of the Kanban Method …

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities & titles
• Encourage acts of leadership at all levels in your organization

General Practices of the Kanban Method …

1. Visualize (the work, workflow and business risks)
2. Limit WIP
3. Manage Flow
4. Make Process Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

But Three, where did Three come from?

Well, I can't tell for sure. I've already put too much research effort into this and I think I can live without knowing that, although it doesn't feel like full closure... :) Anyway, now I know more about the  history of Kanban used in software development, which I hadn't if I hadn't tried finding the root of the Three Kanban rules in my mind.

Please, do leave a comment if you have interesting info regarding this! :)

The guest quotes about Clean Code in the book Clean Code

Clean code and code quality

The introduction of the book Clean Code by Robert C Martin begins with the image below, which I find funny beacuse its true. Even when the code is good, you can get wtf moments, but maybe more of surprise of becoming aware of odd things the program has to handle or usable stuff in the framework you didn't know existed than of strange or overcomplicated solutions.

What is clean code?

The focus of this post is on the content of the first chapter, which contains answers from other well-known and deeply experienced programmers on what they think defines Clean Code. Just to have all the quotes in a single place and easily retrievable.

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

 

Grady Booch, author of Object Oriented Analysis and Design with Applications 

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control.

 

"Big" Dave Thomas, founder of OTI, godfather of the Eclipse strategy

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

 

Michael Feathers, author of Working Effectively with Legacy Code

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code's author, and if you try to imagine improvements, you're led back to where you are, sitting in appreciation of the code someone left for you - code left by someone who cares deeply about the craft.

 

Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind design patterns. Smalltalk and OO thought leader. The godfather of all those who care about code.

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

And the longest last...

Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C#

In recent years I begin, and nearly end, with Beck's rules of simple code. In priority order, simple code:

• Runs all the tests;
• Contains no duplication;
• Expresses all the design ideas that are in the system;
• Minimizes the number of entities such as classes, methods, functions and the like.

Of these, I focus mostly on duplication. When the same thing is done over and over, it's a sign that there is an idea in out mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly.

Expressiveness to me includes meaningful names, and I am likely to change the names of things several times before I settle in. With modern coding tools such as Eclipse, renaming is quire inexpensive, so it doesn't trouble me to change. 

Expressiveness goes beyond names, however. I also look at whether an object or method is doing more than one thing. If it's an object, it probably needs to be broken into two or more objects. If it's a method, I will always use the Extract Method refactoring on it, resulting in one method that says more clearly what it does, and some submethods saying how it is done.

 Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one other thing that I'm aware of doing, which is a bit harder to explain.

After years of doing this work, it seems to me that all programs are made up of very similar elements. One example is "find things in a collection". Whether we have a database of employee records, or a hash map of keys and values, or an array of items of some kind, we often find ourselves wanting a particular item from that collection. When I find that happening, I will often wrap the particular implementation in a more abstract method or class. That gives me a couple of interesting advantages.

I can implement the functionality now with something simple, say a hash map, but since now all the references to that search are covered by my little abstraction, I can change the implementation any time I want. I can go forward quickly while preserving my ability to change later. In addition, the collection abstraction often calls my attention to what's "really" going on, and keeps me from running down the path of implementing arbitrary collection behavior when all I really need is a few fairly simple ways of finding what I want.

Reduced duplication, high expressiveness, and early building of simple abstractions. That's what makes clean code for me. 

Rather watch the movie instead of reading the book?

Here you have hour after hour with uncle Bob (Robert C Martin), speaking about that same things that's in the book.

• Clean Code Lesson 1
• Clean Code Lesson 2
• Clean Code Lesson 3
• Clean Code Lesson 4
• Clean Code Lesson 5
• Clean Code Lesson 6

Keep it clean! :)

My glasses crackled within a year...

I saw something that looked like lots and lots of tiny scratches on my glasses. They are almost invisible in bad lighting, but clear when looking at them in sunshine. The seller didn't even care to look at them, just told me surface treatment probably had crackled. She also said that heat is often the culprit, like using them in the sauna.

But I hadn't been using them in the sauna and had also avoided the steam coming out from the oven when opening the oven door. Also been really careful when cleaning them. 

I tried to find images of crackled glasses on the web to compare with, but found nothing. So, to provide the web with content, here are images of my old, probably crakled glasses and of my new ones for comparison.

Glasses with crackled surface treatment.

Because it hadn't passed a year since I bought them, I got new ones on warranty. And they looked like this:

And a few swedish words for the search engines :)

Krackelerade glasögon. Krackelerad ytbehandling.

Har du en gmail-adress? Känner du till att du då har många adresser?

Ett konto, flera adresser

Gmail hanterar e-postadresser lite annorlunda än andra, de har en mer "förlåtande" hantering av punktplacering.

Nedan är deras egen beskrivning från supportsidan Punkter spelar ingen roll i Gmail-adresser:

Om någon skickar ett e-postmeddelande till dig och råkar lägga till punkter i adressen skickas meddelandet till dig ändå. Om du till exempel har e-postadressen förnamnefternamn@gmail.com äger du även alla versioner av adressen med punkter:

• förnamn.efternamn@gmail.com
• förnamn.efter.namn@gmail.com
• f.ö.r.n.a.m.n.e.f.t.e.r.n.a.m.n@gmail.com

Användandet av punkter måste ändå följa e-postadresstandarden, så adressen får inte börja eller sluta med en punkt och en punkt får inte åtföljas av en punkt.

Förutom att det kan vara bra att känna till, kan man dra nytta av det? 

Tja... 

Man kan ju på vissa abonnemangstjänster som använder e-postadressen som kontoidentifierare registrera sig flera gånger med olika varianter av sin adress för att få tillgång till flera gratis prova-på-perioder. Om man känner sig sparsam. Och inte läser tjänstens villkor för noga.

Man KAN ju också använda det som ett trubbigt verktyg för att upptäcka hur din adress sprids/säljs vidare av någon du ger den till. Anta att en sajt erbjuder nåt du får ladda ner gratis, om du bara ger dem din e-postadress. Om du då använder en variant av din adress som är unik för den sajten och du sedan börjar få spam till ditt konto, riktat till just den adressen, så är det stor sannolikhet att det var just den sajten som inte skyddade din adress som de borde. Sen är frågan vad du kan göra med den informationen...

Behöver du ännu fler adresser?

En annan sak som gmail har stöd för är adresser med "kategorier". Du kan lägga till en kategori i din adress genom att skriva ett plus följt av ett kategorinamn, såhär:

dinadress+valfri_kategori@gmail.com

Det här kan dras nytta av på samma sätt som den fria punktplaceringen, men också för att hålla ordning i din inkorg. Du kanske är med i två föreningar och får många mail från dess medlemmar. Då kan du ge dem två olika adresser

• dinadress+minigolf@gmail.com
• dinadress+bowling@gmail.com

och sedan sätta upp sorteringsregler för var de ska läggas i din inkorg.

Plustecknet är fullt tillåtet att använda i e-postadresser, MEN det är inte så vanligt förekommande och därför kan din adress anses ogiltig av vissa sajter och program.

För att kunna skicka från en "plus"-adress så måste den först sättas upp som ett alias.

Användbart?

Det känns som att det finns potential att göra smartare saker med detta än vad jag tagit upp. Kände du till det här och använder det på nåt intressant sätt? Det vore kul att veta, så skriv gärna en kommentar om det!

Känner du till topp fem nyckelelement som särskiljer effektiva team enligt Googles forskning?

Den som söker, finner (ibland nåt annat än den tänkt sig)

Google ägnade två år till att bland annat titta på fler än 250 attribut hos 180 team för att försöka hitta den perfekta mixen av personligheter och färdigheter som leder till ett dream team.

Det visade sig att de letade efter fel saker...
Vem som är med i ett team spelar mindre roll än hur teammedlemmarna interagerar, strukturerar sitt arbete och ser på vad de bidrar med.

De upptäckte fem nyckelelement som särskiljde de framgångsrika teamen från de andra:

• Dependability
  Can we count on each other to do high quality work on time?
• Structure & clarity
  Are goals, roles, and execution plans on our team clear?
• Meaning of work
  Are we working on something that is personally important for each of us?
• Impact of work
  Do we fundamentally believe that the work we’re doing matters?

Men det mest intressanta är det femte nyckelelementet, som beskrivs som överlägset viktigast samt grundläggande för de övriga fyra, och det var: psykologisk trygghet 

• Psychological safety 
  Can we take risks on this team without feeling insecure or embarrassed?

Men vad är psykologisk trygghet egentligen?

Jag hittade beskrivning nedan i bloggposten Så blir ni mer agila – börja med psykologisk trygghet, en beskrivning jag tycker stämmer överens med vad Amy C. Edmondson skriver i sin bok

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth

Psykologisk trygghet handlar om känslan av att jag kan vara mig själv, att jag kan uttrycka vad jag upplever, känner och tycker, att jag kan ställa ”dumma” frågor, presentera nya idéer och erkänna misstag utan att riskera att bli bestraffad.

Öka psykologiska tryggheten - värt att prova? Hur?

 Texten nedan beskriver vilka effekter Google upptäckte att en hög psykologisk trygghet har.

Individuals on teams with higher psychological safety are less likely to leave Google, they’re more likely to harness the power of diverse ideas from their teammates, they bring in more revenue, and they’re rated as effective twice as often by executives.

Tidningen Chef beskriver vad Amy Edmondson upptäckte.

Amy Edmondson ingick tidigt i sin karriär i ett forskningsteam som skulle undersöka effekterna av fel och misstag på ett antal sjukhus. Hon fann till sin häpnad att de mest framgångsrika teamen rapporterade flest misstag, fler än de mindre framgångsrika teamen.
Så småningom upptäckte hon dock att de bra teamen hade en större öppenhet vilket gjorde det lättare att erkänna och diskutera misstag. Bra team gör med andra ord inte fler misstag, de bara rapporterar dem oftare – och lär sig av dem.

Så effekterna är bland annat högre trivsel på jobbet och färre gjorda fel, men öppen och förlåtande inställning till dem när de väl råkat göras. De effekterna verkar ju värda att sträva efter, men hur gå tillväga, ja, det är frågan jag själv håller på att gräva i. Det mest gedigna är förmodligen att försöka mäta dagens nivå av psykologisk trygghet i teamet, sen prova på något som ska öka den psykologiska tryggheten och sen mäta igen och se om det haft nån effekt.

Det enda sättet att "mäta" jag hittat hittills är frågorna nedan, vilket känns lite tunt, men jag har heller inte testat dem.

1. Känner du dig trygg i vår organisation?
2. Om du gör ett misstag, kan du berätta om det utan att bli bestraffad eller kritiserad?
3. Upplever du att ledarna i vår organisation erkänner sina misstag?
4. I din relation med dina kollegor, kan du vara dig själv?
5. Vad skulle göra att du kände dig (ännu) tryggare i vår organisation?

Och än så länge så är det Orangino Work jag testar och hoppas på att eventuella effekter ska vara kännbara och upplevda snarare än uppmätta, även om det kan vara roligt att ha siffror på saker :)

Min känsla just nu är att en riktigt hög nivå av psykologisk trygghet kan vara den pusselbit jag saknat för att oftare få till de starka synergieffekter inom teamarbete som jag älskar när de uppstår! Så klart värt att prova, eller hur?


Uppdatering 2020-02-15
Frågor för att mäta psykologisk trygghet

Amy Edmondson använde sig av nedanstående påståenden för att mäta nivån av psykologisk trygghet hos ett team. Teammedlemmarna fick svara hur pass mycket de tyckte att varje påstående stämde överens med deras upplevelse av teamet.

1. If you make a mistake on this team, it is often held against you.
2. Members of this team are able to bring up problems and tough issues.
3. People on this team sometimes reject others for being different.
4. It is safe to take a risk on this team.
5. It is difficult to ask other members of this team for help.
6. No one on this team would deliberately act in a way that undermines my efforts.
7. Working with members of this team, my unique skills and talents are valued and utilized.