Risks of "definition Done"

Somehow I see some risk in agile projects working with definitions of Done. Here some risks which slips my mind.


Risks:

- Usually only the functionality which meets the "definition Done" will be shown in the demo to the customer. Undone functionality is in the code available although it is not presented in the demo. This might lead to failures in production because based on acceptance of items Done a release might be shipped in production;
- If there are minimal skills in the teams and organization the "definition Done" might also be too small. This might lead that although the software meets the definition huge errors related to fit to process and usability will occur.
- Business has too less knowledge to define a "definition Done" and the team supports the definition phase based on their current knowledge. Definition is written mainly from technical perspective due to expert knowledge of the team of coding and too less knowledge of the business processes;
- "Definition Done" is used by project management to meet their project goals and deliberately narrowing the scope and content of the definition during the project. Instead of proofing that the system fits the business it is turned into proofing that the system fits the project.


I know that there will be more risks to mention, these were just some few which slipped my mind. I certainly not am saying that Agile is not working. I certainly not am claiming that "Definition Done" is creating false trust. I just wanted to show that we have to precise on defining Done instead of stepping too easily over this important tool.

SCRUM: definition "DONE" and the influence of a tester

What I hear and read about the impact of SCRUM for testing differs from success stories to fear when using SCRUM. When using SCRUM a tester might have to change his perception of testing. In these kinds of projects requirements are not that solid. Documentation is not that final. How are we able to test? How can we influence as tester a development process like this?

There are some ways we can walk, here some of my ideas:

I think the power lies in the concept that the team is responsible for the delivery of a potential shippable product. The first thing which comes up in my mind is: Make sure you are on that team. Become also on of the responsible persons. Don't be the outsider test coordinator who sit down and wait until everything is delivered.

When you are on the team you can discuss about one of the concepts of SCRUM: the definition "DONE". If it is important that documentation is available and also according certain standards you have to bring this up for discussion and see if it fits in the goals of the organization that time is spend for good documentation. The same you can do with requirements.

I'm sure that there are more opportunities to help the team, the organization and yourselves. I suggest start with these 2 basic steps first.

SCRUM, it hurts because it is interesting?

Over the last 2 days I attended a course for Certified ScrumMaster given by Bas Vodde and Jens Oestergaard.

In the past I read some about Agile and SCRUM. And were involved in an Agile project. I noticed that it is a different game you play as tester. Bas and Jens were able in 2 days to give you a feeling how different this game can be. Come up with examples which can be translated to your situation without the disturbance how you can improve your project into something what looks like SCRUM. They are able to stick to the main thought of SCRUM.

It was also fun to see how they are able to adapt to each other. And how they pulled the best out of the class.

I could give more information about the content of this course. Only then it would be just another source, since there are already enough books about this or weblogs. It is more fun and informative to attend a course like this yourselves.

If you want to attend this course yourself you might check out for dates and locations yourself on Scrum Courses

Some books you might take a look at are:

• Agile Software Development by Alistair Cockburn
• Agile & Iterative Development by Craig Larman
• Agile Software Development by Robert C. Martin
• Extreme Programming Explained by Kent Back
• Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle
• And somewere during this year (2008): Scaling Lean and Agile by Craig Larman and Bas Vodde

Though I learned and heard a lot and in the class and still processing that information. Some slogans of those lessons are:

• Inspect and Adapt
• It depends
• The team decides
• If it gives you a headache it is assumable not your problem
• Facilitating the team
• There is no direct need for a test manager or test coordinator

Especially the last 2 items hit me like a truck. I always thought I was facilitating my teams. I turned that I was politely with best intentions directive towards them. I also thought there is always a need for test managers and test coordinators. Also in SCRUM. They were able to convince me that in an actual SCRUM project there is no need for them. And that hurts.

Though I think we don't become redundant. As there are organizations who embrace SCRUM. There are also organizations were it is not possible (yet). Does this make the course a waist of time? I strongly believe it is NOT. There are practices in the framework which might help me in the future as test coordinator/consultant. And it helps me to share my knowledge about testing within a team. As it depends if you can use it or not. Every organization is unique and every organization needs their customized approaches.

Still I'm looking forward to work with a SCRUM-team.