2017 was a transformative year for XTC. I can say it’s the year we definitively stepped up from “not quite dead” to “vibrant and engaged”. I can lay the credit on this to a couple of changes we made to the format at the start of 2017:

Reduce occurence from weekly to fortnightly

Ensure that there is a defined topic every meetup

These changes (plus some early visits from Kent Beck) helped focus the XTC community, and help recall past glories. However, we’re always looking to improve…

On Tuesday, 12th December 2017, XTC held a retrospective. Using a simple sad/mad/glad format, mixed in with beer and pizza, we produced the following:

We grouped all the stickies by themes, and proposed some actions for improvement in 2018.

Themes

Venue

XTC has been held at The City Pride since April 2016. These points were raised about this venue:

Only pizza available (sad)

Beer is a bit meh (sad)

Limited disabled access (sad)

“old man’s pub” (sad)

(not actually raised as a card, but we did discuss this in relation to diversity)

Pizza is gr8! (glad)

Quiet room (glad)

Topics

The topic of the next meetup is decided at the previous meetup. At some time during the meetup, an organiser will ask people to propose topics. After all the proposals have been collated, attendees will then vote on the proposals. The proposal with the most votes will become the topic of the next meetup, and the person who proposed the topic is expected to help run the session. These points were raised about topics:

Imperative absolutes (mad)

“How you should do things”

Always/never

The community drives and runs the topics (glad)

“Conversation” format (glad)

Different viewpoints! (glad)

Debate! (glad)

More people, topics, discussions (since 2016) (glad)

My take: don’t tell people what to do. Talk about what you’ve done, and what you’ve learned.

Format

The format was relatively undefined in 2017. Instructions to topic hosts were loosely “do whatever you want”. Facilitation was very light.

I don’t like structured discussion (sad)

Some sessions lacked a clear start and end and were worse for it (sad)

Ambiguity in facilitation (mad)

In depth discussion I can hear. (glad)

Variety of format (glad)

Open debate (glad)

Smaller groups means I can remember names (glad)

Opportunity for community?

XTC Clinic?

My take: general style of format OK, but we can tighted up on facilitation

Attendance

Attendance was one of the big success stories for 2017. Changing from weekly meetups in 2016 to fortnightly meetups in 2017 seemed to provide a sense of scarcity and urgency, and people really responded to the topics. Mid-way through the year we experimented with “old-style” events (no set topic). There was a definite drop-off in interest and sign-ups.

Not a very diverse crowd (sad)

Lack of diversity (sad)

Physical abilities

Neuro

Gender

Ethnicity

Way more attendance (glad)

We did discuss the “diversity” topic once. Happily, we did get a much more diverse attendance that night. However, on average the points raised reflect issues with the general attendance.

Other

We had trouble putting these points into other themes or categories:

Why didn’t I start coming again sooner? (written as a mad, but actually a glad)

Passion and enthusiasm of everyone (glad)

Coming to XTC again! (glad)

XTC is still going (glad)

Joe Schmetzer (glad)

Actions

Here are some changes we agreed to trail/experiment with in 2018:

Defined Host each Event

a.k.a Who’s going to be the “Joe” tonight?

We need to ensure that every event always has someone who understands the format, ensures that everything happens as it should, and can help facilitate talks, etc. It can’t be “Joe” every event 🙂

Playbook / Checklists

We want to make sure that things aren’t missed, and there’s some sort of predictability about the events. The playbook needs to consider at least the following:

Pre event:

Selecting a host

Working with the topic proposer to add an event description

Promoting the event on Meetup, Twitter (anywhere else?)

Getting materials for the event (e.g. pens, stickies)

During each event:

Setting up the room

Welcoming attendees

Ordering pizzas

Introducing the topic vote

Introducing the speaker

Facilitating talk, as required

Tweeting!

Taking the vote for the next topic

Paying for pizzas

Post event:

Claiming expenses

Posting photos to Meetup

Blog post

What else?

Extra Hosts

I’d ask the existing organisers to review their availability and commitments (Over 2016, I hosted the bulk of the meetups, with a scattering of support from Nigel, Tom and Samir. Nader has a conflicting meetup, Nigel has moved out of London, which makes it hard for them both to participate in the future).

We’d be interested in finding new organisers who would be willing to help out. Ideally, we’d like to get a more diverse group of organisers.

Code of Conduct

As discussed in our “diversity” topic, we’d like to introduce a code of conduct. More to come on this topic.

Breakout Corner

Even though we have a chosen topic each meetup, we’d like to explicitly welcome those who don’t care to talk about anything in particular (or just the topic at hand).

Discussion Guidelines

We’d like to provide more guidance to people introducing topics at XTC. A set of guidelines that reflects the essence of XTC (for example, we value stories about experiences over absolutes). More to come on this topic.

Explore Alternative Venues

I think most people are generally happy with our current venue, but we recognise that we are excluding groups of people who might otherwise come. We’re keen to introduce some extra events outside of the normal pub location, if only to see what sort of response there is. #XTCXtra

After dipping my toe in the water a number of times, I’ve finally taken the plunge. Over the last couple of weeks I’ve been migrating a private project from Java to Kotlin. This is a report of how it’s been going…

Firstly, my main interest in Kotlin was the cleaner language design, the clear Java migration path and good interoperability with the JVM ecosystem. What do I mean by “cleaner language”? The my favourite example are the Kotlin data classes. In my code base, I have a large number of classes deriving from “Event”. Each one of these event classes has a number of attributes, with corresponding getter functions, plus an equals, hashcode and toString function. Here’s one of my classes:

This Kotlin code has exactly the same functionality as the Java equivalent, plus it also has a copy function as well.

This conciseness can lead to some large reductions in code size. The module I converted to Kotlin originally had ~8,000 lines of Java code. After conversion, it contained ~4,800 lines of Kotlin, which corresponds to a 40% reduction in code size. This is a significant improvement! Consider that programmer output in terms of lines of code tends to be relatively stable, independent of language. Switching to a language where the same features can be implemented in fewer lines of code means more features can be built.

The more I use Kotlin, the more I find I enjoy using it. I’m definitely going to use it more in the future.

Late last year (the end of 2016), Andy Parker and I were talking about a frustrating problem common to many senior people in teams: how to improve or positively affect the people we work with so that we were all happier and more effective? These discussions have lead me through one of the more intensive periods of growth and learning that I’ve experienced for a long time, and have ended up with a nice gem of a study on the effectiveness of stand-ups. This post is a description of the journey I’ve taken over the last 6 months or so…

Culture and Ethnography

Our first problem: how to get people to change? Andy and I agreed that we can’t make people change. It comes down to a matter of ways to influence people. We thought that this was an aspect of culture, and so our thoughts went to the tools of anthropologists. Perhaps we could learn something there? We knew that anthropologists use ethnography tools to study people and cultures. Perhaps we could look in that direction?

Fieldwork

Andy had heard about Fieldwork, a company that specialises in the study of company culture. Most interesting to us, they had published a guide on how to conduct ethnography fieldwork and a DIY Ethnography Kit.

With this guide, Andy and I both started observing and documenting events that we saw about us at our companies. I started writing posts on our internal company blogging platform, and Andy did the same.

I spent a number of months making observations between my daily work duties. I found these enormously useful, and it helped spark a number of productive conversations.

However, it got to the stage where we had a lot of observations, but no clear idea of what to do next.

On a whim, we searched for online courses which might help us in our quest. As it turned out, there was an excellent course available on Coursera…

Culture-Driven Team Building

Culture-Driven Team Building is a specialisation run by the University of Pennsylvania through Coursera. It is made up of five separate month-long courses. Each course lasts for four weeks, and takes about four hours of study per week.

I’ve learned a huge amount of useful information in these courses, and I can recommend them as a good way expand your skills on leading and influencing teams.

There’s lots more, I’m glad I kept details notes. I’ll be referring to them for years.

Grounded Theory

Remember the fieldwork we were doing earlier? I all my coursework I never really picked up on how to turn the observations into theories and models. Jeff Fredrick hit upon the key phrase and sent me the link: Grounded Theory. This is a systematic methodology in involving the construction of theory through the analysis of data. Finding this was a bit of an a-ha moment for me.

I think when I finish all the coursework, my next point of call will be to return to the ethnography study and apply some more powerful tools as provided by grounded theory.

Daily Stand-up Meeting: A Grounded Theory Study

This all leads me to the last gem: I found a link to a study on the effectiveness of stand-ups:

Since March 2017, Andy Parker and I have been studying the Culture Driven Team Building specialisation from the University of Pennsylvania (delivered through Coursera). The specialisation is composed of 5 different month-long courses. I have published blogs containing detailed study notes for all these courses. This post collects links to all those blog posts in one place.

Organizing Under Uncertainty

Change is in response to changes in the environment, and how to fit better in the new environment.

Solutions can come from anywhere in the system (not just at the top of the hierarchy)

Self-Organisation:

the tendency of an open system to generate new structures and patterns based on its own internal dynamics.

Organization design is not imposed from above or outside; it emerges from the interactions of the participants in the system.

Scenario: Team at GURD, Part 1

Background:

GURD Limited

Software development services company

Works primarily with pharmaceutical companies

New client that they’ve asked to a develop a CRM tool

Team will test the program in 3 months

Stephanie (Project Manager):

Welcome everyone, glad you can be here

Hey Mikki (who is remotely dialed in on video)

As you know, we have an amazing project. It’s a big dal for GURD. If all goes well it could lead to many more projects. If there are any snags, the client could lose al ot of money. A big financial loss, for us as well as them. We just want to amek sure that everything is rolling along as it should for the testing in 3 months. So, where are we at in regards to that?

Gigi (Testing Lead):

We right now are just concerned about the compatibility of systems. We haven’t done any testing so far.

Jacob (Software Development Lead):

Good point, but that’s why we did due diligence before we started this project. We’ve been working hard and really studying the client systems, and making sure that it mirrors the development systems.

Mikki (Software Development Lead):

We can still have technical issues creeping in during the testing phase. We don’t have any control over those client systems, and that due diligence was done a little while ago. They may have done software upgrades since then.

Stephanie:

That’s a really valid point. It could be a really high risk situation if we don’t get on it. What can we do?

Gigi:

I checked the knowledge repository. We have a lot of history here with our previous clients.

Jen (Client Services Lead):

I will definitely be in touch with Theresa at the clients office with regard to IT. I’m certain that they’ve done multiple technology upgrades.

Stephanie:

Good. I think the Software Development Departement really needs to look over this beforehand, right? John’s going to find out all the information from the client. Find out if there’s anything we need to do to adjust and to integrate with their system before three months time. So, you’re going to get that to Mikki and Jacob. They’ll review it over the next few days, maybe over the weekend as well. Next week we’ll meet at the same time, and see where we stand at that point. Sound good?

Jen:

I’ll send you guys an email after I talk to her on Friday.

Stephanie:

OK, good. So next point of business. Company picnic. Did you guys get the invitation?

<<crosstalk> yeah

Stephanie:

Anyone bringing your kids? Mikki, are you bringing your son?

Scenario: Team at GURD, Part 2

Background:

After 3 weeks, the same team meets again

Stephanie (Project Manager):

Thanks everybody for being back. So, hi Jan. Were you able to find out from the client any information about co-ordinating systems?

Jen (Client Services Lead):

Yeah, I met with Theresa and the site team last week, and we put together a list of all the new information, and I sent that along to Jacob and Mikki, and we’re working through it.

Mikki (Software Development Lead):

That was really helpful, they made a lot of changes and upgrades on the client end. So, we’re going to make some changes to our software, so it’s going to work smoothly.

Stephanie:

So, how can we resolve the discrepancies?

Mikki:

Well, I propose we do a dry run. So that way, we can do this thing in real time. If there’s any glitches, we can address them before it gets to user testing.

Gigi (Testing Lead):

I think that’s a great idea. We can schedule a week or two ahead of testing.

Jen:

I’ll let Theresa know so that the team over there is prepared.

Jacob (Software Development Lead):

I just want to say, I’m not sure a dry run will grab everything. I was reviewing some of the implementations and I think it would be in our best interest to bring in a tech expert. Other projects have done it, they’ve been successful with it, I think we should try it.

Stephanie:

Good idea. Should we just throw out some names for people who could do something like this? I’m thinking maybe Janine?

Gigi:

Janine, or maybe Margaret even.

Stephanie:

We do have budget for this.

Gigi:

We put aside a little bit of funding for an expert review. We can get that done like one or two months ahead of testing.

Stephanie:

All right Mikki, well, let’s get the ball rolling, then.

Mikki:

You got it.

Stephanie:

Did you get some of that potato salad yesterday? It was amazing!

<<crosstalk>>

Debrief: GURD Scenario

This is a team that’s working quite differently to most of the other scenarios we’ve shown you.

They have quite a bit of flexibility, adaptability and engagement.

There is an aspect of inclusion

Even though there is a remote member, they are incorporating him into their discussions and social engagements.

Complex Adaptive Systems

It’s energising to be part of a team that is learning and adapting.

Simple problems:

In both meetings, there were some simple problems that recurred, and were addressed easily and readily. They have a formula or format for doing that.

Complicated problems

Knowledge mangaement repository

Someone’s been here before, what did we do?

Complex problems

Client environment is unpredictable. They have no control over the upgrades or changes on the client system.

Mark Twain:

“It’s not what you don’t know that will get you it trouble, it’s what you know for sure that just ain’t so”

The person who identifies problems is not shut down or blamed.

There’s a safe space created.

Safe spaces allow everyone to come up with their own perspective.

This enriches the conversation

Helps them to become more productive and effective

Customer’s world is constantly changing.

The team exhibited responsiveness

Diffusion of ideas

Knowledge management repository

Record of previous projects.

Ability to learn from past mistakes

Find out what has been done previously that can be applied now.

Emergent behaviour:

Teams that are future focused are more able to handle uncertainty and ambiguity

There are going to be variables that we don’t know

When teams handle emergent problems they need to constantly update their information.

Our work together on this team has been emergent

Helpful to add new perspectives

Liberating Structures: Examples of Team Exercises

Enabling structures:

are ones that support teams and group working.

e.g. Rewards need to be structured so that they encourage teamwork

i.e. reward the team, not the individual.

Liberating Structures:

We can invite people in the container (team, group), but we need ways to engage them, get them to engage, exchange view points.

Liberating structures can encourage the Complex Adaptive System to adapt, to be resilient and learn

Impromptu Speed Networking

How to get everyone engaged from the start? This technique gets everyone involved, indepentant of rank.

Think of one or two provocative questions that are pertinent to the meeting

Situation you’re in

Problem you’re trying to solve

Get everyone in an open space (a container)

A facilitator rings a bell and says “think silently for a minute or two, gather thoughts on the question that is in front of us”

After a while, the facilitator rings the bell again. Everyone finds someone in the room which they know the least well, and have a conversation with that person (up to five or ten minutes)

The bell is rung again, and pairs swap.

This is repeated for two or three rounds.

At the end, everyone sits together and asks:

“What did you discover about the question?”

“What were some of the insights that came out?”

“What do you now think about it?”

“How did your perspective change as a result of the conversations?”

1-2-4-ALL

Not everyone feels comfortable talking or asking questions in a meeting. This creates a safe space for all those questions to be asked, and for others to listen to. Allows all voices to be heard

Participants in the meeting are given a chance to reflect on a problem, situation or question that needs to be answered

They pair in twos and discuss their reflections on the question

It then moves to a larger group of two pairs (4 people)

It then gets disussed in the whole group

Q Storming / Wise Crowds

Instead of taking questions one at a time, take 2, 3, 4, etc questions at a time.

This gives options about how to thread those questions together

TRIZ

A good way of discouraging the old disabler activies

The group asks the questions in order:

“What’s the worst possible outcome we can imagine?” or “What do we absolutely not want to happen?”

“What would cause this to happen?”

“What are we doing that is very similar to what would produce the bad outcome?”

Get rid of the last thing.

Defensive routines (Agyris):

An example of a taboo: asking “What’s not working well?”

Easy to answer the question “What’s working well?”, but the opposite triggers defensive routines.

TRIZ can help open up these taboo subjects.

Premortem

Start with the question: “What could go wrong with this project?” (at the start of the project)

Dissenting voices

Conflict is averted because it is no longer repressed

Empowering conversations

These liberating structures prevent a senior or alpha person from hijacking the meeting, asking the first question.

They break the frame of hierarchy

Everyone has to participate! (can’t zone out on a laptop or phone)

Suggested readings:

Hackman, J. R. (2002). Leading teams: Setting the stage for great performances. Cambridge: Harvard Business School Press.