Dave Thomas, one of the creators of the Agile Manifesto, has declared Agile as dead, stating that the values of being agile have been totally lost behind the implementation.

In recent years, a barrage of criticism has come down upon Agile, as well as on Scrum, one of its most popular implementations. “It encourages risky decisions.” “Lots of meetings and nothing to do.” “It creates technical debt that never ends.” These are just some of the opinions I’ve heard. There are numerous critical articles on the Internet about Agile and Scrum.

I have implemented Scrum four times in the past six years in different software development teams. The way I see it, there are usually two reasons for criticism of Agile/Scrum. Either someone has an incomplete understanding of the approaches, or they’re forming their opinion through the lens of an unsuccessful implementation attempt. I would like to share some insight that’s worth considering if you’re implementing Scrum.

Scrum is a solution, not a goal

So, you’ve decided to implement Scrum and be Agile. To start, you should answer some questions:

• what problems are there in the existing process structure?
• why will Agile help solve these problems?
• why have you chosen Scrum out of all of the Agile development methods?

Before implementation, you need to figure out which problems you’re solving and how Scrum will help. Implementation works best when you and your team acknowledge existing problems and want to fix them. That’s how you’ll have the greatest chance of success.

If you have no problems, or if your only problem is that you’re not using Scrum when everyone else is, then you should go read up on cargo cult programming. Don’t bother with Scrum and just work how you’ve always worked.

If you’re organizing your work from the ground up, trying Scrum may not be a bad idea, even if you don’t have any problems yet. But by no means does that imply that Scrum is what you need.

I use Scrum when a product is still seeking an audience and business model, meaning we have to test product hypotheses quickly. Scrum has also worked well for me when dealing with teams that lacked a project management system as such. Scrum ceremonies are relatively simple. They can be implemented quickly, and they’re a great substitute for a chaotic project management process.

Team motivation over processes

Let’s list the problems that usually prompt teams to consider switching to flexible development methods.

• long development cycles and subsequent stakeholder dissatisfaction;
• increased functionality not adding value for users or business;
• lack of systemic processes as such.

Before deciding to switch to Agile, you need to understand the reasons why these problems have arisen. I’ve come to the conclusion that these problems often have nothing to do with project management; they’re related to the team’s motivation.

I’ve met teams that release excellent products without using any of the ceremonies or artifacts from any project management methods. On the other hand, I often meet teams that do all the ceremonies meticulously but still run into the problems listed above.

The difference between these teams usually comes down to the fact that a team must love their product and want to release it. Without motivation, even the best experts using the best methods will miss the mark.

Implement what you understand

So, you’ve decided to start using Scrum. Your first thought may be to read about all the artifacts and ceremonies and then implement them all to a T. But you have to be careful.

It can be pretty difficult to change people’s habits, and that’s what changing the development process is — changing habits. You need to implement ceremonies gradually, one step at a time.

The person initiating the changes must understand the benefits of each of the ceremonies and artifacts implemented, and they must be willing to communicate these benefits to everyone on the team. Every ceremony will be met with distrust or even open criticism, and its usefulness will need to be proven.

If you don’t fully understand how an artifact or ceremony will be helpful, you won’t be able to use it correctly. Therefore, step-by-step implementation will also be useful for the person doing the implementing. You will gain an understanding of each component, making sense of why you need it and what its benefit is for your organization.

You may think that Scrum needs to be used either fully or not at all, and the Scrum Guide states that this is true: “Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum”.

From my point of view, Scrum can be useful even it’s partially implemented, and at the same time it can also end up not being useful even if implemented perfectly. What makes the difference is the common sense of the person implementing, as well as their understanding of what’s being implemented and why.

Use the right software

Using Scrum in a development team usually goes hand-in-hand with using compatible software. The choice is usually made to use intricate and complex software, such as Jira or Tar-getProcess. Sometimes this does more harm than good.

To be sure, you need a place to create tasks, manage product and sprint backlog, track task statuses, and so on. Almost any software will let you do those things. But using new software is stressful at first, even for IT professionals. You have to roll out the software, figure out the new interface and functionalities, set up access, and much more. And the more complicated the software, the more difficult this process is.

When implementing new project management methods and new software at the same time, we’re asking teams not only to get rid of old habits in favor of new ones, but also to figure out how to use new software they don’t completely understand yet. This creates additional stress and decreases your chances of a successful implementation.

It’s best to begin implementing Scrum using the software your team is already working with. A good alternative could be using simple software, like Trello. In theory, there’s nothing stopping you from trying to start using Scrum with colorful stickers — that works, too.

Changing processes is painful

When I implemented Scrum for the first time, I was positive that the team would be excited about it. “Everything is organized in such a cool way,” I thought, and made another serious mistake.

Anyone who wants to change an established convention should take into account that they will have to fight against other people’s habits, their usual course of action. And that fight is never a simple one. If you’ve ever tried to convince a smoker to stop smoking, you’ll understand what I’m talking about. Keep in mind that the positive effects of quitting smoking are obvious. The positive effects of daily scrum? Not so much.

In certain cases, members of the team may consciously or unconsciously sabotage the implementation process. This is usually just a strong reaction to significant changes to the usual way of doing things, but sometimes it means that your actions are the wrong ones to be taking. You need to think about what happened and possibly make changes to the process.

Let’s say a team of developers is routinely doing poorly in sprints. You try planning fewer tasks for the sprint, but that doesn’t help. What could be wrong? It’s easy to blame the team and get complacent, but that’s the wrong approach. The situation needs to be investigated. You need to understand the state tasks are stuck in, which tasks were underestimated, and how assessments were given. It’s possible that the problem is in the length of the sprint, the size of the team, or insufficient task specification and decomposition in the backlog.

Scrum is more than just artifacts and ceremonies

Scrum is an Agile framework, so when implementing artifacts and ceremonies you have to remember why all of it started. The goal of implementing Agile and Scrum is to make the development process more flexible and make the product sought after by the market or customers. If you didn’t reach your goals after making all of your changes, you shouldn’t assume that everything was done properly, even if the Scrum guideline was followed to a T.

So, try to keep in mind Agile manifesto:

• 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, while there is value in the items on the right, we value the items on the left more.