Agile? Scrum? What and Why?

Andy Ang
EverestEngineering
Published in
7 min readApr 12, 2023
Photo by Austin Distel on Unsplash

Have you ever questioned whether scrum/agile was any better and would it be better to go back to the days before scrum/agile where the developers just give a rough estimate, start developing and delivering? There are no daily stand-ups or sprints, no story points, no sprint planning, no scrum master that tells you what you need to do and what not to do; when everything was way more simple. Several years ago, I came across several similar questions in Quora and people from my team and other teams were debating about Agile and Scrum. Too many times, I find it weird that people are explaining how it should be done, what we have to follow and obey, how are we considered doing proper Scrum or doing it right, rather than actually focusing on what was the problem and why and how can we improve.

So, I would like to share a story, it’s back in the days where I had no idea what is Scrum or Agile; in my first 10 years of working experience, I’ve no experience with any software development methodologies. Things were simple, we were delivering incrementally, we communicate, we help each other and solve problems together, we adapt to changes and we find ways to improve our work; we don’t even use or knew about version control, and we find ways to continuously integrate our code manually and minimise conflicts.

In this story, I was invited by my training course-mate to work together with a team of developers which he brought together to develop a software for his client and we would be paid on a daily basis with meals provided. There’s no office, we just work in some rented house and everyone sit together on a big dining table, including the client.
There’re no structured process in place, our goal was simple, to work together and deliver the result as quickly as possible, and for the person paying us is also very simple, he just want to know what have we done, if there’re any issues, when can we complete for each module. Since we sat together on the same table and work together, we first tried to agree on a similar working hour and then we tried to update each other on our progress, like, what has been done and what we will be doing, so that we could complete each task as quickly as possible and help each other if needed. There’re no boards like Kanban board, but we have a list of features to be delivered and we just pick the next from the list when we have delivered our current feature. This all comes naturally, and in fact, we don’t just update once a day, instead, we communicate quite frequently like maybe someone is struggling or stuck in something, he would just speak up without hesitation or worry about being judged, and when someone completed his task, he just update that he has done and ask if anyone needed help or need him to take over any task, or he could pick the next one. As for the client, he would get updated immediately on the progress and at the same time, he would also get to see the progress and how it looks like and provide his feedback on it immediately. Before each task is considered done, we would also need to show the client to get his approval or any changes that he would like.
This all works so well and efficient.
I had no idea what is Scrum.

During my studies, I’ve learn about Waterfall methodology but never really practice it since I never really have any work experiences that applies it during my first 10 years. I’ve read something about Agile but had
no idea what it really meant, just know that they’re modern approaches.

When I first involved in a project team that were practicing Waterfall, I was actually excited because finally, I thought to myself, I’m working in a proper professional project environment, and also version control with branching strategies (GitFlow, which is another story for another day). The experience? In short, it was bad. This goes on for about 3 releases and we were introduced to Agile, where I learn about Scrum, Daily Standups, Review, Visibility, Immediate feedback, etc… and I could relate everything to what I have done previously even without knowing such things even existed. However, it was a long journey with a lot of challenges for the team to adopt the Agile mindset and applying Scrum, which is again, another story for another day.

Therefore, the question about going back to the days before scrum/agile, it doesn’t matter at all, because you DON’T need to know scrum or agile, what’s important is to be able to work efficiently and well as a team to deliver the product and that the customer is satisfied. After learning about those processes and reflecting on what I’ve experience, I could relate and understand why communication and sitting closely together as a team is important, why we need to work together to complete the task, why we need a quick feedback from the customers, why we needed visibility for the customers. In fact, just before the Covid-19 pandemic started, we have one project team that prefers to sit together in the meeting room and work for as long as they could book the room. We could see them communicate a lot and the team has strong bonding. This team later on joined my project as a second team and they’re still continuing practicing it; When the covid-19 pandemic started, and we’re working remotely from home, the same team created an all day meeting room for collaboration. I’ve also convinced my team to do the same, it took time to build the trust and bonding, but it brings people together and working more like a team.

So, why does people complain about Scrum/Agile does not work? In my honest opinion and based on my experience, I think most people are trying too hard or strict in following the rules and process defined, they do it because they NEED to, because the rules and process requires or stated it.
For example: We’re required to do daily standup, and for daily stand-up, we need to limit it to 15 minutes and only to update 3 things, what I do yesterday, what I will be doing today and are there any impediments. If people do it because they NEED to and following what they are required to do without understanding the purpose or why, then it will result in, this is a waste or time, why am I doing this? Why do I have to hear what others are doing? etc. This is an actual feedback as I’ve personally talk to my team members trying to understand what they think or feel.
Have you ever feel that sometimes the daily updates were not very helpful or meaningful? This happens because people don’t really understand the purpose and why. Similarly, we encourage updates before we off work, so that in the case of the person needs to go for emergency leave, anyone could understand the update and follow-up. If the update is not helpful or meaningful when someone needs to take over, then what is the point of the update?
Additionally, there’re also Scrum Masters or people that would follow strictly to the Scrum Guide, rules and adhere to it based on how they understand or interpret without understanding why it is there in the first place and how it could help each team. In my approach for my team, I would have a session with them during their onboarding to simply just talk about Agile, Scrum, why are we doing it, getting their feedback and opinion and discuss on it if there’s something we can improve or change. It’s more important that they know why, the purpose and working together as a team.

Just like everything else in life, if we just do something because of the rules and process stated it or because someone else is doing it, we will not be able to truly understand and benefit from it, instead, we will feel it’s tedious, waste of time, and just complain about it. Rules and process are just guidelines that we could apply to help us, we should try to understand why it is there and apply it accordingly, or inspect and adapt accordingly; what we want to achieve is the outcome, there’s no point if we follow all the rules and process “perfectly” but the outcome is a failure. The rules and process does not and will not ensure a successful outcome, it’s only meant to help to aid the process in achieving the outcome.

This is a very good example to explain about doing something without understanding why, it’s about “Cutting the end of the lamb roast” by Kevin Rae:

And this article about How Scrum is broken, because of the similar thing I’ve experienced when people starts turning useful principles into dogma and forcing people to follow it. And, the statement that Agile was an attitude, not a method or instruction that people could simply take classes to learn, read from books:

--

--