Teach student teams to shorten their feedback loops

Shift left to learn more quickly about your work

What follows is a story that repeats itself every academic year in our year-long software engineering course. You might recognise it too from your own experience.

Team Alpha do as much as possible as individuals. They act as if they can do everyone individually, and keep team meetings, and collaboration to a minimum. The team members think they have enough to do between this and the other three courses, so fitting in extra meetings will be messy. They will try to do as much remotely via email, chat, and the tools in GitHub. They figure seeing everyone once a week in the practical lab session will be enough.

Team Bravo realises that it needs to collaborate in order to succeed, and adapts its work to suit the circumstances. They create a combined schedule showing everyone’s classes, work schedule (to be updated as needed), and sports activities. With this in hand, they schedule an hour long, and a two-hour long weekly meetings in addition to the two-hour practical lab session each week. They also set up chat and will use GitHub tools.

Feedback loops affect progress

Team Alpha has slower feedback loops than Team Bravo. Alpha are only meeting weekly, this means they only uncover issues once a week. Rework, or remedies then take another week. Bravo can discover issues three times a week, so probably will resolve them faster too.

In practice, I find that students are reluctant to use chat or email to ask for help from team members. This comes later, when they know each other better. At the start of their collaboration, trust is low, so they avoid it except to schedule meetings, or ask questions about minor things like which API library they had decided upon. This is why in-person, or remote meetings are more important.

Feedback take many shapes

Feedback in this article means any comments, suggestions, help, or support from others. In some situations, it could also be collaborative co-design or co-creation too when the participants each contribute and build upon each other’s work in cycles of work.

The diagram above is probably wrong. Consider it my crappy first version. I suspect that I’ve left something out, or didn’t express the idea clearly enough.

My intention is to show that when you’re working, you have various options for feedback, with faster ones on the left, and ever slower ones going off to the right. For example, if I’m doing a task on my own, I could ask for help in a meeting, or send a message, which might not be replied to as fast as I’d like. A better option would be to pair with someone on the task, as we could immediately support each other.

With this diagram you can see how Team Alpha is going to move slower than Team Bravo. Alpha is on the right in the practices they are using. This means Alpha will always decide, learn, and produce work more slowly. Team Bravo, by contrast, is possibly in the middle, and maybe hopefully, more on the left with its practices.

What do your practices look like?

Take a moment to think of the work you’re doing. Which practices are you using in your collaborative work? How might you shift left in your work?

What’s missing in the diagram?

The part that I think is missing is something showing what I imagine are concentric, and overlapping circles. As an individual I have the line above for feedback. When I work in a team we each also have options for feedback too. Similarly, our team also has options with respect to how we code, test our code, and work with our client, or users, and gather feedback from them. I hope you get what I’m driving at here.

In any case, please let me know how you think it could be improved. What did I forget? Which ideas could be expressed better? What part might be wrong? Maybe you think it’s fine and useful as it is. That would be good to know too.

You can also find this post on LinkedIn if you’d like to leave comments there.

---