Archive for the ‘Collective Ownership’ Category

True Collaboration!

April 9, 2011

Last week we had an issue in production. One of the reports was hitting the servers pretty hard. Our “Production support monkey” (all developers rotate this job every sprint) mentioned the problem in the standup meeting.

“The problem is that this report could be run for any date range and taking lot of time. Mean while user is clicking on the submit button multiple time that caused several instance of the report running.”

Soon after the standup meeting was over, engineering manager sent out an email with details of his research on who requested the report and how many times it was requested etc. This email went to whole engineering department.

DBA did some performance tuning to database and sent out an email with the test results of his change.

System administrator sent an email offering a shell scripting solution to monitor multiple running instance of the report and alert if they are running for too long.

Developers already thinking of couple of simple fixes to avoid user clicking multiple times. Team has all the knowledge and working on a integrated solution.

Points to note:

1.     Every one knows about the problem. This was automatic since everyone comes to standup meeting as well as everyone gets the emails.

2.     No one assigned any task to anyone. Everyone shared the responsibility and offered a solution from their side.

That’s what I call “True Collaboration”!

What could we learn from Cricket?

March 26, 2011

I mean, Cricket – the game that is played in most of the major countries of the world.

We had our “Agile Hyderabad” group meeting yesterday. We spent most of the time discussing about testing challenges. Most of the companies those follow agile software development has the problem of developers and testers keep “We and They” attitude.

While I was watching cricket, as we are fully into the World cup fever, it struck me that there are few things we could learn from the cricket teams. A cricket team has “Batsmen” and “Bowlers”. However, if it is required, a bowler (supposedly “none to less” experienced in batting) is expected to make few runs. Same way if the regular bowlers are not making an impact, the captain decides to use any bowling skills of the batsmen. The goal is to win the match and every member of the team strives for it.


The goal of an agile team is to deliver the quality software at the end of the iteration. The team has to figure out who does what, but the goal is to deliver the stories. Some team members would have the specialized skills like programming or testing, but they should be willing to do other activities outside their specialization also. This could be a developer performing some testing or tester fixing bugs or architect writing documentation or what ever. Agile teams need to redefine their roles and develop “We are all in this” attitude.

Moving on to a different topic, when I talk about agile way of developing software, it is big change to lot of people from how they have been building software.  People say  – “ We have been doing it for ages. Why do we do it in different way now?” Do we have to follow something just because we have been following it forever?

Long time ago when I was small, a cricket match always started with a pace bowler starting the bowling session with a new ball. It has been well established for decades that a pace bowler could make a new ball to swing and get some early wickets. To my surprise, a spin bowler started bowling session when India played against Australia in the world cup 2011. The reason why the captain took that strategy is because they don’t have enough good pace bowlers and they have very good spinners. Besides, Australia is not very good at playing spin bowling. Indian team ditched the conventional practices and implemented the practice what goes with the current situation. As a whole the team did a great job and India won the match against the odds.


In the current market conditions, the stakeholders of a software project expect that the time-to-market should be reduced to beat the competition. Organizations want to be adaptive to the market requirements. To achieve today’s market needs, an organization needs to implement the practices those work for the current conditions. Change is hard, but it is inevitable.