One of the most common critiques about Scrum that I've heard from smart software engineers are "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 told me that "Scrum is too fragile because it does not specify the documentation the team need to write". People often say these things because people could not find in Scrum Guide that says what technical practices the Scrum team need to do. But just because 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 sustain 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. Scrum Guide 2017 edition 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 even to manage a church and to manage a family. One thing to highlight here is, Scrum is general framework for product development that is why any technical practices is left up to the practitioners to discover themselves.
Moving Forward
Because of these misinterpretations, we at Scrum.org felt we owe the community a service by writing blog contents that emphasise how Scrum work with other technical practices such as DevOps, Emergent Architecture, even Extreme Programming (XP). Yep that's right, Extreme Programming. We will even discuss how Scrum works with other elephants in the room 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 compliment 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 are 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 but not listed here. Hopefully, these effort will encourage more software developers to use Scrum with technical practices.
Scrum and Technical Practices in General
So how does 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 Sprint later they may bump into quality issues. Professional teams should keep on learning and improve the way they deliver software. Sprint Retrospective is a good opportunity 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.
Scrum Guide 2017 edition explicitly mention 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 decide 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 setup 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 already has BDD setup, 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 Behaviour Tests for that PBIs are complete.
So the flow is, 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 needs to be setupped.
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 to 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 it. 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 down below for any other complimentary practices that you want us to cover.