Scrum in Design Factory Projects

Scrum is an agile project management framework that is widely used in IT development. It is an effective way of joining development and customer feedback during the development process. Agile development is important especially when the project outcome can’t be fully determined before the project begins.

When the Design Factory Projects begin with the second-year students of the Computer Applications and Business Information Technology degree programmes at Häme University of Applied Sciences (HAMK), the students do not yet have a clear picture of the project targets. They are not yet professionals who can predict a project’s outcome based on experiences of previous projects. Since the intention is to learn leading industry methods, scrum is an ideal framework for us. From the first implementation of the Design Factory Project, we were given important information for developing the projects and their management.

The Scrum framework

Scrum is an agile project management framework that helps teams collaborate effectively and deliver high-quality products. It is based on iterative and incremental development principles and is particularly suited to complex projects with rapidly changing requirements (Figure 1) (Schwaber & Sutherland, n.d.).

Various parts of the Scrum framework can be divided by time and content. Timewise, the project is developed in sprints that could be 2–4 weeks long. Each sprint begins with a sprint planning meeting, where the content of the sprint is decided. The planning process includes setting the priorities of the items, estimating the workload (effort) and setting up a sprint goal. The sprint ends with a review and a retrospective meeting. Every development day will begin with a daily meeting called the daily scrum.

The content of the project is divided into user stories that depict the needed functionalities for different users. User stories are written in the product backlog, a list of all the things that need to be done in the project. For each sprint, some of the product backlog items are taken to be developed. From them, the sprint backlog is designed (Scrum, n.d.-a; n.d.-d).

In our Design Factory Project, we had programming projects from two companies and the HAMK Edu research unit. First, the structure of the project contained a two-week period of getting to know the project content and then three two-week sprints. The project course was 5 ECTS.

Scrum roles

There is always a scrum master in scrum projects. The role of the scrum master is to keep the project running and make sure that it is done with the scrum methods. The scrum master organizes daily meetings where the developers discuss what they have done, what they will do next and possible problems. These meetings should be short, like 15 minutes. The Scrum master is part of the scrum team and as such, is one of the developers as well (Scrum, n.d.-c).

The product owner mostly represents the client of the project. The product owner tries to increase the value of the project continuously with the correct selection of backlog items and their development order (Scrum, n.d.-b).

The role of the product owner is a difficult one in this kind of student project, especially if the customer is an outside company. In professional projects, the product owner organizes the backlogs and the interface for the company. The main discussions take place in the reviews. The students, however, typically need more assistance than professional product owners. This demands more from the product owner and requires commitment from the companies.

Since the scrum has been designed for IT companies, it does not mention the university teachers as facilitators. In a university project, however, we need such for the management and evaluation of the project. The teacher-facilitators (Kunnari et al., 2021) support team building, sort out suitable students for the scrum master and product owner roles and get the team to fully understand the project. The teacher-facilitators also keep track of the presence and activity of students in the project. In the first Design Factory Project implementation, the teacher-facilitators also needed to take some part in the product owner role. To keep the student project running, the teachers needed to answer students’ questions immediately on behalf of the clients.

Tools and development environment

To manage scrum projects, IT systems are often used. Two popular systems are Jira and Confluence. Jira is more for process management. Confluence is more for documentation. The first year we got Jira and Confluence relatively late in the project. That was due to their late installation time to the university servers. So, they were new to the students. Therefore, the students had to learn the usage of Jira and Confluence during the project and all teams used them during the rest of the project. From now on, those systems will be learned already in the first year and students will be familiar with them before we start the next projects.

For the first year, we gave the students the unfettered option to use any technology they wanted. These included the programming languages they learned in the first year like PHP and JavaScript, in addition to systems they had not previously learned, like PowerApps. This created complexity and some additional challenges for software development. The students used a lot of time to search for a development environment. In the feedback discussion after the third sprint, we came to the conclusion that instead of having total freedom to select a development system or make one development system mandatory, we could offer them a few options like the mentioned programming languages and Microsoft Power tools. The students would have an option to choose, but not a massive variety of choices so that we could reduce the complexity of the project.

Experiences and learnings

We had to form small mixed groups of students. We had almost the same number of Finnish students of the Business Information Technology degree program and international students of the Computer Applications degree program. Hence, the teams had an equal number of students from both degree programs.

The experiences of the students were dependent on the roles they filled during the project. The original idea was that as the groups normally had eight members, three could be scrum masters and three could be product owners for one sprint, i.e., two weeks, and spent the rest of the time being developers. The other members were developers throughout the process.

Scrum Master experiences

We had different strategies for the scrum masters during this first Design Factory Project run. In most projects, there was a different scrum master in each of the sprints. In some projects, there was the same scrum master throughout. There are pros and cons to both approaches. In the rotating scrum master role, more than one student gained hands-on experience in that role. Project continuity may not be very good when the scrum master changes all the time (cf. Bolloju et al., 2018). With one scrum master, only one student gets good experience in the role.

Based on feedback from the students of the first Design Factory Project, we will change the beginning so that the teacher-facilitator will act as a scrum master in the first meetings. This will serve as an example to the students of how they should act in the role of scrum master. At the time of writing this article, we have not yet decided whether there will be only one scrum master or a rotating system. It could be that the teams decide that themselves.

Product owner experiences

In the first run of the Design Factory Project, the rotating role of a product owner was given to the students even if we knew it would not be ideal. The students in this role had a hard time figuring out what they were meant to be doing, even with the aid of the instructions. This is something we need to develop further in coming implementations.

Since this role was very problematic in the first run, something must be changed. The best idea so far is that a Design Factory employee would act as a product owner for many projects. This person would know the projects well but would not burden the companies excessively. This person would be able to answer the students’ questions quickly due to their being from HAMK. Because of the large number of projects and project groups, there should be more than one Design Factory employee in these roles. They should divide the projects so that each of them can concentrate on only some of them.

In future projects, we will have two product owners from the Design Factory. For the autumn implementation, we estimate that we will have 16 small groups, so that each product owner will be responsible for about eight projects. Many of these projects will be implementing the same assignment for a company. With that established, it will be handy if none of the students try to call the company with the same problems, but they instead contact the in-house product owner, who will give all the groups the same answers.

This also has an effect on the reviews. We can split the reviews into two classrooms and place product owners in each of them. We will have four teachers, so we will place two of them in each classroom. Then we can schedule the projects for 20-minute reviews in these classrooms. On a weekly schedule, we have 3 hours and 15 minutes for all these reviews. Retrospectives, where the students reflect on what went well and what needs to be improved, are held the same day without supervisors and product owners.

Overall feedback from the students

The student feedback was different from the two degree programs. The Computer Application students rated this course roughly a 4 (on a scale of 1–5) and the Business IT students rated it above a 3, so overall, the mean rating was 3.7. So even if this was the first implementation, the students gave positive feedback. When prompted to list the good things about the project, the students mentioned everything, describing it as challenging while also listing its enjoyable and educative work-related subjects such as interacting with clients and further noted that its teachers were committed.

On the development side, the students wanted to choose the project members themselves based on their motivation and knowledge. Unfortunately, that is exceedingly difficult to organize, but next year we will not only take into account the received credits from the first year but also the grades.

Hopefully, we can improve next year, by which time most of the bottlenecks will have been repaired, and the new product owners will have taken their place.