Certified Scrum Master

About a month ago, I took the Certified Scrum Master course with Bas Vodde as our trainer.  I’ve wanted to take a CSM course when I started reading more on Agile and Scrum but costs were the deal breaker: there were no local courses being offered, and the ones nearest the Philippines were beyond reach financially.  Good thing our friends from CodeLean brought the course to the country and made it accessible to us.

And I almost missed it!  I wasn’t feeling 100% at that time and had to work from home earlier that week.  I managed to pull myself up and get to Makati for the course.  I had three objectives for joining , which were:

1. To know the difference between books on Scrum and the actual CSM course.  Each of us were asked to write down why we took this course and this is what I put down.
2. Gather the perspective of other professionals in this industry.  I’ve only worked with O&B so far and thus my experience is limited to that.  I was hoping to get a chance to hear the thoughts of other people from other companies, their situations, and circumstances.
3. To try the food at Dusit Thani, which is where the course was held.  This was my biggest motivator to take the course.

And maybe to become a Certified Scrum Master as well, of course :-).  Plus it was my first-ever company sponsored training, and I was going with Butch,  Joel, and Martin to it.

Some of my takeaways from the course were:

• The keywords to remember in Scrum are: inspect, adapt, and improve.  Exposing these things is what the Scrum process does, and we need to remember that the process is simply a means to this.  I guess it is possible to do Scrum without getting the point of why it was set up this way.
• A Scrum Master is not part of the team, which was huge and something I did not expect after reading Scrum books.  This is to maintain a separation of roles.  The Team needs to decide and implement a sprint as best as they can.  An SM needs to always take a look at the Scrum process and ensure that both the Team and the Product Owner are playing within it.  Both are full time jobs and having the role of an SM and being part of a Team would either: make one less effective in both roles, or give a person too much power in Scrum and start breaking down the process.
• Self-organization is easy to say but hard to do. How hard is something that I didn’t really understand before.  There has to be change both on the organizational level as well as on the individual level to accomplish this.  Self-organization is both letting go and taking responsibility, with a focus on learning and improving. And not everyone is comfortable in doing that which is the hard part.
• There is a huge focus on the Team and its jelling as one.  Bas spoke of teams that have been together for years which allows them to work really well in projects.  Bas suggested different ways to do retrospectives for one, and different activities to get the Team to be closer to each other.
• Culture plays a role in the dynamics of a team.  “Patience” and “silence” are very helpful to being an SM, and are ingrained in Bas culture.  The Filipino culture on the other hand are conscious on emotions which can help resolve issues in teams better.  These realizations highlight the fact that culture needs to be taken into consideration and thus used to a team’s advantage.
• Sprint planning seeks to understand what a Team needs to do in a sprint.  This is done by breaking down stories into smaller units which gives us more confidence in estimation, but the actual process of doing this varies depending on who you ask.  Some people prefer to break down stories to smaller one rather than tasks, and estimate them with story points rather than hours.  This course was on the tasks and hours camp, which I think is a good starting point that can be evolved as needed.
• We had some informal discussions on current trends such as distributed version control systems, acceptance test driven development, Lean, and KanBan.  DVCS is somewhat incompatible with continuous integration, as it lessens the pressure of integrating (read: committing to the source repository) daily, but this is: due to the nature of DVCS and how it started in the first place, something that can be dealt with, and not a problem right now but will probably be in a few years time.   ATDD showed me how it is possible to break down the assembly-line approach to design-implementation-testing which is what usually happens.

And the list goes on.  I’m hoping to be able to expand each of the points above and more in the future as one blog post is not enough to cover them.

It was quite a course and I’m glad I actually took it.  We were about 25 in the course and was quite a mix.  Some were developers while others were project managers.   Some were heads and leaders in their respective IT departments and organizations, while some were simply interested to find out more about this Agile thing.  The questions and discussions that resulted from this were definitely interesting and I hope we can have more of them informally in the future.  And the food was great!  I wish I could dine here everyday.

We had a night out after the first day of the course and took Bas to a local store that served good Filipino food.  He apparently does not like desserts and soup much.  Pictures at my Flickr site.

I’ve spent the past month working with Joel, Butch, and Martin on how Scrum affects O&B as a company, and what things we can adopt.  On a macro level we have begun moving into a more team-based organization, adding a support structure for our teams both in leadership and in career development.  We recognized that not all teams can do the Scrum flavor of Agile and we need to work with this.  On the micro level we started implementing what we’ve learned in the course to our teams with the focus on inspection, adaptation, and improvement.  There is a lot of work to be done and it will definitely take time, but we are at least happy on where we are moving.

And finally, my biggest thought after the course is if I actually want to be a Scrum Master, which is something I share with Lorenzo of Headstrong which was also in attendance.  It would be much easier to simply stay as part of the Team as a developer and handle the technical side of things.  Interesting thought to ponder on indeed.