The two trainers from Zilverline, Michael Franken and Sander Nieuwenhuizen, did a really great job in making this training a big success. Here is my report of the two day training.
Day 1
Today was the first of two Sprints (days) of the Certified Scrum Master (CSM) training. It was really a great day with a lot of useful information.
We started the day with coffee and some introductions. After the coffee the training began with a game called ‘The Ball Point Game’, where we were forced to work together as a team and innovate by listening to each other. Another important goal of this exercise was to challenge the trainer on the given assignment. It was immediately made clear that we were expected to actively participate.
Next we had to write down why we came to this training and what we wanted to learn. We did a stand-up and decided as a group on what we wanted to learn from the course. The outcome was a prioritized list which would be our agenda for the next two days. It was a really useful exercise because during the prioritization we were not allowed to talk. Even though it felt very unnatural it was a very effective way of doing a fast prioritization.
Basically we created a training ‘backlog’. It was made very clear that is was allowed to change this backlog during the training. A key point in Agile and also Scrum is that change will happen, Scrum allows for change! The backlog is constantly subject to reprioritization and features can be added or removed as the product owner requires this.
Now we had a clear agenda the trainers gave an introduction on why Agile and Scrum are fundamentally different from more traditional software development methodologies like Waterfall and RUP. They also made it clear that software development is not a factory like industry. It is very difficult to predict upfront what the exact outcome of a project will be, how much time a project will take and what features the eventual product will certainly contain. You simply cannot predict time and budget and features upfront. Especially the more traditional methodologies fail to deliver on on time and/or budget. They presented some figures form the Chaos Report (Google for: The Standish Group Chaos Report) on failed IT projects to support this statement. It turns out that projects that have max 6 team members and a duration of 6 months have a success rate of 55%. When duration and team members increase, the success rate starts dropping dramatically!
Before lunch we had covered the prereqs for starting an Sprint and where given an overview of a Sprint and all Scrum roles and Stakeholders involved. Especially the roles of Scrum Master and Product Owner were discussed in more detail. A common mistake is to think that a Scrum Master is a part-time role. But in reality, especially in teams that are just starting Scrum, the Scrum Master has a full time job in making sure the Scrum process is applied correctly.
Another really important role is the Scrum Product Owner. This is the person that should make sure that all the requirements are clear and prioritized so the team can start development. The Product Owner can be the typical project manager, but also has to make sure that he/she understands the needs and problems that the team is facing.
For me it was an eye-opener to hear that people who are not fully committed to the project are NOT part of the Scrum team. They can be promoted to stakeholders, but are not actively involved in the daily Scrums etc. They communicate with the team through the Product Owner. Example stakeholders are: testers that work on multiple projects, architects, etc. Basically, if you are cannot commit to the team, you`re out!
When the group resumed the training after the lunch we were given an introduction of the Scrum Basics. The group was separated into 3 teams and we did some exercises with defining stakeholders and user stories. With these user stories we created a prioritized product backlog. Michael explained a few techniques for defining user stories. He also showed us a technique called the Nine Boxes, which can be used to interviewing a customer for collecting requirements.
Next up was an exercise with Planning Poker. I already had some experience with planning poker but it was really useful to learn from the extensive experience of the trainers but also the other people in the group.
We closed the day with a retrospective technique called Temperature Reading. In this session the team members are given the opportunity to tell what went well, what went wrong and what needs to be changed.
For me the key takeaway points of today where:
- Software Development is not a factory like industry!
- Scrum is not Rapid Application Development
- Scrum Master is a fulltime job!
- People that are not dedicated project members are NOT part of the Scrum team
- The product owner role is very very very important!
Tomorrow is the second (and last day) of the training. According to the trainers we should be capable of passing the CSM exam after day 2.
Day 2
Day 2 started at 9:00 AM in Hotel Breuken, the Netherlands. After an exciting first day, I was ready for a new Sprint!
I forgot to mention a few important things that I had learned the first day, but they are also covered in this post so continue reading 😉
We started the day with a stand-up meeting. As you might have noticed, the two day course also uses Scrum, eat your own dog food I guess? 😉 During the stand-up we were told what the agenda for this day would be. The trainers took the feedback of the retrospective of day one and used that as input for the agenda for day two. The agenda items had already been prioritized and estimated by the trainers.
Our agenda of day two would be:
- Spaghetti Game
- Scrum in Detail
- Selling Agile
- XP Game
- Retrospective: Timeline
Spaghetti Game
After the stand-up the group was invited to the back of the meeting room to play a game called the Spaghetti Game. The point of this game is to show that directive management does not work better than self-organizing teams. If you want to know more about this game LMGTFY.
Scrum in Detail
During day one we covered most of the Scrum basics, but we still had to go into the details of Scrum. According to the trainers we should be able to pass the exam after finishing Scrum in details.
The following three major subjects still needed to be discussed in more detail:
- Scrum roles
- Scrum activities
- Scrum artifacts
Scrum roles
There are three roles that are essential for Scrum:
- Product Owner (PO)
- Scrum Master (SM)
- Team Member (TM)
The Product Owner is the mediator between the team and the rest of the world. The customer and other stakeholders communicate with the team through the Product Owner. It`s not forbidden for people outside of the team to speak with the team, but formal communication should always be through the Product Owner.
The Scrum Master role, when looking at it from a distance, looks really simple. The Scrum Master makes sure that the team uses Scrum correctly and helps the team by removing any blocking issues. But in practice the Scrum Master makes sure that also the outside world also understands why a Scrum project does things the way it does. The Scrum Master makes sure all activities take place, communication is done through the right persons and all activities are timeboxed and executed properly.
Team members in Scrum are people who are dedicated to work on a Sprint. From Sprint to Sprint the team may change, but it is better to keep the team together for a longer period (one or more projects!).
Activities
An important aspect of the Activities in Scrum is that they are all timeboxed. This means that there is a fixed amount of time reserved for a specific activity. The following important activities were covered:
- Preparing a Sprint
- Planning Session 1 and 2
- Sprint Review: important moment for feedback
- Retrospective
Activity: preparing a Sprint
What we had learned from day 1 is that a good preperation of a Sprint is essential! If the Product Owner has not done his homework the Sprint will become one big mess. What I forgot to mention in day one is that the Product Owner relies heavily on the team for getting the Product Backlog estimated properly. We were told that a team will spend about 25% of their time doing estimations for the Product Owner. This can be done whenever the Product Owner needs an estimation or at a fixed time during the day. You can use the planning poker technique for providing estimations.
Summarizing: before you can start a Sprint there needs to be a prioritized and estimated Product Backlog!
Planning Session 1 and 2
There are two planning sessions in Scrum, normally they take place in the first day of a new Sprint. The first planning session is with the team, SM, PO and optionally with stakeholders. The goal is to make sure that the stories for the upcoming Sprint are clear for the team. After this planning session the stakeholders must leave and the team starts the second planning session. During the second planning session the stories are broken down into tasks and the team gives commitment for the stories.
The outcome of the planning sessions is an understood amount of work that is doable according to the team.
Scrum artifacts
There are not a whole lot of artifact described in Scrum, unlike RuP for example. This does not mean that you cannot use other documents and artifacts to support the proces. Scrum descibes the following artifacts:
- Product Backlog
- Sprint Backlog
- Burndown Chart
- Overall Progress Burndown Chart
Product backlog
The product backlog a prioritized list of things to do. The items with the highest priority are on top of the list and are also more detailed. As work progresses the items lower on the list start moving to the top and need to become more detailed. The Product Owner is responsible for making sure this happens.
Sprint backlog
During a sprint there is also a backlog. Items from the Product backlog are moved to the Sprint backlog and are broken down into tasks and put on the Sprint backlog. Again, the Sprint backlog is also prioritized and items that are on top of the Sprint backlog have the highest priority.
The Sprint backlog is typically to be found on the Scrum planning board. It contains the Sprint backlog, unplanned items and Burndown chart.
Burndown Chart
This is a chart that displays the amount of work to do and the time that is left in a Sprint. You can easily see if the team is still on track and will manage to deliver on time.
3×3
Now we finished Scrum in details, we were ready for the Certification exam 😉 To demonstrate this, we had to explain the Scrum details in groups. We were given some time to prepare a demonstration of what Scrum means, the 3 groups were assigned one of 3 subjects:
– Scrum Roles: ScrumMaster, ProductOwner, TeamMember
– Scrum Activities: Timeboxes: Sprint, Stand-up, Planning Session I & II, Sprint Review, Retrospective
– Scrum Artifacts: Product Backlog, Sprint Backlog, Burndown chart
But first lunch, after the lunch break the groups presented their Scrum subject.
Selling Agile
We were given some tactics on how to sell Agile in an organization. It is important that Agile and Scrum are not a goal on its own, but should actually provide value. In some organizations it might just not work. It also takes some time to get an organization to adopt Agile and/or Scrum.
The following items were covered:
- money for nothing
- change for free
The XP Game
The last game of the training was the XP game. In this game we were expected to apply Scrum hands-on.
Retrospective: Timeline
Last up, a retrospective technique called Timeline. In this technique you should write down on post-its what you think went well and what should be better, max 3 post-its for each. The post-its should be placed on timeline, representing the Sprint, where you got the feeling things went better or went wrong.
This was the last exercise of this two day training. We ended the training with a group photo.
The Online Exam
Two days after the training I received an email of the Scrum Alliance about the Certified Scrum Master exam. The exam is a multiple choice test to see if you indeed know what Scrum means. I did the test in approximately 15 minutes and passed it, so I am now a Scrum Master now 😉 But I feel like i just covered the basic. To become a real master in Scrum you need to succesfully apply it in projects!