Is A Demo A SAFe Area?
I have been asked many times whether it is “ok” to include work that is not complete in a demonstration/sprint review (I’ll use the term demo from now on). The simple answer is that is a bad idea 95% percent of the time. Demos are agile’s mechanism to share what the team completed during the current sprint or iteration. The use of ‘complete’ is purposeful. It means the work meets the organization’s technical standards and is potentially deployable in production. Complete mean stories that meet the definition of done – before the demo, not the next day. Teams define done before they begin work. Done typically includes steps such as coding, testing, documenting and reviewing. Unless the piece of work meets the definition of done (or a deviation agreed upon) then the work is not done. Demonstrating in progress material is a bad idea in most situations for many reasons. Mixing done and not items in a demo:
- Obscures problems in the flow of work. One of the core tenants that powers agile is the idea of inspecting and adapting (continuous process improvement with using the dreaded process word). Work items committed to by the team and not completed are not completed for a reason. Finding and fixing the root cause of the problem improves the capability of the team. There’s a maxim that you should always be willing to hear information about your finances and your health. I would like to paraphrase that maxim: you should always be willing to hear information about the health of your processes. Anything that obscure problems is information avoidance.
- Makes it easy to step away from the definition of done. User stories have lots of safeguards to ensure that what is delivered can be consumed by the organization without adding to the technical debt. Acceptance criteria define functionally what the piece of work needs to deliver, while the definition of done defines the technical and process standards of the organization. Product owners and other stakeholders, being human, will see the work and immediately forget any warning that it is not done and demand to use the functionality. This increase the potential for production defects. NO ONE WILL REMEMBER THAT YOU SAID IT WAS NOT READY FOR PRIMETIME. In the same vein, increased pressure to install nearly done work increases systemic technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. Teams accrue technical debt intentionally or unintentionally; either way maintenance cost and lower productivity is the outcome.
- Promotes starting work rather than finishing. Teams that are allowed to demo work they have started often feel incented to start lots of work and the cost of actually finishing work. I find this problem the most insidious of all. Being busy does not equate to being productive.
It is easy to assume that “people” are perfectly rational economic entities. If we state that some stories are not done, they will remember. The will also remember that putting work in before it is ready could cause problems and irritate their customers. The problem is that they don’t remember. People are not always rational actors, therefore when I am asked whether it’s ok to show work that is incomplete, the answer is usually no. At root, the demo provides the team with a platform to get feedback on functionality. Demos build confidence and customer satisfaction if they are done well and are best when they are unambiguous. While if you demonstrate incomplete work no one will send a lightning bolt down to smite you, you may well hate yourself in the morning.
Next – The other 5% of the time or when the answer is yes.