In the UK at present there is a drive by the government back to very traditional schooling methods with the focus being a return to learning by rote and a focus of learning based on the theory of subjects with the assumption that to be creative you must first understand the theory.  The secretary of state for education in the UK Michael Gove recently said the following.

About English he said “creativity depends on mastering certain skills and acquiring a body of knowledge before being able to give expression to what’s in you … You cannot be creative unless you understand how sentences are constructed, what words mean and how to use grammar.”

Regarding mathematics he said “unless children are introduced to that stock of knowledge, unless they know how to use numbers with confidence, unless multiplication, long division, become automatic processes, they won’t be able to use mathematics creatively … to make the discoveries which are going to make our lives better in the future”.

And on music he says “you need first of all to learn your scales. You need to secure a foundation on which your creativity can flourish.”

Let’s think about this for a second, and consider these comments, do you think they are correct?  I certainly don’t.  You don’t need to “master certain skills” in English for example to be creative and you certainly don’t need to understand scales to be musically creative, just like you don’t need to understand or master brush technique to produce a creative piece of art.

Did the person or persons who invented the wheel understand mathematics or physics to produce something so creative, I doubt this very much.  Go and tell Lionel Richie that he can’t be creative because he cannot read music.

Therefore in my view to be creative and creativity itself is not dependent on being a master of certain techniques or skills, in fact if you are first of all creative and are inspired to be so then you may have the desire and inclination to go deeper into a subject to master these skills.

So if we persist with the current government thinking then we will most likely stifle creativity in our young people and kill it off in them completely.  What we need is people leaving schools and universities with creative skills and the desire to be creative just like we need them to be team orientated, this is another problem with schools and universities which is a focus on the individual with little regard to focus on working within teams which of course is exactly what we want in the work place, but that is another topic.

So what has all of this got to do with software development and in particular software development in an agile context?

Well first of all software development is a creative process and it is knowledge work, it is probably as far away from engineering as you can get which was an unfortunate choice of word that was chosen to describe software development, we are not software engineers we are closer to software artists.

To produce the best software our teams need to be creative in everything they do and furthermore when we ask our teams to inspect and adapt their process we are asking them to be creative and to have fresh thinking in resolving problems and improving themselves and their processes, we expect the same when we inspect and adapt our product, we want fresh ideas, we want creativity.  Creativity allows the best processes and the best products to emerge and flourish, and it is this creativity that will ultimately give organisations the competitive edge.

What we need is software development teams that are creative, expect to be creative, want to be creative and are not afraid to be creative; if this is ingrained in them we will get the best results.  Yes of course we also need these people to be highly skilled but highly skilled people without creativity will not produce much of value or use, it is creativity that sets our best products and our best teams apart.

So we now come full circle, if our education system stifles creativity and places sole emphasis on skills and learning by rote then new people coming into the work place will feel that they are not creative and they will not have the confidence to be creative, if we are to be successful as teams and organisations it is creativity that will make us so, without creativity we are doomed to fail and therefore we need an education system that supports and nurtures creativity and not one that kills and stifles it.

An education system that kills and stifles creativity is not a good place for businesses to be in, businesses can only succeed with creativity at the centre of what they do and therefore an education system that supports this is of paramount importance.

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.

A little while back on a trip to Las Vegas I went to see a great show, upon leaving the show on my way back to hail a taxi en-route to my hotel I encountered rather surprisingly a huge queue, probably a good 150-200 people deep. I joined in and as I looked around noticed that there was an equally large fleet of taxis! More than enough to cope with the demand, I was puzzled as to why the fleet was so big.

As I watched the queue of people slowly dissipate, I could see that there was a Valet who was controlling everything, the taxi’s would not move to the head until called by the Valet and the passengers would not approach a taxi until called out to do so. Furthermore, the passengers would not open the taxi door as they waited for the Valet.

This was all extremely time consuming, even more so when the Valet was slightly distracted for any reason as the passengers and taxi drivers had to wait for him to signal them to move on. Essentially things were only done when the Valet said so.

This all caused a lot of frustration for the waiting passengers and no doubt taxi drivers too, as the longer they waited the less time they had to earn a living.

This whole situation led me to think of Euston Railway Station in London, UK. Euston is a large mainline station where at peak times there are hundreds of people getting taxis. But the one big difference is the queue is always fairly short as people move through it quite rapidly.

I considered why this was the case as the taxi rank in London also had someone with a similar role to the Valet, it dawned on me however that the key word was similar. The Valet in London does not control, direct, or manage the queue but simply guides the whole process. The taxi drivers move themselves to the head of the queue when they see the customers are ready and it is safe to do so, and the customers walk towards the taxis as they approach, open the door themselves and hop in. The London Valet only gets involved if there is a bottleneck and in this instance he removes that bottleneck. All in all this leads to a smooth flowing and fast queuing system.

So what has all of this got to do with Agile? You may already have worked out that in London the whole process is self-organising, the team (customers and taxi drivers) organise themselves, they manage their own workload and decide on how best to do it. The Valet in London acts like a Scrum Master, he guides the team but does not control them and he does not tell the team how to do the work. To be precise he doesn’t tell the taxis when to move to the head of the queue or tell the customers how to get to the taxis or get into them, but when necessary he does remove any impediments that stop the smooth flow of the queuing system. This is all a far cry from the command and control nature and the micro-management approach that was taking place in Las Vegas.

So, if you work with teams allow them to self organise and empower your team, do not direct and control them. If you let go and allow them to truly self-organise then you may just get astonishing results and the team will move a lot faster.

Maybe we should tell the taxi rank operators in Las Vegas, I’m not sure however that the Valets would be pleased to be losing their one dollar tip, but I can guarantee that the customers and drivers would be over the moon with joy.

I originally wrote this article as a blog following some work I had done with Lyssa Adkins in a coaching circle and then putting this into practice with a new team that I was working with.  Having reviewed it I decided that I would seek publication on the Scrum Alliance website and they kindly obliged.

This article is summarised as follows:

“One of the best ways to ensure that a team grows to be high performing is to get them off to the right start.   Read on to learn two team start-up activities that focus on process and help ensure everyone is on the same page from the beginning.”

Find the full article here

http://www.scrumalliance.org/articles/184-the-quest-for-high-performance

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.