Thinking Inside a Bigger Box

The Agency for Public Management and eGovernment in Norway is currently developing guidelines for IT-projects within the Norwegian governmental sector. The Norwegian Computing Association hosted a presentation and discussion about this work yesterday. I was privileged enough to summarize the comments from one of the three discussion groups at the meeting. For the enjoyment of the internet, I hereby provide a few ideas on eGovernment projects.

Read the rest of this entry »

This is a test case from my current project:

Scenario: Finish gathering information
  Given I have an open case
  And the case has a task "gather information from X"
  And the case has a task "gather information from Y"
  When the user confirms that task "gather information from X" is completed
  And the user confirms that task "gather information from Y" is completed
  Then the case should generate a new task "evaluate customer standing"

It seems pretty run of the mill. A tester will sit down with a bunch of these and try out the application.

Except that the tester in question is not a person! Instead it is a program named Cucumber.

I first learned the ideas behind Cucumber from Dan North at the ROOTS 2005 conference. And this year at the ROOTS 2009 conference Aslak Hellesøy, the creator of Cucumber, will give a tutorial that brings the ideas of Behaviour Driven Development as the next step in effective requirements and testing into the mainstream.

I’ve been attending the ROOTS conferences every year since 2000 and was on the committee for three years. The conference hosts world-class speakers and has a focus on up and coming ideas. It’s a small and intimate conference with tutorial style sessions that lets the speakers go into depth on their areas of expertize.

Do you want to stay years ahead in your field? Go to Bergen for the ROOTS 2009 conference April 27th to 29th.

I’ve been part of the group organizing the Norwegian language, lightning talks based conference Smidig the last two years. This Norwegian language article describes the essential guidelines to giving a short presentation.

En god lyntale kan ha enda større påvirkning enn et godt foredrag, fordi lettere kan nå flere mennesker. Men det krever innsats. En god lyntale er:

• Fokusert: Du skal ha ett poeng, én påstand eller ett spørsmål som foredraget bygger rundt. En god lyntale er ikke kortversjonen av et timesforedrag, eller abstraksjon over erfaringer. Snakk om konkrete erfaringer. Finn det aller viktigste poenget og snakk om det.
• Forberedt: En lyntale krever forberedelser, akkurat som et annet foredrag. Men siden det er kort har du anledning til å trene på det flere ganger. Vis ditt publikum respekt. Hold talen for en vegg tre ganger før du holder den for et menneske. Det tar bare 30 minutter.
• Pirrende: Når tiden din er brukt opp skal du ikke ha sagt alt du kunne ha sagt, og ditt publikum skal ikke ha hørt alt de kunne ha hørt. Både du og publikum bør ha appetitt på mer informasjon.

Kan du skape mening på ti minutter? Klart du kan.

Kommentarer, eksempler på gode lyntaler og forslag til revidering av “manifestet” mottas med takk!

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate.

Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten!

Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt. Jeg er bare en programmerer. Jeg er en programmerer som ønsker å jobbe på gode prosjekter. Jeg håper at det er mulig for meg å jobbe på gode prosjekter som også advokatene og politikerne vil være fornøyde med.

Hva er et godt prosjekt? Den enkle definisjonen er at et godt prosjekt er et prosjekt som både leverandøren og kunden, både utviklerne og brukerne er fornøyde med. For meg som programmerer er dette viktig. Og jeg tror det er viktig for mange andre programmerer. Hva er det som gjør at enkelte mennesker synes programmering er spennende? Jeg tror svaret er enkelt: Programmerer er mennesker som brenner for å skape ting som noen har bruk for.

Jeg ønsker å skape verdi, og for meg er smidige metoder en god rettesnor. Jeg tror ikke smidige metoder er et magisk ord man kan bruke for å få til vellykkede prosjekter, men jeg tror at verdiene smidige metoder beskriver forbedrer sjansene mine for å delta på gode prosjekter. Men bare dersom man forstår verdiene og ikke bare utfører tomme ritualer som man kaller “smidig”.

Jeg har jobbet noen år som programmerer. Og jeg har deltatt både på prosjekter jeg var fornøyd med og på prosjekter som jeg ikke var fornøyd med. Den triste sannheten er at de fleste prosjektene jeg har sett eller deltatt på var ikke gode prosjekter.

Derfor var det veldig spennende for meg når jeg først fikk høre om veillederen. Spørsmålet jeg håper veilederen kan svare på: Er det mulig å forbedre sjansen for at leveranseprosjekter blir gode leveranseprosjekter? Kan veilederen forbedre sjansen for at prosjektene våre blir gode prosjekter?

Jeg har lest gjennom det som har blitt skrevet med en blanding av håp og skrekk. Mitt svar er “jeg vet ikke”.

Men jeg er skeptisk. Det virker som om smidige metoder, som mye annet, er i ferd meg å bli et offer for sin egen suksess. Kan vi risikere å falle i fella at vi tror at fordi vi bruker ord som Product Owner og ScrumMaster og Sprint og Product Backlog så vil alt bli bedre av seg selv?

Det er lett å si “smidig”, men det er ikke alltid lett å gjøre smidig. Så for å forstå hva smidige metoder dreier seg om, gikk jeg tilbake til kilden.

Jeg bladde opp på http://agilemanifesto.org. De smidige verdiene er kjent for de fleste nå. De står på forsiden. Men det ser ut som om mange overser den første linken herfra. Den går til de tolv smidige prinsippene. Jeg har valgt ut tre for dere:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Det jeg har fått ut av smidighet, er erkjennelsen om at vi ikke kan anta perfekt informasjon. Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.

Så jeg står igjen med et siste spørsmål: Er det mulig å lage en leveransekontrakt som verdsetter denne dype verdien om feedback? Det håper jeg å få svar på i denne debatten.

I’m going on the road again. This time it’s not far, just to Trondheim for a seminar for the Norwegian computer association that I will be giving together with Aslak Hellesøy on agile development and testing.

This will be similar to our line-up at JavaZone: Aslak will cover “how to make the correct software”, and I will cover “how to make the software correct”. Hopefully, we’ll make a few test managers think and a few others angry.

The Norwegian word “smidig” means “agile”. So when we wanted to make a Norwegian conference for the Oslo Agile community, “smidig 2007” (November 26th and 27th) was a natural choice for a title.

The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month. The inception of the open spaces conference was delayed over the summer, and towards the end of the summer, Trond Pedersen and myself were discussing the success of the Oslo XP meetup lightning talks over a beer. The more we thought about it, the more it seemed natural: We need a whole day devoted to lighting talks. Meanwhile, Simen Fure Jørgensen decided to start up Oslo Lean Meetup.

We tossed the ideas around on the smidig.no forum for a while, and Christian Hauknes noticed how disorganized we all were about it, and decided to make it all come together. Along the way, many enthusiasts have contributed. Without them, it would all still be a fantasy in the minds of a few people.

Finally, we all came together with a single vision: A two day conference for the community, by the community. We know that there are a lot of people with extremely valuable experience who seldom get heard. Instead, conferences focus on big names that tend to overshadow the participants.

We hope that Smidig 2007 will be different. Both days of the conference are devoted to ways to get the participants to learn from each other. Open spaces workshops allows for in depth exploration of topics and experiences, while Lightning Talks, a presentation form that limits all talks to 10 minutes, allows for a wide range of point of view and experience.

Over 50 speakers have already signed up. For a conference where we expect a total of not much more than 200 participants, this is great. I’m overwhelmed by the great support of the business community. Over 20 sponsors have signed up, ensuring that we won’t go broke in the process of pulling together this conference. We have the budget to pull of a spectacular conference dinner, video recording of the whole event, and the most interesting venue in all of Oslo.

There are still a lot of things that could be improved. If you read this blog, and you would like to play around with the Rails-based conference application, organize a conference dinner, organize an open space conference, write about the conference, discuss experiences using agile principles on the forum, or help move chairs and table around during the conference, we would like your help. Or even better: If you yourself see room for improvement. Send an email to the conference mailing list to get in touch with us.

I have always been impressed by the insights of Oslo software professionals. I am looking forward to hearing a dozens of them speak in November.