Oil And Water, Or Are They?

Tester and developer couldn't be further apart, both of them fighting all the time without knowing any better. As one of our former tester put it, we have different goals: developers want the software to work, testers want it to break. For a long and regrettable time we shared this belief. But then we thought with agile it is over: bringing the tester closer to the team, both locationally and spiritually, would bring everyone to the same goal, i.e. to create quality software. It didn't work out as expected. Maybe the shared goal still wasn't shared enough, but I think we were missing a more important ingredient.
Fortunately we had learned our lesson, and with our new tester we tried harder. Once again Kent Beck helped us to find the missing pieces: Respect and Trust.

Though in his lecture he talks specifically about how trusty realtionship between developers and clients can help both parties to concentrate on creating values, I watched the inner workings of respect and trust in a tester-developer relationship.
In a timespan of a couple of 2-week iterations, our tester became a full-member of our team, thank to trust and respect. Quite rapidly we have arrived to the point where she trusts the developers enough to dare to ask them about the observed and expected behaviour of the system. She knows now she can be sure that a bug-candidate won't be dismissed due to programmers' arrogance or ego. She also knows she can freely ask all sorts of questions and won't be shushed or ignored or made fun of.
On the other hand we developers learned to respect her and her view on our software, and we learned not to discount whatever she has to say based solely on the fact that she didn't write the code, and in fact wouldn't even know how to.
Few minor, though important things at last. This productive relationship couldn't spring to life without our seriousness toward bugs: in an attempt to avoid the mini-waterfall effect we try to act quickly upon new bugs, this is not only practical from the technical point of view but also expresses respect, and thus strengthen trust. Unit and functional tests makes it possible that very few already working features break due to a fix of a new bug, again strengthening trust. Finally, our relatively fast build closes a very short feedback-loop of finding, fixing and retesting a bug creating a productive and positive atmosphere.

Read full post...

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...

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...