Projektledelse & produktudvikling

Dba.dk har fået en blog....

noreply@blogger.com (Rune Mai) — Fri, 12 Jun 2009 19:42:00 +0000

Endelig er det sket, at vi er gået i luften med vores egen blog på dba.dk. På bloggen kan du både læse om nye features inden de lanceres, spændende statistik, inside-viden og om jobmuligheder.

Tag et kig på: http://blog.dba.dk og husk at tilmelde rss feedet til din foretrukne rss-reader (http://blog.dba.dk/atom.xml).

Downfall of Agile Hitler

noreply@blogger.com (Rune Mai) — Wed, 13 May 2009 07:15:00 +0000

Den her er lidt på kanten, men alligevel er det svært at lade være med at trække på smilebåndet.

http://www.youtube.com/watch?v=l1wKO3rID9g&eurl=http://www.agile-software-development.com/2009/05/downfall-of-agile-hitler.html&feature=player_embedded

Retrospective Anti-patterns

noreply@blogger.com (Rune Mai) — Mon, 30 Mar 2009 16:45:00 +0000

En essentiel del af Scrum er retrospectivet. Det er her man finder frem til, hvad der kører, og hvad der skal forbedres i forhold til proces, teambuilding, programmering osv.

Mødet er måske det sværeste af de møder, man støder på i Scrum. Det kan meget let ende med at være "formålsløs" stirren tilbage på alt det som ikke duede og så bliver det sjældent en konstruktiv affære.

Jeg stødte på en kort og præcis artikel omkring nogle af de ting man helst ikke skal gøre og hvordan man undgår dem:
http://radio.javaranch.com/ilja/2009/03/25/1237998972110.html

QA Manager med Agilt fokus søges til Den Blå Avis!

noreply@blogger.com (Rune Mai) — Tue, 24 Mar 2009 15:46:00 +0000

Er du knaldhård til tests af high performance web sites både hvad angår automatiseringstests og testing knyttet til vores scrum projekter. Er du den der kan sikre et rent site, hvor "sundheden" løbende kan monitoreres? Har du arbejdet med testing i en del år, har du ledelseserfaring og kunne du nu tænke dig at prøve at bygge en QA afdeling op fra bunden af?

Så læs lige her: http://www.dba.dk/info/qaman.asp

Fantastisk citat...

noreply@blogger.com (Rune Mai) — Mon, 26 Jan 2009 08:04:00 +0000

Et vigtigt aspekt ved agil udvikling er at sikre en kodebase, der kører næsten uden bugs. Dette er selvfølgelig vigtigt (1) for at kunne leve op til princippet om, at hver sprint/iteration leverer release-bar funktionalitet og (2) for at undgå en death march periode inden noget skal releases. Jeg læste fornyligt en artikel fra Mike Cohn omkring naturen af nye funktioner i et softwareprojekt (artiklen stiller et interessant spørgsmål, så læs den...) og her stødte jeg på følgende citat:

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

Tænk lige over det. Ville du nogen sinde bestige et bjerg uden at sikre hvert skridt? Overfør så det til dit daglige arbejde med softwareudvikling... Selvfølgelig kan man altid invende, at softwareudvikling ikke er en disciplin man dør af, hvis man træder forkert, men så igen, hvis man ser bjergbestigning som en disciplin hvis målsætnings success er betinget af, at man ikke træder ved siden af (uanset om man dør eller ej), så er vi jo tilbage til at muligheden for at nå trygt i mål afhænger af kvaliteten af ens arbejde undervejs.

Krav - hvordan og hvem gør hvad...

noreply@blogger.com (Rune Mai) — Fri, 12 Dec 2008 08:41:00 +0000

Vi har brugt en del tid på at optimere kravsprocessen her i huset, og vi blev i den forbindelse klar over, at vi med Scrum og fokus på roller og deres funktion måske var endt i en grøft, hvor forventninger til Product Owneren var for store. Vores PO skrev krav og overleverede disse til teamet under Estimeringsmødet op til en sprint. Dette er problematisk, da kravene ofte ikke var modne nok. Det er som citatet nedenfor også pointerer svært for en person alene at stå for dette arbejde.

"It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why."

Alle på teamet deltager i dette arbejde. Det er en kollaborativ proces. Man kunne spørge sig selv: hvorfor? Er det ikke spild og skal vi ikke lige netop fokusere på at eliminere spild i processen??

Jo lige netop! Ved at gøre det til en kollaborativ proces så sikrer man også den bedste vidensdeling og at udviklerne har et "godt" forhold til de krav, som står i backloggen, og som skal estimeres på et tidspunkt. Vi anvender user stories, som jo pr. natur er tænkt som værende et kommunikationsredskab, og derfor giver det endnu mere mening at samarbejde om modningen af disse, så hver user story fungerer som en effektiv placeholder for kommunikation. Ved at gøre kravsmodning til en kollaborativ proces tidligt i projektforløbet kan man opnå følgende gode fordele:

Øget kommunikation imellem PO og team
Bedre forståelse af user stories og deres boundaries
Hurtigere og mere præcise estimeringssessioner (sprint planning 1)
Bedre og mere præcise velocity-forudsigelser
Bedre krav
En velfungerende backlog, som teamet stoler på
En PO som teamet stoler på
etc.

Hvilke erfaringer har i gjort jer på området? Hvordan faciliterer i kravsmodning?

Mike Cohn om User stories og estimering..

noreply@blogger.com (Rune Mai) — Thu, 11 Dec 2008 11:44:00 +0000

To videoer som virkelig er værd at bruge lidt tid på...

Del 1:

Del 2:

Brænder du for webudvikling i et agilt miljø?

noreply@blogger.com (Rune Mai) — Sat, 12 Jul 2008 20:40:00 +0000

Vi søger pt. en webudvikler som føler sig naturligt hjemme i objektorienteret design og udvikling, og som behersker både ASP.NET og C#. Er det dig? Eller kender du en? Læs vores stillingsopslag her:

http://www.it-jobbank.dk/ShowProfile.aspx?ProfileId=50177277

Derfor holder budgetterne ikke, når projekter skal realiseres

noreply@blogger.com (Daniel W. Mathiasen) — Fri, 11 Jul 2008 12:38:00 +0000

"Mennesket ser for lyst på fremtiden – bevidst og ubevist - og derfor holder budgetterne ikke, når store byggeprojekter skal realiseres." Oprindelig artikel fra Ingeniøren af Bjørn Kock Sørensen

Jeg faldt over dette citat i denne artikel og selv om den går på byggeprojekter, og uden at have nærmere på Bent Flyvbjergs arbejde, eller på Daniel Kahnemans for den sags skyld, mener stadig jeg det holder på de projekter jeg har været tæt på.

Skal man budgettere ud fra hvad man ud fra hvad man ved, det vil sige ikke se spøgelser?
Skal man være pessimistisk?
Skal man gøre det nedefra-op eller oppefra-ned?
Eller hvad med Planning Game?

---

Kender du Bent Flyvbjerg og Daniel Kahnemans arbejde? Er du enig med deres perspektiv?

Hvordan estimere i arbejdet ved jer?

SCRUM Værktøjer

noreply@blogger.com (Daniel W. Mathiasen) — Sat, 05 Jul 2008 08:43:00 +0000

Tjah, efter at have brugt noget tid på OnTime fra Axosoft, er der to ting om det produkt som jeg gerne vil dele med jer:

1) Der er et ret fedt produkt, der er ret modent

2) Det understøtter ikke SCRUM, og tro ikke på sælgerne

Så hvis du står og skal kørt et nyt system ind, så vælg et andet en OnTime 8.1

Se også dette indlæg.

Agile tool - task management...

noreply@blogger.com (Rune Mai) — Thu, 05 Jun 2008 20:58:00 +0000

Har gennem de sidste uger tænkt meget over at anskaffe et værktøj til styring af opgaver i organisationen, lige fra projekter, designopgaver, helpdesksager og til ideoplæg. Det må gerne understøtte vores Scrum-proces og dermed gerne have mulighed for både at kunne håndtere product backlogs og sprint backlogs. Jeg har kigget på flere forskellige, men savner egentlig råd fra folk med praktisk erfaring. Vi har tidligere brugt MS TFS, som jeg på ingen måde ønsker at bruge. Alt for datacentrisk og simpelt - eks. kunne man ikke på nogen nem måde få overblik over stories og de underliggende subtasks til dem.

I øjeblikket kredser mine tanker meget omkring to vidt forskellige systemer:

Mingle - et fuldt udbygget agile management tool med subversion integration

JIRA - et generisk issuetracking system.

Begge har rig mulighed for opsætning af felter, lister og flows. Har du praktisk erfaring med et af disse? Kan du give nogle gode råd? Eller har du erfaring med andre, som du ønsker at anbefale, så skriv gerne en kommentar.

Cargo Cult Agile

noreply@blogger.com (Rune Mai) — Tue, 03 Jun 2008 19:02:00 +0000

Jeg læste en interessant artikel forleden omkring en vinkel på hele Agile-paradigmet. Artiklen handlede om en stamme af indfødte på en af øerne i nærheden af bikini (mener jeg), som efter at have set amerikanere bygge transportbase (en landingsbane og kontroltårn) forsøgte at "efterligne" disse artefakter for at tiltrække den transportlast de så komme ned med "jernørnene". Mange år efter fandt man således disse indfødte, som nu havde bygget kontroltårne af bambus og lavet deres egen landingsbane og som gik rundt med kokusnøddeskaller på ørene (som høreværn) i håb om at tiltrække de spændende ørne med den gyldne last. Ørnene var selvfølgelig aldrig kommet, men på trods af dette var det blevet en del af de indfødtes ritualer og spirituelle oplevelsesregister at dyrke denne vision.

The term ‘cargo cult’ is a reference to aboriginal religions that grew up in the South Pacific after World War II. The practices of these cults center on building elaborate mockups of airplanes and military style landing strips in the hope of bringing the return of the god-like airplanes that brought such marvelous cargo during the war - http://catb.org/jargon/html/C/cargo-cult-programming.html

Det er ikke første gang, jeg selv har tænkt tanken om, hvorvidt det vi udfører blot er Cargo Cult indenfor agile-paradigmet. Altså vi bruger sticky notes, whiteboards, burncharts, sprintplanning, retrospectives og impediments, men er vi virkelig agile?

Indskudt note:
Jeg har også set eksempler på nettet, hvor folk "praler" med deres compliancy i forhold til Diane Larsens ideer om retrospectives. (Hun har et eksempel, hvor hun anbefaler dot-prioritization, som blot betyder, at man går til tavlen og sætter en prik ved de tiltag man ønsker at prioritere højest.) Folkene havde til en større retrospective-session købt små runde dot-klistermærker, som man kunne sætte på papirerne i lokalet - how far out is that? Hvad er der galt med en kuglepen eller blyant?

For at runde den lange svada af: når alt kommer til alt bør man spørge sig selv om, hvad essensen af agile egentlig er? Alle artefakterne er i sidste ende vel mest biprodukter af denne essens? Hvad er dit bud på kernen - den inderste essens?

Projektleder søges!

noreply@blogger.com (Rune Mai) — Sun, 01 Jun 2008 18:06:00 +0000

Har du fulgt med på denne blog? Hvis du synes Scrum er spændende og du allerede er projektleder eller mener, at du ville være god som projektleder, så søg stillingen hos os:

http://www.samheadhunting.dk/jobs/job.aspx?lang=1&ID=5909

Udviklere til Den Blå Avis

noreply@blogger.com (Rune Mai) — Sun, 01 Jun 2008 17:57:00 +0000

Er du udvikler og synes du det er spændende at arbejde med webteknologi? Brænder du for microsoft-teknologier som ASP, ASP.Net, C# og Visual Studio? Kunne du tænke dig at arbejde med udvikling i et miljø, hvor processen er baseret på Scrum, og hvor der er mulighed for at blive ScrumMaster certificeret? Kunne du tænke dig at arbejde med udvikling af produkter, der skal bringe Den Blå Avis ind på helt nye markeder? Så tag et kig på de stillinger, vi har slået op lige nu:

http://www.hhminternational.com/job/1588.htm

http://www.samheadhunting.dk/jobs/job.aspx?lang=1&ID=5910

PS: Hvis du ikke selv er udvikler men kender en udvikler, som du mener passer på ovenstående, så må du også gerne henlede opmærksomheden på disse opslag :)

En artikel på jp.dk

noreply@blogger.com (Daniel W. Mathiasen) — Sun, 18 May 2008 07:11:00 +0000

Så er SCRUM omtalt på JP, i en længere artikel der beskriver processen.

Se artiklen her.

På den positive side nævnes at:

Mest overraskende er produktivitetsforøgelsen. Der bliver virkelig leveret meget, meget mere programkode - i høj kvalitet
Metoden kræver en del is i maven
Der kommer oftest flere og bedre resultater ud af processen, end når man anvender traditionelle metoder

Blandt de negative erfaringer nævnes:

Teamet bliver meget indadvendt
Teamet let kommer til at overse afhængigheder til andre projekter
Teamet let overser forudsætninger, der skal være på plads

"Lean i softwareudvikling"

noreply@blogger.com (Daniel W. Mathiasen) — Mon, 18 Feb 2008 14:28:00 +0000

Der er udkommet en ny og gratis bog "Lean i softwareudvikling" på onLibri.dk

Bogen er en ret minimalistisk, og på nogle områder simplistisk gennemgang - men dog stadigvæk værd at læse, hvis man er ny i den agile verden. Hvis man har erfaring lærer man nok ikke så meget, men det er jo trods alt altid sundt med andres perspektiv på udvikling.

Agile testing - hvordan skal denne disciplin organiseres??

noreply@blogger.com (Rune Mai) — Thu, 14 Feb 2008 07:59:00 +0000

(note: indlægget her ser bort fra TDD og unit-testing, som selvfølgelig er en del af udviklernes arbejde)
Vi har pt. ikke dedikerede testere tilknyttet vores projekter. Det bliver løbende et større og større problem, da det både kræver, at udviklere og product owners (vores forretningsudviklere) bruger en stor portion af deres tid på at teste.

Jeg anser det for et problem fordi

1. Udviklere er naturligt "blinde" overfor fail-scenarier. Man selv har skrevet den kode, logik og funktionalitet, som skal testes, og i mange tilfælde vil man derfor let komme til overse en række boundary cases, fordi man tænker i "positiv" scenarier i forhold til den kode, man lige har skrevet.

"... the term ‘FUT’ (frequent unit testing) for the activity of creating unit tests along with the software code, regardless of whether the tests or the code are created first. And then he goes on to say that the risk with FUT is that ‘blindness’ may prevent the developer from writing tests for
the edge cases he did not consider when coding the application.", http://www.developertesting.com/archives/month200501/20050131-BlindSpotsFrequentTestingSoftwareAgitation.html
2. Kunden/Product owner er heller ikke nødvendigvis den bedste til at optænke alle nødvendige tests. For det første er ens fokus på udvikling af en given forretning, og man har ikke nødvendigvis det kompetencesæt, som er påkrævet. Derudover har man heller ikke tid, da man jo er travlt beskæftiget med at udvikle og drifte en forretning.

I min forestilling er der behov for mindst én på et projekt, som har sit fulde fokus på softwarens kvalitet. Dette sikrer, at kvalitetsprocedurer overholdes og gør det muligt at opfange fejl/mangler tidligere i forløbet og dermed spare refaktoring-tid i en sprint.

"Being in a more detached role, sometimes the tester can see a neckbreaking hairpin curve in the road before everyone else.", http://www.testing.com/agile/crispin-xp-article.pdf

Derudover skal der være i hvert fald en i QA linieorganisationen, som har det overordnede ansvar for kompetenceudvikling og retningslinier for testere på de forskellige projekter. Det skal også være denne afdelings ansvar at sige go eller no-go til projekter ud fra kvalitetskravene.

På testing.com fandt jeg et ret interessant eksempel på, hvordan agile testing skal organiseres og hvorfor:

"Rather than communicating at people, we need to join and encourage the ongoing
project conversation. Testers and developers should sit in the same bullpen,
share offices, or occupy alternate cubicles. Many testers should be assigned to
help particular developers, rather than to test pieces of the product. The test
plan should evolve through a series of what James Bach calls "drop-in meetings"
- short, low-preparation, informal discussions of particular topics. These will
result in what James Tierney calls "test doclets" - short memos addressing a
specific issue. Test status should be reported via big, public, simple-to-read
charts that answer specific development questions like "what parts of the
product can we stop worrying about?", http://www.testing.com/agile/agile-testing-essay.html

Jeg kan godt lide det fokus på kommunikation, der vægtes i ovenstående citat. At testere skal assignes til at hjælpe en eller flere udviklere, istedet for at teste et eller flere områder af en applikation, virker soleklart på mig. Det drejer sig jo om at undgå distancering og ansvarsfraskrivelse i sidste ende, hvis man altså ønsker at være virkelig effektiv.

Jeg kunne godt tænke mig at høre jeres ideer til emnet, og hvis muligt høre fra nogen af jer, som har implementeret lign. i jeres organisationer.

PS: et udmærket link til udforskning af holdninger og tilgange til emnet kan findes her: http://www.testing.com/agile/

Flere checklister...

noreply@blogger.com (Rune Mai) — Mon, 04 Feb 2008 09:59:00 +0000

Man kan ikke få for mange checklister til afdækning af, hvor godt ens Scrum-proces er implementeret / fungerer i det daglige.

Specielt synes jeg følgende lister er interessant (udover den fra min forrige post):

Henrik Kniberg - forfatteren til den gode bog Scrum And XP From the Trenches - har lavet et udkast til en liste:
http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html

Ligeledes har Michael James lavet en liste. Denne fokuserer på rollerne og det tekniske:
http://www.sendspace.com/pro/dl/qh5zug

Kender du nogen som er værd at nævne?

Hvor er agile er vi?

noreply@blogger.com (Rune Mai) — Tue, 22 Jan 2008 13:47:00 +0000

Prøv at gå igennem score-arket her med jeres teams:

http://kw-agiledevelopment.blogspot.com/2008/01/how-agile-are-you-take-this-42-point.html

Den er god til indikation af indsatsområder, omend lidt for "værktøjsorienteret" i mine øjne.

Mødekultur....

noreply@blogger.com (Daniel W. Mathiasen) — Thu, 17 Jan 2008 19:31:00 +0000

Jeg faldt over denne på Bug Bash - Godt spottet...

Et andet hint: Indkald mødet til 2 minutter i, og slut fem minutter før... så er der mulighed for at folk husker at komme til tiden, og i har en lidt skarpere deadline ;-)

"Er IPMA en metode?"

noreply@blogger.com (Daniel W. Mathiasen) — Thu, 17 Jan 2008 18:52:00 +0000

Jeg faldt over indlægget "Er IPMA en metode i projektledelse? " på Finn Svennings blog om projektledelse.

Jeg er helt enig i Finn's betragtninger - jeg vil dog gøre opmærksom på hvad NCB'en (National Competence Baseline) fra IPMA (måske) også kan bruges til.

I vores projektorganisation, har jeg lige talt med en af projektlederne om, at vi kan bruge NCB evalueringen som udgangspunkt i den faglige kompetence udvikling, som ved os foregår i dagligdagen.

Man tager simpelthen udgangspunkt i en selv- eller fælles evaluering af projektlederen, finder frem til forbedringsområder - og kan så finde frem til værktøjer, metoder eller adfærd der kan hjælpe til den personlige faglige udvikling.

Det kan da være en måde at gøre MUS arbejdet mere nærværende... vi har ikke afprøvet det endnu, men hvad siger i?

Teams #3 - Selvledelse

noreply@blogger.com (Rune Mai) — Tue, 15 Jan 2008 11:12:00 +0000

Selvledelse er i følge Det nationale kompetenceregnskab (s.12) en kompetence baseret på
"...evne og vilje til via eget initiativ at beslutte og gennemføre opgaver i
arbejdet i overensstemmelse med virksomhedens strategier."

Selvom definitionen er lidt stiv, så kan jeg godt lide dens fokus på, at det både er et spørgsmål om evne og vilje. Selvledelse kommer ikke af sig selv. Det er en kompetence, som individerne på et givent team skal opøve og ikke mindst ville.

Det enkelte individ skal være indstillet på at bryde med vaner og hele tiden udfordre sig selv og sit eget standpunkt, men samtidig også turde stille samme krav til andre. Det kræver både evne og vilje. Først når alle på et team gør det, vil teamet blive reelt selvledende og selvorganiserende.

Som leder er dit job, som jeg ser det, at opstille de rigtige rammer for ovennævnte kan ske. Ledelsesarbejde skal baseres på

tillid fremfor kontrol
motivation fremfor ordrer
uddelegering af ansvar fremfor uddelegering af opgaver

Der er sikkert også mange andre ting, men det er i hvert fald et godt sted at starte, og husk på, når man uddelegerer ansvaret, så kan man faktisk også tillade sig at stille spørgsmål ved planlægning og løsning af opgaver, hvis planerne skrider, for nogen har jo taget ansvar for planlægningen og løsningen. At modtage og acceptere ansvar er lig med at bevæge sig væk fra ansvarsfraskrivelse, som efter min opfattelse er det største problem ved projektledelse baseret på command-and-control tankegangen.

Jeg slutter med et godt team-citat hentet fra en fantastisk god historie om transitionen mod Agile:

"The first thing we learned was that we needed to make open and honest
commitments as a team to produce high quality software every iteration. It’s not
as easy as it sounds. You need to check your ego at the door. There are no
heroes on our team….our team is the hero. There are no goats on team…our team is the goat. We sink or swim together."

Et godt link til danske artikler om selvledelse og teams kan findes her

Velocity.... fart hvad kan man bruge det til?

noreply@blogger.com (Rune Mai) — Fri, 04 Jan 2008 09:29:00 +0000

Hvis i har tid så læs følgende artikler med hver deres perspektiv på, hvad konceptet velocity kan tilføre en agil projektproces:

Velocity er et ret simpelt koncept, som bygger på Mike Cohn's ide om at man skal estimere i størrelse og uddrive farten igennem udførelse - estimate size, derive duration - og på den måde opnå en empirisk kontrolleret forståelse for den fart, hvormed et givent projektteam kan eksekvere en given opgave (eller user story).

Den del som tiltaler mig er, at eksekveringen af "estimat-timer" (som Cohn ynder at kalde story points for at undgå forvirringen med kalender-timer) adskilles fra estimatet selv. I alt for mange år har man talt om at estimater aldrig stemmer overens med de faktiske timer, og så har man brugt ligeså lang tid på at udvikle metoder til at foretage beregninger på estimater up-front for at gøre dem mere præcise osv. Hvorfor?

For mig at se er det temmelig indlysende, at et estimat givet på et tidspunkt, hvor viden om projektet og de konkrete projektopgaver er lavest (=dvs i begyndelsen af et projekt), aldrig kan indfri et ønske om 100% præcision. Det gør dog ikke estimater ubrugelige. Estimater fortæller jo stadig om et projekts størrelse og kompleksitet i grove træk, og det er faktisk meget værdifuldt i forhold til planlægning af projektet, og måske endnu vigtigere: porteføljeplanlægning..

Hvad synes i? Bruger i velocity på jeres projekter? I givet fald hvilke erfaringer har i gjort jer med det?

Så er det tid til Julemad

noreply@blogger.com (Daniel W. Mathiasen) — Fri, 21 Dec 2007 10:03:00 +0000

Er du ingeniør, eller har du bare en hjerne der kræver at alle omkring dig er super præcise?

Tjek Cooking For Engineers , et meget seriøst site med diverse opskrifter :-)

Hvad med planlægningen af julen og nytårs festen... bruger i SCRUM principper?

Måske er LEAN eller SCRUM vejen frem til en stress fri jul? Tjek DR.dk for et perspektiv på den sag.

Glædelig jul til jer alle,

Rune og Daniel

Teams #2 - Tillid

noreply@blogger.com (Rune Mai) — Thu, 20 Dec 2007 08:04:00 +0000

Hvad skaber grobunden for et velkonsolideret og high-performance team? Jeg tror, at det er det samme, som venskaber er bygget ovenpå: tillid og respekt. Tillid: at man har tillid til den andens adfærd og handlinger udføres med det bedste ønske i forhold til en selv. Respekt: at man respekterer hinanden og de forskelligheder man måtte have, og faktisk bruger respekten til at lære hinanden noget nyt hele tiden.

Vi har under Scrum-møder den sidste måneds tid stillet det samme spørgsmål (efter de tre andre..): Respekterer vi hinanden og hinandens forskelligheder? Det virker måske lidt too-much-agtigt og akavet, men formålet med spørgsmålet har været at bringe et konstant fokus på, at man skal se hinanden som ligeværdige i forhold til teamets mål og opgaver, og kunne stole på hinanden i forhold til, at hvis en udfører en opgave på en bestemt måde, så har andre på teamet respekt nok til at lade denne person udføre opgaven på denne måde, og ikke mindre, hvis nu opgaven er forkert udført, så har andre personer respekt nok til at turde indgå i dialog herom.

Tilliden har jeg hele tænkt som et biprodukt af fokuseringen på respekt, men efter at have læst en slide-præsentation af Diana Larsen om tillid og teams, så ser jeg nok lidt anderledes på det. Her er f.eks 21 gode tips (på engelsk) til at forbedre/skabe tilliden på ens teams:

1. Trust first—To get trust, give trust and act trustworthy
2. Set a tone for interaction and collaboration from the beginning
3. Identify clear, consistent purpose and performance goals
4. Communicate openly, freely, and honestly
5. Listen carefully and seek fairness
6. Develop comfort with discussing mistakes, concerns, and limitations
7. Respect each other’s opinions
8. Learn about each other’s perspectives
9. Establish strong business ethics
10. Visibly do what you say you’ll do
11. Interact with the team consistently and predictably
12. Decide how the team will decide
13. Take responsibility for team action
14. Give credit to team members
15. Empower team members to take risks and act
16. Make yourself available, accessible, and responsive
17. Show awareness, sensitivity, and support for the needs of other team members
18. Maintain confidences
19. Watch your language
20. Create social time for the team
21. Expect and allow emotional release, find a safe space to vent