Three challenges for agile projects When I join projects now, I want to challenge all the stakeholders to make three commitments: Simulate production at least monthly: The software should be run in an environment that is comparable with the target production environment with loads and data variations similar to that of production. Thus, the technical stability of the project is proved. Demo with the business side at least monthly: The results of the project should be showed to the product owner, or perhaps even the end users.

As my previous Norwegian language article turned out to be one of the all time top hit articles in my blog, I will continue to write a few articles in Norwegian. This one is on an idea on how to do reseach on the success of agile projects. Next week, I will return to another popular topic: Testing. Under paneldebatten på Geilo-seminaret til Dataforeningen, satt Magne Jørgensen meg, Lars Arne Skår og Niklas Bjørnerstedt litt til veggs med et ganske enkelt spørsmål: Hvordan kan vi vite om smidige metoder virker?

What is the secret to happiness? Surprisingly, this question can be answered more and more definitively. I want my work to be conductive to the happiness of myself and others, and I believe agile methods can help me do that. Years of research into happiness can be summed up in a simple sentence. You all know what gives you a happy life. It’s not anything strange or unexpected. It’s simply enjoyable progress towards a meaningful goal.

Two of the hardest problems of software development are integration and what we could call business-IT alignment: The whole organization working towards the same goal. SOA claims to address both of these problems. After listening harder than I’ve ever done before to SOA evangelists, I think I understand what mechanisms SOA proposes to solve these problems. I think the idea of SOA is based on a set of rather bold claims:

When I give talks on agile, people often ask the inevitable question: “When is Agile not appropriate?” My response is that I don’t really care what people call what they do. What I am concerned about is the quality and frequency of the feedback that informs the control and decisions regarding project management and technical decisions on my project. I find the idea that you might not want to improve your feedback to be very odd.

This post is a Norwegian language summary of a talk I did April 14th, 2008 Jobber du smidig? Jeg jobber ikke smidig. Men jeg jobber smidigere enn jeg gjorde for tre måneder siden og enda mer smidig enn jeg jobbet for et år siden. Og om et år kommer jeg til å jobbe enda smidigere. Men Smidige metoder handler ikke om et mål, de handler om konstant forbedring gjennom bedre og hyppigere feedback.

In my previous articles, I have showed you how to create a simple blog application with articles, comments, rss feeds and formatting. However, as it is currently written, the application allows for anyone to create or edit an article. This is a serious security issue, and we better fix it. In this tutorial, I will show you how to make sure that only logged in users can create articles, and that nobody else can edit an article that you created.

On my project, we use Maven to build our software and FitNesse to write functional specifications. However, it was obvious that FitNesse wasn’t designed by Maven-fans. When I use Maven, I already have control over my classpath, and specifying it in every FitNesse test gets to be old really fast. Why can’t I just inherit the project class path, and start FitNesse using maven-antrun-plugin or just from my IDE? I found a neat way to implement this by overriding FitNesse.

Anders Nordås wrote a blog post where he talks a little about how he uses his beautiful moleskin notebook. I will pick up his challenge and write about my favorite tool, Post It notes. As many who know me are aware, I always have a pad of Post-It notes and a pen in my left pants pocket. I use the sticky notes for todo-lists, note taking in meetings, planning talks and doing brain dumps.

A number of great sins have been committed under the guise of making software more maintainable. And 60% of software cost is during maintainance, according to Robert Glass. So what goal could be more laudable to pursue? The only problem is that we call things maintainable which are not. Putting remote interfaces in your application is done to “make it more maintainable”, creating frameworks is done to “make it more maintainable”, using EJBs is done to “make it more maintainable”.