It’s been a while! I was pretty busy this year, but here are some brief news. I got a new course : 40 lessons to teach my student how to access a MySQL DB from PHP using PDO. 40 lessons is very very short! When you have 14 students, all having different levels of understanding PHP, SQL, not knowing what is a function, what is a connection string, what is a query, or even what is an associative table. OUF!
So I tried it for one trimester with one classroom, I thought we could do this easily, like I show something on my computer and then, they do something similar on theirs. Some of the students had no problems doing this, searching PHP Manual to see how things work etc. But others were stuck with some small issues, like their inputs not showing in $_POST, just because they forgot to put a name in the html input tag…
So when I realized that I would have to do it again with 3 classes, I decided I had to change the way they learn. I created a tutorial, with Google Docs, published all the chapters on a Google Classrom, and said to my students : ok you have these 11 chapters to cover, you have 40 periods. If there’s something new in a chapter, a video is available on my YouTube Channel, you watch the video and you develop a CRUD from scratch.
And I also created a mini-portfolio for my students, so I can follow their work, ask questions live and check who’s stuck or who’s work is in progress. The portfolio is created with Google Sheets, and projected to the classroom. Very useful to make everybody know where they are and what is still left to get the job done! The live effect of Google is incredibly appropriate for this kind of pedagogy! I can react to any student comment and give a personal feedback, I can see if they did the corrections I asked for, and I can just sit near them and help when needed.
After a few weeks of experiencing SCRUM with another class, the results are way better, especially because of the first GIT phasis where the students had time to learn what they needed to know for a basic project managed with GIT.
This being done, I spend less time resolving GIT conflict, and have a more coaching role within each Scrum team.
The first two half days were entirely dedicated to GIT. Then we started discovering the SCRUM concepts. Every student of the classroom was in charge of presenting one of the concepts (Sprint planning, User story, etc.). After they discovered the concepts, we did the Airplane game, which I improved a bit by adding a new challenge into it.
So, they had to make planes and boats, the PO had to specify which object to make during the iterations and they had to estimate how many of each to do in every sprint. It was even funnier to do it this way, and it gave to the PO a real role during the game, which was not really the case with only planes.
Now it’s been 3 weeks that we are working on a C# project. The class is divided in 3 teams, but they all work on the same project, which is something that I need for work.
Next week, the project shall be finished, we already had one sprint review, it is a small project, so 2 sprints are sufficient.
The Scrum experience is getting better, but there are still some things to improve, for instance, the project size, which should be just a little longer.
After a more or less chaotic experience in a previous semester course (see my blog about SCRUM), where I tried to “teach” SCRUM, GIT and CSharp in a same course, I realized that it wasn’t the best mix I could imagine.
Since a new course is starting this semester with a new class, and the subject is Project Workshop, I decided to introduce GIT first, then Scrum and then we’ll see.
I learned from my last experience that GIT is very complicated for students at this stage, so, I imagined a step by step experience. The idea is based on one of my teacher fellow’s mini-course.
The idea is to prepare a set of exercices, that the students have to realize in groups of two in order to discover the concepts of version control.
The exercice is very simple, they have to create a mini website using GitHub and GitExtensions to manage their code.
In order to do it, I give them oral instructions, which are completed by small videos that they can watch at their pace.
The videos are available on my YouTube Channel, and are less than 2 minutes long.
We’re starting next week! I’ll keep you in touch. In the meantime, here is the first video :
A first sprint for the Swiss Mountain Huts has finished last week.The students prepared their sprint review, and each group made a demo in front of all the classroom. Most of the demos did not work, they called it the “demo effect”, and learned that for the next sprint review they shall test the demo on the demo computer before presenting.
After the demo, they did a retrospective. This is a ceremony which they manage quite well, they were used to do retrospectives with me last year.
And then, they planned the next sprint using the poker planning apps. They are now quite used to do the poker planning, they discuss their point of views and analyze the stories before estimating. But there is still place for improvement.
The second sprint started yesterday, and ofcourse, many issues with GIT occured again.
Even though I tried to simplify the GIT usage to the maximum, it still is complicated for beginners. Also, the fact that we work with Visual Studio does not seem to help. They mostly experience merge confilct (see figure above) with the Form Designer files. The code in these files being automatically generated by Visual Studio, it is often hard for them to solve the conflicts. So they sometimes choose to re-do a layout instead of trying to understand which part of code to take.
Introducing so many new concepts at the same time was not the best idea I had. They had to learn
Within C# they are also trying to apply some newly learned POO concepts, so no surprise in the fact that they sometimes struggle!
Next semester I will introduce Scrum in another classroom and will try to do things a bit differently, especially for the GIT part. I think I should prepare some very small use cases where they will learn how to use GIT properly, and then start working with scrum on a project.
I also thing, after these few weeks in my SCRUM classroom, that a team of 5 is pretty big for students. It’s ok at work, but in a classroom configuration I will limit the teams to 4 in the next semester.
For now, we have 2 weeks left to finish the Mountain Hut Management, we’ll se how it will end :).
So, after a 6 weeks (*Reminder : when I say 6 weeks, I mean 6 afternoons of 5 periods of 45 min each)learning phase, we started a new, more complex project with Scrum.The aim of this new project is to manage swiss mountain huts.
I separated the project in 2 releases :
Release 1 : Simple Hut Management including, hut details, contact details, comments, price per night, etc.
Release 2 : Energy management for huts (still just an idea to dig)
The three teams work on the exact same project, but they have some liberty in the way they implement their application. The product owners of the different teams decide what they want to have in the final product.
Some constrains are the same for all the teams :
C# Windows Forms Application (this is a school decision)
Common Database for each group (they usually have one local db per student)
Git (one repository per group)
SCRUM (ofcourse they have to manage the project with SCRUM)
After a first catastrophic Sprint, the Sprint 2 and 3 went better :).
I installed Git Extensions on every computer and the students understood better how to use GIT with this interface. We also decided to work with the “Rebase” system rather than branches which seems easier to understand for beginners.
The teams became more and more independant and managed their sprint plannings, retrospectives and stand-ups by themselves during sprint 2 and sprint 3.
I still spent time with a few people trying to correct wrong commits and trying to find workarounds for some C# issues.
Sprint 3 went pretty well for every team. And then, during the last lesson, we realized that nobody had done a Sprint Review.
Since they were working on quite small projects we decided to organize a Release Review which covered the 3 missed sprint reviews.
Before the Release Review, I decided to organize a Test session. Every team was responsible for testing applications of the other teams. The students were happy to do this, and very eager to find mistakes in the other projects.
Then, the teams had time to discuss the bugs and decide which ones to correct before the final review.
In the middle of the afternoon, each group presented their project. They had the following instructions :
Business oriented presentation(not technical)
Some quantitative information (how many sprints, how many story points and business value was burned)
And since I couldn’t attend their retrospectives, I asked them to briefly explain what they improved in their process for each sprint
The presentations went well and what was most interesting is that all the teams had one main problem during the sprints : Lack of communication!
Strange, we are all in the same classroom during the whole afternoon, and yet, they did not communicate. It’s the exact same problem in a real Scrum Project. I was confronted to this kind of things in my work before as well. But the students learned fast and started asking the PO about everything every time they had a doubt. If only, the adults with whom I used to work had the same state of mind 🙂
At the end of all the “Release Reviews”, we did a “Global Retrospective”. It was aimed to discuss the course and the way we worked during the past weeks.
Students had a lot of positive things to mention :
Paper Plane Game (of course :))
Git Extensions (in the end they like it)
Discovering of Scrum
The fact that they had different Roles in the teams
The team work and spirit
Big teams (for them 4 or 5 is a big team, they mostly work in groups of 2 at school)
Among negative points they expressed their lack of knowledge of GIT and also the fact that they learned less C# than expected because they “lost” time with GIT and Scrum.
This was the end of MY “Sprint 0” for this experience with Scrum. The aim was to make them discover the main concepts and try to work on a very small project for a start.
Now they have a small idea on how it works and they have a 6 weeks practice.
As a next step, we are going to start working on a bigger project. Every team will have the same project, but they will plan their own stories and sprints.