Estimates, Teams and Commitments

Teams for many years have been used to providing estimates and  being held accountable for meeting them and are frequently told that the estimates are far too big and to reduce them because “it cannot possibly take that long”.  To make matters worse these estimates have often been provided on the team’s behalf by people who will not do the work and little or no account has been paid to the amount of time that people are actually available to spend on the work.

I ask anyone reading this to let me know if they have ever been able to spend one full day working on nothing but the task in hand, without any interruptions at all, no phone calls, no emails., no brief chats.  If you have then you must be unique so come along and see me and I will happily buy you a drink :)

We must learn to separate our estimates from our commitments; we must also learn to allow the team who will do the work to provide the estimates and accept that the team who will do the work are best equipped to estimate the size of the work.  Why are we surprised when things do not arrive when expected especially when the definition of an estimate is “an approximate calculation or judgement of the value, number, quantity, or extent of something”; and on top of this the estimates have been given to teams, or teams have been told to cut them, or no account has been made for the difference between size and duration.

We must change this thinking.  We must allow the people who do the work to estimate the size of the work and we must allow them to be able to make a commitment that separates the size from the duration and no longer force our opinions onto teams; until we do this we will always be bitterly disappointed with the results. 

To do this takes trust and courage, but by embracing courage and giving trust we will get more predictable results and ultimately have far better teams with more predictability of when work will be complete.  This can be a big step for many people who have been involved in IT for a long time, but it is a step that you will be glad to have made should you have the courage to take it.

Individual performance, rewards and the team

A while back I heard a comment that some people were worried that moving to scrum would have a direct affect on their ability to gain financial rewards as scrum was based on the team and not the individual.

I’ve thought about this over time and realised that this is an ingrained cultural issue that is maybe prevalent across the whole industry.

Now of course different members of a team may well be on different salaries for different reasons.  Market forces for example will dictate levels of pay for certain roles, its likely that it will cost you more in salary for someone recruited to a company than maybe it would for someone grown organically within the organisation.

Often however following someone’s initially salary, financial reward or pay rises have been given based on people’s personal performance or perceived performance, it could be there is a hierarchical structure that you move up based on certain criteria.  This has been on going for many years so when people hear that we succeed as a team, we work as a single team and we win or lose as a team then I can understand how they may be concerned with how it affects their yearly financial rewards in terms of pay rise etc.  I don’t see however that just by moving to scrum an organisations method of determining pay rewards would change and in fact I am very confident that it doesn’t and the methods of reward remain unchanged.

If we examine the topic further and take the current approaches to pay rewards what issues may this cause in relation to working with a scrum team?  If financial reward is based solely on individual performance perceived or otherwise then this could lead to a hero mind set.  People may take on over bearing workloads, work excessive hours, with hold information from other team members, not help other team members and let the team fail as long as on an individual level they succeed and ultimately ensure they make themselves look good so that come financial reward time they will get the lions share.  This I’m sure we would all agree is not the best place to be when we need to work as a team to deliver successful projects or products.  In addition of course if everyone took this approach there would be a high probability of project failure and this may reduce the desire to offer any financial rewards from the company.

So how can we change this?  Well if we work as a team, deliver as a team and win or lose as a team then surely we should be rewarded as a team.  If the team is successful then the team is rewarded, if they are not successful then the reward is reduced.  If we took this approach then what mindset would this promote?  If people are measured as being part of a successful team then this will encourage a mindset of one of a team player, ensuring it is the team that wins and not individuals at the expense of everyone else.  Workload would be shared out, information cannot be withheld and people will willingly support and help each other.  They will do this as they will know from a financial aspect it is to their benefit.   We should focus our rewards on successful teams delivering working software and individuals displaying the characteristics that move the team as a whole forward. This method rewards teamwork and successful teams and not successful individuals at the expense of the team.  If all the team work together towards common goals and objectives and not as a set of individuals then there is less likelihood of project failure and therefore the organisation may have more money to offer in terms of financial reward.

Some people may say that this would allow weaker team members to hide away but would this really be the case, this in fact may draw them out more quickly, people will need to be on the top of their game and be adding value to the team in the best way that they can for the team to succeed and in fact may breed higher performing teams.

Over and above this what about the case where we do have outstanding individuals, they may work well in a team and tick all of those boxes and we may want to reward them highly to retain their services and avoid them being tempted to go elsewhere, how do we reconcile this and cater for this scenario?

Now I have been extreme in how I have painted the picture and somewhat simplistic, people and teams are not really at such opposite ends of the scale and of course there are many other factors at play in how teams function and work together other than financial reward but the question remains how do you align individual rewards against the team ethos which in essence was the comment that I heard.

I don’t think these are questions that a scrum team can answer,  this is far deeper and far more in grained and cultural, we would need to change the entire organisation to think in this way and indeed would need to change the way financial rewards are seen and dealt with.  This would be a big ask of any company or industry.

Will we ever get to rewarding by team as opposed to individual? I don’t know, maybe there is some aspect of this already with team bonuses and maybe they need to co-exist along with individual reward as opposed to individual rewards being replaced.   Maybe we need to find a happy medium that recognises and rewards the team, with team work being paramount but can also recognise and reward individual excellence as long as it is not to the detriment of the team or encourages hero behaviour.   

Do I think we should get to the position whereby scrum teams are rewarded as a team based on team success?  Yes I do, will it be something that I will see as common practice in the medium or maybe even longer term?  Probably not, that is within the hands of individual organisations and down to industry trends. 

Indeed maybe these questions throw up many more questions in themselves and this whole topic is one of extreme complexity with many factors at play whether this is at an industry level, organisational level, team level, individual level and even down to the culture within the country that you operate.

Team sizes and communication pathways, wow what an eye opener.

On a recent project of mine we set up a new team, I wanted to keep the team size within the scrum recommended team size of 5-7 plus or minus two but for various reasons the team was formed with 12 members all of whom were co-located.  I wasn’t entirely happy about this but thought OK its only three more than what scrum recommends so it should be OK.  At this stage I knew a little about communication pathways and team sizes but not a great deal.

So off we went and we started on our project after a short while I started to notice a few things.  Firstly the daily scrum started to take longer, they were more difficult to keep short and get concise answers to the three questions and I could start to see that sometimes people would zone out.  It was more difficult for me as scrum master to recognise things that were becoming bottlenecks or impediments.  Further into the project I started to notice that the scrum was in fact becoming two scrums, in essence the team had naturally divided itself into two teams (A common problem with larger teams).  This then added to the problems and communication was becoming an issue and people were becoming less aware of what others were doing and communication was suffering.  On top of this there were a lot of new members within the team so the team was also going through the forming, storming, norming stage that was adding to the problems.

We discussed these problems in our retrospective and we tried to split the team into two scrum teams for one sprint, but at the end of this felt after all it would be better to stay with the one larger team.  I also conducted a little research which really opened my eyes and allowed me to understand the theory behind the scrum recommended team size.

A chap called Fred Brookes devised the following equation to calculate the number of communication pathways, it is [n * (n-1)]/2.

If you run this for a team size of 5 you will get [5 * (5-1)]/2 = 10 communication pathways, as team sizes increase you get

  • [7 * (7-1)]/2 = 21 communication pathways ( a 110% increase in pathways compared to 5 team members)
  • [9 * (9-1)]/2 = 36 communication pathways ( a 72% increase in pathways compared to 7 team members)
  • [12 * (12-1)/2 = 66 communication pathways ( a 85% increase in pathways compared to 9 team members)

When I looked at this the size of the communication problem hit my smack between the eyes and I could start to understand some of the problems we were having.

So what did we do, well I could have mitigated the problem by removing people from the team but I choose not to do this, but instead choose to get the team working more effectively and we discussed this as a specific point in a retrospective.  We examined how we conducted sprint planning and changed things about we also made our daily scrums more focused, but ultimately it was about communicating better within the team and being more focused with our communication.  Where as with a smaller team we didn’t need to focus too much on communication specifically as it was easier with less people, we found with a larger team that we had to work at our communication skills.

Now we are further down the line, our daily scrum rarely goes over 15 minutes, quite often they can be as little as 10, people don’t zone out, they are more focused and team members are much more aware of what other team members are doing, impediments are easier to recognise and communication is far more effective and we are all much happier about it although we still try to improve all the time.  I am sure as well that the team being more settled and familiar with each other has also helped having gone through the team forming stages.

In conclusion would I have a team size this big again, by choice no I wouldn’t but if I had too I would, would I go larger than 12 I very much doubt it. 

If you find yourself in this situation then by all means have a larger team but do it very much with your eyes wide open, be prepared for communication being more difficult, sub teams being created and then having to work hard to keep the information flowing through all of those communication pathways and most of all don’t underestimate the problems it can cause and the effort required to resolve them.

We Work With

baille Gifford british airways cabinet office credit suisse ericsson here kaplan microsoft minsistry of justice objectivity vocalink