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.

Value first

The speaker from The Norwegian Government Agency for Financial Management (SSØ) pointed out that many projects are not sufficiently concerned with satisfying real objectives. Such a project may be a technical success, but still not worth doing.

Guidelines for eGovernment projects must first and foremost focus on the value delivered by the project.

Beyond the remarks of SSØ, we believe it is important that this value is delivered incrementally. Too often, the idea is that a project represents a substantial investment that hopefully fulfills some objectives. If a project delays long before it proves its promise, the business case may prove to be a mirage.

The business case has to be concrete and verifiable. For example, if a project claims to be able to eliminate 100 full-time positions, plans to actually terminate these positions should be within the project scope.

When should a project be terminated? Too often, projects are terminated too late. Guidelines for eGovernment projects should provide guidance to allow a project to terminate when it has realized only some of its promise, if there are better uses for future investments. And without incremental deliveries, there is no way of doing this without losing the whole investment.

Focus on experience

If the effort of the Norwegian eGovernment guidelines only result in a static document, it fails. Instead, we need an ongoing conversation where projects can share experience and recommendations.

There is much experience from existing eGovernment projects that can be utilized. Some examples from the discussions:

• During a project start there are some activities that are useful and many that are just a waste of time. Even so, experience about what common activities that provide no value is not widely shared.
• Some of the discussion participants have much insight into how to terminate projects ahead of plan. This experience can be critical to avoid throwing good money after bad. And to avoid throwing bad money after good.
• There are a few competing contract standards that are frequently used in eGovernment projects. Often the specific choice of contract is more a matter of personal choice than experience.

The scope and impact of recommendations

Many of my discussion partners were curious about the level of ambition regarding the official guidelines for eGovernment projects.

The overall goal of these standards is to create value in eGovernment projects. However, that goal is much too value to be a sufficient vision for the work ahead. It is especially important that the goals of the standard are Specific and Measurable if the end result is to be valuable.

During the discussion, it was also unclear what the scope of the recommendations would be. Early work on the standard could benefit from a table-of-contents that articulates what areas the standards will concern themselves with.

Is “project” the right word?

From the discussion, I draw my own conclusion:

To create effective eGovernment, it’s insufficient to look at projects in isolation. Instead, the various agencies must concern themselves with the full value proposition of their whole IT- and operational systems. Creating value in the context of a project can be a distraction from the everyday operational concerns of the organization. And the key to the value that can be created is in these everyday concerns.

A project runs the danger of becoming detached from the organization that it is created to serve and that will eventually bear the maintenance cost of the project deliveries. The number one concern should be to close this gap.

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.

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.

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 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.