The first sample chapter is going to get out of the printer today or tomorrow. This chapter is about requirements. The title is Extraordinary Requirements Quality. It is printed for my next talk at the Develop conference. I have worked a lot on the Games Industry in the past year. I have studied projects from the inside thanks to a major games publisher. I also have played games like never before in my life. Man, I could tell you some stuff about the experience of becoming a gamer when you are not 15 years old! Maybe in a next article…

At the Develop conference, in Brighton, on the 15^th July 2010, I’ll be talking about actions that can be taken by Studios (and in most cases Publishers) to win more projects. One of these moves is definitely to work on the requirements. This is why I have selected this chapter to be published on that occasion.

If you are interested in getting this sample chapter (64 pages), please get in touch with me. We only print 100 of it, so hurry up in case you wish to get one. The easiest is to leave a message here and I get an email immediately saying you did so. I’ll get in touch with you.

Oh by the way, the full set of Project Cycle Optimization principles will be comprehensively covered in the final book:

1. Mentality Shift
2. Skills Management
3. Extraordinary Requirements Quality
4. Team Goal Alignment
5. Communimatics
6. Improved Production Chain
7. Positive Rule Breaking

Most of the book is already written.

Personally, I have played more games during the recession than at any point in my life. A good game eases the economic misery and they are still fantastic value for money. I’ll be continuing my unwavering support of the UK’s creative industries. We pack a big punch for a small island – but we all know that!

Anyway, my point here is that the time has come for more efficiency, better projects, risk reduction, etc. But the Games industry is not precisely working like most other industries. It has strong specificities that make applying traditional recipes for software efficiency more difficult. It also has very strong structural reasons to have disturbed human dynamics such as the ones I talk about in other articles of this blog. Communication of clear information between people and between sub-teams is a permanent challenge. Managing expectation properly between Producers and Studios is always challenging. Cross-cultural communication is a daily reality with all its difficulties. Last but not least, the transition of the industry from Waterfall to Agile processes such as Scrum is not an easy move (it’s never been easy for any industry anyway).

To contribute my effort in support of the industry I will be speaking at the DEVELOP Conference in Brighton next month (13-15 July 2010) and taking out a stand to provide advice. I’d love to see you there. If you can’t make it just post a comment with your email on this blog and I’ll send you a copy of my talk on PowerPoint. http://www.develop-conference.com/

What Picasso was getting at here was that in order to innovate you have to know the processes and rules very well. In fact you don’t even want to know them but you want to live them, breathe by them, make them automatic/reflex.

In the software development arena (e.g. the Games industry) do we sometime suffer from not knowing the processes and rules well enough before breaking the rules? I would say so. In my experience, I have been confronted in numerous situations where projects were in danger of failing. When asked about the reasons for being in danger (completed over 50 projects), more often then not I find the following issues (list non-exhaustive):

• The process is not applied
• The code is not fully tested
• The communication points between business and technical team are loose
• The architecture is not described
• The iterations (assuming agile process) are ill defined

Most of the time, when I am looking for the reasons of these issues, I am finding answers such as: “Nobody really applies the process, why would we? We are better the way we do.”, or “No real time for testing by the book, let’s just apply common sense and save money”, or “We are agile, we don’t need documentation.” Ad infinitum.

Am I missing something here? Because to me this looks a lot like laziness hidden behind the ultimate excuse: creativity!

Let’s think about IT !

Why on earth am I worried about what I am signing off? After all, in almost all cases I even looked forward to get to that point. I did want to buy that expensive stuff that I will pay over 55 years. I did want to get that mobile connection so that I can be disturbed any time or indeed disturb anyone I want any time I want. I did want that life insurance that will protect me and my family. So what’s wrong? The answer is trust. I actually do not trust a single second that the other party will play a fair game. First of all the contracts I am signing are made of 4 to 10 pages of famous small prints. I am asked to sign when I have not read any of these lines. Should I want to do it, the person in front of me would find that outrageous. Should I decide to indeed read it, I would not even understand what I am signing anyway. And believe me, I am not someone giving up in front of words.

But why, are you asking, is he telling us about these signatures that we all know about anyway? I am because as a consultant in software project optimisation, I have been asked again and again how we can reconcile sign-offs and iterative process. This is most of the time the case in organisations coming from a strong waterfall process culture. Before answering that question, I’d like to analyse what it means in a software project to get these sign-offs.

Recently, we were consulting for a rather big public service which had troubles with their software delivery. Basically, they had reached a point where the business side of the projects almost refused to sign any kind of requirements document. They were saying that they did not understand the content well enough. So they were delaying sign-offs as far as they could and incidentally creating a mess in the IT department’s schedule. The business did not want to sign and the technical team refused to start before sign-off. Why? Because, they say, the business people can’t make their mind and always change their view of what is needed. “You can’t work with people like that.” In fact, I would say that this organisation had reached a kind of honesty point where everyone was recognising almost heart fully that the other side was a bunch of crooks. …But were they? Do not forget that they were all part of the same organisation!

My answer to that is of course connected to that dreadful signature that you need to put on that big fat un-understood document. The very reason why you have a need for a signature on a document is because you do not trust the other part for doing their job in the first place. If you do trust the other party, then this document is seen rather differently as a way to state what we both believe is what needs to be done. If things change in time, as we both trust each other, we will re-read that document and surely amend it as needed. That is what I do with trusted partners. Yes we have paperwork done but we all know that this is not what our deal is based on in reality. In fact, if you really try to describe in writing what a proper, honest, healthy deal is based on, you end-up with or a very light document describing in a few lines what the objectives are, or you end-up writing forever all the things you mean, you meant, you will probably mean and you surely would mean otherwise. It is mission impossible! That is why these law firms are making such a huge amount of money for writing a contract. And guess what? Even with these big fat contracts, the same law firms will make even more money in trial to explain the proper interpretation of that contract. It is hopeless! My view is that there is no need for building relationships on these bases. I would even say, it is the top level management responsibility to make sure that internal departments of the same organisation do not apply these hopeless rules to projects supposed to increase the business profitability. It is almost a crime to do so!

And here comes a better approach with the iterative software development processes. I will not explain in detail what this is about because it is almost common knowledge nowadays and it would take longer than this text to do so. In short, for those who have not boarded the train yet, iterative development is based on the idea that you will not wait for the final version of any specific step to do the next one. You will develop the software in small chunks. But mainly: you will deliver the software regularly from as soon as possible. As a result of these deliveries, you are building guess what? Indeed: trust! Where is the signature then? Oh sure you can maintain them if you wish. What about signing there for the piece of work we will deliver next week? Great, let me sign that and see you next week to make sure that I get what I have in mind. It is much more of a gentlemen handshake than a lawyer contract. If by any chance you do not get what you had in mind, you will make it known and make sure that you get it next week. And believe me; nobody in the IT department will be bothered by a change to do on a one week work.

Everywhere we have implemented such approach we have the business getting addicted to this delivery mode and the level of trust is rising like mad! If you want to have a better idea of the in depth reasons why this is happening and why the business if empowered again in front of IT, you can check on my previous article Iteration size and the tap water glass.

Let’s think about IT

In short, and I’ll come back to that, living in harmony with a different culture than yours is difficult and there are so many good reasons for that that you should not feel bad about it. At the same time, we have seen in the recent years enthusiasm for off-shore outsourcing. Depending on what country you are based in, the elected off-shore country is always one which is more or less speaking your language. I’ll take two examples: United Kingdom will outsource in India due to their English heritage. France will outsource in North Africa for the same reason. Of course, other parts of the world are heavily used, like Russia, Eastern Europe, China, etc. But anyway, for at least UK and France, I can say that common language is seen as the way to work together.

Now what happens? Every day, we hear more and more about disappointed companies regarding the success of their off-shore outsourcing. And most of the time, the complains are the same and turn about inability to understand each other, deliveries that have not much to do with expectations and in the end, some managers recognise they would be far happier if they could stop dealing with “this lot over there”. In a word: misunderstanding!

The point is: communication is not about using common words and common grammar. Culture is not about TV programmes or football results (another topic for a next article regarding off-shore and call-centres). Until we acknowledge the real complexity of culture, the real meaning of belonging to a people, the serious complexity of human communication we will end-up in misunderstanding. This misunderstanding can be very costly indeed when a company is injecting huge amount of money off-shore with the expectation to get things faster and better.

In “Beyond Culture”, Edward T. Hall, explains that whatever the domain, there is something universal in communication: the message received by a target is always composed of the message, history (previous communications), internal context (pre-programmed reactions from the receiver) and the external context. If the external and internal contexts are supposed to play an important part in the decoding of the information, we are in a “rich context”. If the message contains all the information needed for the decoding, then we say the context is “poor”. Of course we permanently adapt to the situation but there is one element we hardly adapt to: the culture and all the things that we are all supposed to know. The problem is that during a cross-cultural communication both sides of the channel will make the wrong assumptions by considering a common ground for this context. This is precisely how we end-up with reactions such as:

• “How could they convert what we said into this?”
• “It was quite obvious that we would not want that!”
• “We have to tell them everything like children!”
• And so on…

In fact, yes, when we are dealing with a different culture, just like children, we have to learn again the basics. So, I hear you say, what do we do?

First of all, we need to recognise that fact that whoever we are dealing with, as soon as they are from a different culture (and you do not have to go far from home to find that) there will be misunderstanding. It is the nature of the relationship we are creating in the first place. It will then become far easier to fail than be successful. Then we need to understand that being ISO or CMMI compliant will not solve that, it will just guarantee that the misunderstanding is following the agreed process! You will get high quality rubbish! Then we need to take action to tackle what the real problem is: a cross-cultural communication challenge.

I will not detail here all the steps you need to take to improve the communication in the context of an off-shore project bur I can mention a few:

• Produce less plain English documentation;
• Increase the use of modelling languages such as UML which convey the poorest context you can think of and therefore maximises your chances to share the same identical understanding;
• Agree on the framework/process you will use and incorporate in this process steps that will identify risks, potential misunderstandings and errors as soon as possible;
• Use a risk driven approach to your development;
• Use an iterative development cycle with short iterations (I mean short!);
• Increase the human to human relationship and do not trust that what you have sent in writing will happen fine. Follow-up, talk, meet and remain calm on both sides as everybody is probably trying his best;
• Run workshops on cross-cultural communication so that everyone understands the nature of the problem to come;
• Stop thinking you are going to change the other side. That will not happen!

In the end, in these times of globalisation, I believe it is futile to try to avoid these problems. Off-shore or not off-shore, companies are international and very often the off-shoring is in fact using another part of the same company. Belonging to the same company is a plus but not a guarantee to be understood. I strongly believe as I have experienced it myself, that working on the matter with the firm intention to remain intellectually honest and true is going to make a difference and drastically increase the likelihood of success in your projects!

Let’s think about IT!

Now, I am asking the question: if we, for our own personal interest, can’t figure out what the plan will be for Christmas, 6 weeks in advance, or where we’ll be sleeping in a trip 6 weeks inside the journey, I wonder why on earth we would be naturally interested (I mean genuinely, deeply, honestly) in knowing what the plan will be for our software in 6 or 12 months time. I am not challenging the relevance of the question in terms of business planning, budget management, sales perspectives. I am challenging it in human terms. The scale an individual is comfortable with has nothing to do with the scale some big projects are talking about.

One way to tackle that problem is definitely to manage the project iteratively. This has the immediate benefit to reduce the time scale to something people can naturally cope with. We all can have an objective in mind to achieve in the next 3 weeks. So, in terms of connecting with human’s behaviour, it does the job. Now, does it have other serious implications in terms of business benefits? Here comes my glass of tap water!…

This example is taken from “The Fith Discipline” by Peter M. Senge. The point of the chapter it is taken from is to be able to describe the root cause of problems rather than stick to the surface of the problem. So, here is the example: one is trying to fill a glass of water from the tap. This simple action is in fact rather complex and involves a real time reaction to the situation if one wants to get the glass filled right. We never think about it but that’s what we really do (the arrows mean “influences”):

Now that works fine because of the speed of the influence between each step. You get immediate change in the water flow when you move the faucet and you see immediately any change in the level of water in the glass. Now comes the interesting bit: what if we introduce a delay in the system? What if we had a 5 seconds delay between the move of the faucet and the flow of water? That would look like this:

Concretely, you are very likely to overfill the glass due to the lack of response from the system when you make an input! What I find interesting in that simple fact is that if you think of the system as a Software Development Project, then you get the following:

At that stage, if you are the sponsor of the project, your obsession becomes to remove the delay in the system. The longer the time between, in one hand, the injected money and effort and, in the other hand, the possibility to evaluate the result (perceived gap box), the bigger the error will be. This is what Peter Senge calls a reinforcing loop. Pragmatically, the consequence of this will be:

• More money injected due to the lack of response of the system. This is the equivalent of one opening the flow of water bigger because there is no response.
• Counterproductive actions due to the feeling of panic that target will not be met in time. Imagine that the delay is now 30 minutes when you are filling your glass, we would probably be hitting the faucet, swearing at the pipe, put the glass aside while we would look into this, even maybe start some unnecessary quick fixes, like opening other taps to fill the glass. We would certainly start thinking of reducing our objective and intend to fill the glass by 30% only. We might even call the plumber for enlarging the pipe to fix this problem once and for all when this is not the problem.

In the end, I think it is important to understand that an iterative development approach is not only beneficial to the development team in terms of respecting the human scale of projects but also very beneficial in terms of financial control. The more often you get a feedback for the effort put in the project, the less you will waste time and energy fixing the wrong problems on the project! So, let’s get the shortest possible iterations in our software development projects!

Let’s think about it!

Let’s start with the Zajonc experiment. Robert B. Zajonc (pronounced Zy-unce – like Science with a Z; born 1923) is a Polish-born American social psychologist who is known for his decades of work on a wide range of social and cognitive processes. In 1969, this fellow and his team have conducted a strange experiment with cockroaches. He found out that cockroaches ran faster down a runway to escape a light source if the runway was lined with an "audience" of onlooking fellow cockroaches (each in its own plexiglass cubicle). This work led to the theory that the mere presence of species mates elevates drive/arousal of the performer. Since then, plenty of other research teams have lead other experiments. In the end, a meta-analytic review has been conducted by Bond and Titus in 1983 of both published and unpublished works involving over 20,000 participants. I give you the overall conclusions:

• Yes, the presence of others has an impact;
• This impact is positive for simple tasks and negative for complex tasks.

Here comes my question: what is the impact of working in open-spaces for the software industry? Are we, like the cockroaches likely to perform better because of the others watching us or are we, like Bond and Titus found likely to perform less because of this situation? Clearly, we cannot consider software production as the result of a reflex, like running, eating or having sex (yes, studies have shown it works on sex as well!) Although requiring highly collaborative activities, software production requires a high level of concentration, thinking and lonely work. None of these can be done in an open space where:

• You can hear 5 colleagues phone conversations at any time;
• You can be interrupted by anyone seeing you and wishing to ask a question, share a coffee or simply say hello;
• You benefit from the never ending printing noise of the whole floor;
• Etc.

And anyway, you’ll notice the high number of workers using headphones to isolate themselves from the crowd. I have even personally put ostentatious headphones on my head, although not listening to anything, just to stop people from interacting with me.
In fact some research have demonstrated why we are doing that. The key fact is that when we are bombarded with attentional demands, our focus of attention shrinks (Geen 1976). Did we need a research to know that? Clearly, some companies (quite a lot in fact) should read a bit more about human interactions and behaviour. They might rethink their workplace strategy!

Let’s think about IT!