I wanted my students to be more intrinsically motivated so I introduced them to Scrum and let them work totally self-organized for a whole semester. Here are my thoughts about how I set up the framework in my special context.
I have been working as a senior lecturer at a University of Applied Sciences in economics for about ten years now. My goal each semester is to motivate my students and get them excited about what they (have to) learn. From the start I recognized that they generally where not too enthusiastic about business communication. In one module – corporate communication: concepts and texts – I especially I felt that they weren’t motivated at all. Perhaps it’s about external factors like the point in the overall curriculum or the workload they generally have at the time.
There was something more: After the first few weeks in this module the students have to give in a paper, written in small teams of two or three. They get feedback within the semester, before they have to do the final paper. I try to be a coach rather than a teacher. But at the point where you have to grade the work of your coachees they understandably reject you as coach. After that point I never could connect to them again.
Self-organization as motivator
When I started to read about motivation at the workplace I soon found Agile and agile frameworks. It seemed obvious that self-organization makes people happier at work. The students at our school have to do a lot of work in teams of three to five, so they are used to self-organize. Still, I got my hopes up and tried to do the whole semester in self-organization. I would be a coach exclusively and I wouldn’t give them any one-way input nor would I show them any slides. I would still lead discussions if they wanted me to and of corse I would provide them with assignments according to the scope of the module. If you think that like this I had less work: I worked about twice as much – but it was fine with me. It allowed my to experiment in a field where I am always looking for improvements. So I am happy with it.
I decided to go with Scrum: It has some simple rules you can stick to very strictly. Some might say that this is too rigorous but I found it helpful for the students to give them something rigid they could hold on to while everything else they know was falling apart. An other advantage of Scrum is that although it comes from software engineering you can use it for almost any area where you can work in iterations.
The Scrum framework for learning about corporate communication
I let my students team up in groups of about five people and told them, they were the communications department of a newly founded company. Each team could choose what fictional company they work for. They now had the overall assignment to build the foundation for the future communication activities for that company: Write a concept for integrated communication (like corporate desgin and corporate behavior), communication with employees, with stakeholders, with citizens and with the public. Attached to the concepts were assignments for actual text examples, e.g. an editorial for a company magazine or a press release. These were possible subjects for the final exam and the teams had to make sure that every member could actually write such a text.
I built a framework sticking as close to the Scrum Guide (see also the Guide for EduScrum) as I could. [Alterations are in square brackets.] Essentially, the work goes on in iterations (called Sprints) where independent parts (called Increments) of the whole product are built (the whole product being in this case a concept for corporate communication with specific examples of texts). I specified the assignments and let some room for choosing out of several options. The Teams are allocating the tasks between members in self-organization. Also, they decide by themselves what they will do to accomplish the work and to meet the Definition of Done (DoD), a checklist or guideline of expectations the product has to fulfill.
The DoD is created by the organization [in our case here that’s the department of the University] and the Team. I set the DoD at the very beginning of the semester together with the students following the standards they already knew from previous modules and general (quality) specifications of the school (for example rules of comprehensibility or how to cite texts and so on). For each type of text we dated up the DoD.
The Scrum Roles:
- Product Owner: Buts the assignments in the Product Backlog, knows what they are about and answers questions about them. [This role is mine, because I still am responsible for the students to reach the educational objectives.]
- Scrum Master: Is part of the Team, facilitates the Team’s decisions and removes impediments. [Since all the students could profit from this role, I made it a changing one: The teams could pass on the Scrum Master’s role every Sprint.]
- The Team [originally Development Team]: Does the needed work on the Sprint Backlog items to produce an increment that meets the DoD.
The Scrum Artifacts:
- Product Backlog: An ordered list of all that has to be done. [In this case the order was along with the subjects of the module scope. There was no refinement possible. Also, there was not much changing of requirements going on, since the scope of the module usually doesn’t change during semester.]
- Sprint Backlog: The items the teams pulled from the Product Backlog for the current Sprint. [I tagged the items in the Product Backlog als „Must“ and „Option“ to guarantee that the teams didn’t miss mandatory objectives from the scope of the module.]
- Increment: The parts of the product that are produced during a Sprint. [The increments here probably do not meet all aspects of incremental premises, since the products were single concepts and texts, but over all they should work in the context of a consistent corporate communication.]
The Scrum Events:
- The Sprint: A Sprint usually is three weeks during which the students worke on the items. [Although the Sprint went on for three weeks, the students didn’t work on it for more than about three to six hours per week since they were not working on the Sprint exclusively, meaning that they have other lessons and also are employed in real companies. Further, they had to finish the work within the Sprint, since each Sprint had a new issue covered.]
- Sprint Planning: The Product Owner introduces the items for the Sprint. She hands out the User Stories and the teams pull the work in their Sprint Backlog. They discuss what work they will have to do and how to do it. They choose a suitable Sprint Goal.
- Daily Scrum: Each working day [that was one day a week] the teams have a Stand-Up-Meeting in front for their board and discuss what they have done, what they will do and whether there are any impediments.
- Sprint Review: At the end of each Sprint everyone does a Review where the Team present their work and get feedback from the stakeholders. The Product Owner inspects the increment and verifies that it meets the DoD. [Since this is valuable for all students we did this in plenary sessons: Team after Team explained what they had done and why, always explaining the context of their very own fictional company.]
- Sprint Retrospective: After the Review the Teams get together and reflect their work as a team. [The Product Owner didn’t take part in this, since I had three Teams at the same time and also because I felt the Teams would be more honest if I wasn’t a part of it. Some of them decided to talk to me about their reflections anyway, presenting me their insights or even asking me about my observations.]
The framework proofed to be successful: The students worked on their tasks self-organized and the results meet the DoD. It seems to me, the produced concepts and texts also are more creative than before. I will reflect on the outcome in my next post.