Done vs. done done

Last post 03:57 am June 24, 2014
by Ludwig Harsch
6 replies
07:03 am June 22, 2014

Hi all,

Within my current company I'm facing with the following problem.

Our development is using scrum to deliver small stories. This is going well and we've build up a steady pace within our 2 week sprint.

Although the development team is doing a good job in delivering stories every 2 weeks, the story is not 'done done'. After the stories are 'done', other external process (which are depending on the stories, like some hardware modification etc.) gets started.
So, the team is able to produce stories within 2 weeks, but for it to be 'done done' we're usually talking about several months.

What to do? (by the way including these external processes is not an option)

02:58 pm June 22, 2014

Incremental releases can be seen as part of a value chain, where value is added by different stakeholders at different points. One team's understanding of "done" may not match that of consumers further down the chain. That doesn't necessarily mean that there is a problem and that the team's DoD is inadequate. The increment might well be fit for purpose as far as a PO is concerned. He or she might simply plan to add further value to the product in order to sell it on, this perhaps being their business model.

The key consideration is that of technical debt. If you find that you have to perform rework as a result of the "external processes" you mention, then you do indeed have a problem, and the DoD is not fit for purpose.

01:41 am June 23, 2014

Hi Ian,

This is the case. Sometimes problems gets discovered during that phase which results in rework.

Now that external (hardware) process that comes after software development is a very complex process which is almost unplannable. Only when we're in that second phase, we find out what we're missing.

03:20 am June 23, 2014

OK. The first thing to do is to deduce (or estimate) the cost of this rework. If you have a hard figure of what this is costing the company, you are more likely to get executive sponsorship for a solution.

The figure should include the time cost of teams performing the rework, the cost of any additional resources consumed, and the cost of delay incurred by having to revise the product before it can reach the market. Other things to factor in might include a wider missed opportunity cost (while a team is tied up doing rework, other opportunities may pass the company by) and quality cost or cost to reputation (since not all of the technical debt may be discovered during rework). These are harder to estimate.

I recommend getting a figure like that first. Once you have it, you should effectively have a budget for working out a solution.

06:07 pm June 23, 2014

My team faces the same issue. Although for us, testing is the piece that doesn't quite fit within the two-week sprint so stories and tasks that are implemented in sprint 1, aren't testing by QA until sprint 2.

07:27 pm June 23, 2014

On similar lines what Ian expressed - I wanted to put my views. Please feel free to correct me

Quite often vendors or external parties don't adopt methodologies which organisations practice .

A working shippable product increment (definition of done) has to be determined within spring planning.
So a risk has to be logged with PO if by any means we think definition of done will have a external dependencies.

Also, Vendors or external parties should be made clear (with support from management) that sprint goal is important and they should show up instead of delaying the results.

I think the best way would be to include this support role into development team so that they will have accountability / ownership for the sprint goal.

If current sprint testing and QA is done in next sprint , it's not scrum but we can name it as ScrumBut. ScrumBut can never have desired results as Scrum.

03:57 am June 24, 2014

If I understand correctly, you are trying to scale Scrum. What you call "done done" should just be called "done". The definition of done for each team should include integration with all other teams. This means it might be impossible to have 2 week sprints, because it is not enough to deliver the stories. If hardware is included, it can even be very difficult to have 4 week sprints. If your company is fine with several months of development, and you do not need to be more agile, that's OK. You can consider the software of your team as the product which is delivered to the other teams who are stakeholders, and you can do isolated Scrum.
However if the market and competitors force you to be faster than that, you should think about how to get to 4 week sprints with an integrated increment at the end. There are approaches for this like rapid prototyping.