Hans Brattberg

Hans Brattberg

Agile and Lean Coach

The importance of size and proximity

We have translated our blog on team size and proximity to english.

If you prefer to read it in Swedish it’s called Storlek och närhet har betydelse.

The english version you’ll find at Nomad8 site, because Jimmy Janlén is currently in New Zealand.
🙂

 

Storlek och närhet har betydelse

Process är dyrt. Större team, distansarbete, deltidsarbete samt många specialister leder till mer uppstyrd process. Kanske är detta självklart, men ju fler företag vi lär känna, desto mer upplever vi detta vara något som ignoreras.

Jobbar vi i någon form av agil process såsom Scrum, Kanban, eller Lean UX värderar vi högt samarbetet mellan olika kompetenser. Ett team av olika kompetenser som kan ta en idé från start till mål brukar kallas tvärfunktionellt.

XFT team -- Idé till release_004

Ett tvärfunktionellt team är ett team som kan ta en idé hela vägen till release.

Enklast möjliga agila process för hur dessa personer kan samarbeta ser ut så här:
read more »

Lean Startup comic book “Jennie Discovers” now as a poster

JennieDiscoversPoster1
We have just released our short comic as a poster, free to download and print!

Jennie Discovers is a comic that tells a story about working Agile and Lean. It’s a story of product discovery, the journey from first idea to continuously releasing and updating a product or service. This book is written for product owners, requirements analysts, and project, purchasing, and line managers. Concepts covered: Hypothesis, MVP, Lean Startup, Pivoting and User stories.

/Hans and Jimmy

GraphWiki

My GraphWiki is now in a public beta 🙂
http://www.graphwiki.com/

Lean Startup

Du har en idé om en tjänst.
Hur kan du snabbast och enklast verifiera att någon vill använda den?
Det är vad Lean Start-up handlar om.

read more »

A Scrum Product Owner Checklist as a mind map

If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!

read more »

Kanban Basic Patterns

I have collected and distilled  some of the basic patterns of Kanban-board patterns I’ve found on various boards. You can combine them in any way that suites you, but you probably don’t need all of them at the same time.

Here’s how a sample pattern looks like:

Kanban Board Pattern

If you print the pdf to 9 pages per A3 you’ll get a nice overview. Let me know if you are missing one of your favorite ones!

To see an actual flow of tickets and evolution of a Kanban-board I recommend this slide show!

And here are some more links to kanban patterns:

A team experiment with and without offshoring

A cross-functional team I was working with last year had three testers offshore in India. The rest of the team (about 15 people) was co-located here in Stockholm.

Some team members had a nagging feeling that they could go so much faster if the testers also moved to Stockholm so they went to their boss and asked. The reply was that testers are so much less expensive, by a factor 2.3, so it was not possible, unless they could settle with fewer testers.

So they decided to do an experiment for a few months. They moved one of the testers from India to Stockholm and dropped the other two testers (re-allocating the other two to other teams) to see how that would work.

read more »

Properties of a good daily stand-up

I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties:

  • Time-boxed (15 minutes)
  • Everyone is engaged
  • Synchronization is taking place
  • Attention to problems
  • People ask for help
  • The conversation is about stuff that matters to most people, individual issues are postponed
  • Anyone can lead the meeting, not just the Scrum Master / Team Coach
  • The meeting is the starting point for the day, afterwards everyone feels energized and can start working right away
  • Ends with a punch that marks the end of the meeting and the start of the day*

* The team has dumbells by the scrum board. The rule is that if you feel the current speaker is monopolizing the meeting, you can hand the speaker a dumbell. Now the speaker can keep talking only as long as they can hold up the dumbbell with an outstretched arm.

Scala Code Kata Roman Numerals

There’s a Scala User Group in Gothenburg that had several meetings during this summer.  In one of the meetings the group solved a Kata named KataRomanNumerals (A Kata is a small problem that you do over and over again to learn)

The KataRomanNumerals says you should write a function to convert from normal numbers to Roman Numerals: e.g.

1 –> I

10 –> X

7 –> VII

Unfortunately I could not attend at this meeting, so I had to do it on my own during a few summer nights when my family finally was asleep :-).

Here’s my solution:

object Program extends Application {

class RomanInt(number: Int) {

def toRomanString() = {

val ones = List(“”, “I”, “II”, “III”, “IV”, “V”, “VI”, “VII”, “VIII”, “IX”);

val tens = List(“”, “X”, “XX”, “XXX”, “XL”, “L”, “LX”, “LXX”, “LXXX”, “XC”);

val hundreds = List(“”, “C”, “CC”, “CCC”, “CD”, “D”, “DC”, “DCC”, “DCCC”, “CM”);

val thousands = List(“”, “M”, “MM”, “MMM”);

thousands(part(1000)) + hundreds(part(100)) + tens(part(10)) + ones(part(1))

}

def part(digit: Int) = {

number % (digit * 10) / digit

}

}

implicit def Int2RomanInt(number: Int) = new RomanInt(number)

println(154.toRomanString()) // prints ‘CLVIII’

}

Here’s the code with better formatting.

Please comment and correct if I didn’t write idomatic Scala or if you have suggestions for improvements.

/Hans

Emo-lines

If you coach a scrum team but you’re not around to observe them during the sprint, how do you know how they felt about it?

Ask them.

You can interview them individually or as a group. Both approaches have their problems and limitations. Individual interviews take a lot of time, and sometimes you can’t share the results without breaking confidence. If you ask them as a group you usually only get answers from the most outspoken people because:

It’s hard to talk about your feelings among strangers.

One of the teams I coach had mixed feelings about Scrum. Some were healthily skeptical, and some positive. The first sprint went very well, with a good sprint planning, a lot of initial energy and a demo that actually showed customer value. But I felt that some of the team members were not too sure how the others felt about the whole thing. I wanted to help them with that and also get some feedback myself (I admit I was a bit nervous about not being around).

I used Emo-lines.*

Here’s how you do it. First draw a time-line representing the whole sprint and ask everyone to put up notes, marking memorable or unusual events. The team’s looked something like this:

Then you prepare for the Emo-lines, start by drawing a line directly underneath the time-line. The line represents neutral feelings, with feeling good above, and feeling bad below:

Next, have each person draw how they felt during the spring using different colored markers, starting at the sprint planning and ending with the sprint demo. Here’s a simplified version of the team’s chart:

The team members’ feelings varied greatly, you can see from the chart that the sprint demo went well though because everyone felt pretty good at the end.

The next step is to ask each person to comment on his/her line. Here’s what the team said:

Mr Green – a skeptic at first.

Mr Green is a very influential person in the group and the architect, he was the first to go. He said that he was a bit skeptical at first (as everyone had noticed during the scrum training right before the sprint started). He was worried that sitting and working in a team room would interfere too much with his flow and his privacy. As the sprint went on, he came to appreciate how quick and easy communication was with the new setup and realized that it was rather fun working that way. And when the first demo went well, well…

Mr Blue – a scrum advocate who got lonely.

Mr Blue was one of the driving forces in introducing Scrum to the company and the only one who was a certified scrum master. So I was a bit surprised and worried that he had such a dip after the first week. As it turns out, during the second week he had to work from home because his kids were sick, so he felt isolated and unproductive.

Mr Orange – an enthusiast both when skeptical and when not.

Mr Orange was also one of the skeptical-at-first but enthusiastically so. At the beginning of the sprint he felt that it was fun and that it worked for him. The problem was that they actually completed the whole sprint backlog mid-sprint and he thought that was boring and unproductive. As soon that they got some extra work from the product owner he was happy again.

Are Emo-lines useful?

The team thinks so, and they decided to use them at the next retrospective. The second time they got even more out of the chart, each line showed more variation and the explanations were more detailed.

They are also valuable to me as a coach. Even when I am not with the team during the sprint I get detailed feedback about how the team feels at the end of each sprint.

I also noticed more than one surprised look on the other team members’ faces when Mr Green talked about his line, and I think some team building took place.

Here’s a picture of the whiteboard:

*If someone has another name for these, please let me know, I heard about them from my colleague David Barnholdt, and he didn’t have a name either.

Emo, see http://en.wikipedia.org/wiki/Emo

Parprogrammering med Niclas Nilsson

Jo, jag vet, fel dag att skriva blogginlägg, detta är inte ett aprillskämt.

Niclas Nillson, Factor10, har just publicerat ritningar för sitt parprogrammeringsbord, det inte bara fungerar, det är snyggt också!

Niclas och jag ska hålla en parprogrammeringssession på Öredev i november, mer info om det senare. www.oredev.org/

ScrumMaster på svenska?

Vad borde ScrumMaster heta på svenska, och varför heter det ScrumMaster och inte Scrum Master på engelska?

Enligt en anekdot jag hört så var ursprungsnamnet Scrum Slave, men Ken Schwaber och Jeff Sutherland insåg tidigt att det inte skulle vara så säljande. 🙂

Hur översätter vi då Scrum Master till svenska?

Enligt lexin så har Master har som vanligt en massa översättningar till svenskan, och frågan är vilken av följande synonmyer som man borde fokusera på:

  • Herre, mästare, överman, härskare
  • Lärare, läromästare, lärofader
  • Mästerlig
  • Orginal
  • Styresman, föreståndare

OK, jag spånar ihop några kombinationer så får vi se vad det blir
Scrumherre, Scrumhärskare, Scrumlärare, Scrumläofader, Scrummäster, Scrumoriginal, Scrumstyresman, Scrumföreståndare.

Vilket av dessa? Vi måste nog krypa under skinnet på vad man förknippar för egenskaper med själva ScrumMaster rollen. En ScrumMasters uppgifter är enligt Mike Cohn:

Vara ledningens förlängda hand i projektet

  • Se till att Scrums värderingar och principer följs rigoröst
  • Tar bort hinder
  • Se till att teamet är fullt fungerande och produktivt
  • Möjliggör tätt samarbete mellan alla roller och funktioner
  • Skyddar teamet från externa störningar

Från dessa skulle man kunna tänka sig
Scrumchef, Scrumledningsrepresentant, Scrumpolis, Scrumhinderborttagare, Scrumlagkapten, Scrumfacilitator, Scrumstötdämpare.

Själv tycker jag att en ScrumMasters främsta roll är att främja kommunikation. Och enligt wikipedias artikel om scrum så är en synonym till ScrumMaster facilitator. Facilitator betyder enligt lexin “en person som hjälper andra att diskutera effektivt”, vilket skulle kunna vara en konfliktmedlare eller kanske snarare en diskussionsledare.

Scrummedlare, Scrumdiskussionsledare.

Sen har vi naturligtvis möjligheten att helt enkelt använda en försvenskad variant av ScrumMaster, Scrummaster.

Hur ska jag avgöra det här då, äsch, ni som läst hit får vara med och rösta!
Mejla scrummaster@erudio.se det alternativ nedan som du tycker man borde använda i svenska texter när man pratar om ScrumMaster. När jag fått 100 röster så ska jag redovisa resultatet här. Välj mellan:

  • Scrumherre
  • Scrumhärskare
  • Scrumlärare
  • Scrumläofader
  • Scrummäster
  • Scrumoriginal
  • Scrumstyresman
  • Scrumföreståndare
  • Scrumchef
  • Scrumledningsrepresentant
  • Scrumpolis
  • Scrumhinderborttagare
  • Scrumlagkapten
  • Scrumfacilitator
  • Scrumstötdämpare
  • Scrummedlare
  • Scrumdiskussionsledare.
  • Scrummaster

Förövrigt så heter det ScrumMaster men Produkt Owner, kan det vara så att det är Trade Marked eller något? Har förjäves försökt googla på det men inte hittat något svar, om ni har något, mejla gärna mig på hans.brattberg@crisp.se.

Lean för mjukvara på 10 minuter

Lean handlar om att bli snabb genom att sluta göra onödiga saker.

Lean ser det som vi producerar som ett arbetsflöde. Ett arbetsflöde startar med en idé som en kund vill ha gjort, och slutar med leverans till kunden, från Concept to Cash. Lean strävar efter att ta bort allt onödigt som sinkar och stör detta arbetsflöde så att tiden det tar från beställning till leverans är så kort som möjligt.


Lean handlar om att minimera tiden från att vi har en idé/beställning till vi har producerat det som någon är beredd att betala för.
Cykeltiden är hur lång tid det tar från det att en kund kommer med ett önskemål, tills dess att hon fått det levererat (och är beredd att betala för det).

För att kunna optimera cykeltiden kikar man på vilka flaskhalsar och köer som finns i arbetsflödena i en organisation.

Ett enkelt sätt att hitta de flaskhalsar man har är att kika på var vi har saker på hög, var är våra köer? En kö bildas alltid före en flaskhals.

Efter en kö finns det alltid en flaskhals.


Var någonstans ligger halvfärdiga saker på hög? Ligger de i bugghanteringssystem, orderhanteringssystem, otestad mjukvara eller i kravspecifikationer? Vilken flaskhals är det som kommer direkt efter denna hög?

Lean handlar om att identifiera dessa flaskhalsar, se till att de försvinner och skapa ett jämt flöde. Ett flöde som därigenom på kortast möjliga tid och med minsta möjliga resursåtgång levererar det kunden vill ha.

Lean värdesätter det som levereras och inte det som påbörjas. Att få saker ur händerna istället för att jobba hårt.

Många företag arbetar enligt filosofin att hela företaget går bra om alla delar arbetar effektivt och hårt. Lean optimerar istället på helheten och mäter cykeltiden, from concept to cash, vilket inte nödvändigtvis är samma sak. Låt oss ta ett exempel. Här nedan är en ögonblicksbild av ett arbetsflöde.

Vi har tre stationer. Vid varje station arbetar man optimalt och hårt. Trots det ligger saker i kö. Vi har station A där det i genomsnitt tar 1,5h att genomföra en sak, och där det för närvarande ligger 3 saker i kö och väntar. Station B där man är två som arbetar och är överbemannad och därför inte har någon kö, och det tar i genomsnitt 1/2h att göra en sak. Station C där det tar 2h att göra en sak i snitt och det ligger 3 saker i kö.

Låt oss säga att alla arbetar heltid. Då har vi en arbetstid på 160h i veckan (4 personer á 40 h). Vi slutför 20 saker i veckan eftersom sista stationen C levererar en sak varannan timme. I genomsnitt tar det 14,5h från start till mål att utföra en sak (summan av hur länge en sak ligger i kö + göra tid). Antal saker som vi samtidigt arbetar med är 9 vilket är alla saker vi arbetar med plus de saker som ligger halvfärdiga i olika köer (4+1+4).

Arbetstid 160 h
Tid genom systemet 14,5 h
Levererade saker i veckan 20 st
Antal saker på gång samtidigt 9 st

Låt oss nu begränsa mängden som vi arbetar genom att anpassa oss efter flaskhalsen, station C. Vi tillåter helt enkelt inte att A och B producerar så länge det finns en kö i C utan tvingar dem till att vila.

Vi har nu den totala arbetstiden fortfarande 160h, men utav den vilar vi i stationerna A och B totalt 70h (10h + 2*30h) per vecka  och vi producerar fortfarande 20 saker i veckan. Däremot har vi färre saker i systemet, nu endast 3 saker åt gången (inga köer). Tiden det tar från att vi börjar med något tills det är klart för leverans har sjunkit från 14,5h till 4.

Med köer Utan köer
Arbetstid 160 h 160 h
Tid genom systemet 14,5h  4 h (mer än tre gånger så fort)
Levererade saker i veckan 20 st 20 st
Antal saker på gång samtidigt 9 3 (en tredjedel)

Om vi låter flaskhalsen styra hur mycket var och en ska producera får vi alltså

  • Lika mycket levererat
  • Leverans till kunden tre gånger så fort
  • Färre saker att hålla reda på

Pausa lite här och reflektera, detta är inte intuitivt: Genom att jobba mindre levererar vi snabbare!

Men vi slutar inte med detta, låt oss optimera flödet. Vi har ju två personer på station B som inte behöver vara fler än en. Vi flyttar en av dem till flaskhalsen C och ser vad vi får för resultat.

Nu har vi fortfarande 160 timmars arbetstid men tiden att inte göra något gäller nu B och C medan A går för fullt. A är alltså den nya flaskhalsen som bestämmer hur mycket som produceras. Då den blir klar med en sak på 1,5h så blir antal levererade saker per vecka 40/1,5 = 27. Tid genom systemet är 3,5 timme och antal saker som man arbetar på är fortfarande 3.

Med köer Utan köer Optimerat utan köer
Arbetstid 160 h 160 h 160 h
Tid genom systemet 14,5h 4 h (tre gånger så fort) 3,5h (ytterligare lite snabbare)
Levererade saker i veckan 20 20 27 (35 % förbättring)
Antal saker igång samtidigt 9 3 (mindre än hälften) 3 (oförändrat)

Efter att ha identifierat flaskhalsen och åtgärdat den har vi alltså ökat det vi levererar med 35% och jämfört med vårt utgångspunkt levererar vi fyra gånger så fort.

För att sammanfatta strategin ovan

  1. Begränsa arbetet som var och en gör så att igen producerar mer saker än vad som behövs i det totala flödet (limit work to capacity).
  2. Identifiera flaskhalsen.
  3. Åtgärda flaskhalsen

Lean handlar om att få detta att fungera.

Exemplet ovan är taget från typiskt fabriksarbete, men om man ser sakerna som för sig i flödet som en funktion som ska läggas till i en mjukvara, där station A kan vara någon form av krav analys, station B kodning och C testning så stämmer resonemanget även inom andra områden. Om du vill se ett sådant flöde i praktiken, gå in på en lunchrestaurang i rusning, till exempel Subway.