02.01.08
Bokcirkel II är igång
Här kommer en kort uppföljning av mitt tidigare inlägg om vår nästa bokcirkel. Tack för alla bra boktips!
Resultatet av omröstningen blev i alla fall som bilden nedan visar:
Om det inte går att se så kan jag berätta att det blev jämnt skägg mellan ”Becoming a Technical Leader” av Gerald Weinberg och ”The Art of Agile Development” (som kom in på slutet av omröstningen). Båda fick 5 glada miner och 2 halvglada.
Vi fick göra en ny omröstning och valde då den förstnämnda. Tyvärr var den slut hos alla förlag och verkar inte gå att få tag på. Tyvärr! Det ser ut som att den ska finnas hos Amazons hangaroundförlag, men till och med de fick återkomma och säga att den var slut.
Det fick alltså bli ”The Art of Agile Dev”, vilken vi nu precis har kommit igång med. Det ska bli spännande att läsa den då det verkar vara mycket bra och praktiska råd om agila arbetssätt. Utgångspunkten är XP, inte Scrum, så det blir nog en del nytt för teamet (fast jag tror att vissa kommer att bli förvånade när de inser hur mycket XP de egenligen har gjort, he he).
11.30.07
Vår nästa bok
Snart blir det bokcirkel igen. Efter vår första succé (ja, jag kallar det så) med ”Implementing Lean Software Development”, vad skulle kunna toppa det?
Vad söker vi? Helst ska boken kunna läsas av hela teamet (programmerare, användbarhetsexpert, ScrumMaster och produktägare). Helst ska boken vara lagom tjock och trevligt indelad i lagom stora delar. Helst ska boken vara lärande och tankeväckande. Helst ska vi kunna använda det vi lärt oss i projektet.
Här är våra nuvarande kandidater:
- ”User Stories Applied”, av Mike Cohn. En tung spik i kravhanteringskistan. En nackdel är väl att vi redan gör det mesta av vad boken föreslår. Har själv dock läst denna några gånger.
- ”Agile Estimating and Planning”, av Mike Cohn (igen). Mikes uppföljare är lysande. Han känns mer säker på vad han vill säga. Återigen, mycket av det gör vi redan. Har läst den en gång varpå jag prompt glömde den i ett flygplanssäte. Behöver ett nytt ex…
- ”Managing the Design Factory”, av Donald G Reinertsen. På rekommendation av Marcus Ahnve (tack!). Ska vara bättre än Poppendieckarnas böcker, vilket lovar gott.
- ”Agile Software Development”, 2nd ed, av Alistair Cockburn. Första utgåvan var tung, har inte läst den andra. Alistair är en tänkare, om än ganska abstrakt ibland. Här finns bl.a. den underbara utredningen om ”bandbredd” i olika kommunikationssätt.
- ”Agile Software Development – Principles, Patterns and Practices”, av Robert C Martin. Plus från mig är att jag inte har läst den (skäms!). Kanske är väl programmeringsnära för en del av teamet?
- ”Pragmatic Programmer”, av Dave Thomas and Andy Hunt. En underbart handsnickrad pärla. Också rätt teknisk i sammanhanget. Läst den två gånger.
- ”Extreme Programming Explained”, 2nd ed, av Kent Beck. Fortfarande mycket tankvärt i denna. Givetvis har jag läst denna några gånger.
Jag har skrivit ut lite information om böckerna från Amazon. Dessutom har jag skapat en liten matris på en av våra vita tavlor (se bilden). Ska bli spännande att se resultatet!
Har du någon bokrekommendation till teamet får du gärna kommentera (av de ovan nämnda eller andra).
11.25.07
Generalister och specialister
En av många aspekter vi måste tänka på när vi ska sätta ihop högpresterande, agila utvecklingsteam är om vi vill ha generalister eller specialister i dem.
Spontant tror jag att många säger: specialister! Fördelar med specialister är förstås att de har specialistkunskaper, till exempel på ett ramverk eller en metodik, som gör att teamet snabbare kan komma fram till en stilig och adekvat lösning. Problemet är att systemutvecklingsprojekt idag är så komplexa att du skulle behöva 20-30 personer med specialistkompetens för en webbapplikation av standardkomplexitet. Tror du mig inte? Ok, här en snabb lista (det finns säkert fler):
- politiker (för att hantera särintressen inom organisationen)
- marknadsförare (för systemet, produkten, projektet)
- domänexperter
- användare i olika roller (sällananvändare, läsare, administratör, rapportläsare, redaktör, …)
- marknadsexpert (produktägare)
- kravanalytiker
- systemtestare (storytestning, prestandatestning m m)
- säkerhetsexpert
- användbarhetsexpert (från behov till nytta)
- interaktionsdesigner
- webbprogrammerare
- grafisk designer
- tillgänglighetsexpert
- systemarkitekt (dvs minst en erfaren utvecklare)
- programmerare
- databasdesigner
- databasadministratör
- driftsansvarig
- processcoach
- verktygsexpert
- byggchef (CM)
- ramverksexperter (på valda ramverk, t.ex. Spring, Hibernate, Rails, Seam)
Att detta skulle vara olika personer har man givetvis inte råd med. Följden blir att vissa kompetensområden gapar tomma i team med utpräglade experter.
En annan nackdel med utpräglade specialister är att de har en tendens att inte vilja gå utanför sitt område – och inte heller släppa in någon annan på sitt område. Det blir lätt ”inte mitt bord”-mentalitet. Enbart en specialist kan säga: ”Ok, teamet hann inte med alla sina uppgifter, men jag blev i alla fall klar i förrgår”. Specialister är sällan lagspelare och kan vara svåra att leda och arbeta med.
Men generalister då? En generalist kännetecknas av ett stort intresse för många olika områden, men som sällan förkovrar sig inom samma ämne en längre tid. Fördelar med generalister är förstås att de är breda. De kan det mesta. Generalister har ofta en härligt attityd av ”hur svårt kan det vara” som gör dem relativt enkla att leda och samarbete med. Vad du än slänger åt dem så har de ett hum om hur de kan lösa problemet. Och de är vanligen inte rädda för att försöka! Den stora nackdelen är att de inte är utsökt bra på något. Utan specialister blir team långsamma och designen ofta allt annat än vacker (eller förvaltningsbar).
Men nästan ingen människa är total generalist eller specialist. De flesta är en blandning av båda, med läggning åt endera håll. Men det finns också två specialformer som jag vill ta upp: Specialiserade generalister och generaliserade specialister. Och båda dessa typer passar utmärkt i utvecklingsteam!
En specialiserad generalist är en generalist som har specialstuderat ett ämne att bli specialist inom. De är ovanliga men förekommer. Det kan till exempel röra sig om en projektledare som tvingats bli duktig på kravanalys i ett projekt och som sedan hittat en ovanlig niche som hon vill bevara. De måste ständigt arbeta vidare med sitt ämne för att behålla spetsen, vilket egentligen inte ligger i deras natur. Dock kompenseras detta av att de ofta mycket ambitiösa.
En generaliserad specialist är en specialist som även lärt sig att tänka som en lagmedlem och är öppen för att lära sig nya saker. Kan en testexpert lära sig grunderna i programmering? Kan en interaktionsdesigner bidra vid testningen? Kan en pythonprogrammerare hjälpa till med att analysera krav? Självklart!
Möjligheterna att bygga högpresterande team är stora med denna typ, då de både kan bidra med specialistkompetensen, men samtidigt kan se helheten och stötta varandra. Agila projekt strävar efter att ha merparten av teamen befolkade med dessa guldkorn. Och du som individuell specialist gör gott i att sträva efter att även kunna grunderna i områden utanför ditt eget.
