Don't go for Scrum unless you have a strong "why"

I've often seen Product Owners or development teams implement Scrum ad hoc. Randomly, selectively, and, worst of all, for no specific reason.

Why do people do that? Because someone in the company has heard that Scrum helps deliver projects quicker. Someone may have known someone whose team has solved interpersonal problems with it. Because there is much talk about Scrum and when in Rome, do as Romanians do.

The hard truth is that if you implement Scrum without any specific reason or a goal, your team will become demotivated sooner or later. It's easy to implement some of its tools. Anyone can arrange a meeting every morning and call it Daily, cut the software development process into weekly sessions and call it a Sprint, or make a summary of such a sprint and call it a Sprint Review.

But what for? What is supposed to come from this? What does one want to achieve with these tools? What is their place in the context of the entire project?

If you want Scrum to work, you need to have a clear and specific reason concerning the project, the team, and the company. If you don’t have a real reason, your team will lose their sense of purpose, the product owner will burn out, and the Scrum implementation will fail.

That's why, before using any framework or technique, including agile methods, make sure that every level of business knows the answer to the "why Scrum" question.

Don’t let an indecisive Product Owner in

You cannot overestimate the role of the Product Owner in the project. PO's are links between the business vision and the team's daily work. They make critical decisions, prioritize tasks and take the most responsibility on their shoulders.

For this reason, a Product Owner must be up to date with the project’s course. They need to be open to dialogue and self-confident, also in moments of uncertainty. The Product Owner must be able to take over in the moments of a storm and admit a mistake when they make one.

If your Product Owner:

  • can never decide which task has a higher priority
  • doesn't understand key features of the app
  • is unprepared for team meetings
  • doesn't get involved in the project apart from meetings
  • doesn't enter into product discussions with the team
  • changes his mind often, and half of his tasks are ASAP's

Then your Scrum Lamp should flash red and howl alarmingly. :)

Your development team won't respect a Product Owner's attitude, as described above. Nobody will want to ask him for his opinion so that the team will push its solutions, ideas, and priorities.

Consequently, missing words between the Product Owner and the team will misalign the project’s business goal and the product. Projects, where the responsibility is blurred tend to blur by themselves.

Don't delegate imprecise tasks

If you tell someone to code something from scratch, you should specify your requirements. A task expressed in one sentence, without detailed information, will give the team space for their individual interpretation. Of course, you might do it purposely, as some projects are meant to exploit the imagination of developers. However, in my experience, much more often, it results from a lack of time or neglect of details.

A simple example: "create a login panel" is a task that one will understand only as two fields for entering a login and password. The other will automatically assign them to restore the password button, the privacy policy, and website regulations.

Whoever defines the requirements has a specific vision of what is on the reel. Assuming that others have the same image is wrong and leads, once again, to a mismatch between the business idea and development process.

Don't give your team undefined tasks. Only this way will you get what you expect, and the team will spend their time efficiently.

Don't open too many tickets at once

I can only guess where it comes from, but people love to take on too many tasks. Maybe it's a matter of ambition or willingness to prove yourself. Perhaps it gives a feeling of work in progress and a solid commitment to the project.

After all, we do so many things all at once! The "do or die" attitude is in the air!

Unfortunately, opening multiple tasks simultaneously, in my experience, often ends in a flop. At the end of the sprint, two are closed out of ten scheduled tasks, and eight remain open. Consequently, the team loses morale because they don't see the fruits of their work; they feel a lack of agency. They can even undermine the essence of Scrum, which can endanger the success of the entire project.

You'd be surprised how common that issue is in our industry. It's the bread and butter of many Scrum teams out there, and if you've ever worked in one, you're probably smiling right now. Who hasn't been there and hasn't done that?

Therefore, as it's often said in the world of agile project management methods, "stop starting, and start closing instead". This thought perfectly captures the essence of Scrum, and if you haven’t already, give it a shot within the upcoming sprint.

You’re welcome. :)

Don’t expect Scrum to work perfectly right off the bat

I want to end with a more general reflection on Scrum, which, however, directly impacts the team's daily work.

Implementing an agile system (or any other framework) is nothing more than repeating certain behaviors consistently. When you repeat these behaviors a certain number of times, you become self-aware and confident in your actions. Eventually, you squeeze the maximum benefits out of the given system, be it Scrum.

Implementing Scrum is a bit like learning to drive a car. In the beginning, you move carefully and slowly. You solve problems at a basic level, e.g., you learn how to start the vehicle so that the engine doesn't go out. Once you master the basics, you start reaching for more advanced maneuvers, such as parking, overtaking, or changing lanes in a traffic jam.

While learning how to drive, you probably have stalled your engine more than once, or you couldn't park the first time. And hey, even after ten years of having a license, it still happens, doesn't it? :)

It's the same with Scrum. You will make mistakes in your first Agile projects. However, don't give up if they occur, as this is the natural course. Instead, keep trying until you reach perfection and be aware that it never comes because, just like driving a car, Scrum is lifelong learning.

Bon voyage!