Testers being the fat kid up front

In the Certified ScrumMaster course, Jeff Sutherland said something that keeps running through my mind. The Agile principle is based on quick feedback cycles and quality of code (xP). A story is not finished until after a 'proxy customer' check. A 'mini acceptance' of the analist representing the customer, if you will. Later on, maybe after the sprint, the story is tested again in some form of integration environment.

To get that feedback in different phases early, he told us to treat the the proxy customers as fat boyscouts. If someone during a boyscout hiking trip can't keep up, it slows down the whole group. You should therefore walk beside them to motivate them. If they still can't follow, you take their backpack. If it's still going too fast, put them in front of the whole group. Make them determine the paste.

I think he's right. We should aid and guide our testers as much as we can. If during the daily scrum stand-up, you hear that someone is blocked from testing, this should deserve your immediate attention.

Proposal based

A month ago I followed the ScrumMaster (CSM) course of Jeff Sutherland and I'm an official ScrumMaster now. It was interesting to hear the guy that invented SCRUM - a former Phantom fighter jet pilot in Vietnam - expressing his vision on the IT industry. A couple of things stood out in the WAY he said them. He likes to formulate things differently. In the Passionate Programmer they talk about the transistion of being technology-centric to being solution-centric. You could tell that Jeff had an infinite respect for the developer (more than for management) but made an interesting statement: 'Developers are always whining and complaining about what's not right. In stead they should offer management clear choices'. For instance in stead of complaining 'we don't get the time to write tests' we as a community should say: 'Either we test and it will save (x-amount of) money in the long run or we don't and it will us cost money'. He's right. I've seen a lot of peers whining :)

Another thing a lot of developers don't do which I always try to, is the way we report issues. Before I communicate a problem to management or the customer, I try to have a list of possible solutions in my mind to propose to them. Not everyone does this, even if the answer to the report of a problem mostly is 'ok, what can we do about it?'.