Årsags/Effekt diagram

Et af de værktøjer jeg, engang imellem, finder frem fra min værktøjskasse er et "årsags-effektdiagram".

Se en beskrivelse her: http://en.wikipedia.org/wiki/Ishikawa_diagram

Det er et super værktøj til at brainstorme over et problem på - forleden brugte jeg og en anden chef kollega på dba.dk værktøjet til at identificere en række årsager til store udfordringer vi har lige nu.

Den store udfordring med værktøjet er at det giver lidt et sortsyn på situationen - du får en rigtig god liste over årsager til problemer, og viser typisk hvor komplekt situationen er.

Har du nogle erfaringer med dette eller andre værktøjer?

------

Jeg har ikke selv brugt det, men her har du et online tool:

http://www.pptmagic.com/downloads/ProjectMgm/Fishbone.swf

After action reviews - Agile retrospectives

For alle projekter i huset afholder vi et after action review, som lister de ting, vi ønsker at organisationen skal huske og samtidig tage ved lære af på fremtidige projekter. Dette anser jeg for almindelig skik i hvilken som helst projektorganiseret virksomhed. Det er vigtig formel kanal ind i organisationens læring og erfaringsopsamling.

Derudover, så anvender jeg på større projekter retrospectives løbende for at korrigere projektets arbejdsmåde, rette projektmiljømæssige problemer (vi mangler en projektor, gruppen skal sidde samlet for højere effektivitet etc...) og for at styrke samarbejdet i projektgruppen. Vi er begyndt at anvende Scrum på vores projekter, og den proces kræver at man afholder et sprint review efter hvert endt sprint. En del af dette review vil blive brugt til at diskutere hvilke ting der skal forbedres eller styrkes på projektet, og disse action items føres så med ind i næste sprint (jeg vil begynde at hænge sticky notes med action items op på projektkontoret, så de er visuelle og synlige for gruppen og dens omgivelser). Jeg har altid anvendt en simpel notationsform for actions items ala "vi skal forbedre x i næste sprint", hvor det væsentlige er en tydelig markering af målsætning for det pågældende action item. I dag læste jeg en artikel på ScrumAlliance.org om emnet. Artiklen foreslår følgende notation for action items: 1. Nedskriv langsigtet målsætning (vi skal have automatiseret build-miljø), 2. Nedskriv her og nu målsætning (Dennis compiler hele koden hver dag en time før fyraften). Meget simpelt, jeg kan virkelig godt lide den opslitning, da den gør det nemmere at få leveret nogle action items, der kan handles på. Artiklen påpeger i øvrigt et andet vigtigt aspekt ved denne form for læring: "udvælg aldrig for mange action items". Hav max. 3 aktive items, så der ikke opstår et overhead i forhold til opfølgning og administration af processen.

Hvis du anvender retrospectives på dine projekter eller føler dig inspireret til at begynde med det, så kan jeg anbefale bogen Agile Retrospectives af Esther Derby og Diana Larsen (sidstnævnte er vært for en del arrangement på årets JAOO konference - kan kun anbefales...).