PD

Working Software and Done

Module
Databases
Skill
[Time/Project Management]
Minutes
60

Learning Objectives

  • Create a checklist that defines what’s needed for an increment to be releasable at the end of a Sprint

Introduction

Many software projects have failed because they only found out at the end of the project that what they delivered was not valuable to the customers.

We should constantly validate what we are developing so that if we have misunderstood expectations, we can resolve them earlier. And we can realise the value we deliver sooner rather than waiting for a risky “big bang” deployment.

Agile software development highlights that working software is more important than documentation and other non-software deliverables, and that you must measure the progress of a project by looking at how much software has been delivered and “done”.

The Scrum Guide (the leading interpretation of Agile) expects developers to agree on a Definition of Done, and to achieve “Done” for each item they work on in the backlog. This allows them to deliver an increment.

The product owner should focus on identifying and achieving “value”.

Exercises

Definition of Done (30 minutes)

Goal: Recognise the steps to achieve a “done” piece of software

Work in small groups. 

Make a list of acceptance criteria you would expect to be “done” for every software development user story (backlog item). You can refer to the Prep.

  • Did you identify all the achievements necessary to deliver working software to a customer?
  • Did you add anything which is not necessary?
  • Did you consider testing, automation, documentation, integration, coding style, acceptance, etc?

After you have a list, join another small group and share your ideas with them. What did you miss out?

Game: Anything but working software (30 minutes)

Goal: Identify incorrect options to delivering valuable working software

Work in small groups. Each person should take on one of the following roles at a time:

  • Lazy software developer
  • “Hacker” software developer
  • Bean-counter project manager
  • Salesperson
  • Proxy customer who is not the end user
  • Customer’s lawyer, who wants to verify the progress
  • Product Owner trying to maximise “value”.

You can have several people in the same role, and you can switch roles, so long as it’s clear what role you are playing at the time. Please caricature your role as a “Devil’s advocate”.

Go around your group, taking turns.

  • Propose something you could offer other than working software that is valuable or convenient for your role. For example, a video demo of the software. Or a specification of the product you are going to build.
  • Describe why this is more valuable than working software from your point of view.
  • The whole group should discuss if this is better or worse than delivering valuable working software. Sometimes the answer will be “yes”.