CHOW #285 – Unwilling developer

Bill is a Product Manager in a large software product firm with their development centre in India. He felt that the developers do not understand the customer’s business context enough. He spoke to Ram, Engineering Head in India, and sought volunteers to join the two-day user group conference in China. To his surprise, Ram came back with one of his Engineering Managers as the volunteer and said developers did not show interest in the conference. He added, next conference in Europe may be more attractive.

What do you suggest Bill and Ram do?

Suggested solution

It reflects on the conditioning of the developers. There are a few possibilities: 1. Demonstration of technical skills may be rewarded better by the organization. 2. Developers are not used to conversations with product management on requirements. Engineering Managers could be playing the role of bridge between product management and development teams. Their job is more of coders than solution builders. 3. All the training for developers may be technical and to some extent on soft skills. There may not be any focus on building domain knowledge to learn about customer’s business context. 4. Engineering unit has the mindset of order takers than innovators. It is important for Bill and Ram to have a conversation about the reason behind getting volunteers to user conferences. They could then work together to come up with a strategy to realize the true intent of creating greater value for customers by bringing the developers closer to the users. It would require joint vision, changes to operational processes, changes to reward systems and revised skill development programs. It is certainly achievable with alignment and collaboration between Product Management and Engineering functions.

Leadership, Communication; Culture
What do you think?

2 Responses

  1. Velocity of each individual iteration will be a different figure. There are many ways velocity gets impacted. Apart from planned absence (planned leave, training etc.) and holidays, there could be unplanned absences caused by illness, personal emergency etc. which impact velocity. User stories that do not get completed in an iteration get moved to next iteration. This brings down the velocity of the iteration where the story was started and bumps up the velocity of the iteration where it got completed. This being the situation, good practice is to take an average of last five or six iterations as the velocity of the team. Team stability is another factor that impacts velocity. Teams that have higher churn will see higher volatility in velocity. Other factors such as change in technology, adoption of new tools, increase in automation, will also impact velocity either positively or negatively! However, if team is stable and has reached “performing stage” steady rise in average velocity will be seen over a period of time till any of the factors mentioned above comes into play and impacts it.

    1. Thanks Milind, fully agree with your comment.
      Finally, irrespective of the increasing trend in velocity, there is improvement for sure. This cannot be missed, if observed. One of the intent of my blog is to encourage this observation, by taking a mildly provocative stand.

Leave a Reply

What to read next