Monday 23 November 2009

The True Weight Of An Iteration Board

An iteration board carries lot more than its actual weight. It is there every day to remind you of all your mistakes and weaknesses. Sure, many people envy us for our friendly atmosphere and the unusually humane working environment we work in. What most people fail to see is our constant struggle to do our best. They don't see the cruel honesty that forces us to face our shortcomings day after day. There has not been an iteration, however successful, going by at the end of which we didn't identify issues in our process, approach or skills that we needed to resolve.
This honesty could be a real burden, especially for one with a programmer's ego, if you don't reach out to Kent's Principle of Opportunity, that states that we need to look at problems as opportunities. In this case as opportunities to improve.
Also don't forget, the problem is not the iteration board and its bug-cards for instance. Iteration boards and burndown-charts can solely be indicators of something going wrong, they are not the problem, nor the cause. So next time when you look at a burn-down chart that is not steap enough, or an iteration board that is not "green" enough, don't rush to find solutions to make it steaper, or don't try to organize your work, so that you can score more green points. Try to find the underlying problems, the more the merrier, forget your ego, and think of all the improvements you now have the opportunity to make.

Read full post...

Saturday 7 November 2009

The Navigator

Pair programming is one of the key practices of XP, and so there is a lot to know and learn about it(which you can start by reading Pair Programming Illuminated by Laurie Williams, Robert Kessler). Let's focus on the navigator for now.
The navigator's role in my view is to look ahead: while the driver is to keep us on the road without any accidents, the navigator is to know where we're going and why, also what we're gonna do when we get there.
I figured that the best way I can accomplish this as a navigator is if I sit back and don't even watch what my driver is typing.

Don't get me wrong, it's not without merit when the navigator and driver don't talk much, just simply understand each other through bits of code and a few words, though this benefits the team more on the personal and social levels, helps to build mutual respect, team spirit and so on.
But the navigator's sort of turning away from the screen makes it imperative for him and the driver to start talking about the problems and solutions. A lot of good things can come out of saying something out loud. For instance you can realise you can't say it: it's too blurry to be said, and then chances are that your solution or your model of the problem is way too complicated. Other times when you try to explain your implementation out loud, you realise that it's just simply wrong.
In our praticular office layout there is another, quite relevant side effect of my turning somewhat away from the monitor: I get to see other parts of the room: the iteration board, the release board, the burn-down chart, our product manager, our tester, our build machine - all of which remind me to look at the problem at hand from many, different perspectives: all of which I might have forgotten about, had I watched my driver and his code unneccessarily closely...

So you can try it next time when you're the navigator and let me know how it turned out...

Read full post...