The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Engineering Standards. The glossary has the following description:
Engineering standards: a shared set of development and technology standards that a Development Team applies to create releasable Increments of software.
This is one that might scare you off at first if you’re not technologically inclined. Thoughts of clean code conventions about redundant code, single responsibility principles and otherwise technical terminology might start popping up in Google when you start trying to understand Engineering standards. You might even consider this to be a Development Team endeavour, which is not worth your Scrum Master or Product Owner role’s time. Let’s analyse if that’s actually the case by deep diving into the description:
a shared set of development and technology standards
Does the word “shared” cause a deja-vu effect for you? It should as it reminds of the shared understanding we talked about in the Definition of Done. The Definition of Done is the de facto place to put these standards to create this shared understanding. It’d be good a check to see where your team is describing them right now as creating multiple entities that describe standards will only result in less transparency as we start creating multiple truths about the standard is. The whole idea behind creating a standard is that there is only one singular answer to what the standard is when asking anyone so we can maintain a default amount of quality. The conversation should therefore never be able to happen about doing anything with lower quality than the standards, saving you tons of time and money on discussion.
So what’s the difference between development and technology standards in this description and why is there a need to mention both? Let me try and give examples. Standards often have a philosophy behind them where we base our set of ‘rules’ on. An example of a development standard philosophy could be: “Create the product under the assumption that at a moment’s notice you will be dropped out of the project and someone else has to take over.” This would mean some rules would need to provide guidance to the way we work to ensure there is always adequate information and access for new people to be able to pick up work. This could mean all source code is available to all developers, a version control system is used, automated tests are implemented and kept up-to-date, documentation is up-to-date. As you can see development standards are setting expectations on the way the team created products. Generally development standards increase the amount of effort needed to create a product.
Technology standards establish boundaries on technology that is acceptable to use or not to be used, which generally speaking, decreases the effort needed because we’re limiting our product to use only certain technologies and not all of them. An example could be that we only create our product to work on the iOS and Android platform. Behind this could be a philosophy to enable at least 90% of mobile users to use our product (as Android and iOS as of writing of this article make up 98% of the market share (http://gs.statcounter.com/os-market-share/mobile/worldwide, sd)). This would make the team exempt from having to create a product for other platforms.
Both are needed as part of engineering standards to ensure there’s a shared understanding about what the Development needs to put effort in and what they don’t have to put effort in.
that a Development Team applies to create releasable Increments of software.
Near the start of this article I stated that a Product Owner and/or a Scrum Master might not want to be involved at all with engineering standards. You might still think that is the case after reading the first part describing the term. This second part of the description however should clarify that there is a definite need for both roles to also be involved, as they provide major influence to the engineering standards and in some cases it should even be indirectly affecting their accountability.
A Development Team might be applying the engineering standards. However, because they are applying them for the sake of creating releasable Increments there’s a Product Owner influence here. Because applying engineering standards has effect on the amount that a team can deliver as it increases effort needed there’s a tension field between Product Owner and Development Team. As described previously in my article about the Definition of Done it’s not just the Development Team that can provide input. The Product Owner has a cost conscious incentive to provide quality that the customer is actually willing to pay for. As an example: A decision between providing the product to only iOS users could cut your potential market to four times smaller, which would make it a marginal amount of effort easier for some products to be created and could even indirectly increase quality through focus on a single platform. On the other hand it might be a bad business decision to drop 75% of your potential userbase. So this will always be a conversation between both roles about consequences.
The Scrum Master actually had an even more important role here in my personal opinion. As the Scrum Master is accountable for Scrum Framework as a whole, there’s an accountability to get the Development Team enabled to create releasable Increments. Especially development standards will help enable these because they clarify what’s needed for an Increment to be considered releasable to everyone. The Scrum Master should be able to facilitate this discussion and ensure the Development Team becomes capable enough to manage their Definition of Done as part of their accountability. As Scrum Master you should be aware of development practices and be able to introduce and suggest these to a team that isn’t aware about them yet.
All roles benefit from engineering standards in Scrum. They should all be concerned on creating a shared understanding about these, with the Development Team having the accountability to manage them in their Definition of Done.
Did the concept of engineering standards get a bit more clear to you after reading through this article? What are engineering standards you have used or introduced to your teams? Let me know in the comments. Next time we’ll be discussing “Forecast (of functionality)”.