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!


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.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Immersive Professional Scrum Product Owner with Russell Miller over 8 weeks starting 11th October 2023
Virtual Immersive
11 Oct-13 Oct, 2023
09:00-13:00 EDT
8 weekly half-days
Immersive Applying Professional Scrum with Simon Bourk over 10 weeks from18th October 2023
Virtual Immersive
18 Oct-20 Oct, 2023
09:00-13:00 EDT
10 weekly half-days
Immersive Professional Agile Leadership Essentials with Joanna Płaskonka Ph.D. over 7 weeks from 20th October 2023
Virtual Immersive
20 Oct-1 Oct, 2023
09:00-13:00 BST
7 weekly half-days
Live Virtual Product Backlog Management Skills with Joanna on 2nd November 2023
Virtual Traditional
2 Nov, 2023
09:00-17:00 GMT
1 full-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood
🚀 Navigating the intricacies of the Sprint Goal in Scrum? 🎯 Discover the essence of crafting a goal that drives real value! 📈 Dive deep into the tactical steps, avoid common pitfalls, and ensure your team is on the right track. 🛤️ Let’s demystify the Sprint Goal together! 🤝 #Scrum …
Martin Hinshelwood
Software Development is not just a systematic process but a dynamic interplay of critical work that shapes the progress of your product. A Scrum team’s work can be classified into Sprint work and Refinement. To steer your Scrum Team towards success, it’s essential to understand, manage, and balance these two …
Daryn Basson Would you recommend the APS course to a newbie scrum team, and Why? Why the APS Course is a Must for Newbie Scrum Teams In this article, I’d like to share some thoughts on the Agile Practitioner Series (APS) course and its relevance to newbie Scrum teams. But first, …
Martin Hinshelwood
🚀 Navigating the nuances between the Definition of Done and Acceptance Criteria? 🤔 Dive into our latest article that explores the sanctity of a working, usable product without compromising value. 💡 Let’s ensure quality and value go hand in hand! 🤝


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.