What Scrum are you using? Is it Agile Scrum or Flaccid Scrum?

Preface

Scrum has always been a mainstay in my software development career, but leveraging engineering practices from XP is something I consistently apply whenever I can. Throughout my career, mostly in offshore development, I have experienced a lot of different opinions and understandings of using the Scrum framework to manage complex software delivery. However, in most cases, I personally see that people usually put too much focus on the framework, the process, or the activities around it while in Agile thinking, adaptive planning, and a people-oriented mindset are the key factors of any method, and Scrum is no different. In this article, let's take a step back to see if we can find anything from its origin.

The problem

Scrum's users, especially the "boss" usually focus on the delivery part of the framework. They use it to deliver working software with good external software quality and usually don't put too much focus on internal software quality. In another world, great developers care about the internal software quality. Sometimes it's not actually a choice if they want to?keep releasing new features and changes quickly. Managing technical debts and adding useful engineering practices to enhance team productivity and culture are things that are always on their mind.

The ironic thing is that people tend to use Scrum as a tool/process to manage software development projects while 1 of the 4 Agile manifestos is: Individuals and interactions over processes and tools, and again I suppose you all know that?Scrum is part of the Agile approach.

Martin Fowler once describe the same problem in his FlaccidScrum bliki

What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll soon find your productivity dragged down because it's much harder to add new features than you'd like. You've taken on a crippling TechnicalDebt and your scrum has gone weak at the knees. (And if you've been in a real scrum, you'll know that's a Bad Thing.)

Why did this happen?

It could be the people and the semantic diffusion effect. In the Scrum Guide, there are no strict requirements to apply engineering practice when using Scrum in software development. Part of the Scrum guide said:?"Various processes, techniques, and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary." In a nutshell, you could put in whatever engineering practices you think should work. The most important thing is that it's required for developers to be conscientious. While taking project apply XP, for example, the 1st priority is always internal software quality. This method emphasises strong engineering practices like TDD, YAGNI, and collective code ownership, etc.

Another possible reason is that people did not actually "Read the Label Before Taking the Medicine". You can laugh?all you want, but a lot of my colleagues did not know that there was a Scrum Guide.

My suggestion

The key is to combine Scrum with another method that focuses on engineering practices (XP, Devops, or Lean software development) that is appropriate for your team and organisation. Remember to take it slow, just 1 step at a time, and note that the main factor to this being successful is always start with "INDIVIDUALS."

The successful roadmap

If you don't have an Agile coach or "guide" in your team, I recommend using this Agile Fluency Model to define your expected zones and benefits. I usually?started by applying Scrum, creating cross-functional teams with good engineers to address organisational and culture issues, focus on highlighting business priorities first. The next step would be to try to?create a collaborative and friendly environment. When you see the proficiencies coming from the team, then you could add XP engineering practices and Lean thinking to expand the team owning zone, deliver greater business value and reduce the time to production.

How about the opinion of Jeff Sutherland and Ken Schwaber (owners of Scrum)?

From The Scrum Papers by Jeff Sutherland

The key to entering a hyperproductive state was not just the Scrum organizational pattern. It was a combination of (1) the skill of the team, (2) the flexibility of a Smalltalk development environment, (3) the implementation of what are now know as XP engineering practices, and (4) the way we systematically stimulated production prototypes that rapidly evolved into a deliverable product.?

From Enterprise and Scrum, The (Developer Best Practices) by Ken Schwaber

Use Scrum engineering practices so that the team always knows the status of development. Test-first development ensures that the code reflects the design and that the code is tested as soon as possible. Source code management, continuous integration, and automated testing suites find errors as quickly as possible. Refactoring keeps the design simple, elegant, and easy to debug. Not writing arcane, heroic algorithms keeps code easy to understand. All of these practices combined mean that when you think you have a working system, it really is a working system that is sustainable and maintainable. This is known as an increment of potentially shippable (implementable) product functionality.

Kent and Jeff talked about Scrum common misconceptions in 2017 Scrum Guide Update online webinar (from minute 35 to the end)

For my dear Vietnamese colleagues: Scrum Guide - Vietnamese version

The Vietnamese version of Scrum Guide is available here

Shout-out to ?OàN NGUY?N MINH TU? for the translation.

Further reading