It´s funny… In March 09 i wrote about a “work person” exiting the elevator saying that “Scrum doesn´t work on large scale Oracle projects“. Now, 9 month later i found myself about to try just that.

For most of this fall i have been working as the lead architect for a large (I call it large when it is designed to handle 45 000 000 transactions/week) national tracking system for the food industry in Norway based on the EPC IS standard. We evaluated the requirements and landed on Oracle as a technology partner.

After beating IBM in a close head2head BID race for the  system we ´re now ready to begin the project initialization process and we have through the whole process had the goal to use scrum as project methodology. We have put together a great team of highly skilled engineers and developers and we know that there are two fixed factors, price and project end date. This is going to be fun! Continue Reading

The daily scrum

While taking a leg-stretch AFK at work today I was walking with the senior developer in our new development team for a startup project. I’m appointed  scrum master for the project and  asked him at what time of day would be  best suited for our daily scrum standup meetings, and he’s answer was “Let’s keep it floating and do it when everyone’s not bussy”.

I could not disagree  more! – Even tho we are a small team, with a base of  3.5 developers and one UX resource, inside  an environment where you almost have to hide while  juggling other departments or projects requesting you in meetings  and “emergency-just-fix-this-5-minutes-max-thingy’s” . Continue Reading

On friday a colleague of mine wrote a nice article about how to writing agile use cases after we had a discussion about how we should write effective use cases that also maintain the need for documentation.

 We are both excited about working with agile methods and we will be writing some articles in our respective blogs about our effort to “agilize” our development projects.

That was the statement i heard going down the escalator at work earlier this week.

“Scrum may be good for some things, but for large scale Oracle development projects, it doesn’t work…”

And I was like.. wtf???.. I have been thinking about this statement for a few days now and I still wonder why shouldn’t scrum work in large scale Oracle projects? anyone got a clue? Continue Reading

Computerworld skriver idag om Finn.no som har tatt i bruk scrum som metodikk for for sine prosjekter.

Finn sier noe jeg selv er helt enig i at “Bakgrunnen var at 60 prosent av alle it-prosjekter har forsinkelser, overskridelser og mangler, til tross for at mer enn 60 prosent av alle funksjonene aldri blir brukt.” Og jeg ser fram til at vi flere store som tar ibruk metodene og får erfaring slik at man etter hvert kan få håndfaste tall som viser at man faktisk tjener på å ta i bruk smidige metoder.

Håper også at Computerworld etterhvert legger ut en tilleggsartikkel som kan hjelpe med å finne scrum-funksjonaliteten på finn.no

Oslo Lean Meetup arrangerte mandag 1. Desember et seminar på The Dubliner i Oslo med Diana Larsen, som er leder for Agile Alliance Board Of Directors og er en internasjonal størrelse innen smidig tankegang. Hun har spesielt fokus på kontinuerlig forbedring gjennom sine metoder for “retrospectives”.

Var en svært nyttig seanse, der hun fortalte om hva hun mente var veien til inkrementell kunnskap og erfaring  – jeg må si at jeg synes det hun sa hørtes riktig så smart ut. I ryggraden av smidig utvikling og prosjektgjennomføring, ligger det å systematisk lære av erfaringer og feil, for hver sprint sette seg ned å finne ut av hva man kan gjøre bedre. Her kommer så sprint og prosjekt evalueringen inn. Selv har jeg ikke helt fått til å holde retrospetiver, 2 ganger har jeg forsøkt i mitt nåværende prosjektet, men det virket rett og slett ikke som om resten av deltakerne som var med virket spesielt entusiastiske til å evaluere noe som helst og synes ting var greit slik de var.
Continue Reading

digi.no skriver idag om IT-Selskapet Dips, som  i løpet av de siste 15 månedene har innført scrum som metodikk i organisasjonen.

Adm. Dir i Dips sier til Digi; “Vi mener Scrum innebærer store fordeler for oss. Det aller viktigste er at metoden vil gi oss bedre og raskere systemutvikling. Det er en vinn-vinn-situasjon, for kunden vil også merke forbedringen.Hittil har det vært en suksess”

Jeg synes dette høres fantastisk ut, og ønsker dem hell og lykke videre. Håper også de vil dele sine erfaringer med oss andre som ikke helt har kommet så langt. Kanskje et lite foredrag på en Lean Meetup hadde vært tingen?

18. september 2008. En merkedag i min løsningskarriere. Den dagen ble jeg “uteksaminert” og fikk den til dels tvilsomme tittelen SCRUM-Master, og kan føye til CSM på visittkortene mine, forkortelser er gøy og fler skal det bli.

Det som var det bemerkelsesverdige var at jeg mer eller mindre hadde en “åpenbaring”;

HVORFOR I SVARTE HAR MAN IKKE DREVET PROSJEKTER PÅ DENNE MÅTEN FØR???

I 1970 beskrev Winston W. Royce (1929–1995) fossefall metodikken for utvikling av programvareløsninger. I 1971 (ca) tok amerikanske Department of Defense metoden i bruk for sine utviklingsprosjekter. Senere, på midten av 70 tallet ble den adoptert av NATO, men da visste allerede DoD at metodikken ikke fungerte særlig bra og har vel side lett etter alternativ metodikk. Men av en eller annen måte har denne metodikken fått spre seg som et prosessvirus og ødelagt mang et utviklingsprosjekt.

I mine 15 år i jobb med utvikling av programvareløsninger har jeg sittet i utallige interne møter der man har prøvd å komme fram til en måte å gjennomføre utvikling fossefallsprosjektene med så liten sprekk og risiko som mulig, men det er nært sagt ingen som er i stand til å gjøre det. Fakta er at 80-90 % av alle programvare prosjekter som startes opp og utvikles etter fossefallsmetodikk bryter sammen på enten økonomi, funksjonalitet/innhold eller tidsfrister. Continue Reading