2008 October | Agile Pain Relief

by Mark Levison on October 28, 2008 in Software Development

Is there Value in the Noika Test

A few years ago Bas Vodde defined a simple test to help his coaching group determine whether teams were trying to be agile and whether it would be worth investing coaching time with these teams.

As described by Joe Little, the test is:

The Nokia Test is in two parts.
First, are you doing Iterative Development?

Iterations must be timeboxed to less than 4 weeks

Software features must be tested and working at the end of each iteration

The Iteration must start before specification is complete

The experience is that if you ask a lot of “Scrum” teams if they can pass this part of the test, they can’t. If you are at a conference, often not a single team in the room.
The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

You know who the product owner is

There is a product backlog prioritized by business value

The product backlog has estimates created by the team

The team generates burndown charts and knows their velocity

There are no project managers (or anyone else) disrupting the work of the team

Comments { 0 }

by Mark Levison on October 28, 2008 in Software Development

Agile Games for Making Retrospectives Interesting

I wrote about this last week on InfoQ but I thought it worthwhile to call out the games I think are the most useful and interesting. In the news item I used a quote from Mike Sutton, that neatly sums up the value of games to my mind: "There is nothing as effective to accelerate learning as a physical immersive game. The simpler the better, better still with near to no props. As low tech as possible. You get to see the penny actually drop with some folks too – and that is a great moment".

Comments { 1 }

by Mark Levison on October 23, 2008 in Software Development, TDD

TDD Randori Workshop

A few weeks ago I ran my first Coding Dojo/Randori and while the participants learned from the session there had been a few key flaws:

The problem was too big
The problem was in a domain that was unfamiliar to everyone
The facilitator (me) participated too much Ouch. It was true.

This week we ran a second session and had a much better time. The key to success – pick a smaller problem and let people struggle for a good long time before making suggestions. In addition remind them frequently to ask the audience for help.

This week's problem:

Score a bowling game, (credit to Bob Martin and Ron Jeffries for the idea) based on the following rules:

A single bowling game consists of ten frames.
For each frame, a bowler is allowed a maximum of two rolls to knock down all ten pins
When a Strike is thrown, the current frame is finished
Scoring:
• 0-9 pins knocked down: score the number of pins
• Spare: 10 + number of pins knocked down by the next throw
• Strike: 10 + number of pins knocked down by the next two throws.

Effectively this means the ball after a Spare is counted twice – once for the spare and once for the strike. With Strikes the next two balls are counted twice.

Comments { 2 }

by Mark Levison on October 17, 2008 in Photography

Lightroom 2 Book Recommendations?

I’m looking for one or two Lightroom 2 books.

First I’m looking for a book (or even website) that provides a rock solid (fast, fast, fast) workflow. I’m reasonably proficient in Lightroom 1 – but am finding I have ever shrinking quantities of time to spend working with my images. Anything that can help save me even a few minutes everytime would be a god send.

The more difficult problem. I would like a book that gives me a deeper understanding of the develop module. I have got a fair understanding of the basic controls (white balance, exposure, fill, highlight recovery, vibrance, clarity etc.). But I get lost when I’m looking at the Curves, HSL controls, … – 2.0 has just made my life more complicated (in a good way). For Lightroom 1 I bought the O’Reilly Lightroom Adventure and its a good book, but I found the section on the develop module focused only the what. What effect does each control have? Good to a point – but I struggled to figure out when and why I would want to use the Curves (etc). Are there better books for 2.0? Martin Evening’s book gets great reviews but I’ve no idea about the depth in this area.

Other candidates include:

Adobe Photoshop Lightroom 2 How-Tos: 100 Essential Techniques: the table of contents doesn’t not offer hope.
Lightroom 2 Professional Shortcuts: What are the contents?
Adobe Lightroom 2 – The Missing FAQ: Real Answers to Real Questions asked by Lightroom users: What’s in this book?
…

What can you recommend? If you happen to be Martin can you tell me – does your book have alot of depth in the develop section?

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

If you enjoyed this post, subscribe now to get free updates.

Comments { 1 }

by Mark Levison on October 14, 2008 in Software Development, TDD

Advantages of TDD

During last weeks TDD Randori session I was asked, what are the advantages of TDD. Here is my short list:

Writing tests first require you to really consider what you want from the code
Short feedback loop
Creates a detailed specification
Reduced time in rework
Less time spent in the debugger and when it is required you usually get closer to problem quickly
Tells you whether your last change (or refactoring) has broken previously working code
Allows the design to evolve and adapt to your changing understanding of the problem.

Comments { 0 }

by Mark Levison on October 8, 2008 in Software Development, TDD

TDD Randori Session

We're ran out first TDD Randori session at lunch today (approx 15 attendees). I was inspired by Dave Nicolette's session at Agile 2008 and used the Danilo Santo's paper on their Brazilian Coding Dojo as a guide.

In a Randori we work as a group trying to solve a small problem using TDD:

There is one computer with the video output projected on a screen so all participants can see it.
Coding is done at the single computer by a pair of developers.
One half of the pair switches out every 5 or 10 minutes.
The pair on the keyboard should continuously explain what they are doing.
The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
The pair will use TDD (Test-Driven Development).

I picked the problem based on a complaint I've heard from people after many of the TDD classes: "the examples are too trivial and don't speak to real world problems. I also hear that we don't enough chance to practice TDD"

Comments { 2 }

by Mark Levison on October 6, 2008 in Software Development