Scrum Is a Great Hammer, but Not Every Process Is a Nail

But first, a little coming out of the closet is in order. I am a consultant and evangelist in the field of Agile methodologies (amongst other things; “other things” being Software architectures). I do Scrum consultancy for a living and I strongly believe that it can bring fast results in many processes of software development. I actually wrote a book on Scrum.

Now that we have my little secret out in the open, let me tell you why Scrum is not for you. Yep, I am looking at you, the new guy in the corner.

What Is Scrum?

“Scrum is a framework for and sustaining complex products” says the Scrum guide, a 17-pager published and re-published by Ken and Jeff, the authors of Scrum for software development.

Although this sentence serves me well for the purpose of proving my “nail and hammer” point, let’s go back a bit further.

Scrum actually goes back a bit further than 1995, when Ken and Jeff first talked about it in 1995. An article in Harvard business review published in 1986 is the actual birthplace of Scrum and it was again the work of two gentlemen: Hirotaka Takeuchi and Ikujiro Nonaka. It was titled: The New New Product Development Game.

Notice two things in common in both these sentences? I knew you would! They actually both use the words product and development.

Scrum is a framework for developing products. It is highly adaptive to your process and helps you further adapt your process towards continuous improvement. It responds well to change, depending on how you define well. It promotes motivation, emerges talent on all levels and focuses the team towards effectiveness. It pretty much rocks. But don’t trust me, check out this 2015 research by the Standish group on the picture below. Based on a surveyed group of 10.000 projects, Agile projects have an up to 7x better chance of succeeding. Yes, I can hear you whispering in the corner— “that is based on all of the Agile frameworks, not just Scrum”. Sure! Though, according to the latest StateOfAgile, Scrum is the de facto Agile framework — used by around 2/3 of Agile projects. So, yes — it rocks!

Scrum Is Not for You!

Scrum is a very specific framework. It is based on very well studied theories that go back to the early days of the product industry, mostly the automotive industry. It is very opinionated about how you organize your work. If you do not like opinionated, it’s tough luck. But it is not just a matter of preference. Sometimes “The One Scrum Way” will just not work. Let’s go to these cases. Now is the time to pay attention to the new guy.

1. Maintaining Software That Is Working in Production

Scrum is proud to be responding to change. The backlog is not a fixed basket. We define it and re-define it at will. We put stuff in and stuff out within Scrum. We take stuff out of it every 1–4 weeks and work on it. Wait! What did you just say, every 1–4 weeks? What if a bug happens tonight, I need to wait for 1–4 weeks for you guys to start working on it?

Yep. Scrum organizes work in iterations which are time-boxed. These iterations promote focus and are one of the main reasons for Scrum being successful. But Scrum does not do a good job of responding to change within these time-boxes. Sure, we can re-plan the Sprint at will, but this will start eroding Scrum if done too often. And if we are maintaining a system in production, it is going to be done hourly.

There was a dead giveaway from the start here: no mention of the word “development”. Check for the clues new guy.

2. Unstable Teams

When clients tell me that they can’t focus a team for a single product, I rarely buy that. I try to tell them that it is just a matter of deciding to “stop starting and start finishing”. I perform a lot of my Aikido on them to persuade them to create dedicated teams. But, sometimes this can not happen for a number of reasons. Perhaps the organization is too small and works on many products in parallel.

What happens to Scrum when a team is not dedicated? Well, pretty much nothing works as planned. The ceremonies can’t take place and they are the core engine for adaptation and empirical process control. The focus is not there. Transparency is hard to maintain. Overburden goes bananas.

Not working. If you are in that 1% of organizations that really (I still don’t buy it) can’t focus the team, use something else.

3. You Are Not Willing to Adapt Your Process

Scrum is not a process. It is a framework which promotes empirical process control. Your process is already there, be it something complicated or a simple “Develop, Test, Deploy” workflow. When you start using the Scrum framework, the main idea is that you improve your process using Scrum’s tools.

So, if you are going to stick with the original process and not adapt, then why use a framework for empirical process control? You will invest time and energy and gain little results.

I Get It Now, but What Is for Me?

Agile is an umbrella term for many different methods. You can spend a lot of time studying them, but I’ll make it easy for you. They are either time-boxed of flowable. This makes a world of difference for issue number #1 in the previous chapter. Flowable frameworks, such as Kanban respond to change at any time. They do not have iterations and can adapt to new work constantly. They play well with Scrum and can be combined in many ways, Google it (out of scope for this blog, sorry). So, maintenance guy, Kanban is much better for you.

About issue #2, you could also try with Kanban. It will give you a framework for empirical process control and not force you to reconsider your team organization. As I said, I still rarely buy this story of “not being able to focus teams”, but for the 1% — go with Kanban.

If you are stuck at issue #3, well — sorry for you. Adapting is a key for succeeding in the long term and I wish you would reconsider. Otherwise, nothing will help you.