At this time, everybody in tech (and outside) has heard about “agile” and “scrum.” We have all heard about the benefits and how a stuck and complicated project didn’t sink because the team changed to scrum. And we all want that for our projects. We want to be the heroes of the company.
But what really is scrum? What really is agile?
Many managers believe that agile and scrum are the same concept. They use them interchangeably, leading to confusing terminology, especially when someone on the team has previous knowledge. But let’s start.
What is agile?
Agile is not a methodology; it is a philosophy. It is a complete change of mindset, values, and culture that rules all the decisions, processes, and methodologies that a company or a team enforces. But also, we must not forget that agile was born in the departments of technology, specifically in software development, and its characteristics answer directly to problems that needed to be solved when it was created.
With time and good results, agile was adopted by many industries and adapted to other areas: design, marketing, finances, etc. But, even though Agile has proven its value many times, you still hear some people say that Agile doesn’t work. Not Agile doesn’t work for me, or my team is simply a bold statement: DOESN’T WORK.
Why does Agile seem to work for some teams and not others? The answer is simple but very hard to admit: we don’t understand what agile is.
Agile is not a methodology.
One of the first misconceptions is that agile is a methodology—something like a recipe that you follow to help you obtain the desired outcomes. But no, it is a philosophy based on some values that helped the projects improve their success rates.
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
You probably have heard these often; you memorize them, but what do they mean? One thing is certain: it doesn’t mean you must use Scrum as a matter of fact.
The second misconception is that agile is scrum. When people say, “We are going to change to agile methodology,” they often mean we will be using scrum. They assign someone the role of Product Owner and Scrum Master, create a daily event called “stand up,” and start using Jira. And that’s all.
Some Project Managers tend to sit back, expecting all the problems to magically vanish, developers to suddenly speed up, and revenue to skyrocket. But that’s not possible, and it is not realistic to expect that.
The third misconception is that everyone has a different idea about agile. Some managers believe it makes work faster, some developers think it requires many meetings, and some designers think they will have no power to make decisions.
Usually, the team forgets to communicate all of their questions, doubts, and expectations. They just start with the recipe they read online and expect everything to work. And sometimes, that’s better than nothing. In Learning Agile, Andrew Stellman and Jennifer Green say that even when agile is being used wrongly, it has better results than not using it at all. However, if we continue without attending to the real problem, we will eventually come back to old, known problems.
What really needs to be solved
Let’s come back with the agile values:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
These values were created to solve common problems you probably have experienced in your companies. The developers receive vague information about what they need to build or an overly extensive plan that doesn’t consider risks or changes. Project managers expect to receive extensive documentation about how the software works because that makes them feel safe. The team experienced a lot of stress because the deadline was near, and half of the software hadn’t been built.
And, after many sleepless nights, screams, crying, and fights between the team members, the deadline is here. The team shows the client what they have built (probably in two years), and the client is not impressed. In fact, the client said: that’s not what I wanted; my main competitor has had all those features since last year, and now that’s not innovative anymore.
And to solve all that stuff, the Agile Manifesto was created. If we value people, their interactions are better because we keep a team motivated and happy, with good communication and willingness to work on the project and consider it their own. Value working software, we will have a better MVP to deliver to clients and improve it in the next iterations. If we value customer collaboration, clients can see their software being built, and feeling safe is exactly what they want or need. And finally, if we respond to change, we can adapt to the changing everyday technology, the market, the clients of our clients, etc.
Conclusion
But we need to keep those values at the top of our decisions. We need to abandon old practices, such as punctuality and productivity bonuses, and use the metrics to simply fire people and micromanage them to the point they feel suffocated; we must respect people as the people they are and the professionals they are and we hire.
We must stop simulating scrum by doing a daily stand-up with a checklist, stop scolding people for not finishing the sprint at 100%, and promise unrealistic deadlines to the stakeholders. Don’t use agile and scrum as synonymous. Start questioning which agile frameworks work better with our team. We must also create a friendly and empowered environment, start being the leaders we want to have, and respect people.
