Hi guys, thank you for sticking around to the end tonight. I promise I won’t go over time.

It’s been an awesome evening listening to everyone speak. I feel lucky to be here. So thank you. Thank you Youhanna for organising tonight.

I think we need a golf clap…

For those of you who don’t know me. Hi, I’m Kahne.

I’ve been with Readify for about 10 months. I generally do things with C#, JavaScript, stuff on HTTP, and I tend to join data.

I’m also a musician and an artist. I play violin in orchestras. I paint pictures and sell them.

My point is, I like being creative and I reckon everyone else here does too.

I think software development is really similar to painting and playing the violin. Especially when it comes to making something new and collaborating.

A few weeks ago Youhanna asked me if I’d like to help out by doing a talk at bar camp. At the time I was grappling with a personal / professional issue around Processes and Rules.

I dislike them.

My catch cry at the time was…

“Great innovation is the result of breaking the rules and not following processes.”

You know, like evolution, like unexpected mutation? I love that.

At the time I was asking questions like…

  • “How do I remain creative and divergent in an industry that is process driven?”
  • “How do I work faster and smarter?”
  • “When is it OK for me to fail.”
  • “When is it OK for me to break the rules?”

I tend to sit in slow meetings and think about stuff like that.

One of the things I find most interesting about being a consultant is that more often than not, our clients are searching for solutions rather than failures.

I mean, to some extent failure is not an option.

In the minds of our clients I imagine it works like this…

“Dear Readify, We’ve got this very important show stopping idea we need your help with. We do have an in house tech team who are on the job but I think this one needs more juice. Can you please bring a crew, figure out what we need quickly, and write some code for success”.

What i sense they are asking for is “change”. perhaps they need the sort of change that comes from an independent perspective.

This expectation presents me with a challenge.

  1. How do I bring change to a well established organisation that can’t support change itself?
  2. Change involves risk. How do I allow for that risk? How to allow for failure?

In my search for an answer to these questions I’ve found some solace in the idea of a “Social Contract”.

I’ll come back to that in a minute.

Grace Hopper had an interesting perspective on this.

She was a powerful women in technology.

One of those early pioneers back in the 40’s who popularised the idea of machine independent languages. She worked on relics like the Harvard Mark 1. She spoke about software with a passion. She coined the term “bug”.

She felt that one of the most dangerous phrases in the English language was:

“We’ve always done it this way.”

How interesting…. “We’ve always done it this ways”.

I imagine she was highlighting a certain attitude towards innovation.

I like it. I sort of agree with her. For me it implies that change and creativity is bold and necessary. It makes me think that well worn processes and rules are something of which I should be a little wary.

In my head, whenever someone says “Process” I soften that word by thinking that what they really mean is something like… “Best Current Strategy”.

Here’s a recent example. Last week I found myself saying this:

“Hi Adam, did you know that our BEST CURRENT STRATEGY is to ensure that all Pull Requests be approved by a fellow member on the team?”

I honestly think that sounds a hole lot better than…

“Hi Adam, did you know that our PROCESS is to ensure that all Pull Requests be approved by a fellow member on the team?”

I’ve see people cringe when they are told they are not “following the process”. Even worse, I’ve seen people switch off after being told they must “follow the process”.

All this has helped me realise that processes can be seen in both a good and a bad light. I should try not to hate on them all the time. especially when working in a big team.

I’d also like to add. I really love working in big teams. I love working with smart people. I love working with people!

I’ve started to understand that making progress doesn’t just happen in the background whilst creativity is allowed to take off.

I’ve started to realise that forming reasonable agreements with colleagues is really really hard.

I’ve had to come to terms with the fact that working in group naturally tends towards the formalisation of rules. Often it’s about setting broad expectations.

I would normally run a mile from this sort of thing. I sense it stifles creativity and innovation.

I mean, a basic example of a team wide rule that I find challenging on a daily basis is this:

“You should all be at work by 9am.”

I question simple rules like that. I mean, what if some of us find our flow at midnight? Do we “not” want people like that on our team?

This sort of thing is a real challenge for me.

It’s ridiculous. I even worry about people out there who have something to offer who don’t fit the mold, who get left behind.

I’m convinced that good processes accommodate all types of people; people with kids, people with disabilities, people with kids who have disabilities, creative people, women, creative women with kids who have disabilities, old people, immigrants, non english speakers, and so on.

The more the merrier!

As in, the more diversity in a team, the better their solutions will be.

Processes sometimes make that difficult. And yet at the same time I also realise that a complete lack of process is equally stifling.

Here’s an example of a rule that I actually “like”.

Test Driven Development. TDD.

I’m actually a blind fool hardy TDD fan boy. TDD is alive and well in my book. I love it but it often leads me to a conundrum. I regularly find myself in between a rock and a hard place on this.

Is it better to follow best practices and industry standards or is it sometimes ok to roll out my cow boy boots and cut to the chase with something fresh and random?

i see fresh random cow boy style success stories every day. which surprises me.

“I’ve actually been rabbiting on about this stuff for the past few months with many of you. i wanted to quickly take this opportunity to thank you guys for helping me with all of this. ive learnt a lot.”

Here’s a question.

What do the words “Social Contract” mean?

Without getting bogged down by definitions here’s what Rousseau had to say on the topic:

“A Social Contract is an implicit agreement among the members of a society to cooperate by sacrificing individual freedoms for state protection.”

I’m not sure how relevant that is to agile software development but i think it’s still interesting. its background.

Here’s what I’ve come up with:

  1. Individuals form agreements. Teams for Social Contracts. Social Contacts are setup to scale. Social Contracts help people work together towards a common goal. It could be an agile methodology like Scrum, or a techolonogy like Entity framework or a language like JavaScript. at the end of the day, it’s an agreement.
  2. A social contact is something people create and defend for themselves. It’s negotiated and agile. It’s built on trust.
  3. A social contact is mature. It often contains hidden meaning and value beyond the obvious, which can make them difficult to ignore or reject.

I’ve got a famous example of how a social contract was once formed in a lab, in the 60’s, by a scientist name Gordon Stephenson.

here’s how it goes.

Stephenson started by putting five monkeys in a room.

In the middle of the room he positioned a ladder. At the top of the ladder is placed some bananas.

Now please bare in mind this experiment is slightly macabre, but I hope you find it interesting from a group dynamics perspective.

With time, one of the monkeys took the bold step of climbing up the ladder in search of those bananas. Perhaps she was a leader. Perhaps she was curious.

When she made it half way up the ladder Stephenson stepped into action by scolded her with a fire hose of cold water. She scurried away.

Stephenson didnt stop there. He went on to scold the other four calm monkeys with the same fire house of cold water.

All in all it was a bad experience for the group.

After some waiting a different monkey tried the same game. This monkey was persistent.

The evidence had been clear. There was no change in the room, and yet she decided to try her luck and get those bananas.

She attempted to climb the ladder and again she was met with the same fate. And just like earlier, everyone else in the room received the same cold treatment.

On the 3rd attempt things changed.

An optimistic monkey tried her luck, but before she could get a foothold on the ladder, the other four tore her away from the ladder and scolder her themselves.

It was at this point Stephenson intervened.

He swapped out one of the monkeys for a new monkey.

A naive monkey.

As you would expect our new friend saw the bananas and on queue made her way straight for the ladder. Before she could get onto the first rung the four in the room had pulled her away and scolded her.

Stephenson swapped out another monkey.

We now have three monkeys who have seen the fire hose and experienced the cold water. The other two naive monkeys are unaware.

Again this 2nd naive monkey attempts to climb the ladder and again the other four scold her. Even the first naive monkey, who had arrived only moment ago, joins in. Why? Perhaps she was confused. Perhaps she trusted in her new slightly weird aggressive friends and followed in their footsteps.

Perhaps she understood that they were trying to protect her.

The experiment continues.

Stephenson carries out the same scenario another three times.

Now all five of the original monkeys are gone.

And so too is Stephenson. He’s packed up his fire hose and gone home.

As you would expect, the final naive monkey goes for the ladder and the group pull her away.

And this is where the experiment ends. But it leaves me with a question.l

I can imagine asking those monkeys a question.

“Why are you scolding anyone who attempts to go for those bananas?”

I guess their response would be something that would upset grace hopper immensely.

Perhaps they would say,

“Well. im not exactly sure. i guess its because we’ve always done it that way.”.

What I find most interesting about this experiment is that it highlights how naivety, curiosity, hope, protection and fear play a role in forming social contracts.

It’s made me realise that bringing change to a group is hard. Its hard when you don’t understand why the rules exist.

It’s made me realise that defending processes whilst also allowing for failure takes skill.

It’s made me realise that rules and processes are more often than not there to protect me.

Let me try to recap by focusing on this puzzling term “social contract”.

Here’s my stab at define it in an agile software development context.

“I think a social contract is a “best current strategy”, or agreement, or rule, formed by a team, that celebrates diversity and promotes safety.”

If that’s too vague. Try this.

When you want to say…

“Hi Adam, I really need your agreement on how we approve pull requests.”

Say this instead.

“Hi guys, let’s catch up and see if we can form a social contract on how we approve pull requests.”

I’ve seen it work.

Thanks for listening to me speak tonight. As you can see I’m still exploring many of these ideas.

I’d like to know.

  • Have you been to a gig recently and found rules and processes that you felt could be improved?
  • Did you want to change them?
  • Did you try?
  • How did you prepare?
  • Did you succeed? And if you did, what would you recommend?