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 

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!

User Stories or Use Cases

This seems to be the question of the month. I got it quite sometime in last few weeks. So thought of penning some of the discussions, thoughts and research I did on it.


As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.


Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.


User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.


I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.


The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.


The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.


The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.


Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?


I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.

Certified Scrum Master

Yooohoooooooooo! That’s how I feel after earning my very own Certified ScrumMaster (CSM) certificate.

While working on Agile Scrum for almost 5+ years now, I always wanted to get myself this certification. And it simply feels great to complete it with a commanding score of 96%. Sad part is the 4% I missed on one question is something I always talk about in my Agile trainings and coaching. It was a comfortable exam with some of the tricky ones. But the end is sweet sweat.

After returning to Mumbai, I searched for the CSM courses and to my surprise, there were no courses conducted in Mumbai. So contacted Pete about the same. Couple of months later, received the course invite happening right here in Mumbai. So got registered, got the real good insight into Pete’s knowledge base, his easy ways of making you understanding and very impressive skills to communicate. 16 hours later it was a great feeling to realize that most of what Pete taught is something I was practicing already. And many new things I learned are very effective. The knowledge from training was immediately useful on the project I was working on.

But that last action was still on me. To go and take the online assessment. Waited for it for 2+ months. Not that I was scared but just that I just could not devote time to take it. Finally just yesterday committed myself to the cause and complete it. A whopping 96% felt really good. And I am officially the Certified Scrum Master now. Visit the link here to check my profile on ScrumAlliance.

Now my eyes are on becoming a Certified Scrum Trainer. I hear that it is a 2-3 year journey after becoming the CSM. Well, who is in a hurry? Do it slow but do it right!