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. The two trainers, Michael Franken and Sander Nieuwenhuizen of Zilverline, really did a great job in making this first day a big success.
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 fundamentaly 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 prioritzed 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.
To be continued!
nice one
Do post the next part
Hi deep root,
Just posted part 2!