Start slow to go faster later

Each team has a culture; go slow to build it consciously to support your collaboration.

When a team collaborates to build a software application there is often lots of excitement. The thing will be cool, it’ll be new, and different from what others have done. There is often an urge to start coding. Now. After all, ‘they just need to … (fill in the blank with your favourite flavour of the month) and then deploy it, and they’re done’. It all seems so obvious.

If only it were that simple, then there would be no challenge.

When I start larger team projects with students I tell them to also schedule time to go do something together: share a meal, walk on the beach, whatever. Sadly, only some do this. Those that do find it a good start to their work, especially if they have only just met.

As educators we need to teach people to take the time to consider their options as they start their team collaboration. By doing this the team creates the culture they want to carry forward. Even if they only do a few of these things, then they will save themselves time later.

Photo by James Littlejohn via Flickr

No decision is still a choice

If the team just launches into the work, then they each assume the others are thinking like them. The culture will evolve based on what people think is happening, and will only change when people ask questions later, based on bad experiences. For example, if people turn up late to meetings, without having done the work they committed to, and no one is called out on this, then that will continue. Or, if people submit buggy code with no tests, then others will do the same. You can see how this will only make the collaboration move slower.

Focusing on the artefacts they’re building is not enough to achieve a good product. Doing this will leave pauses, gaps, in the workflow and slow everything down. People can’t move as quickly as they could if they had feedback from team members. Someone will be holding back their code from commits to the team’s version control system, because they think it needs more work, as “it’s not good enough”, and others don’t think they need to tell people to start without them, so don’t know there aren’t enough people to make decisions.

This is not a happy picture. This is not what we want to see happen.

Make conscious choices for a solid foundation

It is better for teams to discuss their options. The team should talk about how they’ll address each of the ten phases discussed previously. At a minimum to start they should cover how they’ll stay in touch (group chat), and agree on the version control system, and check that everyone can push/pull from the repository, and is using the same version of the programming language. This is the basic version.

A better team would also set up a shared calendar so that it’s easy for every to know and be reminded of date, time and locations for team meetings. They might even do the same for the pairing and mobbing sessions to help build a shared coding experience too, and decide upon coding standards for the team.

A higher performing team would layer in social activities so team members know each other better. By knowing each other better it is easier to support team members. This happens when team members know each other better. These are the teams you see having lunch together, and getting on well, even when things are a bit panicky near the end of term.

Provide time for the team to start slowly

Encourage your teams to start slow, and to use social activities to build their culture. These activities offer chances to talk, and to find and build common connections between each other. These connections help form a shared culture in the team.

For larger projects the team will spend lots of time together, so it makes sense to spend some of that time learning about each other.

Structure some activities to enable this to happen in the classroom, and encourage them to do it outside the classroom too. I use a mixture of things for this. I like to give each person a card from So Cards, an ice breaker type of activity. The cards have questions like: if you were introducing your home town to your friends, what would you show them? Or, if you could bring one person back from the dead, who would it be and why? I steer clear of any questions that might accidentally embarrass them. I use the cards as openings for them to talk to each other and share stories.

After putting in the foundations so students know the common connections the team has, they develop empathy for each other. Empathy means they know that x turns up late, as they had to stop at home to look after someone today. Empathy means you know it’s ok to tell them team you need help, because no one knows how to use this framework yet. Empathy means you make allowances for your team members and don’t immediately leap to stereotypes, and the blame game.

With empathy in place, the team can do more effective work later because they support each other.

Ideally the team discusses how it wants to work, how it will handle conflict, and make decisions.

The best solution is to create a team charter, or agreement that captures these decisions. This can be used, updated, and modified over time. This is what a number of software development teams use for their work. I’ve created a modified agile chartering template, that seems to suit the needs of students. I’ve found it helps students focus on what they individually want to achieve, and to also provide a place for them to capture decisions. I do have to remind them to fill it in. I wish I didn’t. If you use it, then please let me know how it works (or doesn’t) for you.

Students need to be guided in how to create team cultures, as they usually don’t have a lot of experience in this. Help them with this, and you’re also helping them with life skills.

---