On my current project we have decided to appease my sensibilities and have called these Cross Functional Requirements to better express what they truly represent – requirements which cross all the functions we are building. So far the wording works – but we have only finished the 2nd week of inception.

The problem is that they see the order that stories should be developed in should mirror the process flow of the tasks that the customer needs to take; after all, you can’t buy an item without choosing what you want to buy and you can’t buy anything before you login. This might also be due to the stories revolving around the tasks the user needs to undertake instead of the goals they are trying to achieve.

Now,  if I was to build a classic shop-on-line website, the first story that I would start with would be to implement a page which accepts payment information and a Buy Now button in the middle of the page. What is the customer going to buy? The same product that every other customer will buy. Now, this does not seem to be that fantastic for the user – they don’t even have a choice in what they are buying, but this is actually the best place to start because it is not the As a Customer I want to buy a book So that I can learn new stuff story that we are implementing; it is the As a Business Stakeholder I want customers to buy my products So that I can make a living story. By defining our stories based on goals, and ordering the development based on what is more valuable, we can launch our site with only one story complete and still make money.

Now, lets go back to the beloved login story. One thing that I hate is a website which puts up a high barrier-to-entry before I can buy a product. At a real-life store, they don’t make me fill in a form to say who I am before I can buy my Big Mac meal; there is no real-world equivalent to the login functionality. What is the real reason that I as a customer needs to login? Where is the value? What is their goal? The next story in this area that you could play would be As a Customer I want to view my purchse order in an email So that I can keep a record of the payment. This story could just involve a text field where the user enters their email address if they wish to receive the email receipt (remember, back in the day, receipts from over-the-phone sales would be sent in the post). Again, we can go live with this and we are still not requiring the customer to login.

The final goal that summaries the customers experience is that As a customer I would like the computer to do some work and remember their details So next time I make a purchase, I only need to place items in the basket and checkout.  All this requires is the customers email address (a perfect URN by the way – why would you even think about having usernames???) and a password. Importantly, however, the gathering of this information does not need to occur before they purchase their items! It can happen at the end of the transaction, thereby allowing the customer to complete their goal (purchasing their items) without hinderence. 

The customer’s goals are now met, and the business stakeholder’s goals were met in the very first story, it is only the marketers’ goal of wanting to capture information about the customers on the site which has not been met. Usually marketting departments ask that the customers complete a 4 page registration form, in order for customers to register (As a marketer I want to know information about our customers So that I can target our features to meet their needs). But, what value or incentive is there for the customer to fill in this information? To appease both our market departments, and our customers, however, we could incentivise the customers by rewarding bonus points which go towards their next purchase for completing their registration form. But also importantly, this does not stop the customer from spending money on your site.

So, next time you go to add a login box on your site, think about what the customers true benefits are.

Firstly, if you don’t achieve the target then you feel bad, and feel really pressured the next iteration as now the project is running late. This tends to effect junior/inexperienced/graduate developers more than their experienced colleagues; they feel the pressure and so they work late to finish stories or (as I have once witnessed) coming in over a weekend to make up some ground. The real problem with applying this pressure arbitrarily is that most teams do not do root-cause analysis to find out why you didn’t achieve said target and work out what is slowing the team down/how they can go faster*. 

Secondly, if you do acheive the target, you generally do not increase the target for the next iteration which means that there is no chance for an s-shaped curve on the burn up graph (ie you don’t have the opportunity to go faster); and

Thirdly, when you achieve the target for the iteration, generally the next lot of stories are not ready, so you don’t have anything to work on and you tend to waste days. It also means that you are more likely to stall finishing the last stories (gas expands to fit the size of the room; developers expand the time it takes to complete a story to fit the time they have available)

Lean and KanBan offer an alternative to this approach: the backlog. Essentially, iterations are demarkations in time to allow you to reflect on your processes (yes, I know that in KanBan there are no iterations, and this reflection happens on an on going basis). To know what work needs to be developed for a day is all about prioritizing the top X stories (eg top 3 stories) in the backlog. That way, there are always X number of stories that have been analyzed and are ready to develop, the stories in development are the most valued stories (whether the value is to the business or to de-risk the project) and there is no bad pressure because you didn’t achieve what you set out to achieve. The only question that the team needs to be constantly asking and answering is:

“What can we do to make us go faster?”

* A retrospective as I detailed here may help in this case.

What are the concerns around pairing?

• working with an argumentative pair – someone who wants to argue with you all the time, and disagrees with any approach you come up with
• keyboard hogs – the other person wants to snatch the keyboard away from me all the time
• unequal domain knowledge – one person knows everything, one person knows nothing so it is frustrating for the know-all to keep explaining everything all the time, and when they don’t the person who knows ‘nothing’ just tunes out.
• differing styles
• adds to the overhead – eg computer setup, time to bring someone up to speed on what is happening when you swap pairs frequently
• I don’t have time to check my emails
• there is no concept of ‘my computer’
• you can’t get into ‘the zone’ when pairing, like you can when you are working by yourself because you always are interacting with another person
• too much time rotating pairs
• physical environment  - room to work

Interestingly the flight deck of large commercial planes, like the Boeing 747 is intended to be flown by 2 people and it works best when you have one person checking the other, or both willing to participate. “It’s .. clear that when you have two people operating the plane cooperatively, you will have a safer operation than if you have a single pilot flying he plane and another person who is simply there to take over if the pilot is incapacitated”. Apparently, and surprisingly, most crashes (of the Korean Airlines) occurred when the captain was piloting the plane (someone who has many hours of experience), as opposed to the co-pilot (who typically does not have as much experience). This is because if the senior captain sees something wrong that the co-pilot is doing, then he will issue a command to the co-pilot to correct the situation. However, if the co-pilot sees something wrong he will not issue a command to his superior officer as a command, and will either hint at or suggest a correction. It is clear that clear communication is the essential ingredient to correcting otherwise fatal sequence of events*.

Unfortunately for the crew and passengers aboard the fatal Korean Airline planes, Korea has a culture of high respect for authority expressed in both their customs and their language. So, the cultural forces behind the Korean co-pilots makes it nearly impossible for them to speak up and correct the captain, even when they know that the captain is in the wrong (read the book – the black box recordings are amazing). What turned Korean Airlines around? They realised that the problem was not to do with the experience of their pilots or the maintenance of the planes, but that it was this cultural force which was at fault. They hired some help, enforced English (which does not have an inbuilt respect for authority) as the only language which could be used in the company, and as a result helped the co-pilots have the confidence to speak up when there was a problem.

Now, don’t get me wrong – I find airline investigation to be truly fascinating (have you ever read about the lead up to the flight on the Challenger? It wasn’t just the O-rings fault). But the most interesting take-home for me was how the cockpit experience parallels pair programming.

Pair programming is intended for 2 people, and works best when you have one person checking the other, or both willing to participate. It is clear that when you have two people working cooperatively you will have a safer (ie higher quality) software than if you have a single developer developing the work and another person who is simply there to take over. Pair programming works well when you have the less experienced developer at the keyboard flying the development, and the more experienced developer course correcting when the co-pilot makes a mistake. And just like the cultural forces that caused so many disasters for Korean Airline, the cultural forces of the development community leads to many pair programming sessions, crash-and-burning.

There are many people out there who only experience the forces that lead up to pair-programming disaster stories. It can be very dismissive of us to say that these people just don’t get it (and never will), or that they haven’t tried hard enough, but Gladwell has lead me to start believing that there is a cultural bias towards single programming. Take universities for example – you can be expelled for working collaboratively; individual results count, team work in assignments is often discouraged.

Korean Airlines managed to change their practices despite of their culture; I am confident that anyone who is willing to can change their practices to have a successful pair programming flight. The first step as always, is to acknowledge the problem.

* Typically, plane crashes occur as a result of seven trivial malfunctions, which, individually is no problem but the combination of all those errors leads to disaster. Typically crashes occur when the weather is poor, when the plane is running late and when the pilot has been awake for more than 12 hours. 44% of the time two pilots have never flown together before. (page 184 Outliers Gladwell, M)

However, in practice they can easily degrade to daily habits, where each person talks, no one listens and nothing is accomplished. Observable signs that this is happening in your team:

• there is low energy – people walk away nonchalantly
• the developers say “I worked on xyz story. Today I will work on xyz story. No Blockers” (Yes I know – I can see the story board and we were all there when you picked it up)
• their pairs say “yeah, what he said”
• the QAs say “I tested stuff yesterday, I will test stuff today”
• after the meeting, a conversation ensues along the lines of “Oh, the builld’s not running. Hey everyone, I have just spent 20 mins looking at it and there’s something really wrong with the box as it doesn’t even respond to pings.” “Yes, I know. I have brought down the network for the moment to install the latest patch. I said so in the standup this morning.” 

Needless to say, the standup is no longer a useful forum. The major problem with this style is that people tune out because no one is saying anything of value. They are usually repeating common knowledge (by stating on what they were working on, when the whole team can see that by the story wall).

At my current project, we faced a similar problem*. So, I changed the rules of our stand up.

The new format

1. No one is to say anything in the format What I Did Yesterday; What I Will Do Today; Any Blockers. This format is scrapped, binned. 
2. Instead, I only want you to tell the team what you think is valuable to them; what did you do or find yesterday that is of value sharing with the team; what do you know, that we need to know.
3. The only person allowed to be speak will be the person holding the speaking token.
4. If something has just been said that you feel you should to add to, answer or have question, all you need to do is signal for the token (hand gestures along the lines of “Pick me Pick me” will be rewarded). 
5. If someone requests the token, the token-holder finishes the sentence and passes the token along to the requester.
6. Every member has a red card. If a discussion starts, and you are not interested in it, you raise your card. Two cards (dependent on the size of the team) and the conversation is immediately (mid-sentence) stopped and is taken offline.
7. When you have finished sharing, you throw the speaking token to someone who is not to your immediate left or right. 
8. If you don’t feel you have anything of value to add, you can pass the token onto another person.
9. The standup does not remove the need for us to talk to each other throughout the day.

The Result

Our meetings are quite high energy, high paced and highly informative. Everyone adds value and we all walk away from the meeting energised and ready for action. Our meetings allow for useful discussions to start, but also allows for a mechanism to control them if they are getting out of hand. If suddenly you find the same repeat offender does not have anything of value to add, that is feedback; perhaps the person is a little shy, perhaps they have been slacking off – either way, if they don’t feel like they can say anything of value now, what were they saying in the old method. Blockers are still talked about, as they usually have value. Also, having a cute throwable soft toy helps.

* Actually, before we faced this problem, we had the problem where no one would start talking. The introduction of a speaking token  solved that problem.

• What We Did Well
• What We Did Less Well and
• What’s Puzzling Us

I find with these retrospectives, the same issues seem to crop up, with actions that don’t get resolved and nothing really improves for the next iteration.

I think the main reason we should do iteration-based retrospectives is to focus on what will make us go faster next iteration, and what are our current impedances. The best retrospective ‘game’ I have seen to support this is the hot air balloon/speed boat** analogy. This means that issues should not get raised which do not directly impact how fast we could potentially go. I have tried this exercise before, and have found that it was too broad a scope, and so not many new ideas came out***.

Yesterday, I tried a variant on the hot air balloon exercise, with really good results.

The New Format

1. Place the stories of the iteration (stories that were completed, in QA, in development and ones not started) on a wall in a pseudo timeline
2. Group any ‘bug’ cards around the stories to which they belonged (these ‘bugs’ were issues that the QAs found which meant that a story could not be QA signed off and therefore needed more dev effort).
3. Describe the story on the wall (similar to the timeline game), to get everyone back into the mindset of when they were working on the stories. It is also useful to state the estimate for the story and the actual time it took to deliver.
4. Give the group time to write stickies for each story, with the focus on why they thought the story took longer to complete or was faster than expected. The idea is to explain the hot air balloon metaphor, and get them to focus their thoughts for each particular story. Essentially, I said to them “What was the magic sauce that made this story really quick and easy to do; and what was the crud that got in the way?”
5. Walk through each sticky note, identify themes, discuss and record any action items.

The Result

The issues that we discussed highlighted problems that were not caught doing the usual style. The actions from the issues discussed directly corresponded with ways to improve the velocity of the team.

By turning the focus onto each story lifted the pressure of having to think generally out of the box, and focussed the teams effort to think about what was really the problem. This highlighted not only external problems, eg too many meetings, but also lead to an examination of the code base, eg It took me too long to add that line to the screen so I think that area of code needs a clean up.

All in all, this is an exercise that I will repeat.

** The narrative I give with the hot air balloon goes something along these lines. “The hot air balloon is like our velocity, it has the potential to go really high (fast) but the problem is two-fold. We have sandbags (impedances) which are currently actively slowing us down and we don’t have enough fire (which is trying to lift us up). So lets think about what in our project are our sandbags and what is our fire. What is slowing us down, and what could we do to go faster”. The speed boat has anchors in the water as impedances and an engine as fire.

***  Actually, I played this after weeks of the usual retrospectives defined above and most of the what we did well stickies were placed in the fire area, and the what we did less well were placed in the sand bags.

Surf’s Up was created differently to most animated films [1]. Traditionally, most movies are writen by a script writer, then handed to the actors who need to confine themselves within the lines of the script. In Surf’s Up however, the directors put a lot of focus on getting real genuine conversations from the actors. To aid this they did a few things.

First, the dialogue was recorded with all actors together in the booth; most animated films record the voices independently. Co-locating the actors meant that the reactions and interactions were genuine, not just something which had to be faked.

Also, the directors put alot of focus on letting the actors ad-lib their lines. While there was an overarching story they were telling, the specific details of the dialogue was left to the actors imagination. 

Now, I hope you can see where I am going.

Recording the dialog with all the actors together is much like co-locating your delivery team. This has various benefits:

• the team quickly build up a rapport and their chemistry can be seen (or heard) on screen;
• any changes to the script or subplots can be developed in-situ, and do not require dragging actors who have already recorded their parts back to the studio to fix the dialog for the new requirements (ie any changes to the requirements can easily be dealt with as the team is all together, working toward the goal simultaneously);
• it could be cheaper/faster to record (develop) with everyone in the one place as you do not need to keep repeating the setup for each new actor who comes to record their part (actually, I am just guessing on this one, but you can see where I’m going).

Letting the actors ad-lib their lines is analogous to getting developers to design their own code (hopefully through TDD/BDD/DDD). The architecture of the software is like the story they are telling, and the implementation details is like the dialogue in the script. By allowing the actors to improvise, the directors have allowed the actors to develop each character in a unique way, bringing their own personality to the foray. This meant that the actors were also responsible for steering the ship: an example is the cute, funny character of Arnold was apparently developed by Zooey Deschanel (who plays Lani) during one of the ad-lib sessions.  

Surf’s Up is a pretty cool movie, one which you can easily forget that you are actually watching animation. No doubt its success has something to do with the manner in which it was made.