SCRUM : We’re getting used to it

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

  • Scrum
  • Git
  • C#

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 :).

See you soon for more Scrum Adventures!

SCRUM : A new beginning

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)
  • The test data has to be based on real data, and they can get information from this website : http://www.cabanes-suisses.ch/

So let’s get the ScrumParty started!

 

Lesson 5-6 : SCRUM, Sprint 2-3 – and a first release

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 :

  • No PowerPoint
  • 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.
More details coming soon!

Lesson 4 : SCRUM, Sprint 1 – a hard beginning

After a few successfull lessons, we finally initialized the first sprint, starting with our first standup for the 3 teams.
First stand-ups
The stand up went pretty well, but once the sprint started, I totally lost control of the groups.
  • Some groups had problems with their GIT project, merges went wrong, they lost some work, couldn’t cherry pick it.
  • Some groups didn’t understand that the whole point of scrum is to do things as defined in stories. So they continued working as “before” : first we create the whole interface, then we will do the code behind the buttons, even if there is no story in our sprint for the whole interface.
While I was repairing the GIT issues of one of the groups, the third group finished the sprint, had a retrospective, planned a new sprint, and then I realized that they didn’t even do a sprint review.
In short, everything went kind of wrong! I couldn’t follow the 3 groups at the same time and I couldn’t help them with everything they needed.
When we started, we already knew that the 3 projects were too small to work have many sprints, but we wanted to experiment SCRUM anyway and maybe then start a more complex project in order to really have a chance to implement the Scrum Framework.
But I didn’t really realize at which point I was suppose to help them and support them in their work, which created a big mess in the last lesson.
Next week, I hope I will find a solution to manage the 3 teams and their respective issues!

Lesson 3 : SCRUM, Sprint 0

For this third lesson with my 14 students, we kept the same groups as for the Aiplane Factory done the week before. (see last article)

So, 3 groups of young Scrum beginners :

  •  2 groups of 5 
  • 1 group of 4 people. 
Every group has a Product Owner and a Scrum Master, and of course a Dev. Team.
Being in a school environment, the PO and the SM are also developers since their Scrum roles aren’t enough to have a fulltime occupation.
So for this 5 period lesson, we decided to have a Sprint 0. The groups chose a project that they already developped in their Delphi course. I wanted them to choose something that they already did before, so that the “Functional specs” are clear enough. The aim being to recreate the same project using C#.Net and working with SCRUM.
For the Sprint 0, I gave the following instructions to the different groups and to the different roles :

Product Owners 

  • Write user stories / epics for their project and try to make them the smallest possible.
  • Give a priority to the stories by setting a Business Value from 100 to 2100 to them
  • Once the stories are ready, start the Sprint Planning. The PO is responsible to explain the stories to the team.

Scrum Masters 

  • Prepare an Excel Spreadsheet that will allow them to follow the project, know which story is asigned to which developer, prepare a working Burndown Chart and test their Excel Spreadsheet with some fake values
  • Prepare the physical board where the post-its corresponding to the sprint stories will be presented and where the stand up will take place

Developers

  • Learn what is GIT by following some tutorials on the web
  • Prepare a .NET solution for the future project
  • Prepare a GIT Repository for team work
  • Take a CSharp tutorial in order to get to know this programming language
Once everybody was ready, I explained that we will start the Sprint Planning. Every team had to do its own Scrum Poker.
In order to avoid buying Scrum Poker Cards, every student downloaded an App for their phones which allowed them to play the Scrum Poker and plan the sprint.

  • Android phones : Scrum Poker App
  • Apple phones : Scrum Time App
  • *No one had a Windows Phone, ouf! I didn’t even check if there is an app or not 😀
At the end of the afternoon every team engaged for a certain number of story points to realize during Sprint 1.
And here are the dashboards, ready for Sprint 1!!!!!

See you next week for Sprint 1!

Lesson 2 : SCRUM, let’s try it !

For this second lesson, I first started by reassessing what my students were supposed to learn the week before, meaning all the SCRUM terminology.In order to accomplish this, I re-used the flashcards created the week before, but this time, I made the students choose a card randomly and present it to their classmates. This exercice allowed everybody to get back on track.

After this small review, I explained that the aim of the afternoon will be to create paper planes, which created a total chaos in the classroom.

My objective for this lesson was to make them understand the way SCRUM works without starting to develop a real program yet. I remembered the first course I attended about Scrum and a game we played at that time. The game was something similar to the paper plane creation but we had to make boats and hats.

Anyway, I searched the Internet to try to remember how the game worked exactly, but instead I found the Paper Plane Factory Game, which I decided to use.

I split the students in 3 groups, 2 groups of 5 and one group of 4 and started the game by alternating 2 minute sprints and 1 minute retrospectives. Before each sprint students were asked to estimate the number of planes that they plan to produce. At the end of each sprint, I tested all the planes and decided if they were conform to the specifications or not.

Students simply loved the concept! Imagine 14 boys, well young men (18-22), learning that they will be devided into 3 groups in order to produce paper planes. 🙂

They definitly had fun! And more importantly, through the game, they learned :

  • what is a sprint,
  • what is a retrospective, 
  • what are the acceptance criteria 
  • what is quality. 

The learned how to re-adjust their estimation and their work-flow from one sprint to another. They also learned to deal with “technical” constraints, for example having only one pen for each group.

The game took us a bit more than an hour, and at the end, the different teams decided to stay together for the next step of the course : Developing a real project with SCRUM.

This exercice created a team spirit in every team, and even if in the begining they weren’t very happy with their groups, at the end they decided to keep the teams as is.

Next week, they will choose an existing exercice developed in Delphi and will have to write the backlog and start to plan a sprint to re-do the same exercice in C#.NET.