Categories

Latest Comments

Arbeidsflyt, Jira og statuser

K I S S – Keep It Simple Stupid

Det er alltid en arbeidsflyt tilstede i et systemutviklingsprosjekt. Den kan variere i størrelse og kompleksitet, men den har ofte noen karakteristiske trekk. Den har for mange statuser eller tilstander.

La oss ta et eksempel hvor flyten er relativt enkel og man raskt kan få en oversikt over systemutviklingsprosjektet.
Denne flyten har en oppgave som er kommet inn og den skal flyttes til status “I arbeid” når noen har plukket den og begynt å jobbe med den. Dette hindrer at andre plukker samme oppgave og man har mulighet for å se hvor mange oppgaver som er i arbeid hvis man viser oppgaver fordelt på statuser i f.eks Jira.

Agile Task Board
Man benytter seg jo ofte også av verktøy for å synliggjøre en form for statusoversikt over nåsituasjonen i prosjektet. Denne oversikten kan vise frem antall oppgaver, hvem som jobber med de og hvor langt i arbeidsflyten de er kommet i form av statuser. Dette sikrer at man ved et øyekast kan se hvordan det står til med fremdrift i prosjektet. Det gir også andre muligheter for å kunne bedre lede et systemutviklingsprosjekt i at det gir direkte tilgang til mulige flaskehalser som for eksempel for mange oppgaver står til test og ikke på lukket når man nærmer seg produksjonssetting. Det kan være for mange oppgaver som står på en person. Det kan være en oppgave som ikke har endret status på flere dager. Dette åpner opp for en mye mer gjennomsiktighet i prosjektet. Det blir enklere å få oversikt og man kan raskere påvirke risikoelementer som dukker opp.

Man kunne tenke seg at man gjerne ville ha flere statuser på oppgavene. Det er mange eksempler på folk som tror de må ha en status for alt som er mulig av hendelser i et prosjekt. Dette kunne sett ut noe lignende som dette bildet.

Poenget med statuser i et slikt prosjekt og i arbeidflyten må gi mening og at man kan enten tenke seg at en status skal benyttes til noe man vil måle eller ha en oversikt over. Det må gi verdi for prosjektet. Jeg vil påstå at det siste eksemplet har unødvendig mange statuser. Hvis man benytter Atlassian Jira som sitt verktøy så er det mye bedre å benytte funksjonaliteten for Impediment i Task Board i stedet for en egen status for Avklaring. En status som Avklaring vil kun bli en status oppgavene går til når de skal dø. Ved å benytte impediment så markeres saken som hindret. Og det er jo nettop det den er. Den er hindret i fremdrift på grunn av manglende avklaring. Dette skaper en helt annen håndtering av oppgaven og ofte et høyere fokus på å få avklaringen gjennomført.

Det er andre statuser som jeg også ser som helt unyttige og det er for eksempel kodegjennomgang. Denne bør heller være iboende i prosjektet at man ved for eksempel steget fra arbeid til test gjennomfører en kodegjennomgang. Dette er en del av det å utvikle funksjonalitet og at oppgaven ikke er gjennomført før kodegjennomgangen er ferdig. Samme gjelder litt med “Klar til test”. Hvorfor har du behov for en status som sier at den er klar til test? Kan den da ikke bare testes? Kan den da ikke få status Test? Og når den er ferdig testet så får den status Done eller Lukket?

Faren med å opprette for mange statuser er at man kan komme opp i flaskehalser. Folk kan lett slippe ansvaret for saken når den er kommet i en annen status som krever en annen person sitt arbeid. Dette gjelder spesielt hvis ma jobber med Scrum som utgangspunkt og har prioritert oppgaver slik at det ofte er viktigere å få den høyest prioriterte saken helt til Lukket så fort som mulig.

Strategi og Mål

Marlene Dumas, Waiting (for Meaning) (1988), courtesy The Museum of Modern Art

Marlene Dumas, Waiting (for Meaning) (1988), courtesy The Museum of Modern Art

Alle selskaper må ha en strategi har jeg hørt folk si, men hvis vi spør hvorfor så er det sjeldent vi får et godt fundert svar. Derfor tenkte jeg at jeg skulle benytte meg av Google sin søkemotor. “why do we need a strategy?” Dette ga meg 131 000 000 resultater på 0,42 sekunder som er meget imponerende tall, men jeg ble fort skuffet når jeg leste side en og to med treff. Ingen treff som jeg følte passet til hva jeg trodde strategi var. Jeg tror strategi er en plan for å nå et mål. Derfor søkte jeg istedet med setningen “why do we need a goal?” og fikk 224 000 000 resultater på 0,13 sekunder. Ikke bare gikk det raskere å søke, men det fant mange flere treff! Øverste treff er en liten artikkel om hvorfor vi har behov for mål. Artikkelen er her hvis du ikke ønsker å benytte Google selv.

Tilbake til tanken om en strategi. Kan det være slik at en strategi er en plan om å gjøre noe for å oppnå ett eller flere mål. Da vil jeg stille spørmålet, hva er viktigst? Strategien eller målet? De fleste vil svare at målet er det viktigste. Det som da bekymrer meg er at jeg møter mennesker hele tiden som jobber i selskaper som har en strategi, men ingen mål. Da spør jeg meg selv om hva de skal med strategien.

Jeg utfordrer ledere i alle bransjer og selskaper til å tenke på meningen med det de gjør i selskapet. Har det noen mening? Er det å få mest mulig penger i lomma et mål? Er det å bli størst i verden et mål? Hvis man svarer ja på de to siste spørsmålene så vil jeg gjerne stille et til. Hvorfor? Hvorfor er det viktig å bli størst i verden? Hvorfor er det viktig å ha mest mulig penger i lomma?

Hvis man jobber med strategien i selskapet. Begynn med målet. Deretter se på mulige måter å komme dit.

Mål inspirerer. Mål gir fokus. Mål gir mening.

Do You Have Purpose?

These last few weeks have been interesting. Suddenly I’ve been getting emails and stumbled on blog posts about purpose and inspiration. It makes me feel that I have no other choice than to post a small update and point you guys in the same direction.

Currently I am reading a book called Passion at Work by Albion and Kang, so far I am enjoying it. It can be recommended if you need to find incentives to change your life and it gives you a few techniques to overcome some of your resistance.

Another source of inspirational information was the video RSAnimate made of Dan Pink’s talk on Drive.

So I challenge you! Do you have a purpose in life? Are you even living your life?

Supporting Communities

I just backed a project on kickstarter. If you have not heard about it yet, head over there and have a look. It’s a great way to start a community project or help others to have a better day!
For this spesific project, take a look at TEDtalks first then check out the kickstarter project page.

Hva har barnevogn og trafikklys med smidig å gjøre?

Vi lever i en verden som er full av andre mennesker. Dette betyr i praksis at man må kommunisere og forholde seg til andre rundt seg hele tiden. Hvordan gjør du det? Se på de to eksempler nedenfor og spør deg selv hva du ville gjort.

Hvilken ende egner seg best?


1. Du har en barnevogn og skal på trikken. Som dere alle vet så er det to muligheter for å få barnevognen inn på trikken. Enten med fronten inn først eller med “håndtaket” først. Er det noen steg opp for å komme inn på trikken så krever denne jobben to stykker. En på hver side av barnevognen. Med hvilken side av barnevognen ville du som gått inn på trikken med først?

Ville du tenkt over din egen situasjon? Ville du tenkt hva som var beste måten å gjøre det på? Ville du endret måten å gjøre det på hvis du så at den andre personen måtte bøye seg helt ned og har vanskeligheter med å løfte vognen inn på trikken samtidig som du må strekke armene i været fordi håndtaket kommer så høyt? Er du villig til endring fordi det du gjør ikke er bra for andre?


2. Veier har ofte mye trafikk her i Oslo og dette har medført at det finnes mange overganger for fotgjengere. Mange av disse har også trafikklys slik at du som fotgjenger kan trykke på en knapp og få mulighet til å påvirke trafikken og din egen mulighet til å gå over veien med mindre risiko for ulykker. Du kommer til overgangen en morgen og det er et godt stykke til neste bil som vil passere. Hva gjør du?

Ville du trykket og ventet på grønn mann for å kunne gå over? På denne måten har du minst risiko. Ville du trykket og deretter sett om du hadde tid for å krysse gaten før bilen og gjør det? Høyere risiko, men kontrollert. Dette valget ville også påvirket trafikken da de måtte stoppe for rødt lys etter at du hadde gått over gaten. Eller ville du gått over gaten uten å påvirke trafikken med å trykke på knappen for å få grønn mann?

I den første situasjonen (1) så tør jeg påstå at man kan ta lærdom av omgivelsene sine og de rundt seg. Er det slik at den måten du utfører jobben din på gjør at andre ikke får utført sin jobb på en god måte? Samarbeider du med andre om et felles resultat? Kommuniserer du med andre om forbedringer?

I den andre situasjonen (2) så handler det ikke så mye om kommunikasjon som om evnen til å se effektiviseringer og forenklinger. Skaper måten du jobber på et hinder for effektivitet i resten av teamet? Påvirker du andre rundt deg ved å gjøre oppgaver som ikke gir verdi? Utfører du handlinger uten å se deg omkring?

Ta en tur innom smidig.no og les det smidige manifest (på norsk). Smidigkonferansen er også åpnet for registrering og vil bli arrangert den 16-17 November.

Manifest for smidig systemutvikling

Vi oppdager stadig nye og bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette:

* Individer og samspill framfor prosesser og verktøy
* Fungerende system framfor utførlig dokumentasjon
* Samarbeid med kunden framfor kontraktsforhandlinger
* Å reagere på endringer framfor å følge en plan

Det betyr at selv om punktene til høyre er verdifulle, verdsetter vi de til venstre mer.

Hva er smidig?

Spørsmålet om hva som er smidig dukker alltid opp når vi begynner planleggingen av en ny konferanse (Smidig2010) og det er like aktuelt som tidligere konferanser. Det finnes like mange svar på dette spørsmålet som antall personer som blir spurt.

Det finnes ingen objektiv definisjon på begrep slik som Smidig. Selv en definisjon vil bli tolket når den blir lest og lagret inn i en hjerne.

Men før jeg farer avgårde på filosofiske stier om subjektivitet og andre ting som hører livet til så ønsker jeg å komme tilbake til det jeg hadde lyst til å skrive om i dag. Hva er smidig for meg, ja nettopp, subjektivt. For meg så betyr smidighet det samme som evne til å endre noe. Slik som en Tai-Chi utøver som alltid er i balanse og kan bytte retning når en vil. I dag er det tre ting som for meg er avgjørende for evnen til endring.

Min hjerne


1. Reell tilbakemelding så tidlig som mulig
– Får jeg tilbakemelding fra de som faktisk skal benytte funksjonalitet som utvikles mens jeg utvikler den så vil jeg enkelt kunne endre funksjonaliteten. Dette er ikke dog ikke noe som kommer av seg selv. Dette krever også et stykke godt håndtverk. Se Software Craftmanship for mer detaljer eller les en bok om emnet.

2. Lav risiko ved hver leveranse
– Kan jeg levere små og hyppige leveranser til produksjon/drift så vil endringene være såpass små at man kan ha en viss kontroll på risiko samtidig som man unngår unødvendig kompleksitet i selve produksjonssettingen.

3. Læring
– Hvis jeg får lov til å levere både hyppig og til reelle brukere i produksjon så vil jeg få tilbakemeldingen jeg behøver for å kunne lære av det jeg nettop har gjort. I motsetning til noe jeg gjorde en gang for lenge siden. Jeg husker knapt hva jeg gjorde forrige uke. I tillegg så endrer jo verden seg fort. Endret verden seg etter forrige produksjonssetting?

Det finnes selvfølgelig mange måter å definere smidig på, men fra mitt ståsted så må man jobbe med de tre punktene over for å kunne øke sin evne til endring i et prosjekt. Det finnes som Eriksen sier i sin post flere måter å gjennomføre et prosjekt på være seg Agile eller Lean, men for meg så bunner det fortsatt ut i å kunne få reell tilbakemelding på hyppige leveranser for å lære mer. Med mer kunnskap så vil også du kunne gjøre mer.

Switching to Norwegian in the upcoming posts

Due to the fact that most of my readers now are located in Norway or Sweden I will change to Norwegian when writing posts. This will enable me to be even more clear in the communication with the agile community in Norway.

Please do not hesitate to add a comment on my blog with any questions that you may have (in Norwegian or English).

Yes, The Tool Does Matter In Agile!

Tool box

Thanks to http://theaterforthefuture.com for the picture


Agile is not about tools, but it still matters to the team members. I am always focused on people in projects and that is why I say that tools matter. If the team member is having a great time when doing the tasks of the day it will show results. So what does this have to do with tools? Isn’t it all about having skilled and motivated people around you? I can easily answer yes to that question, but there is more to it than that! What do you need in your life to have a nice day at work? What stops your motivation at work?

If I stare at a computer screen for eight hours a day I want to see and do exciting things. I want to be able to work without the hassle of being dragged down with errors in software or slowed down by applications that should have been faster. I want my boring tasks to be automated and I want to be able to effectively use my tools. I want to be good at using my tools. I want to be a craftsman with good tools.

Ever wonder why your carpenter has really good tools? Because he needs them to do a good job. They might be expensive, but they do not break down after a week and they are good to work with. I asked a carpenter once, “Why do you have that expensive hammer?” and the carpenter said, “It’s very good to hold in my hand”. His tool made his day better.

It’s the same in our projects. We need tools that gives us value so we can deliver value to our customers.
If the tool does not give any value, get rid of it or change it. Also think about this when you make applications for your customers. Does the tool you make give any value? Is it quality in what you make? If not, change it..

New Project, New People – What Do You Do?

I’m currently in the phase of starting up a new project and we are to take over the development and the maintenance of several systems in a big organisation. This is what I love about my job! Working with people and change.

So what do you do when you have finally won the big contract? Beside planning and assessing risks and all those standard tasks you need to do something even more important. You need to create relations and establish a good area for communication in your team. I know you have heard about team building before, but its more than that.

Jumping in to the unknown in Malaysia

Picture from http://airsportstv.wordpress.com

Here are some actions on my list when entering or making a new team:

1. Get to know all the names and if possible read their CV.
– This will help you remember everyone and believe me, it will be noticed.

2. Discuss simple things as well as big ones.
– This enables communication and builds relations.
– Discussions often lead to commitment and ownership.
– Let the team decide how they want to work together.

3. Meet the boys and girls early.
– Arrange it so everyone has met everyone.
– Do it with workshops, lunch or other activities.

4. Acknowledge the change
– Moving to a new project is change for everyone and we deal with it differently
– Pay attention to the little things as well

As with all change we need a feeling of safety to help us make the jump in to the unknown. It is always good to know that there is a whole team making that jump together.

Do not let fear hold you back from a wonderful day!

Being Sick

Once in a while we all get sick. We get the flu or other illness that keeps us from going to work.

Flu

http://www.benettontalk.com/google-vs-the-flu/

Well that is what we are supposed to do, stay at home and get well.

Many people misunderstand this message because they think that they should try to be at work even if they are sick, a practice known as presenteeism. They feel they at least can be there and help. What they are doing is not helping. The problem with presenteeism is that it’s making the rest of the team sick or its not helping you to get rested and well.

In Norway we got paid sick time and there is no financial reason to go to work until you are well enough to do so. So if you are sick, stay at home.

Presenteeism on wikipedia