I am always surprised at the number of teams that release undone work to production. I understand that one may need a few sprints, or many if you inherited something nasty, to pay back that debt, but if it’s more then you are not a Professional Scrum Team . The sheer amount of software that I have that is buggy, slow, or just not finished makes me think that there are few professional Scrum Teams out there!
Every organisation has the right to hold their Developers accountable for the quality, but never quantity, of the software that they build. Every Developer should pursue engineering excellence through DevOps practices, automation, and rigorous attention to detail for every release. Working software builds trust with your users and promotes your brand, faulty software encourages distrust and hurts your reputation. Defective software and technical debt are the causes of the current death grip that organisations have to traditional Taylorism based management techniques.
Ultimately if your organisation will not let you build software any way you please its because of the shit that you have been trying to get away with delivering in the past. You have work to do to build trust again.
Treat your team to a Professional Scrum Developer class to get them up to speed.
Working software is software that is free from fault or defect. Developers are primarily accountable for the quality and delivering a usable increment. While they are also responsible for value delivery, the accountability for that lies with the Product Owner . That means that if there is a choice between delivering value that lacks quality or providing less value that is of higher quality, Developers should always choose quality.
Since “rules are for the guidance of wise people, and the obedience of fools” I am going to caveat that statement for those that like to latch onto absolutes. Since any software that you build is an organisational asset, and all assets are attributed to the value of your company then that software must exist on a balance sheet somewhere. If you as the Developers decide to cut quality to make a delivery do you immediately speak to the CFO so that they can accurately reflect that loss of value on the companies balance sheet? Because if you don’t, then knowing or not there is a danger that your organisation is committing fraud by inaccurately reflecting the value of your software! Ultimately the decision to cut quality should only be taken with the full consent and understanding of your executive leadership team.
The decision to cut quality is not one that the Developers , the Product Owner , or IT management are able to take, it is reserved for executive leadership alone.
Working software is software that is free from fault or defect, but it does not necessarily meet the Product Owner’s or stakeholders expectations.
It is just not possible for everyone’s expectations to be understood let alone met, and thus it is unrealistic to expect the Developers to deliver on them. At the end of every Sprint we have a Sprint Review where we invite stakeholders, and the Scrum Team , to pause and reflect on the Product Backlog based on that which was delivered. There you can explore the difference between expectation and delivery and then update the Product Backlog to reflect that difference. The Scrum Team should continuously be investigating the difference between what they delivered and stakeholders expectations so that they can close that gap as much as possible, so while they are responsible for meeting expectations, they can’t be held accountable.
The Development Team consists of professional Developers that are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work.
The Scrum Guide very deliberately does not tell you how to build working software. It only states that its delivery is the accountability and accountability, and responsibility of the Developers If you don’t have working software, then you are not yet doing Scrum, although you might be working towards it.
So, to define working software we have to look at what working software is not:
The other name for the things that make it difficult to get to working software; Technical Debt. All of the things listed above are forms of Technical Debt, but the biggest form is just poor quality code. Code that is not tested or would not meet even a cursory code review by another software engineer.
If the Developers are not held accountable for quality why do you believe that you have it? Quality is one of those hidden measures in software that can be there or not, and you would not know unless you were using that product in anger. If you put pressure to deliver on a Developers , they will consistently and increasingly cut quality to meet whatever ridiculous deadline you give them.
Every organisation needs to focus on delivering quality working software that is of use to its customers. The entire Scrum Team is accountable and then works together over many iterations, experimenting and continuously improving, to deliver the best possible outcome in the circumstances. So instead of being an amateur team, be a team of Professionals that deliver working software because that is what your organisation and your customers deserve. If you are having a hard time delivering then discuss your options anytime, but especially at your Sprint Retrospective, and figure out what actionable improvement you can make that will help you pay back some of your technical debt and move forward. Once such step could be making sure that your Developers at least understand this with a Professional Scrum Developer course.
Use empiricism to Inspect and Adapt with Scrum.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
CR2