Professional Scrum teams build software that works

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!

TL;DR;

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.

Scrum teams build quality software that works

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.

Quality software is not about expectations!

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 2020 Scrum Guide

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:

1. Known errors or exceptions - if you find a bug then fix it. If it’s too big, then raise it with the Product Owner , and get it on the Product Backlog. To much time is spent managing rather than fixing bugs. Just fix them.
2. Manual Tests - if you have manual tests then you are already working towards software that does not work, or that you struggle to deliver. It is unsustainable to have any manual testing, so get automating.
3. Manual pipelines - in 2017 no-one should be building production code on their local computer, never mind shipping it to production from there. Even if all your build does is package up some files, and push them to an FTP location. Automate your build process… If you have a person that has to do something more than approving between code and production, then you should look to automate that process away. Humans make mistakes, and humans miss stuff. At least with an automated process if not continuous delivery, you get consistency, and you can increase the complexity over time for consistency. Make sure that you automate both your build and release pipelines.
4. No Source Control – Yes, I still meat organisation with no Source Control, or no control over it. I wrote Getting started with modern source control and DevOps for just that reason. If you don’t even have source control, whatever you are developing, then you need to get help and quick. The business risks that are exposed by not having it are just too big.
5. Lack of feature flags – It is a fundamental fallacy of the rejected backlog item, and your engineering team is going to have to figure out how to release at the end of every sprint (or every commit) regardless of the quality of the PBI’s being worked on. Hide features that are not completed behind feature flags so that they are not visible to end-users, but your code can still be shipped.

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.

What happens if Developers are not accountable for Quality?

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.

Use Scrum to Inspect and Adapt empirically

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.