Scrum and Technical Excellence
Give a little more, get a little more. Just because there are common practices not detailed in the Scrum Guide, doesn't mean they shouldn't be followed.
Join the DZone community and get the full member experience.Join For Free
One of the most common critiques about Scrum that I've heard from smart software engineers is that "Scrum does not care about technical practices. Scrum is for wimps." I've also heard managers down the hallway say that "Scrum is for wreckless developers because its main concern is only about fast delivery." I've heard many business analysts and solution architects tell me that "Scrum is too fragile because it does not specify the documentation the team needs to write."
People often say these things because they could not find in the Scrum Guide that says what technical practices the Scrum team need to do. But just because the Scrum Guide does not explicitly mention any technical practices you need to do, it doesn't mean you couldn't or shouldn't do any technical practices. In fact, professional Scrum teams will find that technical practices are required for the software to be sustained in the long run. This is what agility is all about, not just about being fast in the beginning but slow at the end because of technical debts.
Scrum is popular in software development but Scrum has also been used successfully outside of software development. The 2017 edition of the Scrum Guide wrote that Scrum has been successfully used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations, and it even been used to manage a church and to manage a family. One thing to highlight here is that Scrum is a general framework for product development. That is why any technical practices are left up to the practitioners to discover themselves.
Because of these misinterpretations, we at Scrum.org felt we owed the community a service by writing blog content that emphasizes how Scrum works with other technical practices such as DevOps, Emergent Architecture, even Extreme Programming (XP). We will even discuss how Scrum also works with more archaic practices, such as #MobProgramming and #NoEstimates practices. We thought rather than bashing each other to prove which is better, it is better to discuss how to complement these practices with Scrum because these practices are good for delivering quality software and Scrum does not get in the way for teams to use it. Here is some of what we'll be covering in the upcoming Professional Scrum Developer (PSD) Blog Series.
You can also leave a comment down below for any other practices you want us to cover that are not listed here. Hopefully, these efforts will encourage more software developers to use Scrum with technical practices.
Scrum and Technical Practices in General
So how do Scrum Teams do these technical practices in general? Scrum Teams may start with "Vanilla Scrum" that does not have good technical practices. It may work for several Sprints. Several Sprints later they may bump into quality issues. Professional teams should keep learning and improving the way they deliver software. Sprint Retrospectives are good opportunities for Scrum teams to level up their game. For example, from a retrospective, the team may decide that the highest priority to do in the next Sprint is "Behaviour-Driven Development."
To ensure continuous improvement, Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting.
— Scrum Guide
The Scrum Guide 2017 edition explicitly mentions that in the next Sprint Planning, the Sprint Backlog must contain at least one high-priority process improvement from the previous Retrospective meeting. If BDD is what the team decides to do as process improvement, initially this will become a Sprint Backlog for the next Sprint as the team may need time to learn and set up the development environment for BDD. The learning and setting up may occupy their capacity and may affect the number of Product Backlog items they can gauge.
Once the whole team has a BDD set up, in the following Sprint after this, behaviour tests will be in the Definition of Done. What that means is any selected Product Backlog Items are not "Done" unless the behavior tests for that PBIs are complete.
So the flow is that every Sprint the team will discuss process improvements for the next Sprint during retrospectives and the highest priority items out of this meeting will be a Sprint Backlog item for the next Sprint. But not all process improvements discovered during retrospectives becomes Sprint Backlog for the next Sprint. It is also possible that these technical practices go immediately to "Definition of Done" because there is no learning curve or any infrastructures that need to be set up.
As Scrum Teams mature, it is expected that their definitions of "Done" will expand to include more stringent criteria for higher quality.
— Scrum Guide
Professional Scrum Teams vs. Mechanical Scrum Teams
So what separates Professional Scrum Teams from reckless or mechanical Scrum Team? It is their Definition of Done. Professional Scrum Teams have high attention to quality and you can see that from the content of their Definition of Done that has exhaustive technical practices. Scrum does not say the technical practices you need to do but it does not mean you should not practice them. Scrum is a general product development framework and barely adequate to develop quality products. The framework is designed so that it doesn't get in your way to continuously discover what technical practices that are appropriate for your products to be valuable in the market. It takes imagination and creativity to discover the missing pieces for your process within the Scrum framework.
Stay tuned for more content around "Scrum And ..." from us. Don't forget to leave a comment for any other complementary practices that you want us to cover.
Published at DZone with permission of Joshua Partogi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.