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.

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.

I’m sure you are all familiar with sprint retrospectives, how they can be run and the value that they add but have you thought of using this tool to run a project review.

A short while ago we completed a project with our customer and we decided that we should do a project review.  In my case the customer is external to our organisation. 

I thought about this for a while and remembered back to previous project reviews I had been in and how stale and stuffy they were and sometimes a very defensive meeting, a thought occurred to me which was to run a sprint retrospective but for the project.

I rang my colleague Richard another scrum master on the same project and mentioned this to him and to my delight he’d had the same thought so we agreed that we should try this out.

When our customer visited for the review we briefed them on how we wanted to do it but also warned them that we hadn’t ran a project review this way before, we have a good customer relationship so this wasn’t a problem to them.

Richard ran the retrospective starting with a time line and key events.  It was really interesting to see the different perspectives that people had and quite enlightening to us some of the things that our external customer thought was key and enlightening to them on what their supplier thought was key.

We then progressed to the good, not so good and what can be improved and then agreed on what actions needed to be taken, exactly as I’m sure most people run their sprint retrospectives.

What struck me most however was the interaction, fun, openness and feeling of a single team that this process created and it was a joy to be part of with everybody being open and honest in a non-confrontational way about the things that are important to them and us all working together to inspect and adapt our project for the better.

Never again if I have my way will I be in a stale, stuffy or defensive project review meeting.

Sprint retrospectives for the project are the way to go.

Many of you reading this maybe familiar with the ballpoint game.  For those of you who are not then it is a simple game that can be used to demonstrate scrum.

The basic rules are that you need to pass a ball from one person to another and it must go through every ones hands in the team with air time.  The ball must not be passed to your immediate neighbour and you must pass it one ball at a time, there can be many balls at the starting point but the ball must start with a designated starter and end with a designated finisher back at the same starting point.  Any ball that goes through the team without being dropped counts as one ball point.

You allow the team 1 minute to plan how they do it and provide an estimate of how many times they will be able to successfully complete a cycle in 2 minutes, they then get on and do it.

When they have completed the 2 minutes allow them time to re-plan and then iterate.  I do this 3 times.

This exercise covers the basics of scrum

• Product owner sets the objectives and goals
• The team understand and ask questions
• The team plan how they will do it and estimate
• The team implement the plan
• A retrospective is conducted

For more detail see this link for details of the game by Boris Gloger http://kanemar.files.wordpress.com/2008/03/theballpointgame.pdf

Now sometime ago on the yahoo scrum board when we were discussing games Angela Druckman said she added an extra iteration into the plan called the bonus round.

This was to make up a number of times that you have had one team complete the pass of balls and ask the team to try to beat it.  This number is of course fictional and much larger than the teams best in the previous 3 rounds but it is there to demonstrate to the course attendees the impact on the team being set an unrealistic challenge with constraints placed on them that they have no way to alter or influence, with unrealistic expectations being set and no buy in from the team.  This could of course be likened to teams having a software schedule forced upon them.

Now I have run this a number of times but never before had one that demonstrated the point so well as I had on the course that I run yesterday.

The team started to plan for 1 minute and got nowhere, they then started their 2 minutes and still got nowhere spending their time talking about how they might do it and second by second falling into more panic, chaos and disarray, it really was beautiful to watch, in a nice way that is knowing that the whole intention of this part of the exercise was to illicit this exact response.  The number of balls completed through the cycle was zero.

When I asked the team to reflect on what had happened they picked up on the key points that the exercise was there to create and it really did bring home the negative impact that setting unrealistic expectations, constraints they could not influence or alter and the fact they were set targets that they had no buy in too can do to a team.

If you ever run the ball point game or are thinking about doing it consider adding in this twist, you might be surprised with the results.

Working in an agile way can be difficult for some people to grasp, but once understood and adopted there can be no going back.

The agile manifesto embodies the spirit of collaboration and communication and that human beings working together in an adaptive way will produce the best results. Adopting an agile mindset is the beginning of a journey, one where you will never stop learning and one that will never end.