Making agile work when it’s not full-time means attending to your schedule
A student brought me up short the other week, and his question has been mulling around in my head ever since. Students complete surveys for each course near the end of term. Ideally they tell us what they think about the course, its delivery, what worked, what didn’t work so well and those sorts of questions.
The student commented that they’d found it hard to apply scrum on their team project. All of the team members were doing three other courses alongside this software engineering one. It was hard to do things when the team didn’t meet every day. No one had mentioned this in class, so it was news to me.
‘Scrum is so simple’ it can be explained on a beer coaster
The scrum process fits on a beer coaster. It-agile, a good agile software business in Germany, even sell them, and give them away at conferences. ‘Entwicker’ means ‘developer’, ‘produktiel’ means ‘product goal’, ‘sprintzeil’ is ‘sprint goal’, and the rest is close enough to English, so should be fine.
With this image in mind, I figured, assumed, that each team would create a schedule and develop a routine to enable them to do the work. I always meet with each team each week and often ask how often they meet outside of class. I also ask them how they do the work: solo, pairing, or mobbing. If they don’t pair or mob, then I ask why, and encourage this.
Maybe this one student and their team either thought there was more they could, or should do to make this work. I’m curious to know more, and find out what challenges they found. From past experience here are what other teams have done in my classes.
Use scheduled classroom sessions to make decisions, and do the work. Everyone should be here already, so make use of this time to the maximum.
Create, and keep up to date a planner, of who’s free. Use this to create two or three regular weekly sessions to meet together as a team to make decisions, and do any mob, or other work together, such as deciding who is doing which stories or tasks.
Have pairs of people find time to do work together. This is easier to schedule than full-team meetings. Rotate pairs too, to share knowledge in the team. This also helps people learn new skills more easily too.
Set up comms channels such as email, messaging, or other tools so people can ask for help, and confirm things. Teams need to know how to ask for help, and let others know the status of their work.
Applying this in practice
Looking at this I see the same practices I use with groups that I’m involved in. Part-time agile is normal for many things. We schedule meetings regularly, and use polls where necessary to find common times to meet too. We also pair on most tasks in one group. This is more fun, and means we always have another person to validate, and confirm the quality of the outputs we’re creating too.
In other groups we’ve experimented to find good ways of working. This is ultimately what I tell student teams to do: try different approaches, and then pause to see how they’re working. This is the ‘sprint retrospective’, and is there to help the team improve how it does the work. It only works though, when the team uses that meeting to improve their collaboration. It is the most important meeting, or phase of other meetings. ‘How can we make this better?’
Always be collaborating, and always pause to consider how you can improve your collaboration.
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.