distributedlife

Last week I gave a short presentation about testing and agile. I couldn’t put the slides up because I followed Seth Godin’s rules on powerpoint slides. They have precious little content and don’t work without me telling you what is going on. The rules are worth reading, but like everything, not to be followed blindly. They can also help when you have a few hours to prepare a presentation.

Anyway, I had originally said that I would put the presentation content up on this blog. So here is part one. The Agile Philosophy, the bits I like. Business Involvement, and as much of it as you can get.

Having the end users or end user representatives involved as often as possible is a boon. It is so easy to misinterpret what has been said or written down. Even if the statement is “The system shall do x, y and z”.

Should it?

Only the business owner knows, by the time the specification has reached the developer it has been spoken by the owner, documented and manipulated by the analyst and statically tested by the tester. One can assume that the professionals that write and review the requirements have done their job. That is what they are paid for. More often than not they have, still doesn’t mean the requirements are correct.

Consider this. I read an article along time ago about one of Chomsky’s theories. In this theory he argued that the language we speak influences they way we think. Therefore the ability for the solution the end user believes what they want could be entirely driven by the language they speak. If the concept they want implemented can’t be articulated in English the user won’t know this and will explain what they think they want. Its up to the BA to analyse and produce a solution. Once again using the language they speak.

You can see that based on this theory it is now up to user experience to ensure you have accurate requirements. Every user is different and there are tens of thousands of languages. I simpler solution is to regularly involve the user and show them how the solution you are development works. There is no language involved in visual experience. There is no ambiguity. The code documents what the system does.

A common example regarding requirements and how they can be misinterpreted is the Chinese whispers game (it is called less offensive things in Wikipedia, but for berevity’s sake I’ll use the traditional European term). They should be drilling this into students at University. For those not familiar with the game, the players sit in a circle and the first player whispers in the ear of a person next time her, that person whispers to the person next to her and so on until it gets to the last person. That person is meant to say the original sentence out loud. Everyone realises its being mangled and giggles about it. Its a kids game.

Getting business involved frequently will short-circuit the game and can help keep the message on track.

note: to all those that read “The system shall do x, y and z” and didn’t see a problem. Tsk Tsk. There are three requirements there and as such should be separated into three separate statements.

2nd note: Chomsky’s theory may have been disproved. I’m not an expert on linguistic theory. The point remains valid however: try to define something using a restricted vocabulary.

3rd note: Simpsons fans will know the chinese whisper’s game as purple monkey dishwasher