Honestly ... Which methodology do you prefer ... Agile or Waterfall?

Honestly ... Which methodology do you prefer ... Agile or Waterfall?

 

Hold it right there.

 

The title of the post is a question, but before you close your eyes and put your index finger on one, let me ask you this - You sure you understand the question? You sure, you understand the methodology of your choice? Answers to both of these questions is absolutely necessary if you want to do justice to your methodology of choice and yes, more so ... if you want to be honest that is.

 

For me, the choice is Clear - "Agile works anywhere and I am a great fan of ?. But if someone asks me “which one is better, Waterfall or Agile”, my answer would be … which one is better “Iron ore or Steel Rod” ... which one is better .... "A seed or a Fruit". Agile would not exist without Waterfall. It's one of those kinds – Dog is an animal, but every animal is not a dog. Same way Agile is Waterfall, but waterfall is not Agile.  .... Yes, I can see some of the eyebrows touching the sky already .... so here!!!

 

Agile is concept. Scrum is a framework that uses Waterfall underlying. Agile is a set of best practices that people put together and called it by a Name. The way I see it, When you are doing Scrum, you are doing waterfall .... repeatedly and fast enough focusing on small portions so that you can avoid surprises along with customer interaction. And in the process you are shifting responsibilities from a controlled and one-person-managed environment to a responsible team along with customer involvement and collaboration. Scrum provides you the guidelines and framework to work together with shared responsibility. If you notice, the focus of all Agile methodologies is “people too” and not just Processes.

 

So what is this big fuss about "which is better"? To me, comparing Agile with Waterfall is a stupid debate. The comparison should not be and need not be between Agile and Waterfall. It rather should be between Agile and Traditional. I repeat .. I am saying “traditional” … coz you cannot ignore waterfall. You cannot write the code without design and you cannot test it without requirement. So process is set, one thing after another ... a liner way. So do it one after another, do it more frequent and faster, do it collaborative way, do it with shared responsibilities, mix some of the best practices, and there ... you have Agile.

Would you agree? And if you do not, I am sure I missed something in the post. So shoot it in the comments and I will res

Agile Testing - Session with ITB Mumbai

Came across this presentation video that I had delivered 2 years back. Didnt even know that it was on the net.

Well, if it is there, then why not share.

The video quality is not good because I think someone recorded this from the Laptop camera.

http://itbmumbai.blogspot.in/2011/04/mtmm3-video-of-presentation-on-agile.html 

Is Agile MicroManagement?

I came across this very funny question recently. And I refer it “funny”, because I find it so.

From experience of working in Agile environment for years now, one thing that I found common in all failed agile projects is that the project teams always blamed it on the overall methodology and associated processes and none of them appreciated the fact that they never got the Agile understanding the right way. And at this point in time, I want to go back to something I read about Agile. It goes as below:

Agile is like teenage sex

Everyone says they are doing it.

But most probably, no one is doing it.

And whoever is doing it, is not doing it right

 But fact remains that there are project teams that tried Agile and failed. And they strongly feel the failure was completely because the way Agile is set up – “Well … it exposes the entire team to the customer with little or no ability for the project manager to manage the situation. There is way too much of involvement from the customer. So much to get done in 2 weeks and with ‘welcoming the change’ philosophy, developers are always on their toes. And QA gets so little time to test in 2 weeks. To top it all, customer has so much of visibility into everyday tasks that they are actually Micro Managing the Project Team”.

 Hold it … right there!!!

 I hear some souls nodding their heads and saying “absolutely … every word related to the project failure justification is true”. And I don’t blame them. That said, it's not that I agree with them. But when I say, I don’t blame them, my point is – what’s the point in blaming a kid who wants to play with fire and burns his fingers. First the kid does not know it's fire, second it does not know it will burn, and third it does not know how to use fire the right way. And ‘fire’ here is only the analogy and not a parallel between Agile and real fire. Given the choice, I would like to call it Ice than fire. But then you might not get my point.

 So basically, if you do not know how to use a tool, you probably are going to use it the wrong way and break it further than not using it at all. So here is what I have observed on all failed Agile projects.

1.       Are we practicing Agile or we are Trying it out? There is a big difference. You would say, if someone is doing it first time, then they would definitely try it once before practicing. Fair point. But when you try it, you do not have to give it up with one or two failure. If that was the case, Edison would not give us the light bulb. So if you know you are trying, then limit it to Trying. And if you want to practice it, then first understand the right way. Don’t confuse between Trying and Practicing.

2.      Agile Project Team – the keyword here is TEAM. So it's important to understand if the project team was working like a team or was it a group of individual performers busy completing their own work. This assessment needs to be done during the course of a project, during the course of a sprint. A post-facto analysis will not help and will produce biased results.

3.       Most importantly, did the Team and everyone on the team understood the Agile the way it should be? Did you really understand the importance and intent of a process or did you go Verbatim way? Do you believe Agile says no documentation or do you understand Agile calls for only necessary documentation? Do you believe Agile means produce as fast as possible or do you understand “as fast as possible expects you not to compromise on quality”? Do you believe delivering on commitment is critical or do you understand that you may go wrong on commitment but what you can deliver – though below committed levels – should be with TOP quality? Do you believe that customer is allowed to make changes or do you understand when to say NO to these changes and recommend the customer to wait till next Sprint? Do you believe Stand up is a status reporting meeting or do you understand it to be an opportunity to collaborate and communicate? And so many beliefs versus understandings!!!

4.      Your customer cannot manage you if you manage the Process. Does your customer understand their role? Do you communicate it to them regularly and frequently? Is your team mature enough to give a necessary push back in line with defined processes? Is your customer trying to get visibility into your Sprint or are you providing maximum visibility to your customer so that they do not have to try to. Is your Sprint Backlog a sequence of tasks or does it provide the clear visibility into your plan to get something done?

5.      Do you have right skills on the team or are you trying squeeze in some non-performers for higher margins? Does your team understand the processes or do they even understand the importance of the same?

And many more such questions you would need to answer, before you blame it on Agile next time.

Hope you would find these answers. And if you could not, just reach out!!