Introduction

Scrum is the most famous and widely used methodology for software product development. In 2001, Jeff Sutherland and Ken Schwaber, authors of the scrum framework, described the method in the book Agile Software Development with Scrum. After that, Schwaber with others founded the Scrum Alliance and set up the Certified Scrum accreditation series. Later, Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org which oversees the parallel Professional Scrum accreditation series. Since 2009, a public document called The Scrum Guide has been published and updated by Schwaber and Sutherland. It has been revisited 6 times, with the current version being November 2020.

So why Scrum is so popular? Because it is so productive and simple, you hear a lot from other people. But is it really? Working in Scrum for more than one and a half decades with various teams and in various companies, I constantly see frustration and irritation of using it. Let's see why.

Mythbreakers

Scrum is simple and productive

Well, if you need a certified Scrum Master to teach your teams how to deal with a guide which fits in 10 pages A4 format then that is not a good start. Mature teams do not require babysitters and people in the mixed team could learn from more experienced members and follow team conventions.

Estimates

It's tough, but it is an essential part of Scrum. You need to split your product backlog items into tasks and put estimations on them which should be in story points and by the way, could vary from story points used in another team. Estimations based on the team velocity. Yes, you need to keep track and re-evaluate your team velocity each Sprint. And if you can't come to conclusion with your team how long it takes to complete a user story - you like a true gamble man, are going to play in Scrum Poker until you get to some consensus. But before you even start with a Sprint you need to define Sprint Goals. It is not enough just to have well-defined User Stories and pick them up from the product backlog. Find a nice description for it!

Scrum is all about commitments

I often see how developers struggle to split user stories into detailed tasks and sub-tasks and put story points on them. After all, they need to commit to the sprint goals. In real life, however, during the work, there is more work discovered than was planned which leads to shortcuts in development, sprint refinement sessions, and other activities. Not to mention that backlog priority often changes and current work on which team spent hours of planning is not actual anymore.

Daily Scrums

Each day you have a 15-minutes meeting where you need to answer three main questions:

• What each person did yesterday
• What they are going to do today
• If there is any obstacle

Shouldn't you work in a team and know what each other works on, without having a dedicated meeting? This is collaboration. And if there are obstacles, you should not wait a whole day - solve them when they appear. Sure, in the last edition of the Scrum guide from November 2020 mandatory daily scrum questions were removed, but it took 10 years to introduce it.

Trust? Empowerment? Responsibility?

The emphasis in Scrum is heavily biased towards delivery predictability, every change should have a "business value". Developers within a Scrum teams rarely, if ever, motivated (or motivated but don't have enough capacity) to continuously improve a product and code base. As a side-effect, you see how technical debt exponentially increases, and in a while introducing any meaningful changes becomes a real pain and very expensive for an organization. Just check how many papers on managing technical debt out there. I'm not telling you that it is only because of using Scrum. You could make a mess with any tool or process, but the way how your development process works affect the outcome. What about fast feedback loop from your customer? The product owner is the only person with business knowledge and acts as a mediator between the team and the customer. How can a team come up with valid reasoning and help businesses without the essential domain knowledge? Also, Scrum does not give guidance on how to manage the product backlog.

How does it scale?

Just throw another Scrum Master on top of existing and create another ceremony - Scrum of Scrums where Scrum Masters report to Master of Scrum Masters. No, seriously, Scrum treats teams as bubbles within the organization. It does not recognize anything outside that - QA, Sales, Marketing, etc. Bigger Scrum frameworks like SAFe do not solve that problem, only make it worse and clumsy. As your organization grows, you need a flexible and reliable way of doing your business, not something which slows you down.

Scrum - good parts (almost)

In my opinion, the most important and valuable practice is retrospective. Even here, Scrum wraps inwards the team by trying to answer questions like:

• What worked well?
• What could be improved?
• What will we commit to in the next Sprint?

It is an inspection on how the last Sprint went with regards to individuals, interactions, processes, etc., but not regarding what is your customers think about it. This is crucial! You need feedback from your customers after each increment, learn from it, and re-visit your product backlog.

Outsourcing contract types

Outsourcing companies provide services for the entire cycle of software development. They work by one of the following schemes:

• Fixed Price
• Time & Material
• Dedicated Team

Fixed Price

The customer and company providing services agree on the exact sum of money that is estimated at the very beginning. This means that the total budget of the project development is known before development starts. It is the worst-case scenario. You just need the work done no matter what and there is not much feedback from a customer and room for improvements, so it is not agile by its nature. Usually, it falls into something known as Iterative Waterfall and could be an option for small projects.

Time & Material and Dedicated teams

With these contract types, you could fully apply Agile methods, because that fits well in the incremental nature of delivery, has room for improvements and a feedback loop from the customer. Although, you need to keep a track of hours spent and several resources utilized. In general, it depends on the trust and relationship between the parties. If your client requires more control, reporting, and upfront estimations, Scrum could be a good option here.

It's a Business

There are tons of courses, books, certifications, and trainings on Scrum. There is a SAFe (Scaled Agile Framework) - an attempt to scale out Scrum for many teams and big organizations, and even more certifications, courses, and trainings on that topic. Advertisement of Scrum is everywhere so it seems like it is a standard and the only right choice to plan and manage work. It pretends to be a trademark of Agile, but it became a way to earn money. There is not much place for a customer, feedback loop, and continuous improvements in Scrum Guide, it is mainly oriented towards a development team, deliveries, and commitments.

It's not only about Scrum

Let's back to the roots for a moment. In the same 2001, seventeen software developers including Sutherland and Schwaber met at a resort in Snowbird, Utah to discuss lightweight development methods and published the Manifesto for Agile Software Development. It states the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is to say, while both sides have value and the items on the right should be considered, the authors of the manifesto chose to tip the balance in favor of the items on the left.

The Manifesto for Agile Software Development is based on twelve principles.

Alternatives. How do others companies do it?

The above-mentioned manifesto is a high-level set of principles and advice to help organizations adapt to the market changes and find a way how to structure organizations and operate for business success. There is no definition of the framework here like it is in a Scrum. There are no fixed roles prescription like Product Owner or Scrum Master. There are no animals like pigs and chickens. There are no daily ceremonies and Poker games with guesstimation. And most importantly, you should not try to fit your organization into that box boundaries. The manifesto declares values and principles on which you build up your way to success.

Most successful companies do not use rigid frameworks but create their own processes based on the current needs of a business, organizational structure, and any other factors which help in achieving their goals. And most importantly, they change processes when they do not work anymore. This is the essence of agility. A few examples could be Spotify with its Spotify model and Netflix with its "Freedom and Responsibility." where they empower employees holding them responsible for decisions.

Most of the Big Tech and Public Tech companies as well as Venture-funded scaleups do not use any formal methodologies. The mantra is Plan->Build (iterate)->Ship. Teams decide on how they do it and what processes they will use to achieve the goals. For this model to work, the whole organization should have agility and culture which shares common values. Many organizations use DevOps culture fostering collaboration amongst all participants involved in the development and maintenance of software. It is not mutually exclusive with Agile and could be used together for better efficiency and results. DevOps or DevSecOps is all about improving and streamline processes, automation, stability, and consistency of software products.

Beyond Scrum

You could say: "Hey, but we are a small startup and just need to build up a process". Well, there are many tools in the Agile arsenal:

• There is Kanban for visualizing your work and flow. To understand it, you need from 30 to 60 minutes, no certifications and you are ready to go. It is much less overhead than Scrum.
• There is User Story Mapping to plan your work in collaboration with customers.
• There is Event Storming to model and visualize processes in the business domain which then will be ground for good user stories.
• You could incorporate DevOps practices and build your culture around building-in quality, automation, and listening to your product's end-users.

Summary

Building up your processes based on Agile principles and values will make a solid foundation for your organization, eliminating all waste and focusing on your customers and your product. It will help to build trust between the organization, development teams, and other departments. You can start with Kanban, User Story Mapping and change it to something which will work for many teams and/or products in a long term. By that time you will have a much better understanding of what works and what not in your own organization. Just don't try to fit your organization into the box of rigid frameworks.