Thinking Inside a Bigger Box

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? Perspektivet til Magne som forsker på utviklingsprosjekter fikk meg til å tenke på spørsmålet, men før jeg fikk kommet med et forslag til svar. Derfor skriver jeg det her i stedet.

Å forske på et spørsmål som “fungerer smidige metoder” er veldig vanskelig. Mitt håp er at noen i stedet vil ta et skritt tilbake og se om man kan få svart på det mer interessant spørsmålet: Er det en sammenheng mellom hyppig feedback og lønnsomme prosjekter?

Read the rest of this entry »

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.

Read the rest of this entry »

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:

• Web Services standards will solve the technical integration problems (”the WS-* claim”)
• Centralizing integration will solve the governance issues surrounding integration (”the ESB claim”)
• Modeling use cases as workflows of services will solve the business alignment problem and promotes reuse (”the BPM claim, part I”)
• The flexibility to restructure the workflow between services will enable business agility (”the BPM claim, part II”)

I hope that an SOA evangelist will agree that these are important claims in SOA. Even if he will disagree with my evaluation of them.

Read the rest of this entry »

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.

But I think I understand what the real question may be now. Feedback comes at a cost. You have to actually release and deploy your system. You have to write and maintain test cases. You have to conduct meetings with the team and the stakeholders.

What cost should you be willing to pay for better information?

I can only speak from my own experience. Currently, we have two-week long iteration. The release, demo, planning and retrospective activities take about one and a half day out of each iteration. So the “feedback cost” is about 15%. I don’t think I would like my project to devote less than 15% of its effort towards implementing a feedback cycle. If you spend days integrating your project every iteration, a one week iteration won’t work for you. I don’t recommend doing fake iterations where the iteration degrades into a planning window, either. So if it takes me several days to do a proper iteration, I would rather have longer iterations.

Here is where I depart from the spirit of the question, though: If it takes you several days to integrate your project, how do you plan to act when you have to fix problems in production? A long feedback cycle is a high risk. If you can’t iterate frequently, this is a sign you need to fix your process, not that you should adopt a waterfall approach.

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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. Using the same technique, I’m also able to debug FitNesse tests.

Read the rest of this entry »

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. After the jump, I post a few examples of Post-It notes from my pocket.

Read the rest of this entry »

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”. Yet all of these moves will make your system less maintainable. How do I know? Because I measure my maintainability. We push out a new snapshot version of our system in 10 minutes, a release in an hour. We push out new version to a simulated production environment every two weeks. And when I threw out frameworks, remote interfaces, application servers and EJBs, my cycle time went down.

Tal Ben-Shahar writes the following in “Happier”, his introductory book into the field of positive psychology: “The proper role of goals is to liberate us, so we can focus on the here and now.” In order to help us have a fulfilling life, our activities should both be meaningful and pleasurable. In this sense, meaning means to have a long term goal, pleasurable means to have a short term goal.

When I was involved in sequential, waterfall-like projects, people always lost sight of the short term goal. Are sequential projects at odds with human happiness?

Read the rest of this entry »