Introducing Scrum to the STEAM Committee

So, this week it was time to introduce Scrum concepts to the overall team (5 children ages 10–12, their teacher — Andrea Flemate - and another parent mentor). Following up on the plan from last week, we started by discussing the “rules of the game” and agreeing to the following:

• Because we are a STEAM Committee our activities should be focused on STEAM concepts beyond what the children will be exposed during regular class participation. Project ideas are only acceptable if they include 2–3 areas of STEAM (e.g. Science, Engineering, Math). More on this later on.
• Borrowing from eduScrum, we established Andrea as the “Product Owner” and explained to the committee members (soon to become Scrum Team) that in that role, their teachers ultimately “own” the “go”/”no go” decision and prioritization of any project ideas submitted.
• Mistakes are an opportunity to learn, as such, the committee will share both the success and failures (mistakes) so their classmates can learn from them and/or avoid them.
• We win as a team. This means that we all rally around our common goal, and help each other as necessary to meet our common goal.

Introducing The Scrum (Kanban) Board

It was then time to introduce the Kanban board to the team. We used painters blue tape and a few sheets of paper to quickly create our Scrum Board on the wall.

Our board had five columns (from left to right):

• Backlog (projects, tasks, ideas): as the name implies, this is the column where all new items are placed.
• Blank Column: more about this in a little bit.
• To Do: a list of activities we need to complete to achieve our goal.
• Doing: a list of activities the team is currently working on.
• Done: a list of activities completed by the team.

After introducing the board layout to the children, they were asked to transcribe the tasks they were so far logging into their committee sheet to post-it notes in the board. And then we started talking about what our goal was. Being from a Montessori environment, the team quickly converged to the topic of learning and sharing lessons.

And so, the blank column in our Scrum board became:

• Lesson Activities: the list of activities the team will need to complete to prepare a lesson for their classmates.

Team Dynamic Techniques

Various team dynamics techniques are employed in this type of fast paced, collaborative work environment. Here are a few we presented to the STEAM Committee:

• Dot voting: we discussed using dot voting to prioritize projects/ideas. It is worth mentioning that while dot voting can be used to prioritize projects ideas and take into account the students’ point of view, like in eduScrum, our teachers will ultimately decide on the project priorities.
• Roman voting: we used roman voting to help us decide our project acceptance criteria (include 2–3 areas of STEAM). We were able to quickly decide on 3 areas of STEAM over 2.

The Scrum Board In Action

In case you are new to the concept of a Scrum (Kanban) board, here is how we plan to use ours:

• All new ideas are placed in the Backlog column.
• Ideas are prioritized and eventually selected by Andrea for the next lesson (taking into consideration lesson plans and classroom activities). The ideas/projects for the next lesson are then moved into the Lesson Activities column.
• Ideas/Projects moved in the Lesson Activities column need to be refined before the team can work on them. This refinement creates a lot more details (activities in their own post-it notes), which are kept in the Lesson Activities column. Refinement happens until the items are broken down in suitable sizes (more on that later on).
• Once it is time to start working on a new lesson, all items are moved from the Lesson Activities column to the To Do column. The Lesson Activities column is now empty and ready to start the planning round for the next lesson.
• The team members select the activities they want to work on from the To Do column. They put their initials in the post-it note (in our case in its upper right corner) and move it from the To Do column to the Doing column.
• The items being worked on remain in the the Doing column. This helps the team identify which items others are working on, and offer to help in case the item being worked on, after all we win as a team!
• As items are completed, they are moved from the Doing to the Done column. Once we finish the lesson, all items from the Done column are removed before starting to work in the next lesson.

Suitable Item Sizes

While there are various ways to estimate task/activity size in Agile, we opted for T-shirt sizes. T-shirt sizes in our context can be small (S), medium (M), or large (L). These sizes to not equate to time, or other precise metric, and should hold true as a relative measure between items.

In practice, you want to break down tasks/activities in the Lesson Activities column until they can fit your teams small, medium, or large definition, before these items can be moved into the To Do column. In our case, we decided to write down the item size in its upper left corner.

Refining Project Submissions

Before wrapping up the meeting, we identified that we needed to refine the current project proposals. And used this opportunity to talk about “definition of done” in the context of project proposals.

Here are the initial minimum criteria we sued for a project submission:

• Identify STEAM concepts involved.
• Information about the project.
• List of materials needed to complete the project.

Wrapping Up With A Checkpoint

Borrowing from eduScrum definition of fun concept, and because ours is a new committee, we quickly went around to check what the committee members were thinking of progress and direction so far.

The feedback was positive but I am taking it with a grain of salt. Read on to see why…

Lessons Learned

Hey, while I did my best, guess what, I also failed! And that is ok especially when we learn from it. And I got to have a few good laughs at night by sharing my misses with my wife ;-)

So, as I am always for a good laugh, how about giving you the opportunity to learn from (and hopefully laugh at) my mistakes?

• As pointed out my parent mentor partner, the one scribe per week idea might not have been such a good one after all. Why? It meant one of the kids was writing while all others were, well, dozing off at times.
• With the focus Scrum, I failed to bring up the maker space as a project (thanks again for me parent mentor parent for bringing it on).
• Probably the gravest failure (in my own assessment) was that I forgot to communicate that the team was allowed to stand up and move around, and bring up items if things do not seem to be progressing well. If I had done so, we should expect someone to call out a break of stand up and move action.
• I later on found out that at least one of the kids dozed off in the first round of roman voting and when came back to it just did what everyone else was doing and put a thumb up :-) So, I recommend doing a trial run of roman (thumb) voting before the real thing. This way you can to make sure the team understands the process and are in the moment.

Next Steps

Planned activities between now and our next meeting (in 2 weeks):

• Identify target dates for the next 3 lessons (currently targeting Dec, Jan, Feb). Andrea will take ownership of these items.
• Refine the current project ideas. The team will be responsible for this.
• Perform a survey/gather feedback of the classroom to identify other project ideas. The team will be responsible for this.
• Lead by example and create a few project submissions, and in the process end up with some sort of template the team might want to reuse for their own submissions. Here are some of them: The art & math around us, Let’s get shaking, Electronic storytelling, Patchwork of knowledge.
• For next meeting, clarify the team dynamic (free to speak up right away when things are not working) and bring up the maker space as an ongoing project.

For Montessori Professionals And eduScrum Practitioners

While the use of eduScrum might add value in other class environments, we feel that the Montessori approach already brings out those same concepts and approaches in the daily classroom activities. This is our assessment at this point in our journey and we reserve the right to change our minds as we learn with the journey ahead.

So, rather than looking to leverage Scrum or eduScrum in the daily classroom activities, we are borrowing concepts from each one (where applicable) to organize and enable our STEAM Committee to tackle projects in an Agile fashion. Much in a similar way in which these concepts are used in the work environment today.

For Scrum Practitioners

So, for those coming from a Scrum background, here is how we would be mapping Scrum concepts to classroom terms:

• Development Team members: children in the STEAM Committee.
• Product Owner: teachers.
• Scrum Master: teachers and/or parent mentor.
• Potential Shippable Product Increment: deeper understanding and application of at least three STEAM concepts in each sprint (lesson).
• Product Backlog: collection of suggested STEAM concepts & projects from all stakeholders (children, teachers, parents, staff) and initially prioritized through dot voting by all children and ultimately prioritized by the teachers (in accordance to their lesson plans and class activities).
• Sprint backlog: activities necessary to complete the selected STEAM project(s) and prepare for the corresponding monthly lesson.
• Sprint Planning: identification of the project(s) to be included in the next lesson and refinement (grooming) of the corresponding activities.
• Sprint Review: lesson to classmates explaining the STEAM concepts used/learned by the STEAM committee children.
• Sprint duration: four weeks.

The following deviations from Scrum framework may occur as we implement it on our STEAM Committee:

• Daily Scrum: these events may be shorter and even not happen on a daily basis due to class work dynamics.
• Scrum Master and Product Owner overlap might happen depending on facilitator availability.
• Sprint duration might vary slightly due to school calendar.