Developing Software in a Scrum Team as a Working Student

Scrum

The Scrum framework provides structure to incrementally deliver value and periodically evaluate the teams processes.

Developers, Product Owner, and others attend regular Scrum events to reduce ad hoc meetings. The Developers try to finish a finite number of tasks in a fixed time scope called Sprint. Once per cycle everyone joins the Planning to prepare tasks for the upcoming Sprint. With the same frequency the team meets up for the Retrospective, where they discuss potential process and communication improvements. Additionally, there is a meeting every morning to align on day-to-day work. Every Sprint is concluded with a Review, where stakeholders are informed about the teams progress.

Challenges

I already had prior experience with the Scrum method when I joined  DKB Code Factory as a working student. I learned about the basics at my university, worked on a project with other students and felt confident applying my knowledge to the real world. In the following I will outline some challenges we faced, and I think would apply to most other working students.

⏳ Part-Time Employment

Working 50%, I had 100% of invites to Scrum meetings in my calendar. Attending them decreased the time I had left for software development significantly. When I decided to skip some Retros, I felt less connected to the team. Missing Sprint Plannings usually resulted in more communication later, as I had to clarify requirements and task dependencies.

Our Sprint cycle felt much shorter to me. Whenever I took up a larger task, I knew the chances of finishing it by the end of the Sprint were slim. Either I would carry it over to the next Sprint, or I would hand it over to someone else. The former meant my tasks where not finished as planned. The latter alienated me from the value I brought to the product. Both effects, I and the rest of my team wanted to avoid.

🥴 Intense Study Periods

Sometimes exam phases and irregularly given assignments prevented me from working on my chosen weekdays, and consequently from joining some meetings and Scrum ceremonies. This contributed to the issues listed above.

👨‍🎓 Learning Opportunities

It was very important to me and my team, that I would be able to grow while contributing to the product. We didn’t want to limit my tasks to small bug fixes and busy work. To solve harder problems, I had to invest a lot of my already limited time in research or consult with other developers, halting their progress.

Strategies

After observing the situation for some time, my PO and I sat down to figure out a better structure. We started by defining our goals.

The working student:
- is enabled to learn and grow
- feels part of the team
- is not occupied with busy work
- is allowed to pick up large tasks
- adequately contributes value to the product

We then formulated some strategies and tried them for a few weeks each. Below I will give a quick overview of the two that worked out best for us.

Pre-assigned Tickets

When refining and/or planning, the PO aims to include at least one task fit for the working student (WS). That task must meet the following requirements:

- achievable on their own, potentially after a personal introduction to the topic by an experienced developer
- valuable to the product or project/team
- uncritical for the current Sprint – “things that would have made it to the upcoming Sprint” are planned earlier to give the WS extra time

The task is then tagged and can only be picked up by the WS. The estimated time is discussed between the WS and PO. In general, they should have time left to pair up on other tasks and educate themselves. The WS can do secondary code reviews for tasks that are also reviewed by more experienced developers.

Sidetrack

Besides the regular scrum ceremonies, there are on-demand meetings between the WS, the PO, and the lead developer (or any other experienced colleague). They prepare tasks fit for the WS and put them onto a dedicated board. They must meet the following requirements:

- achievable, valuable (see above)
- uncritical for the next few weeks (even lower priority then the tickets above)
- independent of other teams’ goals and Sprint cycles

Compared to the first approach, there is no Sprint and no deadline. The WS can pause their task to help the rest of the team, for example in case of feature pressure. This can be done by pairing up or reviewing merge requests, but both activities are recognized as learning opportunities and encouraged any other time as well.

written by Lucas Lee
Backend Software Developer for Team Helios (working on the Broker API) &
Former Working Student for Team Proton (working on the Card API)