Experimenting at the FT
By Luke Bellamy
For years I have attended management meetings and training sessions, where passionate presenters had shared their findings and learnings from researching and listening to thought leaders across the world. The one thing that often rang true for me was that after hearing many of these great ideas, no one actually did anything about them. When looking round the room or listening to colleagues afterwards I often found that people resented being presented with these ideas in the first place. An attitude of ‘oh here he goes again with her new age nonsense’ would descend on the room, with few questions asked at the end and little to no take up.
After watching the same scenario play out across multiple organisations and multiple projects I began working at the FT. Which, in my humble opinion, is an organisation which unfairly suffers from a perception of being a bit old school where it is in fact supportive of experimentation and allows teams to find the best way for them to work (we do have a broad framework we all work within but day to day is left to each team, more info here https://roles.ft.com/)
Given this positive attitude towards change and having been frustrated previously in my career I finally decided ‘Sod it, I’m going to try and do all of them’ and so began my journey of trying to actually put some of these ideas to the test. Essentially I read as many books as I could, listened to the podcasts, watched the Ted talks, acted on concepts that my peers have introduced me to and (hopefully successfully) implemented them within the teams and programmes that I work in, then reviewed and wrote about it here. I will try and take a few ideas from each author that I think are valuable and relevant. Then myself or one of my peers will be writing about them in a sort of series on experimenting here in FT Enterprise Services or the rest of Tech. So far I will be looking to try and implement ideas from the following thought leaders:-
Sam Coniff Allende’s ‘Be more pirate’
Experiments to try
‘The Pirate Code’
‘Constructive rule breaking’
The first one I have written about, and quite possibly my favourite amongst them all. Mr Allende has written a great book on how we can harness some of the lessons from the ‘Golden age of piracy’ and use them in the modern world. It’s sort of a lesson on positive and creative rebellion with some great pirate facts. The ‘Pirate code’ is essentially a set of rules written and agreed by the group or team. ‘Constructive rule breaking’ is the idea that we should all look to break ridiculous rules, the caveat to prevent us falling into absolute anarchy being that we should only do this if we have a better alternative. My interpretation of this is also that if you don’t have a better idea of how to do things don’t complain, be proactive and spend that time coming up with something better instead.
Dan Pink’s ‘Drive’
https://www.danpink.com/books/drive/
Experiments to try
- ‘whose purpose is it anyway’
- ‘autonomy audit’
These are all covered in his ‘Drive’. Dan Pink talks about 3 key components to motivate your staff. These are ‘Autonomy’, ‘Mastery’ and ‘Purpose’. Now mastery is covered by our internal and external training plus the FT’s very generous 10% learning time for engineers, so I won’t be trying to do anything in this space. However purpose and autonomy are areas where I have chosen to focus. The autonomy audit is a series of questions designed to help you assess the autonomy your staff feel that they have and to then help you measure and improve it. ‘Whose purpose is it anyway’ is an exercise that will try and help you understand if your department aims line up with what your staff actually think they are.
David Marquet’s ‘Turn the ship around’
Experiments
‘Organisations Genetic code for control’
Personally I found this absolutely fascinating and its had a huge influence on me personally. The youtube video gives a brilliant overview but it really is nothing compared to the book. As a brief summary David Marquet was a submarine captain in the US Navy who gave no orders and created the best run ship ever in US Navy history. One day I might be able to enact all of his ideas. The genetic code for control is all about helping push decisions lower down the management chain to staff. The aim being to provide more autonomy, engagement, speed and all that good stuff.
Jake Knapp’s ‘Sprint’
https://www.thesprintbook.com/
Experiments to try
‘how might we’
‘5 day Sprint’
Some really interesting ideas in here around how to test new ideas in just 5 days, born out of the authors time with Google Ventures. I am really keen to try and run one of these sprints at the FT, I just need to find a suitable project for it. The other thing that I have taken from this book is a group note-taking technique that Jake Knapp credits Proctor and Gamble with inventing called ‘How might we’. which is a technique to organise group notes from key meetings and prioritise them for an entire team.
I am hoping that this series is informative and gets you interested in trying some of these things for yourself, and if you have any further ideas for experiments please let me know in the comments and I will try and implement as many of them as I can. The first experiment will be Sam Conniff Allende’s Pirate Code, enjoy.
The Pirate Code
Testing the ideas of Sam Connif Allende by a Scrum Master
January 2019
First on the testing block was Sam Conniff Allende’s pirate code from his recent book ‘Be more pirate’. I highly recommend it: in addition to plenty of great ideas it also has a huge amount of interesting details about pirates.
So far I have run this workshop with a single team and plan to do it with a second team shortly. The background concept is that during the golden age of pirates (1650–1730 for those interested) each pirate ship was governed by an agreed set of rules or a ‘code’. This code was defined and agreed by the entire crew who then promptly swore to abide by it, often done by reciting astride a cannon, or swearing on crossed cutlasses. Should your office lack these particular items I would recommend that you hightail down to your nearest maritime museum for authenticity (failing this, simply vocally agreeing should suffice). This pirate ship code would cover stealing from crew mates, how much compensation you got for losing a limb, how much everyone was paid and even what days the on ship band got to have off (amazingly that was a thing!)
I took the central concept of this to be that those having to abide by the rules should have a say in writing them, and though we naturally have company rules of conduct (and thank God that we do) these are high level and rarely if ever cover the minutiae of what your team does and how you operate on a day-to-day level. By having a team code it allows you to develop simple straightforward rules for how the team will engage and work together, this could be as simple as turning up on time to meetings, deploying changes to production, how comms are managed, feedback, or my personal favourite, no phones open or on the table in meetings. The key point is that the code can be made up of whatever the team chooses so that it is specific and relevant to them. Personally I find this particularly useful for new staff who will be unaware of the specific ingrained and sometimes outright mysterious ways of working which long time colleagues and teams often develop.
So how did I go about this, Sam does provide some ideas in his book, I personally found his ‘codes’ too long for what I wanted to achieve and arguably designed to be used for a whole organisation and its mission rather than just a team. It was my hope that we would get very specific and it would be around things that the team deals with every single day.
It took just over an hour for us to write the code together and I did in in lieu of our normal team retrospective. I used a similar format to lean coffee to guide the team (http://agilecoffee.com/leancoffee/ I honestly recommend doing this within your organisations or programmes if you don’t already) with a couple of minor changes. Essentially you will need a pack of post-its for each team member, different coloured pens, a white board and marker. I took the team through what I wanted to achieve, gave them a couple of interesting facts about pirates (who would have known that there is no record of the infamous and ferocious pirate Edward Teach aka Black Beard actually ever killing anyone, now that’s a great example of a successful PR campaign). The aim was to have between 5–10 items on our code by the time we were done. I set up a simple kanban board on the meeting room wall (to do, in progress, done). I then asked the team to spend the next 10 minutes (time-boxed naturally) to write down on post it notes what they would want to be part of our code.
I grouped similar ones together and we discussed each one providing additional details, clarification or context as required. We used a dot voting system (3 dots per team member) to prioritise the ideas that the group favoured the most. The most popular was then moved to in progress column on our board and we began writing the first of our team codes on the whiteboard. Our team was a mixture of very senior engineers and very junior engineers who has joined us through the makers academy (see some of their stories here *) — due to this the most important item that the team wanted was some basic rules around how we would provide feedback to help the team learn and develop. After numerous changes, scrubbing out, re-writing, removal of the word criticism for something more positive and alterations to sentence structure (2 of the juniors were teachers in another life so correct grammar was key), by the end of the hour the team had agreed on the below ‘pirate code’ for our team:-
1. Reviewer to provide one success and one improvement on each ticket/story/Pull Request review
This was probably the hardest of them all to agree on and was the item that most people had strong a opinion about.
2. All effort will be made to pair/mob on stories
We wanted to prevent our juniors from working in isolation as much as possible while still giving them the option to work individually. We did not want to give a mandate that work could only be done while in pairs or mobs.
3. Have respect for each others’ time
No one likes people being late and sitting around waiting for them, but we wanted this part of the code to be broader than just ‘don’t be late for meetings’ . We made this point to cover ‘time’ generally so for example we should not keep a meeting going for the full allotted ‘just because we have the room booked’. If we finished early we now wrap up and get back to coding. In addition we wouldn’t hold meetings that we didn’t feel that we needed, yup, we even skipped a planning session once!
4. Always ask for help. Say early and often if stuck
We often talk about the need to fail fast and fail often, however in my experience people (and I include myself in this) are not always great at admitting when they are struggling and or failing. What’s more society isn’t always that supportive of this approach (though it doesn’t seem to have done Chris Grayling any harm). We wanted to restate at the team level that its ok to admit that you are having a hard time and that you should be able to lean on your colleagues for help without judgement.
5. We use and protect our 10% learning time
Within Tech at the FT we are enormously privileged to have 10% of each sprint set aside for learning and development. Sadly we found that team members were not always actually using this. We wanted to prioritise our team members’ development so we wrote this as our fifth item of our code.
6. Praise is public criticism is private
Always good advice but with more and more of us using slack as our primary form of office communication, comments and discussions reach a far broader audience than they perhaps would have in the past. Though it’s a fantastic tool, I do often find that some slack channels can be the equivalent of cc’ing everyone’s boss into an email, and no one likes that.
Now that we had our pirate code what next? Well, firstly the team agreed to work to this code and hold each other to it. This was key for me as it allowed more junior members of the team a legitimate reference point which they could draw on if required: this came in particularly useful when it came to getting feedback and ending meetings when our aims had been satisfied.
In the future I would be keen to introduce some kind of minor punishment for breaking the code (probably not pistols at dawn, more along the lines of buy fruit for the team, make everyone tea for a week etc) but wanted to start off gently while we all got the hang of it. Since this session, I have published our code on our team slack channel and hung it up in our area of the office. My philosophy being that if it isn’t visible it becomes something that people can forget and ignore.
So how did it go? Personally I found it very useful, it allowed us to really get down into specifics about how we want things to work in the team and led us to some very useful changes. For example, in order to satisfy items 1 and 2 we now have time set aside each day for mob programming, this in turn allows the senior engineers to provide far more effective and specific feedback to the juniors and help them develop quicker, it has also had the additional benefit of increasing the team collaboration and the amount of time the team spends directly communicating with each other face to face. To comply with item 3 we have also moved all of our meetings to the morning so that the entire afternoon is always free and so that the team are not interrupted.
I will be trying to introduce a few other of Sam Connif Allende’s ideas into my teams — ‘Constructive rule breaking’ being my favourite. I would heartily recommend trying this with your team or programmes, I will be doing this exercise with more of the teams I work with in 2019.
Now to finish here are some terrible/awesome pirate jokes.
Q: Why are all pirate films rated ARRRRRRRRR
A: Because of all the booty!!!
Q: Why don’t pirates shower before they walk the plank?
A: Because they’ll just wash up on shore later.
Q: Why is pirating so addictive?
A: They say once ye lose yer first hand, ye get hooked!
*all images from Google search
