Why people stopped practicing Scrum

Fri, Aug 8, 2014

Others Thoughts #agile

I started practicing Scrum methodology in year 2007, and in year 2009 I got my Certificate Scrum Master in Beijing when I was working in China. As time goes by I see more and more programmers and companies talking about Scrum and some companies even make it a mandatory skill when comes to hiring. But at the same time, I noticed that people around me stopped talking about Scrum, or slowly abandon this methodology. Isn’t this a better and more effective methodology compare to waterfall methodology? And when I initially practicing Scrum in my team it was a success, everyone knows what is going on, we helped each other when they face problems, and we definitely work as a team. What changed?

Here is what I think is going on.

Management expects Scrum will (automatically) solve their problems

The truth is, it doesn’t. Scrum is not a solution, it only helps you identify the problems. When you found the problems, you still have to solve it, problems won’t go away just like that. By practicing Scrum, you will still be seeing late delivery, or product qualities didn’t improve much compare to the time before Scrum came in. And the management will start asking:”Why are we still have these problems? I thought Scrum is a better methodology?”. Look, there can be many reasons behind all these problems – programmer over commit, lack of resources, depending on other teams for some external API etc. A methodology will not make all these problem go away.


Incompetent Scrum Master

There, I said it. Scrum master plays an important role in the team. Whenever a team member is having problems, scrum master should be the first one to identify it and try his best to help solving it. For example, one of the member has been working on the same task for quite some time. Before he even asking for help, scrum master should have realized that he might be facing problems and should have also talk to him to see if he needs anything. Some scrum master I met were merely passing message from stake holders to the team. This is really bad.


Unprofessional team members

I once worked in three totally different teams which practiced Scrum, and I must admit that I was having a really good time back then. We were close to each other, we hang out during our free times, we joke and the best of all, we got things done. What did we do right? We were on time for our daily standup meeting, we helped each other, we tried our best to commit to our tasks and we covered each other back. Professional team members are really important and crucial to the team. Unprofessional behaviors can be something like estimate a long duration for tasks without justifying why. This gives management a wrong impression that Scrum is actually a methodology that siding programmers, since programmers get to say how much time they need to finish the tasks.

Professionalism has nothing to do with experience.



Although we can selectively choose what are the things we want to practice in Scrum(although is not recommended by some people), but once we started it, we need to be persist. If we all agreed to have our standup meeting at 10:30am, we will do it everyday, until we all agree to change the time. If we all agreed to improve on one item we selected from the improvements list during retrospective, we will stick to it and examine the result in the next agreed date. Be persistent, or else people will think that all these practices are irrelevant since we will going to discontinue it without notice anytime from now.


The project nature

Sometimes, Scrum just not the right choice. Based on my experience, Scrum is good when you are working on a project that has a delivery date, and some requirements to start with. But for some projects, Scrum is just too slow. Imagine, you are running a website that serves millions of visitors per day, and one day you system went down. And the programmer said “No, we shouldn’t add new task to our sprint since it already started” or “Yes we can work on this but we will be removing some tasks from the task list”. This is just not right. Scrum is agile, but it might not be agile enough for some projects, especially website. We can’t really scrap the sprint every few days just because there are some extra but urgent things we need to work on. I’ve seen some teams reserve a certain number of hours for urgent cases like this, which I think it’s not really desirable. I used to work in a company with many ad hoc tasks. What we did that time is we have a whiteboard (Kanban) and daily standup meeting. We also allow members to choose the tasks they want from the whiteboard, and sales team will be less interfering with programmer’s work as I will redirect them to the whiteboard for the task updates. It worked well.