Ken Schwaber und Jeff Sutherland called the result of a Sprint: „Potential Shippable Code.“ The idea was to present to customer and everybody else a piece of the product that worked. In their trainings both of them showed that a team needs to discuss with their Product Owner and with the management the „Level of Done!“

The phrase: „Level of Done!“, was introduced much later in the history of Scrum, although the basic idea was already stated much earlier. A Scrum-Team will need around 9 month to reach the status in which they can produce code that is shippable at the moment of the review meeting. 

In my daily practice I see both: Software development teams that can do this work correctly from day one on, and others who will need to go a long long way. Nothing is wrong with needing some time to do it. Only the believe, that  ”Scrum will do this for you” is wrong. Scrum will help you to identify, that you need to work on this. Scrum will make clear that your development practices needs to get improved. 

The sad thing is, that Scrum often exposes that teams do not have the necessary skills to do deliver “potential shippable code”.

In all of my first Scrum development teams this was the case. We needed weeks and month to establish the right know-how.  We needed to hire the right people and we needed to invest in training. In all of my current coaching engagement it is also the problem. Sometimes it gets only identified after some month. In the first 6 to 8 Sprints teams work very hard on feature delivery and then we suddenly do not improve the speed anymore. The reason is often, that we now hit the wall: The engineering skills are now the barrier. Too often in this moment the team members start to become defensive. Suddenly Scrum is the evil. Instead of using Scrum as a helper, a diagnostic tool, people feel threatened by the truth. They need to improve. 

A customer said, one of his people told him when they will stop to do the retrospectives. They would have now improved so much. Why not being satisfied with the results? 

Humans can not be satisfied with the results they gained. Never. Nobody says you can not make a pause. Sometimes you need time to integrate new knowledge, sometimes you need a pause to see new ways. But a stop, because we are already so good. That is not what we want. 

So you might be able to deliver “potential shippable code”, now start thinking about doing the deployment immediately after the review. You can do this? Start thinking about plattform architectures. You do this? How can you free your developers so that they can release whenever they like, and be completely DONE with what they wanted?

There is always room for improvement.