Monday, July 12, 2010

Wrong influences on Scrum teams.

There is an inherent understanding in Agile implementation that Scrum is all about team and they have a final say on anything that impacts their productivity.  To a certain extent this is true especially if you have only handful of possibly co-located scrum teams. However, in enterprise wide software development where you have dozens of distributed scrum teams external influences will start hampering the teams final say.

One of the external influences could originate from senior management in large team environment. Most of the time, their decision is based on what they hear and see in the sprint review, the Scrum of Scrum meetings, from what others leads have to say, and there may be other factors influencing them too. So It's quite natural for the management team to implement a particular solution based on gathered facts. Since the management team is not involved in the day to day life of a Scrum at times the analysis might not be complete and it might result in half baked solution thereby disrupting the team momentum.

An example of one situation from my experience -

A particular scrum team in multi team environment decided to work towards eliminating the accumulated technical debt with a conscious decision to abstain working on any new feature this sprint. However, certain new functionality was essential from this team to accomplish the sprint goal. The management had the option to honor teams decision and take a hit by allowing them to work on technical debt, or come up with alternative solution to meet the Sprint goal.

They choose the latter and came up with few options like -
Can half the team work on technical debt and the other half on new feature development?
Can we add additional members to the scrum team to develop new feature?
Both the approaches seems doable,  but the reality might be a little different. To list a few.

  • Are new engineers knowledgeable enough on the design and technology used in the scrum or they need to be trained? Training will take time off of the existing scrum team planned work.
  • Will the newly borrowed engineers maintain responsibility of code they wrote and delivered to production or the work will be transitioned to the existing scrum team.
  • What type of impact does it have on team dynamics - It does take few sprints (normally 4 to 5) for the team to gel together.  Adding new engineers might just disrupt the team momentum.
  • The existing team might be used to working in certain style - eg. coding, code review, TDD, Wiki, etc. It’s difficult for new engineers to follow these practices if they are not aware of it.
  • If half the team is working on technical debt and half on new development, can you eliminate the debt?

I have experienced scenarios where the scrum team size have grown from 10 to 15 engineers where management felt they were helping everyone achieve the sprint goal, but in reality they were disrupting the team dynamics. In addition to the above facts, the team would also experience increase in duration of overall meetings including planning and daily standup due to increase in size of the team. The correct decision should have been  to stop the production line until the technical debt in order before continuing with new development. It's either pay now or pay later with compound interest.