Professional Scrum Master I (PSM I) Training (Erik on Software)

About

Tuesday, March 31, 2015

Professional Scrum Master I (PSM I) Training

Notes taken for posterity during two days of Professional Scrum Master I (PSM I) training recently provided by Juniper Hill Associates at The Ohio State University earlier this month. Much like my notes for Certified ScrumMaster (CSM) training 3 years ago which you can find here and here, these notes are not intended in any way to summarize the course, which covers material beyond what is outlined here.

Although the instructor informally kept track of a number of Scrum topics that he planned to address by use of a wall board, training was formally broken down into the following sections:

Introductions
Theory and First Principles
The Scrum Framework
People & Teams
The Scrum Master
Scrum At Large
Closing

The instructor summarized this training by explaining that it is intended to (1) help teams understand the rules of Scrum, and (2) help remove impediments (a level of abstraction above what might be expected), since everyone naively applies agile the first time around. Unfortunately from my experience, agile can be naively applied over the long-term as well, a phenomenon which I will attempt to address either here or in a subsequent post.

The purpose of this training is to provide experience and insights so students understand how to best use Scrum to build complex products, as well as understand the theory and principles behind Scrum that guide decision making, and the Scrum Master role. While I originally debated whether I should attend this training, due to past training and experience, I eventually determined that it seemed to make sense to get a refresher, partially because of my current client project and partially because I was interested in this relatively newer certification path.

After initially learning about this certification, I did a little research. One of the better comparisons that I came across is in an informal Stack Overflow discussion here, which also contains a link to a more formal discussion entitled Scrum Master Certificate: Which One Should You Choose? The instructor for this course emphasized after my introduction (during which I noted my earlier CSM training) that Scrum Alliance training varies from instructor to instructor, whereas PSM training materials are consistent. And while formal instruction is not required for the PSM, it also requires passing an exam that is not trivial.

While Scrum is sometimes described as a process, and the "Scaled Agile Framework (SAFe)" a "tailored down process", Scrum is actually a process framework
the instructor warned that process training can be misused
Scrum started at Fidelity, and the Scrum Guide includes a thank you to Fidelity
the instructor provided a review of many of the locations where he has provided training
for example, the West Coast does not have much training because "everyone" tends to do agile
in terms of agile, Cincinnati is where Columbus was about 5 years ago
Boston tends to be a hot spot for agile, likewise as is Atlanta, where VersionOne is located
during student introductions, the class discovered that employee #7 of my new employer was attending class alongside us
in a traditional approach, a plan is put together in order to predict
the agile approach uses a plan that adapts to the situation
with Scrum, goals are set and the situation is inspected along the way
the instructor especially pointed out "the complexity of software development" slide
the phrase "Mary had a little lamb, its fleece was white as snow" can be interpreted in a variety of ways because of the words (such as "lamb" etc) that make up the phrase
agile does not work well in chaotic environments - command-and-control does
a "simple" project just means that the problem etc are well known - this does not mean the project is short etc
in his discussion of relating complexity to management style, the author pointed out the article entitled "A Leader's Framework for Decision Making" by Snowden and Boone
the instructor considers Snowden a genius
mismatches exist between environment characteristics and the jobs of a leader
Deming: Plan-Do-Check-Act (PDCA)
Scrum: Plan-Do-Inspect-Adapt
the situation dictates the type of process
predictive (e.g. for assembly line, construction, accounting)
empirical (e.g. sales, marketing, theater)
empirical typical rather than predictive for software development
we need to be transparent in order to inspect and adapt, and this is tough
in discussing transparency, the instructor discussed a consultant's job at one firm to report everything was going well until close to the end of the contract, after which time there was a fixed period - markup was 7% during the initial period, and 30% for the latter period - this lack of transparency was obviously serving a purpose

agile is not better, faster, cheaper - it helps eliminate waste
failing actually might be a good thing - the instructor gave an example of a project where software was being built on top of an internal company platform, and through this process they discovered all the bugs inherent in the platform, leading to abandonment of the project after 6 months
if this had been a waterfall project, they may not have been even able to finish the initial analysis during this time period, not finding out about the bugs until later
the instructor actually mentioned the book "Software by Numbers: Low-Risk, High-Return Development", a book I read several years ago which was co-authored by a professor at the graduate school I attended
Scrum is similar to chess in that the moves are simple, but it takes a long time to master in a particular environment
the instructor said that he will address the following types of Scrum scenarios during this course: fixed price, fixed time, and based on ROI
what if you are just doing maintenance (fixing bugs etc)? Kanban worries about flow, Scrum worries about evolving a product
the instructor indicated that the average sprint length (according to VersionOne) is decreasing over time and approaching 2 weeks
in response to my question to the instructor as to what he thinks about sprint length, he said that scrum.org indicates the length of a sprint is related to the company's appetite for risk
a shorter sprint introduces less risk, and it can be argued that less maturity might actually be a reason to pursue a shorter sprint
a 1997 case study cited in the "Financial Times" discussed a customer who could not afford a burger, so the restaurant made a burger out of a squirrel that it was able to acquire - the customer got sick and sued - this is an example of lack of transparency as to what is being built and what is going on - tell your customer what you are up to
the instructor claims that the test for this certification is not simple - it has about a 15% failure rate for those who take the class and a higher failure rate for those who do not take the class
the instructor recommends taking the practice test over and over until a 100% score is obtained
30 questions, 85% passing grade - the real PSM I assessment has 80 questions
the practice Scrum open assessment is located here
the PSM II assessment is almost all open-ended questions and is graded by only 2 people
do not get a certificate through the "Scrum Body of Knowledge (SBOK)" - the instructor indicated that the individuals who run the organization are "snakes" and the certificate has no value
the Scrum Master is considered a manager role, but a "good" manager role akin to servant leadership
a Scrum Master should only be associated with one team - the instructor knows of one Scrum Master who was responsible for 7 teams, and all he did was attend meetings, which was not very effective
the product owner is concerned with ROI by sequencing the product backlog, and owns the product for its life, not just the project (which is why they are not called the "project owner")
the instructor described the daily Scrum as a "micro-planning meeting for the day", and as a team matures they tend to move toward a conversation at the card level
developers should address "what did you accomplish?" and "what will you accomplish?", always with the producer/consumer in mind, during the daily Scrum
do not call the daily Scrum a standup!
the development team chooses the sprint backlog, not the product owner etc
Scrum calls the thing being built an "increment", which is to be distinguished from "incremental"
the length of a spring is always 1 month or less, is constant, and is dependent on the business appetite for risk
sprints of 1 week in length prefer Monday through Friday, and sprints of 2+ weeks prefer midweek to midweek time period (most companies do this)
velocity becomes unreliable if Monday to Monday is used, because of potential weekend work
nobody should tell the development team how to do their job
remember that business analysts and quality assurance testers can be a part of the development team
individuals outside the development team who explain what to do, like DBAs, are "velocity vampires"
the instructor noted that the term "grooming" has negative connotations in the UK, so do not use the term in that country (I later looked up the term "scrum" and found negative connotations with this word as well, which is very unfortunate)
the instructor indicated that the sprint review is an inspection of the product, and use of the term "demo" to describe the purpose of the sprint review implies that you are just showing what has been done
do not reject a piece of work during the sprint review - rejecting work during the sprint review implies that it is not being evaluated during the sprint
at this point, I commented to the instructor that this would defeat the whole purpose of agile, and the instructor replied by saying that it does not defeat the "whole" purpose, but most of it
according to Scrum, a true "release" goes to production
if you do not finish a story during a sprint, do not just kick it to the next sprint, because over time sprints can lose meaning - just add it back to the backlog!
using story points disassociated from time keeps people from padding their time
the instructor indicated that the following is a hard concept to grasp: "defer constraining commitments until the last possible moment"
scaled agile sprints have "hardening" sprints for bug fixing etc, but the problem with this is that work gets put off until later
the story points exercise that the team went through was especially interesting
we walked through cards with various city names affixed to them to discuss relative distance from the classroom
regardless of whether the team crawls, runs, or takes a car etc in terms of speed, the categories do not change
using 6 hours as a day, the instructor white boarded Chicago as large, the relatively local movie theater as a medium
in discussing with the team, start with the big for sizing the backlog
the instructor then proceeded to convert chosen sizes to the Fibonacci sequence

after the story points exercise, the instructor gave what he later described as a psychology experiment to the team
the instructor first asked everyone to write down whether they think the height of the tallest redwood ever recorded is more or less than a specified height (some were given a height of 137 feet, and others a height of 1978 feet)
you anchor people when you communicate a value one at a time
however, it is good to have reference points - a referential list - this is "affinity estimation"
someone in the class posed that responsibilities in the example might be different (with regard to distance), such as filling the car with gas, cleaning bugs from the windshield etc, and the instructor immediately said, "Let's not beat around the bush, you have a QA department!" with which you are dealing
re-estimate over time to be more accurate
time to complete = (weeks in sprint) X (backlog / velocity)
the instructor then proceeded to move stories around the board from the above story points exercise, and explained how business value points can be assigned alongside story points
a story always has values for story points and business value points
as depicted in the below photos, velocity (in green) will tend to increase over time, value (in red) will tend to decrease over time, and ROI (in orange) will decrease over time as well
note that the ROI calculations depicted below are worked right to left, where business value points (VP) are divided by story points (SP)
the instructor commented that it is typically a good thing for more than one person to work on the same story
you do not want good programmers per se - you want people who are engaged with the product

an informal survey of the class regarding agile software being used in respective work environments resulted in the following list: AgileZen, LeanKit, Trello, Jira, Rally (Community Edition)
a lot of companies seem to have problems with sprint goals
scrum.org made a controversial change recently - no more sprint goal! - it is called a "forecast"
one question that was raised revolved around a scenario where the UI was built to meet functional specifications rather than looking a certain way - is revisiting the UI considered rework, new work etc? - the instructor indicated that it is really up to the product owner
the instructor asked whether anyone has experienced a canceled sprint, and one person said that they experienced multiple canceled sprints in a row because work was being done quickly and not enough stories were made available - people worked on other projects for a while
the instructor has seen product owners let go twice over the course of his career
someone asked about the handling of holidays, and the instructor indicated that it is much better to have the same time box - it is much better to take on less work for the same amount of time
in discussing the average 2-week sprint, the instructor indicated that a 4-hour planning session usually starts the sprint and ends with a 2-hour review and 1.5-hour retrospective
some companies, however, will just have both the sprint review and sprint retrospective on the first day of the sprint - the review and retrospective followed by sprint planning
the instructor compared how things should be done on a project with the development of a baby - the system should be sliced vertically rather than working on different areas or components individually and brought back together later - a baby does not grow one arm or leg or head at a time, these all develop in parallel
the instructor white boarded different aspects of the definition of "done" for a story, sprint, release, and ROM (routine operational maintenance) etc into quadrants
can we do some of these things in different quadrants?
for example, the instructor worked on a project where the deliverable needed to be FAA compliant, meaning that a 500-page document was part of being done
an FAA representative who had an office in the same building was invited to daily Scrums - he initially poo-pooed the daily Scrum, but quickly came to realize that it is better to be filled in along the way rather than looking at the documentation for the first time at the end
there was rework, but much less than it otherwise would have been
the instructor emphasized that the quadrants help drive conversation
what are you inspecting at the end of a sprint if multiple teams are drawing from the same backlog? - the incement - you should synchronize sprint planning etc across teams
done is for the entire product, not just for a scrum team's increment

free sprint retrospective tool was mentioned: IdeaBoardz
I mentioned the Agile Board Hacks website, as well as my contribution
retrospectives tend to start out tactical
several times throughout the class, a "three amigos" approach was brought up - the instructor indicated that it is probably best to do three amigos after work is pulled into a sprint
in response to a question that inquired about the difference between use cases and user stories, the instructor mentioned an article he had written: "Defining Requirement Types: Traditional vs. Use Cases vs. User Stories"
the definition of "done" is for the big picture, whereas "acceptance criteria" is for a particular story
a portion of the class left early in order to catch a flight in the midst of a coming snow storm, and the instructor called my name and had me answer questions on page 64 of the slides
a "scrum of scrums" tends to be reactive rather than proactive because it takes place as a sprint is in flight
a "team of teams" is another option which the instructor has not seen implemented as of yet

Posted at 11:21 AM in architecture, conferences, process improvement, software engineering | Permalink

Comments

Although the instructor informally kept track of a number of Scrum topics that he planned to address by use of a wall board, training was formally broken down into the following sections:

Introductions
Theory and First Principles
The Scrum Framework
People & Teams
The Scrum Master
Scrum At Large
Closing

While Scrum is sometimes described as a process, and the "Scaled Agile Framework (SAFe)" a "tailored down process", Scrum is actually a process framework
the instructor warned that process training can be misused
Scrum started at Fidelity, and the Scrum Guide includes a thank you to Fidelity
the instructor provided a review of many of the locations where he has provided training
for example, the West Coast does not have much training because "everyone" tends to do agile
in terms of agile, Cincinnati is where Columbus was about 5 years ago
Boston tends to be a hot spot for agile, likewise as is Atlanta, where VersionOne is located
during student introductions, the class discovered that employee #7 of my new employer was attending class alongside us
in a traditional approach, a plan is put together in order to predict
the agile approach uses a plan that adapts to the situation
with Scrum, goals are set and the situation is inspected along the way
the instructor especially pointed out "the complexity of software development" slide
the phrase "Mary had a little lamb, its fleece was white as snow" can be interpreted in a variety of ways because of the words (such as "lamb" etc) that make up the phrase
agile does not work well in chaotic environments - command-and-control does
a "simple" project just means that the problem etc are well known - this does not mean the project is short etc
in his discussion of relating complexity to management style, the author pointed out the article entitled "A Leader's Framework for Decision Making" by Snowden and Boone
the instructor considers Snowden a genius
mismatches exist between environment characteristics and the jobs of a leader
Deming: Plan-Do-Check-Act (PDCA)
Scrum: Plan-Do-Inspect-Adapt
the situation dictates the type of process
predictive (e.g. for assembly line, construction, accounting)
empirical (e.g. sales, marketing, theater)
empirical typical rather than predictive for software development
we need to be transparent in order to inspect and adapt, and this is tough
in discussing transparency, the instructor discussed a consultant's job at one firm to report everything was going well until close to the end of the contract, after which time there was a fixed period - markup was 7% during the initial period, and 30% for the latter period - this lack of transparency was obviously serving a purpose

agile is not better, faster, cheaper - it helps eliminate waste
failing actually might be a good thing - the instructor gave an example of a project where software was being built on top of an internal company platform, and through this process they discovered all the bugs inherent in the platform, leading to abandonment of the project after 6 months
if this had been a waterfall project, they may not have been even able to finish the initial analysis during this time period, not finding out about the bugs until later
the instructor actually mentioned the book "Software by Numbers: Low-Risk, High-Return Development", a book I read several years ago which was co-authored by a professor at the graduate school I attended
Scrum is similar to chess in that the moves are simple, but it takes a long time to master in a particular environment
the instructor said that he will address the following types of Scrum scenarios during this course: fixed price, fixed time, and based on ROI
what if you are just doing maintenance (fixing bugs etc)? Kanban worries about flow, Scrum worries about evolving a product
the instructor indicated that the average sprint length (according to VersionOne) is decreasing over time and approaching 2 weeks
in response to my question to the instructor as to what he thinks about sprint length, he said that scrum.org indicates the length of a sprint is related to the company's appetite for risk
a shorter sprint introduces less risk, and it can be argued that less maturity might actually be a reason to pursue a shorter sprint
a 1997 case study cited in the "Financial Times" discussed a customer who could not afford a burger, so the restaurant made a burger out of a squirrel that it was able to acquire - the customer got sick and sued - this is an example of lack of transparency as to what is being built and what is going on - tell your customer what you are up to
the instructor claims that the test for this certification is not simple - it has about a 15% failure rate for those who take the class and a higher failure rate for those who do not take the class
the instructor recommends taking the practice test over and over until a 100% score is obtained
30 questions, 85% passing grade - the real PSM I assessment has 80 questions
the practice Scrum open assessment is located here
the PSM II assessment is almost all open-ended questions and is graded by only 2 people
do not get a certificate through the "Scrum Body of Knowledge (SBOK)" - the instructor indicated that the individuals who run the organization are "snakes" and the certificate has no value
the Scrum Master is considered a manager role, but a "good" manager role akin to servant leadership
a Scrum Master should only be associated with one team - the instructor knows of one Scrum Master who was responsible for 7 teams, and all he did was attend meetings, which was not very effective
the product owner is concerned with ROI by sequencing the product backlog, and owns the product for its life, not just the project (which is why they are not called the "project owner")
the instructor described the daily Scrum as a "micro-planning meeting for the day", and as a team matures they tend to move toward a conversation at the card level
developers should address "what did you accomplish?" and "what will you accomplish?", always with the producer/consumer in mind, during the daily Scrum
do not call the daily Scrum a standup!
the development team chooses the sprint backlog, not the product owner etc
Scrum calls the thing being built an "increment", which is to be distinguished from "incremental"
the length of a spring is always 1 month or less, is constant, and is dependent on the business appetite for risk
sprints of 1 week in length prefer Monday through Friday, and sprints of 2+ weeks prefer midweek to midweek time period (most companies do this)
velocity becomes unreliable if Monday to Monday is used, because of potential weekend work
nobody should tell the development team how to do their job
remember that business analysts and quality assurance testers can be a part of the development team
individuals outside the development team who explain what to do, like DBAs, are "velocity vampires"
the instructor noted that the term "grooming" has negative connotations in the UK, so do not use the term in that country (I later looked up the term "scrum" and found negative connotations with this word as well, which is very unfortunate)
the instructor indicated that the sprint review is an inspection of the product, and use of the term "demo" to describe the purpose of the sprint review implies that you are just showing what has been done
do not reject a piece of work during the sprint review - rejecting work during the sprint review implies that it is not being evaluated during the sprint
at this point, I commented to the instructor that this would defeat the whole purpose of agile, and the instructor replied by saying that it does not defeat the "whole" purpose, but most of it
according to Scrum, a true "release" goes to production
if you do not finish a story during a sprint, do not just kick it to the next sprint, because over time sprints can lose meaning - just add it back to the backlog!
using story points disassociated from time keeps people from padding their time
the instructor indicated that the following is a hard concept to grasp: "defer constraining commitments until the last possible moment"
scaled agile sprints have "hardening" sprints for bug fixing etc, but the problem with this is that work gets put off until later
the story points exercise that the team went through was especially interesting
we walked through cards with various city names affixed to them to discuss relative distance from the classroom
regardless of whether the team crawls, runs, or takes a car etc in terms of speed, the categories do not change
using 6 hours as a day, the instructor white boarded Chicago as large, the relatively local movie theater as a medium
in discussing with the team, start with the big for sizing the backlog
the instructor then proceeded to convert chosen sizes to the Fibonacci sequence

after the story points exercise, the instructor gave what he later described as a psychology experiment to the team
the instructor first asked everyone to write down whether they think the height of the tallest redwood ever recorded is more or less than a specified height (some were given a height of 137 feet, and others a height of 1978 feet)
you anchor people when you communicate a value one at a time
however, it is good to have reference points - a referential list - this is "affinity estimation"
someone in the class posed that responsibilities in the example might be different (with regard to distance), such as filling the car with gas, cleaning bugs from the windshield etc, and the instructor immediately said, "Let's not beat around the bush, you have a QA department!" with which you are dealing
re-estimate over time to be more accurate
time to complete = (weeks in sprint) X (backlog / velocity)
the instructor then proceeded to move stories around the board from the above story points exercise, and explained how business value points can be assigned alongside story points
a story always has values for story points and business value points
as depicted in the below photos, velocity (in green) will tend to increase over time, value (in red) will tend to decrease over time, and ROI (in orange) will decrease over time as well
note that the ROI calculations depicted below are worked right to left, where business value points (VP) are divided by story points (SP)
the instructor commented that it is typically a good thing for more than one person to work on the same story
you do not want good programmers per se - you want people who are engaged with the product

an informal survey of the class regarding agile software being used in respective work environments resulted in the following list: AgileZen, LeanKit, Trello, Jira, Rally (Community Edition)
a lot of companies seem to have problems with sprint goals
scrum.org made a controversial change recently - no more sprint goal! - it is called a "forecast"
one question that was raised revolved around a scenario where the UI was built to meet functional specifications rather than looking a certain way - is revisiting the UI considered rework, new work etc? - the instructor indicated that it is really up to the product owner
the instructor asked whether anyone has experienced a canceled sprint, and one person said that they experienced multiple canceled sprints in a row because work was being done quickly and not enough stories were made available - people worked on other projects for a while
the instructor has seen product owners let go twice over the course of his career
someone asked about the handling of holidays, and the instructor indicated that it is much better to have the same time box - it is much better to take on less work for the same amount of time
in discussing the average 2-week sprint, the instructor indicated that a 4-hour planning session usually starts the sprint and ends with a 2-hour review and 1.5-hour retrospective
some companies, however, will just have both the sprint review and sprint retrospective on the first day of the sprint - the review and retrospective followed by sprint planning
the instructor compared how things should be done on a project with the development of a baby - the system should be sliced vertically rather than working on different areas or components individually and brought back together later - a baby does not grow one arm or leg or head at a time, these all develop in parallel
the instructor white boarded different aspects of the definition of "done" for a story, sprint, release, and ROM (routine operational maintenance) etc into quadrants
can we do some of these things in different quadrants?
for example, the instructor worked on a project where the deliverable needed to be FAA compliant, meaning that a 500-page document was part of being done
an FAA representative who had an office in the same building was invited to daily Scrums - he initially poo-pooed the daily Scrum, but quickly came to realize that it is better to be filled in along the way rather than looking at the documentation for the first time at the end
there was rework, but much less than it otherwise would have been
the instructor emphasized that the quadrants help drive conversation
what are you inspecting at the end of a sprint if multiple teams are drawing from the same backlog? - the incement - you should synchronize sprint planning etc across teams
done is for the entire product, not just for a scrum team's increment

free sprint retrospective tool was mentioned: IdeaBoardz
I mentioned the Agile Board Hacks website, as well as my contribution
retrospectives tend to start out tactical
several times throughout the class, a "three amigos" approach was brought up - the instructor indicated that it is probably best to do three amigos after work is pulled into a sprint
in response to a question that inquired about the difference between use cases and user stories, the instructor mentioned an article he had written: "Defining Requirement Types: Traditional vs. Use Cases vs. User Stories"
the definition of "done" is for the big picture, whereas "acceptance criteria" is for a particular story
a portion of the class left early in order to catch a flight in the midst of a coming snow storm, and the instructor called my name and had me answer questions on page 64 of the slides
a "scrum of scrums" tends to be reactive rather than proactive because it takes place as a sprint is in flight
a "team of teams" is another option which the instructor has not seen implemented as of yet

Erik on Software

Musings on technology, business and running by an architect & open source advocate. Visitors from over 175 countries since 2009.

About

Archives

Tuesday, March 31, 2015

Professional Scrum Master I (PSM I) Training

Comments

Search

Categories

Recent Comments