From ‘trying to impress’ to ‘do the right thing’

Agile is all about a committed team, including the scrum master and the product owner. Very often in an outsourced environment the scrum master and the development team sits away from the product owner, and very often forgets the fact that the product owner is an integral part of the team. The distance, timezone differences and lack of familiarity contributes to this. If the team can elevate themselves from ‘try to impress the customer’ to ‘do the right thing for the success of the sprint and product’, this can be addressed to a great extent. When we look at things from a ‘value to customer through the product’, lot of psychological impediments fall into place, resulting in a highly collaborative environment. It is easier said than done, because we need to get rid of lot of out dated cultural baggage of ‘always the customer is right’ and ‘be in the good books of others’. Sometimes it takes a bad boy to do the right thing, which is good for the product and customer. Thats why the founders of scrum insists on;

Committed team
Mutual respect of people with self respect
Risk taking ability

A confident scrum master, who knows his/her job can make everlasting impressions. In this context I remember the question from Venkat, the CEO of one of the companies who availed my services to roll out scrum within his organization. His question was ‘Aby, whom should I recruit as a scrum master?’ and my answer was ‘Go for someone who is not worried about job security, and can negotiate with you for everything, which will make the sprint successful’. That could be a very special breed of Indian managers, and they do exist . Always recruit people who can disagree with you for the right reasons. I call it ‘intellectual disobedience’. I do respect everyone who can disagree with me for the right reasons based on data. That was the only criteria I applied while recruiting people, and the recruitment errors I made were only two among a whole lot of people. This is the only strategy helped me to build reasonably good teams. Thanks to Ronald Reagan’s quote ‘Always surround yourself with people who can be better than you’, and that is the success mantra behind successful team building. Good luck.

Abrachan Pudussery
Freelance Agile Coach
abrachan@gmail.com
0091 9895372115

Crossing the waterfalls in agile outsourcing to India

During my agile coaching, I have come across three categories of teams in India, who started their agile journey.

Category 1) Small and medium sized product companies serving a market segment, fully owned by Indians, experimenting with agility as a strategic business advantage.
Category 2) Project companies, serving the needs of a customer, who insisted on agile.
Category 3) Project companies, serving the needs of a product company located outside India, who are looking for a long term association with an Indian company as a strategic advantage.

Majority starts without any formal training, and in many cases starts learning agile (scrum) from their customer, who has the early starter advantage, ending up in scrum buts (diluted implementations of scrum). As usual, the easiest route to perfection is training. A trainer is hired, and a cross section of the members gets trained, who become internal trainers later. Unfortunately, scrum is value based, and like any other value based stuff (religion), it needs continuous nurturing and investment from the senior stakeholders. Like in any revolution, it creates some martyrs as well.

Most of the Category1 companies, start with great enthusiasm which fades away over a period of time. In Category2 companies agility is like a storm in a tea cup, which is confined to just one account. Once that customer leaves, agility is forgotten. The Category3 companies are the ideal fertile soil for agility, providing long term strategic business advantage for the customer and the supplier. This is a great opportunity for the Category1 and Category2 companies as well. This calls for investment in building the right competencies (technical, procedural and cultural). Here is where an agile mentor/evangelist/consultant adds lot of value.

Consider the case of an American firm, outsourcing work to a team in India, and they are following scrum (supposed to). The product owner is located in the US, and the Scrum master and the development team is in India. The team in USA, wants the team in India to take the leadership in the product development, and this is the first full development project from start to finish by the team from India. The first sprint failed, and the team is into the second sprint, and is at the middle of the second sprint. The burn down chart have started showing a lag. No feature is done yet, everything is a work in progress. The team is very optimistic about completing the sprint successfully, and they did not report any impediments in the daily scrum. By looking at the symptoms of a widening gap of the burn down, the situation is not that optimistic. The first sprint also had all these symptoms, and it failed. Did the team learn anything from the first sprint?. I tried to collect more information from the scrum master, which turned out to be a futile exercise, which forced me to dig deep into the sprint data, along with the team and the scrum master. The first instinct was to analyse the tasks which caused the burn down deviation. Here are some observations;

1) Some of the effort against tasks were entered in hours and some others in days, creating lot of confusion. Anyone who analysed the burn down would have detected this easily. Was the updation of the burn down chart a mere ritual?.

2) The team committed more story points than their velocity. Scrum master did not correct it during the planning meeting. Is it a violation of scrum?. Yes, of course. Then why it was not corrected?.

3) While doing the feature prioritization, weightage was not given to technical risks. Before having clarity on architecture, the team has started building the features. This is creating a bottleneck, hence the appearance of too many tasks in the being done column. The team says that once they get the clearance from the architect on the architecture, everything will become done on the same day. The team is optimistic. Did my experiences made me a pessimist?

3) As per the team, they do not need help on anything. They sound very optimistic, but the execution data points in a different direction.

My hunch says that tracking the burn down chart closely by the scrum master and the other senior stakeholders will help to complete the sprint successfully.

Why did the team commit to more story points than the velocity of the previous sprint?

It has more to do with social, cultural, and management factors. One must understand that, In India, we come come from a cultural back ground where Mother, Father and Teacher are considered as equivalent to God. When someone joins the corporate life, this gets extended further by adding a list of seniors at work, who are graded by their;

Expert power
Positional power
Reward power
Coercive power
Reference power

When new work gets outsourced to a new team who are very new to the product, who are ultimately getting paid by the customer, based on the feedback by the product owner – who is again part of the customer, the supplier’s team starts very power less. Do not expect them to tell the emperor that he is naked, when he is really naked from day one onwards. The only power the development team can covet in this scenario is the expert power. In order to groom a group of brilliant yet inexperienced (not by the yardstick of number of years in the industry, but the kind of projects executed in the past, and the manner of execution) team members to experts needs conscious grooming by way of;

Effective team building activities
Incentives for excellence
Technical mentoring
Process mentoring
Clear career goal setting to the team members
Leadership mentoring to the scrum master / product owner
Improving Communication skills
Improving the meeting skills
Cultural mentoring

Is asking for help..termed as a sign of weakness?
My experiences with some of my former bosses and Indian HR practitioners make me agree to this very strongly. Whenever I asked for help for improving something, generally I got it back as a weakness in me, during the performance appraisals. That made me very defensive. Is the pattern continuing even today. To be honest nothing much has changed in the Indian I.T workplace during the past three decades. People still use waterfall model, function point analysis, WBS based estimates, tracking project using Gantt charts. If that is true, then behavioural changes takes longer time, if there is a conscious effort towards it.

Who must do this?
Ultimately this must be done by the organization. Scrum master and the product owner has a major role to play here. Definitely, an experienced scrum coach, co-located along with the development team can play a vital role here.

Abrachan Pudussery
Freelance agile coach
email : abrachan@gmail.com
phone : 0091 9895372115

This article do not contain anything about my clients past and present