SAP TechEd 2008 at Bangalore

I along with my team, attended the SAP TechEd at Bangalore. It was a 3 day technical event attended by many SAP folks from various IT companies. The theme was Connect, Collaborate and Co-Innovate!!

Being a green field in an SAP world, I had the first experience of the SAP community at the TechEd. Communities always helps its members, products and technologies. I had always associated communites with only open-source technologies. But I was wrong. May be due to my lack of knowledge :(. Even a company like SAP is promoting and focussing on the SAP community development.

It was an informative TechEd for me.

The Google Story

Today, I completed the book "The Google Story". The book is really good and gives an insight how amazing the Google is. Google founders, Sergey Brin and Larry Page have authoritatively demonstrated the power of innovation and technology.

They just wanted to solve the problem of searching the web. They really solved it and how!!

I particulary liked their motto "Don't be evil". I think this "Don't be evil" attitude helped Google to gain the popularity merely by word of mouth. It is hard to believe that Google-the most powerful brand in the world has not spend much in advertising as compared to others.

Check it out

SAP and Ruby

I switched to SAP.

Yes, that is true. I am posting after a long time and that too with a sudden change in the technology for me. I was not expecting this change but it was inevitable. I could not get a Ruby on Rails project from my client so I had to look outside for the Ruby projects.

I realized that there are not many good opportunities in Ruby and Rails domain. SAP and JAVA are the technologies in demand and that is where the most of the work is done. I chose SAP as I have always regarded it as the one of the most innovative product the world has ever seen.

On the first day, I found that there is a Ruby library allowing access to SAP via the tried-and-true RFC technology. This was exciting that though in SAP world, I can still work with Ruby !!! I plan to try this out and post it on my blog soon.

RSpec Stories and WATIR (Web Application Testing In Ruby) - Part 1

I used WATIR in my last project for automation testing. I started writing tests in RSpec framework. But then I came across the RSpec Story framework which convinced me as the appropriate way to write readable automation test scripts.

I wrote tests from top to bottom. I wrote story and its scenarios first and then its implementation. Since the stories were written in pure English, my product owner could contribute towards writing the stories. According to me, following are the advantages of using story framework:

1. Executable tests in pure English


2. BAs and Product Owners can write test scenarios


3. Tests are written in DSL (Domain Specific Language)


4. Tests are maintainable

Since I work in a onsite-offshore model, a lot of time is spent on daily calls between the two groups. Out of the 250 people at offshore, not many get a chance to evaluate and work on new technologies. On top of that, people are always resistant to change. I am working towards adopting WATIR and story framework in other projects in my organization. I find promotion of WATIR and changing the mindset of people a bigger challenge than learning WATIR.

Check out my recommendation for WATIR and stories on OpenQA

I have created a screencast demonstrating WATIR scripting and story framework. I will post it soon.

Adopting scrum is subjective

I have experienced that "scrum is subjective to the teams" in my current project. I am working on an existing legacy java application. I am part of a scrum team of 10 people. We are termed as one of the high performing scrum teams at my company. Our client is so pleased that they want to retain the same for another project :).

But when I tried to analyse our success, I realised that we never followed scrum 100%! Following are the things that make me believe so:-

• Sprint backlogs did change during the sprints. Team was able to accomodate new stories and deliver value addition. There were many sprints where we could deliver extra credit stories.
• Team used to skip standup calls on days when team(onsite+offshore) didn't have much updates/risks to share.
• Since we were working on a legacy application, the team's estimates were high during the release planning due the less acquaintance with the application. But as we spent more and more time on the application, we were able to revise and reduce the estimates. Once, we changed the estimates during the sprint!!

Following are some of the things that we didn't do and saved time.

• Never created a release burndown chart
• Never created a sprint burndown chart
• Never tracked individuals' hours spent on the tasks

So I feel team should be empowered to decide what works for them and what not. They should alter the scrum in a way that works best for them. I have seen teams with 100% adherence to scrum but performing poorly in terms of the development and delivery.

Any thoughts??