On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen. The quick analysis Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Oracle released Java 7 on July 28, 2011. This is nearly 5 years after the release of Java 6 in December 2006. The release received a lot of bad press, both because it is very meager on features, and because it shipped with a severe bug. Nevertheless, once the most serious bugs have been fixed, you might think about starting to use Java 7. What will this mean? New language features Java 7 has a few new language features.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over.

For those of you who already use PuTTY: Here’s a little improvement that’s surprisingly little known. Probably because it is very hard to explain. But I’ll try. Here is how you can avoid starting programs, entering login information or indeed typing passwords when you use PuTTY: Download Putty installer from the PuTTY Download Page. Make sure to grab the “Installer” Install Putty Start PuttyGen from Start -> PuTTY-> PuttyGen Generate a new key and save it as a .

This blog post is a summary of my lightning talk at XP2011 I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box.

Can the various European Agile User Groups benefit from working together? I am cautiously optimistic. At XP2011 this week, Jurgen Appelo has taken the initiative to launch the Agile Lean Europe network. This is an initiative to bring together representatives from 17 European countries. Sergey Dmitriev and I will be representing Norway. To what end? I’m still not sure. There is no doubt that there is much Europeans can learn from each other.

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement” What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool. Skill If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it.

Teams gather around task boards to plan their day. If the conversation and the task board match, we stay on topic and we understand what the rest of the team talks about. The last month, my project has redesigned the task board with this in mind. Here is a picture of our task board as it looked a few weeks ago: Each column represents a day. The top swimline represents testing tasks, the second swim line represents development tasks, and the bottom represents outside influences.

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better. Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board.