Jun 14, 2006

Scrum & Testing

There are a two schools of thought on scrum and how testing fits into the process.

There's one school that says because of the short timeframes in scrum, testing should be done by a separate team as a separate sprint. In other words, develop in one sprint and do some "nominal testing" and hand the product over to the test team for them to test through in their own sprint.

This is great - if you want to make your scrum process act like the waterfall process. In fact you could split your scrum teams into single discipline teams. Have one scrum for design, one for development, one for testing, one for writing documentation, etc. It could certainly give people the impression that you were running an agile process, whereas in reality it would just be waterfall in sheep's clothing.

At the end of each sprint teams are meant to deliver a potentially shippable version of the product. How can something be shippable if it hasn't been tested, let alone had the bugs fixed?

I obviously subscribe to the second school of thought where testing is an integral part of the development process and it is up to the team to ensure that all testing is done. For this reason I ensure that my teams have at least one BA, one developer and one tester. This does not imply that the tester is solely responsible for the testing; the team is. It does imply that a delivered piece of software has been designed, coded and tested.

It's tempting to follow the first school of thought and separate testing from coding, but this is a slippery slope to step on. It removes the responsibility for delivering working code from the developers (they can rely on the testers to test it later and get it back if it's wrong), code can be stuck in a loop between devs & testers for an unknown number of cycles, and you could potentially ship code that is untested and broken.

Keep testing and coding together - the team is responsible for delivering quality code first time, on time.

Jun 12, 2006

Update on presentation technique

I finally has the chance last week to try the new presentation style on an external audience. I gave a talk about authentication and authorisation in enterprise systems and how our software dealt with the issues.

The audience was a mix of both techies and business people - people who understand the need for security but to whom the implementation details can get a little, ah, mind numbingly dull. This kind of subject is a perfect candidate for a detailed, text heavy and dense style of presentation. Maybe 10-15 slides, each of which could almost be a document in and of itself. And in the past I probably would have gone this way because I didn't know any better.

Instead I sat down and had a good long think about how to use the light and clean presentation style and convey the message conversationally, using the powerpoint deck as a backup for the discussion, not the source of the discussion. In the end I came up with about 80 slides, and a mix of visuals as well as single-line text slides.

When I presented, it took about 30 minutes to run through, and I dealt with all the main questions in a way that both the business people and the techies understood. There was some open discussion at the end, but because the presentation covered most points it was more clarification of concepts and improving understanding than questioning the rationale or reasoning behind it.

The feedback after the session closed was very positive, and personally quite a relief since it was the first time I tried the new style on an external audience and I was a little unsure how it would go down. Trying something new on an internal audience when they all report to you is not exactly scary - after all if it goes wrong, it's only your staff you annoy. Doing it with an external audience is another matter - there ain't no safety net :-)