Guide your software engineering teams

Photo by?Buddha Elemental 3D?on?Unsplash

Provide rules to guide student teams in their work.

Whenever teaching software engineering students that are formed into teams I find various challenges that come up every time. There are issues around how the teams were formed, personal issues, and topic issues.

Each of these issues comes up every time. I always try to answer them before they are asked with varying degrees of success. Students, like other people, don’t always listen until it’s an issue for them too. They also never fail to surprise me with new ways of doing things.

I try to address each of these issues a little at a time over the weeks in class so that it’s more likely that their questions are addressed closer to the needed time. My goal is always to answer regular questions before they’re asked. This doesn’t always work.

Team questions cover who’s there and how to do their work

Team questions cover issues around who’s on the team, and how were people allocated to teams. Some also wonder if they can change teams. I explain that I follow a general guideline of making teams as diverse as possible. I take gender, culture and into account when possible.

Later in the term teams ask more specific questions such as: where do we start, what do we do if people aren’t contributing to the work, and other practical questions. The answers to these are: build simplest version possible that reduces biggest risk, and to talk to team members to find what’s holding them back.

Personal issues are also team issues

Sometimes students want to change teams. I allow this if a student tells me there is a personal issue between two people. I don’t ask what it is, I just trust them to be truthful with me.

There is one special case here when the course spans two terms. There are often exchange students coming and going, but also sometimes students in other disciplines too. I normally map the outgoing and incoming students, and leave the teams as similar as possible in their composition of numbers.

For all of the other issues that appear: people not turning up for meetings, or contributing to the codebase, or other work, I ask the students to contact and talk to the relevant person. I tell them to do this one-on-one so that the person doesn’t feel intimidated by everyone.

I want the team to find the person’s story. What is making it hard for them to contribute? Did they miss a course, or have they found it hard to learn language x? It could also be their work schedule is unpredictable. There are many reasons, and until they know what it is, they tend to follow their bias. They have lots of external reasons why they are late, but anyone else is assumed to have detrimental internal factors; they are lazy, or don’t care about grades.

The solution is to have students learn to see and listen to their other team members and build empathy within the team. Have each team to do a social outing at the start of term. Ideally they should do these regularly. I’ve found the teams that do meet frequently for lunch, or other activities, often do well as a team. They know each other, and learn to help each other.

Topic issues are also team issues

Each team wants to know who their client is, and what they’re building. Our undergraduate students used to pick their own product to build. We provided a basic set of rules: the business logic must required more than simple CRUD operations on the database. This could be either web or mobile, or both.

The postgraduate teams have had real clients for many years. Two years ago we started this for the undergraduates. They missed being able to pick their own project. A real client offers many more aspects that they can’t replicate if they are their own clients. I randomly assign teams to clients. As the goal is to learn to work on a larger software product as a team, the client is not important.

The other topic issues concerned the application technology. This scares and excites them at the same time. It is often enough to reassure them that they know how to learn new languages and technology too. Remind them too to focus on practical steps to apply things sooner rather than later so that they reduce risk.

The last topic issue is always ‘how much do we need to do to pass’. We provide open ended projects. They will never be ‘done’; even if we gave them years.

With that in mind tell them they should aim to have a functional application that can used by their client until it’s pushed further by a future team. For me, their goal is to write a report telling us how the team worked to achieve what they did with critical discussion about the choices they made along the way. Why, for example, did they pick the technology they used, and where they happy with how they organised their work?

Help your students by providing them guidelines

You can address these topics in your courses so that students know what to expect, and how to collaborate as a team. The suggestions above will guide you. You can also refer to the collaboration rules from previous posts too.

Just keep taking notes of what students ask, and then seek to provide ways to supply the answers before they ask the following year. We too can also use continuous improvement in our own work.

If you want more ideas of how to teach collaboration to your students, then

a) follow me on LinkedIn

b) subscribe to this newsletter in LinkedIn

c) Find more ideas, and my books, at my website https://buff.ly/499r3kg

#edtech #edchat #softwareengineering #teamcollaboration #collaboration #studentprojects?#highered #computerscience #teamwork