Notes from Evidence-Based Management Training

These are some of the notes I made for myself during my two day training with Scrum.org and others at Scrum.org HQ. Two mind-blowing days, I assure you!

Agility Path comes in to managers at a solution level, Evidence-Based Management addresses the thought level. (If you haven’t heard about it, it’s essentially the next move in trying to improve the profession of software development.)

What do you want to accomplish & how do you want to measure it?

Metrics for improvement, not performance.

Elevating empiricism to business value.

Measuring input, is not output – what do you actually get from this investment?

Success for an Engagement Manager? Help bring relevant metrics, bc of relevant reasons.

Empirisk processkontroll

En hörnsten i Scrum är tillämpandet av en empirisk processkontroll – för den absoluta majoriteten av utvecklingsprojekt så är komplexiteten sådan att allt annat blir rena gissningsleken.

Lutningen av vagnarna på SJ:s X2000 (iaf det tågset jag reser med idag) har en prediktiv processkontroll. Sitter just nu ett par minuter utanför Göteborg och gungar av bara sjutton. Tåget går knappast snabbare än 40 km/h, men tågvagnen lutas som om vi rullade på i full fart. Resultat? Vi sitter alla och försöker motverka den överdrivna lutningen. Det ser lite lustigt ut, och det känns lite lustigt att vagnslutningen är så fyrkantig.

Agile i Göteborg

In Agile is all about fail quick. If you have success in company you do Agile wrong.

In Agile is all about fail quick. If you have success in company you do Agile wrong.

Det är fart på de agila i Göteborg:

Scrum Beers Göteborg (Meetup)

Göteborgs Agilister (LinkedIn)

Agile for management (DFS)

Tecken på agil utveckling

Sitter och rensar ut gammal e-post och hittade följande som skickades till en kund när ett POC-projekt övergick i “vi gör lite mer än POC” (från 2008).

Som förespråkare för agil utveckling vill jag ju poängtera att

  •  agila utvecklare aldrig undviker att “träffa” ett lager utan tvärtom har som mål att i varje utvecklingssteg se till att man tar ett “helt snitt av kakan” – man tar inte bara glasyren som vi gjort nu, utan strävar att alltid jobba sig hela vägen ner till botten (databasen) utan fusk eller genvägar.

Om vi har 30 minuter kan vi diskutera vilka agila principer vi skall hålla högt i detta projekt :)

Det förra projektet hade följande högt:

  • gemensamt kodägande
  • daglig regelbunden standup (med de tre frågorna: vad har jag gjort sedan senast, vad gör jag till nästa gång, har jag några hinder i vägen)
  • standupen får vara högst 15 minuter
  • planering i iterationer med synlig sprint backlog och …
  • … burndown chart
  • utvecklarna estimerar och planerar sprinten ihop med beställaren
  • sprintens backlog respekterades av alla
  • utvecklarna bestämmer egna dagordningen – alla jobbar med allt, inga revir
  • show and tell i slutet av iterationen
  • kontinuerligt bygge & test av koden
  • alltid körbar kod
  • sprintens backlog underhölls av och var till för utvecklarna och gav PM info om progress
  • endast återstående tid rapporteras

och halvhögt hölls

  • one shot build – ett kommmando är allt som behövs för att bygga och testa allt
  • retrospective – utan regelbunden utvärdering utvecklas man inte
  • gemensam arbetsyta (open work-area)
  • velocity – utvecklingstakt beräknades efter varje iteration utan indelning i mötestid, utvecklingstid, reviewtid, …
  • enhetstestning
  • coding standards – code review

och halvlågt hölls tyvärr

  • testdriven utveckling
  • automatiserad acceptanstestning
  • parprogrammering

och obefintligt var:

  • on-site customer
  • continuous deployment
  • relativa estimat i produktbacklogen (estimaten där hade rubriken timmar vilket var missvisande)

Det finns andra “agila tecken”, jag tog bara ett par ur huvudet och från http://jsolutions.se/2009/10/29/undersokning-om-agil-utveckling/

/Fredrik :)

Böcker om Scrum mm

Jag brukar ta med mig ett par böcker när jag håller workshops eller predikar om ett ämne jag håller nära hjärtat. Eftersom det ofta är svårt att hinna svara alla frågor eller gå på djupet på alla ämnen så brukar det uppskattas att jag lämnar referenser till böcker (eller bloggar) där man kan gräva sig djupare. Efter fredagens “Agile Injection” fick jag frågan om att skicka över listan med böcker jag hade med mig då. Här är den. :)

Följande utmärkta böcker rekomenderas varmt

Agile Project Managemeng with Scrum, Ken Schwaber
9780735619937
Appendix A är Scrum i ett nötskal (~10 sidor). “A book of case studies about Scrum”. Som Knibergs bok, fast mer polerad och mindre detaljrik.

Scrum and XP from the Trenches, Henrik Kniberg
9781430322641
125 sidor med erfarenheter: how we do testing, how we do sprint backlog, how we arrange the team room, how we do daily scrums, … Man bör kunna grunderna (helst prövat på) för att fullt uppskatta boken.

Clean Code, Robert C. Martin
9780132350884
Utmärkt genomgång av hur man renskriver kod, och varför. Ögonöppnare för många.

Working Effectively with Legacy Code, Michael C. Feathers
9780131177055
Utmärkt bok om “refactoring” – hur skall man attackera legacy code (dvs kod som inte täcks av automattest).

Mycket bra är också

The Pragmatic Programmer, Andrew Hunt, David Thomas
9780201616224
Insiktsfullt om kärnan av systemutveckling – hur jobbar en “bra” utvecklare (eller hur blir man).

Följande böcker har inte samma nivå, men är fortfarande bra.

Extreme Programming Explained, Second Ed, Kent Beck, Cynthia Andres
0321278658
Kent Beck försöker förklara Extreme Programming. Lyckas sådär.

Test-Driven Development, Kent Beck
9780321146533
Kent Beck visar upp TDD i praktiken med riktig kod i tre kapitel. En bra praktisk genomgång.

Andra har uppskattat

User Stories Applied, Mike Cohn
Agile Estimating and Planning, Mike Cohn
Agile Software Development with Scrum, Schwaber, Beedle

och lite utanför ämnet

The Mythical Man-Month, Frederick P. Brooks, JR
9780201835953
Insikter kring mjukvaruutvecklingen från 1975, med uppdatering tjugo år senare. Intressant om man tycker utveckling av systemutveckling över tiden är intressant.

Management 101 för 2000-talet

Detta är ett ofärdigt utkast.

Jag är riktigt intresserad av människor. Det är därför jag började bli intresserad av datorer, eller iaf fortsatte vara det. Datorer kan få människor att interagera mer, genom att göra tråkiga, enkla, dumma uppgifter åt människan. Människan blir glad för att hon slipper de tråkiga upptigfterna och kan ägna sig åt något kul istället.

Management by fear

Varje människa jag möter som har ansvar för en grupp människor, hoppas jag skall ha läst följande böcker och sett presentationerna nedan (som bara stärker det böckerna försöker förmedla).

  • Knowledge Worker, Thomas Davenport
  • Agile project management with Scrum, Microsoft
  • Rothstein

TED: Daniel Pink on Motivation

Get the Flash Player to see this content.