A recent talk I gave with my collegue Eben Halford at the BCS London Lean Kanban Day describing a recent STATIK workshop we conducted.

We explore the practical implementation of a STATIK (Systems Thinking Approach to Implementing Kanban) workshop and how we dig to uncover how teams work; what they do, why they do it, their customers’ dissatisfactions, and theirs. We examine the purpose of the system, and ultimately turn the treasures that we unearth into a kanban systems design.

Some while ago, while thinking of a quick and easy way to demonstrate the power of acceptance criteria, I devised this small activity that explains the concept. The activity is interactive and takes about 20 minutes to complete, including the discussion. All you need are some pens and paper and, for a little more dramatic effect, a flip chart — but that is not essential.

If you want to explain acceptance criteria, then this activity gets across the concept very well in a simple, straightforward, and powerful way. I have run this activity in the U.K. numerous times, as well as in Switzerland, and it has worked in both locations successfully.

Let me explain how to run the activity. If you want to simply yet powerfully demonstrate acceptance criteria, try it out for yourself.

First, let me start with some background. When I was at school, all of my classmates were always sketching outline drawings of houses on paper or in their exercise books. So I decided to use a simple house drawing to explain the concept of acceptance criteria. In the U.K., most houses are of a similar style, and I expect that the style I draw is one you can use in many locations. If you don’t feel this style will work for you, however, feel free to alter your house to a sketch of one that will work in your location.

I start the exercise by asking the group whether, when at school, they drew houses in their schoolbooks. When you pose this question people will generally nod their heads in agreement. Then simply say, “OK, take some paper and a pen and just sketch me out a house.” Most people will now start to draw their house; some people will ask questions about what the house should be like, but simply say, “Just draw me a house.”

While they are doing this, draw your own house on a piece of paper or a flip chart sheet, making sure that no one else can see it.

I draw my house like this:

When everyone has finished, walk around and see what they have drawn. No one will have drawn what you have done, so as you go around say things such as, “Nice house — but not what I wanted,” or “How very artistic — but unfortunately not the house that I wanted.” You can make this very lighthearted, but essentially reject all of the houses as not being the house you were looking for.

Once you have been around the room, tell everyone that you need them to write down what you are now about to say, and say the following:

• There is a door on the lower floor in the middle of the house.
• On each side of the door there is a window.
• On the upper floor, there are three windows evenly spaced across the house.
• The house has a pitched roof.
• There is a chimney.
• The house has a garage.
• The house has a fence around a garden.
• The fence has a gate.
• There is a path from the door of the house to the gate.
• The garden has a tree.

Now ask your group to draw the house again.

When they have finished, turn around your flip chart (I find the flip chart works well and there is an element of a magic trick when you turn it around and reveal your house), and then ask them whether their house looks like yours. You will find that they will all have drawn a house that’s very similar, and in some instances it will be almost exactly the same. Now you can go around the room and check the houses and, where they have met your acceptance criteria, you can say, “Yes, I can accept that house; that is what I wanted.” If someone has missed something, you can reject it and explain why. If people have drawn what you wanted but added to it, then discuss this as gold-plating of your requirement.

Sometimes before revealing my house, I throw in a reference to Derren Brown (TV magician, cold reader, and lots of other stuff), or throw in your own local magician who does similar things. I say, “Did I subliminally make you draw what I wanted? You do realize that I trained him.” And then, of course, add, “I’m only joking. Maybe I simply got what I wanted by giving you a set of acceptance criteria.”

We can now debrief on the activity. Explain that through using a set of ten specific bullet points and statements, I got exactly what I wanted. Ask whether you told them how to draw the house. The answer is no, so again restate, “I even got what I wanted without telling you how to do it.” You may find some people draw the tree or garage or chimney on the opposite side to you, so explain that you don’t actually care; in this instance what’s important is that you have them — it’s not important exactly where they are.

You can also go on to explain that when using acceptance criteria with user stories and in the context of software development, you can use tools to automate these acceptance criteria as tests. Therefore you build up an automated regression test pack that will tell you whenever you deviate from the requirements. State the fact that the acceptance criteria are your requirements, and they just happen to be requirements that you can use to test your software and then to automate your tests.

You can now explain how you used the acceptance criteria to verify that you got what you wanted.

Now move the debrief onto how you can use the acceptance criteria to scope your story. Pose this question: “I have given you my acceptance criteria and have asked you how much it is to build my house. You tell me £1 million and I say, ‘That is too much. I only have £900,000. What can I do to reduce the scope of the my house?’” The group will give you answers such as, “Remove the garage and the tree.” You can now ask the question, “What could I do to increase scope of my house?” You will get answers such as, “Build a double garage,” etc. You can also use this to discuss how you can change the scope of a story to take into account time. “How long it will take? I don’t have that much time. What can I do to get it earlier?”

You can now make the point that not only are acceptance criteria your requirements that can be used for tests, and not only can they control the scope of your story, but they can also control the behavior that you expect to see (such as whether the garage should be to the right of the house).

Finally, you can ask the group the general question about how they feel about this. Do they find it powerful? Most people are amazed and surprised by the simplicity and the power of acceptance criteria.

So that is how I run the activity. I have run this many times with many people and have always found it to work well.

Why don’t you give it a go, and let me know how you get on.

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.

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.