Why should Agile NOT be destroyed

Bar, a friend of mine sent me an article with the following title: "Erik Meijer: AGILE must be destroyed, once and for all". Without reading it I instantly knew that it is about someone who obviously doesn’t understand Agile at all and probably hasn't really ever tried. It is just one of those articles with "great" titles that doesn’t have real content in it. Nevertheless since I truly adore the Agile methodology I've decided to comment.

Anyone who have heard me speak about Agile knows what I don't believe that Agile has invented something new for the software industry. Agile, Scrum and all the rituals (sprint planning, retro etc.) are just labels that we, the developers, have added to several best practices that are just the right things to do and every project should use them.

Agile and Scrum in particular makes your whole team responsible for the project and not just the managers, it brings the team members closer to the client and to his world while truly understanding the purpose of the project.

It makes you measure your work and progress allowing you always to know the project's status and if you're not going to make it to the dead line.

It makes the development process transparent for the team, for the managers and for the clients allowing you to code and not be stuck in an endless status meetings lifecycle.

It makes the whole team responsible for the whole project and be familiar with the whole project's code base.

It allows the team leader to be part of the team and code (!!!) since the whole team is self-managed using a clear and defined process of work (sprint planning - daily meetings – review - retro). It makes the TTM (time to market) shorter by developing the most important user story that the client has defined.

The most important part it forces the team to constantly improve while sharing their insights from the sprint in the Retro. 

You see, all those things are good for the project, for the team, for the client and are just right! This is how it should be! It doesn’t matter if you call a short period of time where you design, code, test and deliver a feature "a sprint". Agile has gathered all those best practices in order that your project will succeed!

So what does this Erik guy actually say?

Stand-up meetings in Scrum are an annoying interruption at best, or at worst one of the mechanisms of “subtle control”, where managers drive a team while giving the illusion of shared leadership. “We should end Scrum and Agile,” he says. “We are developers. We write code.

What will happen if we'll "just write code"? We will not know what the other team members are doing, we will not share our problems with the team and more important we will not commit to the team or to ourselves on a daily basis. The daily standup meeting (DSM) is a commitment of every team member to the rest of the team and to himself. Furthermore the DSM is the place to check the "Burndown" chart and verify that our planning matches the reality and truly be notified that we are not going to reach our goals.

 Let's examine more Scrum aspects:

The Sprint planning

People like Erik will say that it is a waste of time, tell the developer what to do and he will do it. Sounds good right? The developer will finish the feature and that’s it. But what about the other team members who didn’t see a single line of code from this feature? How do they supposed to fix the bugs or improve something there? Do you count only on a single developer? What happens when he leaves? And what about the estimations? How do you estimate the time developing a feature will take? I'll tell you – you make an assumption that is probably wrong. It is impossible to estimate how much time precisely a huge feature will take. So if you know in advance that you'll be wrong and you keep on doing it you are simply lying to your client. By the way an assumption means that you make an Ass of yoU and Me (Asume).

The sprint planning makes all your team members truly understand the feature and the task and it allows you to realize in advance that someone didn’t understand the task and so to avoid failure. All the team members have the chance to tell their estimation and to explain themselves. This way all the developers are on the right page. If someone doesn’t understand the task you can immediately see that since his estimation is be different from the other team members. You will invest all the time that is necessary in order that this team member will understand the task, you will even let him take the task and sometimes you will pair him with your best developer so that this team member will become better. And since the sprints are only up to 2 weeks long you will seriously reduce the amount of "unexpected events" that might fail you estimation – your commitment to the client is backed up by all your team members.

The review

You know why there are a lot of developers who hate their job? It's because they are not getting any recognition or since they don’t understand why they do what they do. The review gives them both. The client and all the managers can come to the review meeting and congratulate the team or that junior developer on the great job that the team has done this sprint and more importantly – why this this feature is so important to them. That means the world to them. That what’s keeps them going even when the time gets rough. 

My mom works in a bank and every month or so the county manager arrives to their branch and congratulates the whole staff for the great job they did. She always gets so excited. By the way – they didn’t give it a label – this is just the right thing to do.

 

The retro

Erik says that the meetings in Scrum "are an annoying interruption at best, just let the developers code". 

This is wrong. If you keep on coding and not stop sometimes and just talk you will never get better. Your team will never increase performance, improve the estimation accuracy, delete all the distractions and preserve the good things that they do. You have to stop and ask yourself and all your team members: what was good and what should we improve. You have to let all your team members speak since you cannot know all the things that bother them. A team that shares the faults along with their successes is a team that improves. And a team that constantly improves will deliver a better product and will make its client satisfied.

 

I hope that I've showed you some of the "secret" benefits of Agile and Scrum and I truly hope that you agree with my belief that this is how you should manage a software project and this is how you should develop a project that you want to be successful. Even if you won't do "Scrum" you will make a lot of errors that could have been avoided if you did.

Internalize that you don’t see the whole picture and that you need all your team members to be responsible for the success of the project. You need to work differently.

You need Agile.
You need Scrum. But don’t just use the label – use what it stands for!