Skip to content
Home » Blog Posts » Part-time agile works best when students work in the open

Part-time agile works best when students work in the open

Working in the open speeds up the feedback loops so that you learn more quickly.

Part-time students are in more need of agile practices than they realise. Part-time in this context means students doing one course of their three or four courses that term on software engineering with a team project all term, or all year. These students are juggling commitment for three or four courses, at the same time.

While it might look easier to skip the agile practices that ask for the team to do things together. Not using agile for part-time projects/product development will only lead to delays, and therefore more stress. As mentioned before, scattering duties to people leads to delay. Teach your students better approaches.

Photo by Kaleidico on Unsplash

Tell your students to follow the collaboration rules

The collaboration rules will keep them clear on how, and why, they should put more effort into the coordination of their work. A key part of this is working in the open so that team members can see what they are doing.

The sooner someone else sees a team member’s work, the sooner the person can get feedback for good or bad, on what they did. Yes, they might do something wrong, and this will help them learn a better way to do the work.

Instead of doing work on your own, do work in pairs. With a partner you have instant feedback. This applies to more than pair programming. Pairs can write user stories, write drafts of the report, whatever. Just put two people on the task instead of one, and see what happens. This is how Menlo Innovations organise their work, so it’s not just me saying this.

Instead of people waiting struggling on a task, set a time limit for help. Students often wait until the next meeting to ask for help, which delays finding a solution. Team have hopefully set up team channels for communication, to report progress, or whatever. Get them to use it if they’re stuck. Have them set a time limit, say 3 hours trying to fix something, or integrate a component, and if they’re still stuck after that, then they should ask the group instead of struggling further on their own.

Instead of each task being done in separate branches, have everyone work in the main branch. Yes, this takes coordination. It should also be easy enough to do for any team of five to seven students. They just can’t all work on the same methods at the same time. Orr, they are at least communicating via the team channel to align their work, when they do. Even better would be if they mob for this part. Now everyone is offering feedback, and is in the loop too.

Instead of having one person pull the report together, have it in a shared drive for everyone to see and contribute to. Students always hate the report writing part. This should be started earlier than they think, and should be a shared file for everyone to work on simultaneously. This means people can edit their part together, and it has multiple people proofreading and fixing mistakes.

Instead of waiting until the app is ‘done’ to deploy, have the team deploy a ‘hello world: this is our app’ version as soon as possible. This means their client can see the work, and offer comments. It also means the team reduces one of the biggest risks immediately too. Deploying early is a double-win.

Share this with your students

Go tell these things to your students. Point out that software engineering is hard because it means working with people, and there is no easy way to do this work. Paths that look easy, are slow, and frustrating as noted earlier. Guide them in the hard parts of working in the open, and if they do retrospectives regularly, then they should find ways to make it work for their team.

Lastly, remind them each team is unique. While they can use a pattern from another team, they have to find a way to make it work for them. Doing the same thing as another team, without taking into account their unique context, will not yield the results they expect.


This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.

If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn

The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.

Cookie Consent with Real Cookie Banner