Scaled Agile Notes – SSM certification

Posted on by Andy Jenkins

Agile Manifesto Concepts

Manifesto

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

12 Principles

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity-the art of maximizing the amount of work not done-is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum in a nut shell

Scrum creates competition for objective completion by removing competition against team mates or at least hides it real well so it isn’t obvious… We live in a competitive world and Scrum drives collaboration and being competitive as a team. No one want to be on a bad team and no one wants to fail the team.

Exam Sections

The exam details are located here ScaledAgile Exam Details. I will not be keeping this page current and you should use the resources directly from their site. You have to pay for the access so use it.

Take note of the weighting percentages. With these test it can either mean that that is the percent of the number of questions in each topic you will receive or the questions have a weighting factor built in. There are 45 questions so I am assuming it is the later when you look at the math. This means that you may end up having lets say 9 questions in each section but the weighing to the final score is calculated. So say you miss 100% of the questions dealing with Iteration execution and Finalizing  the program increment you could mis upwards of 15 questions on a 45 question test with this weighting and pass in a perfect scenario. I mention this to help keep me calm for these tests. Go with the first best answer and move on don’t rethink it. Remember a re-take is only $50.00 if you are stressed that is cheap enough to throw away an attempt or two and you may get lucky on one of them. It is Scrum after all and it is all about iterative improvement. Take the exam the same way.

A final note is you agree to the following candidate-agreement as a result I will not post any questions I was presented with for failed questions I will be studying and writing out the concepts that I missed in the sections I have prepared in this page. That is the sole reason for this page.

The SAFe Scrum Master Guide is used in addition to these links for each section. The guide is a PDF you receive when you purchase training. You should start by purchasing the materials. This material and the site are protected under a copyright and the contents will not be posted here. This is the material you will need to pass the certification exams. As an example in Scrum they state you can have a 1 month sprint while SAFe recommends 2 weeks. The intent of this is to pass the exam and you are being tested on SAFe’s implementation of Scrum not Scrum itself. 

Some of the material I am reposting is licensed under the a creative commons license(s):

© 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode

 

Introducing Scrum (13%)

Scrum Master Role (38%)

PI Planning (18%)

Iteration execution (22%)

Finishing the Program Increment aka PI (9%)

Scrum

Scrum Definition

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:
  1. A Product Owner orders the work for a complex problem into a Product Backlog.
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  4. Repeat

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage

Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Developers

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

  • Creating a plan for the Sprint, the Sprint Backlog;

  • Instilling quality by adhering to a Definition of Done;

  • Adapting their plan each day toward the Sprint Goal; and,

  • Holding each other accountable as professionals.

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

  • Developing and explicitly communicating the Product Goal;

  • Creating and clearly communicating Product Backlog items;

  • Ordering Product Backlog items; and,

  • Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

Scrum Master

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:

  • Coaching the team members in self-management and cross-functionality;

  • Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

  • Causing the removal of impediments to the Scrum Team’s progress; and,

  • Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

  • Helping find techniques for effective Product Goal definition and Product Backlog management;

  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;

  • Helping establish empirical product planning for a complex environment; and,

  • Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

  • Leading, training, and coaching the organization in its Scrum adoption;

  • Planning and advising Scrum implementations within the organization;

  • Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

  • Removing barriers between stakeholders and Scrum Teams.

Scrum Events

The Sprint

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;

  • Quality does not decrease;

  • The Product Backlog is refined as needed; and,

  • Scope may be clarified and renegotiated with the Product Owner as more is learned.

  • My be considered a short project.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

    1. Why is this Sprint valuable?
      1. The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
    2. What can be Done this Sprint?

      1. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

      2. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

    3. How will the chosen work get done?

      1. For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

      2. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

      3. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Scrum Artifacts

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Sprint Backlog

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

My SAFe notes (Scaled Agile Framework)

SAFe Scrum cliff notes…

Agile development concepts

  • Delivery early and consistently
  • incremental delivery of the project
  • Agile Manifesto

Scrum concepts and values

There are three pillars in Scrum
  1. Transparency
  2. Inspection
  3. Adaptation 
There are five Scrum values
  1. Courage
  2. Commitment
  3. Focus
  4. Respect
  5. Openness
Terminology Differences…
  •  Sprint -> Iteration
  • Daily Scrum -> Daily Strand-up (DSU)

Transparency, Inspection and Adaptation (Scrum Pillars) -> Short learning cycles

Iteration – Single cycle where where each team works for a duration -> “Iteration” of fixed time. The recommended is 2 weeks. The goal an iteration is to deliver a working system each cycleiteration.

  • defines
  • builds
  • integrates
  • test

The Team Backlog is the beginning and end of it all. It is used to organize the teams work. It all falls apart without this. If it isn’t in the backlog it isn’t getting touched. If it is in the Backlog it still may never be touched. The Backlog is made up of Stories and Enabler Stories. 

  • Created by the Agile Team
  • Ownedprioritized by the Product Owner

The key to incremental development is breaking the Stories up that are in the Backlog into verticalincremental slices. Work can then be validated and adjusted at each increment allowing for further understanding of the desired functionality.

Agile teams in the SAFe framework

SAFe delivers -> alignment, collaboration and delivery

Core Values of SAFE

  1. Built-in Quality
  2. Program execusion
  3. Alignment
  4. Transparency

SAFe Principles

  • Economics
  • Apply systems thinking
  • Assume variability keep differing opinions
  •  Build incrementally learning from each cycle.
  • Base milestones from the evaluation of working systems
  • Control WIP, small batch sizes and keep queues relevant
  • Predictable cyclesiterationscadence with cross teaming planning.
  • Motivate the team 
  • Rapid decision making. Remove sign off for trivial items. 
  • Value is where it is at

Agile Team

  • Two week interati0ns
  • Two specialty roles
    • Scrum Master – value, iteration, remove blockers, events take place.
    • Product Owner –Roadmap: Vision, Prioritizes, manages teams questions, Accepts Stories,
  • Five to 11 people
  • Story and acceptance criteria origination
  • Full life cycle handling of the Story
    • Define
    • build
    • test
    • develop

Agile Release Trains

  • 5-12 teams
  • Share a common Program Increment (PI)

ART eventsceremonies

  • PI Planning: Teams commit to objectives (2 Days)
  • ART Sync: Teams offer up a progress report (1 Hour)
  • System Demo: Stakeholders offer opinions of the Objectives (1 H)
  • Inspect and Adapt: Retrospective for ART

Scrum Master Role

Responsibilities

  • Strivingenforcing for the current goals for: PI and IG
  • Removes blocker
  • Builds the team
  • Schedules these meetings:
    • PI Planning, System Demos, 
  • Supports the Product Owner
  • All Cross Teams coordination
  • Manages story pointing
  •  

Effectiveness

High-preforming teams

  1. Forming
  2. Storming
  3. Norming
  4. Performing
  5. Adjourning

https://videos.scaledagile.com/watch/ZGYn3u2BKZzje9X95yxHQm

Team Events

Stick to the basics of a good meeting

  • Backlog Refinement: Prepare for IP
  • Iteration Planning:  (2 – 4 Hours)
  • Daily Stand-up: (15 Minutes)
  • Iteration Review: Team and stakeholders. (1 H)
  • Iteration Retrospective: (1.5 H)

Coaching

  • individual -> team
  • know it all -> facilitator
  • knowing the answer -. guided discovery
  • directing -> guiding
  • right for me -> right for business value
  • fixer -> team problem solver

 

Cross team communication

  • ART Teams 
  • Scrum of Scrums
  • When in doubt the Scrum Master is in control

Team behaviors: 

Dysfunction pyramid

  • Ignore results
  • Accountability
  • Commitment
  • Fear of healthy conflict
  • No trust (Team killer)

Team Conflict

Find the core issue get past the symptoms…

PI Planning

PI Planning

Program Increment (PI) is cadence based like everything else. Set the schedule. 

  • 2 days every 8 – 12 weeks
  • Everyone attends, participates and plans.
  • Product Management owns Feature priorities.
  • Development Teams own Story Planning and rough Point estimates.
  • Engineers and UX share knowledge and expertise. 
  • Cross team communication
  • Align the business with the Teams in setting PI Objectives
  • Identify cross teamvendor dependencies
  • Balance work in with WIP
  • Faster decision making
  • Features -> Stories -> BV
  • Features should fit in one PI or be broken up
  • Stories should fit one Iteration dedicated to a single team or be broken up.

Use INVEST for Stories:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Story –  3C’s

  • Card
  • Conversation
  • Confirmation

Stories evolve from general statements -> specific examples -> tests for each example

Acceptance criteria: Given -> When -> Then foo 

Enabler Stories breed User Stories. There are for types

  1. Infrastructure
  2. Architecture
  3. Exploration
  4. Compliance

Story pointing aggregates and estimates based on

  1. Volume
  2. Complexity
  3. Knowledge
  4. Uncertainty

Stary points are relative estimate some people adhere to using Fibonacci numbers to drive out large stories that need to be broken down. For the purpose of the test a 6 point story should take 3 times as long. I don’t agree with this in principle and actual execution but remember this is for the test. 

The Scrum Master facilitates the pointing of stories while ensuring full team participation, relative estimates, driving consensus on point value, SME’s are present if needed and time boxing. We want to avoid letting non-team members from pushing for lower estimates, we need everyone to participate.

Refactors are changes to the base without causing any loose of feature or behavior

Spikes are used to determine the unknown. there are two flavors we have Technical Spikes and Functional Spikes

PI Plans

PI Planning is driven by the RTE 

Review final plans

Commit to PI Objectives

Iteration Execution

Completing a PI 

Practicing SAFe

Exam cram for SSM

 

First run at taking the practice test on the SSM site.

I just finished the class yesterday. I payed attention as well as I could to 16 hours of boot camp style training. My instructor was great he was informative as to what is expect on the test through out the course.  I have the page above prepped for notes and what not. So if I do not fill out my everything remember this is my study and test prep. I find it is best to take these test while the classroom is fresh in my mind. I also believe in taking the practice tests first so I can see where my deficiencies are.  I review each question and look up the right answer for each missed question. These are turned in to “flash cards” to increase my speed and accuracy.  Okay I scored a 70% with no prep… (more or less I didn’t nail any section)The questions I missed where in the following topics:

  • PI Planning RACI
  • What are the effective coaching behaviors for a Scrum Master
  • Roles and responsibilities during an iteration
  • General SAFe decision tree for releases
  • Anti-patterns for IP planning
  • When and where each demo type is preformed
  • Scrum master duties… when are they a participant and not the facilitator