By Erik Gfesser — Aug 25, 2011

Certified ScrumMaster Training: Day 1

Notes taken for posterity during the first of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

The course started by individual attendees identifying 5 of 22 provided topics that we thought might be important take-aways, followed by the class breaking up into pairs in order that one might convince the other to switch one of the 5 chosen to another topic.
The 5 topics I had chosen were items I had not yet encountered to any significant degree in the workplace or graduate school, such as specific artifacts and distributed Scrum. The plan was then to apply post-it notes to each of the 5 topics as they were covered in class.

Of the 22 take-away concentrations, the following 5 were the most popular in this class session (all written intentionally in the form of user stories):

7- I can describe how to use the Scrum framework on large projects using Scrum of Scrums and/or other approaches to scaling.
6- I can facilitate the team through the Sprint.
6 – I can advocate for Scrum teams to be colocated, but also help a team overcome the reality of distributed teams.
5 – I can explain the importance of complexity and its impact using empirical or defined processes.
5 – I can describe the responsibility of the ScrumMaster.

These types of exercises tend to interest me, because much of the value add for me in corporate training tends to come from the interactions between colleagues rather than the material itself.

The latest Scrum Guide released 3 weeks ago was included in the handout workbook. The instructor noted that the release planning portion was removed from the previous Scrum Guide.
Development of the Certified Scrum Professional from the Scrum Alliance had its origins in the failure of the Agile Software Development with Scrum text by Ken Schwaber and Mike Beedle and the desire to help realize Scrum practices in its readership.
According to the instructor, worldwide there are about 160k Certified ScrumMasters, about 10k Certified Scrum Professionals, 130 Certified Scrum Trainers, and an unknown number of Certified Scrum Coaches and Certified Scrum Developers.
The instructor also noted that there is some redundancy between Certified Product Owners and Certified ScrumMasters. Although Certified ScrumMaster Professional is the drive right now, it is not a certification that should be called out in one's email signature etc because it does not represent skills or experience, just understanding.
In Scrum, "programmer" is not equivalent to "developer". The development team is comprised of the programmers, architects, business analysts, testers etc with which we are familiar, and all are developers. In addition, the Scrum team is comprised of both the product owner and the development team.
Deliverables are intended to be in a shippable state at the end of each sprint, but not necessarily shipped or deployed to production. To release to production is a business decision.
Identified tasks are not an explicit requirement of Scrum. The development team determines how this is to be done. Even though tasks are the most common method to plan, this requirement was removed in recent releases of the Scrum Guide.
Project resource needs are starting to be requested in terms of Scrum teams of x people for x months.
During our discussion of Scrum motivations, we discussed at what point project tasks are performed during traditional Waterfall and Scrum project timelines. It was amusing for the my colleague and I to find ourselves working through estimation, requirements, analysis, and design, and then working backward from production deployment to fill in the rest of the activities for traditional Waterfall.

During class, I recalled to my colleagues the practices that one of my project managers followed early in my career following the implementation of an enterprise-wide project dashboard. The project manager would spend considerable time each week tweaking the project plan until it would turn green, and consistently trimmed estimates provided by my colleagues in order that they would fit in the predefined timeline, not unlike the Waterfall portion of this exercise.

Scrum is similar to Extreme Programming (XP), except XP has more constraints around how programmers are to perform tasks.
Project complexity is really the driver to determine whether to take an empirical approach. Requirements and technology (and maybe organizational complexity) determine complexity, not factors such as team size and colocation of team members etc.
Of the 3 pillars that uphold every implementation of empirical process control (transparency, inspection, and adaption), adaption is usually the most difficult. The question ends up being: What is the most tolerable empirical approach for my organization today? And agile hybrid approaches are common.

After discussing project complexity and empiricism, we broke up into teams of 3 and 4 to discuss the 12 principles behind the Agile Manifesto, and chose 3 principles that we thought can be removed, and 3 principles that we thought are the most important.

Across the teams in this class session, the following 3 were the most popular for principles we thought are the most important:

3 – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2 – Working software is the primary measure of progress.
2 – Business people and developers must work together daily throughout the project.

The following principle was the only one that managed to get any hits for being removed from the Agile Manifesto:

2 – The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The instructor indicated that some of the writers of the Agile Manifesto have indicated that some of these principles would have been better left out, but that coming to agreement on these principles during a relatively short meeting 10 years ago was a huge achievement. That said, this exercise resulted in considerable debate.

One principle that generated debate was as follows: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." One team argued that "requirements" is often assumed to be business requirements, but the term can also be assigned to technical requirements, and so they argued in favor of this principle.

Another principle that the teams did not generally agree upon was as follows: "Business people and developers must work together daily throughout the project." The term "daily" was the catalyst of the disagreement, because of the mandated frequency of working together.

My team chose the following principle as being one of the 3 we thought are the most important: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly." Speaking from my experience, I have witnessed the value that the Agile Retrospective provides, having used them on multiple projects throughout my consulting career.

One problem that the instructor has witnessed is that few Certified Scrum Trainers have been product owners. Most have been programmers and project managers.
According to Scrum, only one person is intended to be product owner, but in practice this is very difficult.
There appears to be a move in the Scrum community to replace "prioritizing" with "ordering" the Sprint Backlog, and "committment" language has been replaced with "forecast" in Scrum literature, although the instructor prefers the original verbiage.

Unfortunately, I introduced the term "semantics" as part of the discussion on prioritizing versus ordering. What I had intended to convey was that "prioritizing" seems to communicate business needs or wants, whereas "ordering" seems to communicate the order in which tasks need to be completed, perhaps because of dependencies between tasks.

A lot of discussion surrounded the term "shippable" during the portion of our class session working on an exercise where we broke out into teams of 3 and 4 to talk about our current projects and what we can do in each Sprint, what we would like to do in each Sprint but are not able to do today, and what tasks should not be considered as needing to be completed in a Sprint.

The term "shippable" is intended to convey that a deliverable is in shippable state. In other words, it can be released to production or shipped to customers, but is not for any of a number of reasons. For my contribution to this exercise, I indicated that during my upcoming project, I might consider refactoring a task to be done as part of a Sprint, but tasks such as load testing probably fall outside the Sprint, and that I may like to include testing on counterparts to the proprietary appliances that are expected to be used in production, but will probably not be able to do so.

In addition, the instructor said jokingly that "what goes on in the Sprint stays in the Sprint", meaning that hand-offs between programmers and QA for example within a Sprint should not be counted as defects. Remaining defects go back in the Sprint Backlog if not resolved during any particular Sprint. In Scrum, a defect is just work prioritized by the product owner.

Subscribe to Erik on Software