Nedan text är utdrag ur mailkonversation med en kund. YMMV.
Det jag tänker mig är att ni bör bygga en kultur där det är naturligt att ha tid för och investera (er tid) i kompetens och kunskap. Har man en hög nivå av lärande kommer det som skapas vara av hög kvalitet, vilket leder till låg mängd buggar och störningar, vilket ger mer tid till lärande, som ger högre kvalitet i det som skapas, osv. En självförstärkande cirkel alltså. Min erfarenhet är att en aktivitet i veckan verkar vara en bra normal-nivå. Ibland hoppar man över det, som när veckan är kortare.
Exempel på aktiviteter
- brown bag lunch - man äter lunch tillsammans framför en presentation från en konferens (ibland vill företaget bjuda på lunchen och får en “brown bag” med lunchmat i, på andra ställen sker detta spontant)
- knowledge sharing - någon i teamet har förberett sig (max 30 minuter) och man går igenom någonting där kunskapsnivån är olika, t ex om någon har ändrat hur servrarna backas upp, hur vi kör testen i Travis, hur flödet för en faktura till Kungsbacka ser ut, … En regelbunden aktivitet där man fritt frågar, ritar och kikar på något som fler vill (och borde) känna till.
- prao - en halv- eller heldag om året/kvartalet/månaden så skall alla jobba som “prao” i en annan roll än den man vanligen fyller, så en utvecklare jobbar med någon i supporten eller liknande
- intern internkonferens - alla skapar sitt drömprogram över vad en endagskonferens skulle innehålla, man visar för varandra och ser om det finns folk internt som skulle kunna förbereda en presentation på något av de ämnen som kom fram. Har man tur (vilket man brukar ha) så kan man faktiskt sätta ihop ett helt program själv inom organisationen. Folk kan mer än de tror, speciellt om man kombinerar människors förmågor.
- developer week - en vecka om året så bjuder man in en gästföreläsare/workshopshållare så man varje dag får något nytt att inspireras av. Vanligt upplägg är att detta tar halva dagen, så det inte stör “för” mycket, man slipper resa bort, talaren har tid att svara på frågor som är relevanta “för oss”
- Community of Practice, även kallat Chapters - är man en stor organisation så brukar man behöva diskutera ämnen över flera grupper/team.
- coding dojo - regelbundet träffas man för “deliberate practice”, dvs att man går in i en övning där man övar på något man vill bli bättre på, eller bara lära mer om. Vanliga exempel är “hur svårt är det att byta till php7? Vad skulle hända om vi bytte loggning till ELK? Låt oss lära testa Behat. Hur skall man skriva bra system-/integrationstest på Backoffice? Hur kan vi refaktorisera från spaghetti till kända mönster? Hur kan man dokumentera systemflöden - vi testar fyra olika sätt och utvärderar”. Man vill gärna att detta skall drivas av egna krafter, dvs inte att någon utifrån kommer och sätter agendan.
Detta sista, coding dojo, kan vara lite ovant att komma igång med och ett bra område att börja med för att känna på konceptet är test-driven utveckling. Kolla http://growing-agility.com/kurser/software-craftsmanship/ så får du en bild av vad jag brukar använda för att dra igång detta.
När man kör igång en Coding dojo (kodstuga, kodfredag, …) brukar vi också kunna se en hel del synergier i ökad effektivitet, starka teamkänsla, bättre samarbeten. Det kan ta upp till 6-9 månader innan man verkligen ser effekten, men det är få bolag (bara ett) som inte kunnat se en tydlig förändring i arbetssätt.