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!!

Beautiful Colorado on Bucket List

Flying over Colorodo as I type and the view is amazing. Ultimately clear skies with visibility beyond horizon horizontally and up to ground vertically (48,000 feet). And it’s just awesome. The Rockies from the top are absolute amazing and a sight of lifetime.

Started from Portland, OR this morning and on way to Phili. Was too concerned of getting on the plane, but the view changed my mind. Thanks to the change in schedule and I had to take early morning flight. The takeoff itself was eye-soothing. The green mountains and huge and log river makes it an impressive eyesight. And before I could admire the beauty, we were over this dormant volcano mountain. Great view. The mountain ranges are not just ending for last hour or so. I miss my camera on this flight. The landscape is so picturesque that I would be taking 100s of pictures today. The mountains with green tops, the brown slants, the white edges, tall and short look so beautiful. And the winding rivers only add to the beauty.

While I could admire the mountain ranges, there comes the plauto, miles of brown land with patches of green and blue. And see these roads ... so straight, so long and so lonely … there absolutely nothing on either side. I was in US for about 8 years, but never made it to Colorado ... regret that. Probably one of very few things I regret in my life. I should have been here and experienced the drive on these roads. The heat will be unbearable I know, but so was Snow in PA and crowd in NJ. So this could have been some experience.

Should be on my Bucket List. The woods may be dark and deep, but for sure these are the miles I should go before I sleep

Disciplined Agile Delivery ... so called DAD

Well, here we go!

In my last post, I mentioned about this Webinar on DAD and frankly ...Liked nothing about it. No denial the methodology is good ... well it has to be coz its an extension of Scrum. Or let me take that back. Its actually Scrum spelled incorrectly. It only rips off Scrum clothes and puts on new one .... here "Made In DAD" .. stamed and done. Well that "Definition of Done" is a little nasty I would say. And what I hated most was the way it was presented. Many people when promote Agile make a mockery of Waterfal (wrong in first place according to me), and here the presenter just presented Scrum in bad light, thinking it will lighten up his DAD a little more. Thats like Duracell saying Sun is not bright today :)

Primary Roles - StakeHolder, Product Owner, Team Lead, Agile Team Member and Architecture Owner. .... Bang!! No Scrum Master, know why? Because they say the role does not add value. A team without a leader will miss the target. Hmmmm... interesting, but not right I will say.

Secondary Roles - Domain Expert, Technical Expert, Independent Tester, Integrator, Specialist ... Aaaha! Gotcha!! Scrum suggest against specialized roles, but DAD wants to see you do something specific you know (otherwise you may just get into bad company and get drug adict). Is it not adding dependency on particular team member? And isnt Scrum actually talk about shared responsibilities to kill the dependencies only?
(and the slide read "People First" ... don't see where!!!)

No Sprints ..... oooopppsss! Thatz a biggie. Without Sprints, how will you develop incrementally. Thatz a tough one ... but wait and thanks God ... there are Iterations. Oh .. so thats the difference. It took me a while to realize the difference though .... dumb me!!

DAD claimed it's Learning Oriented. Who sasys Waterfall wasnt learning oriented. Give me one process or methodology that is not Learning Oriented. Well, DAD's learning oriented approach revolves around Requirements Envisioning, Retrospectives at end of Iterations, Proving the architecture with working code (???), Training+Education+Mentoring+Coaching (Scrum Master??), Tracking Improvements (retrospective??), Sharing Skills through non-solo developments (eXtreme Programming?).... this reminds me of something. How many of you have seen that "Friends" episode where Joey writes a letter. Well, it wasnt any different ... "sharing skills through non-solo development" .... huge ... keep it simple dude. "Pair Programming" ... we understand it. We dont have a mobile Thesaurus yet :)

Oh oh .... here. Take this one. DAD's concept is "The Agile 3C rhythm". Coordinate, Collaborate, Conclude.... Joooooeyyyyyyy ... where have you been maaaaaaan?

wait wait wait ... and they dont have daily "Stand Up" meetings. Know why, coz it does not have the punch. The "stand up" does not convey the message. So we replaced it .... any guess .... take another minute and tell me .... don't TimeOut on this one though.

And then the cherry on the top. Enterprise Awareness - Optimizing the Whole (hey ... thats a hole with W ..don't forget, they have not renamed it yet. Or may be Joey didn't find this synonym in his Thesaurus). So, here are the Enterprise Awareness guidelines.

• Follow Corporate Conventions / Standards (coding, UI, data, and many more)
• Enhance Organizational Ecosystem (reuse, infrastructure, EA team)
• Share Learnings (Agile Center of competency)
• Interact with other (potentially non-agile) teams (PMO, QA, Governance, EA).
• Don't know what these bracketed teams are non-agile though. May be, thats why DAD asked me to interact with them and find why they are non-agile and that much better.

(ok .. Time Out. so we dont have daily stand up meetings, but don't worry .. we have Daily COORDINATION Meeting. Hmmmm .. that helps!!! I was starting to wonder who should I discuss my status with. Thanks!!)
Well, 2 hours wasted. Don't ask me how many Person Hours. I know I should have followed the Agile Principle and walked out of the Webinar. But being married for 10 years now, you need to stick to listening some times. It was just one of those days.

Anyways, I have a new sign on my office door. "Beware of DADs". You better read it!

Disciplined Agile Delivery .... or something like that

Today I attended this Webinar subjected "Disciplined Agile Delivery". From the subject line it appeared it must be something that will teach you how to deliver projects using Agile Discipline. Well, did not turn out to be true. Rather, it is a new framework that IBM has come up with and the webinar just rediculed the regular Scrum process.

I will write in detail about the so called DAD framework ... but for now only two things ...
1. It just took me back 1 year into time ... when I read about "PlayBall" framework. Nothing new ... just reword the Jargons .... and hurray .... we have a new framework

2. There are two ways to be famous ... either be good .... or show someone/something as bad ... This webinar chose later ... candidly, not a great way.

More to come on this topic. (Posted a new blog about it here http://dineshmadne.blogspot.com/2011/05/disciplined-agile-delivery-so-called.html)

Who should be on your team?

We are starting this new project with a customer and during the envisioning phase someone asked me a question about the Business Analyst being part of the Scrum team. The question was "here we have a BA who needs to work on something during the Sprint, so should she attend the daily stand up calls?" To me the answer is straight ... but let me get that answer to you by using an Agile practice I all as "Ask a Why" (or "Why 5").

So let us ask below questions to ourselves and see if we can get the answers. Is this BA going to work on something
- that is going to affect or contribute to the Sprint Deliverable?
- that may become a bottleneck if not completed?
- that may have some dependency that the Scrum team is going to deliver?
- that scrum team including the product owner will be interested to know the progress on daily basis

If the answer to any or many of above questions is affirmative, then yes the BA should be part of the daily stand up - which also means the BA should be part of the planning meeting, she should have a backlog (as part of your Sprint Backlog), should provide status and report bottlenecks and also attend the retrospective if possible (you never know, the same devil may show up again in some sprint :) ).

The scrum master was intelligent enough to get the answer based on the questions I threw at him and here we are ... working on the Sprint which is going on smooth. And once again "Ask a Why" worked.