Please enable JavaScript.
Coggle requires JavaScript to display documents.
Pretty Agile SAFe Scrum Master 16-17 February 2023 - Coggle Diagram
Pretty Agile SAFe Scrum Master
16-17 February 2023
Lesson 2: Characterising the role of the Scrum Master
2.1 Responsibilities of the Scrum Master
t shaped individuals:
https://en.wikipedia.org/wiki/T-shaped_skills
https://www.scaledagileframework.com/scrum-master/
holding a mirror up to the team
facilitator of questioning and thinking
Pareto analysis
5 whys
root cause analysis
facilitates events
is a servent leader
builds a high-performing team
what activities build high performing teams? CoE resources
metrics for high performance - agree on data points
Helps the team improve process
facilitates the removal of impediments
Fosters adoption of Agile practises
Supoprts the Product Owner
Release Train Engineer - the super scrum master - Scrum of Scrums
'System Team' and 'Shared Services', 'Spanning Pallet team'
Shared Services - the swiss army knife - a connection to a dependency visualised in PI planning and call out we need their help.
2.2. Characteristics of an effective scrum Master
Act as a servant leader
Facilitate the growth of others who deliver the results
2.3 High-performing teams
Stages (Tuckman's)
Forming
team agreements
definition of done
how we'll approach our work and work together
Storming
clash and conflict might arise
we have our preferred ways of working
introduce the scrum values/core values
social contracts
Norming
Self manage and resolve their differences
Appreciate each other's strenths
how to interact with the ceremonies
team looks for ways to improve
fun ways to bring the team closer
Performing
Achieving full potential
Metrics introduced
iteration goals reached more quickly
what can we get better at - OKRs
Attributes
Self-organising
effective decision making
open and clear communication
values diversity
2.4 Team events
Backlog refinement - 1 hour
PO
Has the dependency resources in the room to clarify
adds to stories to refine the work
Iteration planning 2-4 hours
Daily-standup - 15mins
JIRA or
Iteration review - 1 hour
team meets with stakeholders to review deliverables and provide feedback
Iteration Retrospective - 1-1.5 hours
team reviews and improves its process before the next iteration
review metrics
Running successful meetings
prepare for every meeting - make it fun no matter how short
clear purpose and agenda communicated
someone to maintain agenda and action items
expect participants to know why they are attending, how they will contribute and expected outcomes
keep to time
leave with clear action items
be prepared to challenge and be challenged
establish default decisions - decisions shouldn't wait for a meeting
2.5 Coach the Agile Team using powerful questions
Let the team find the answers
Be the facilitator not the subject matter expert
coach the whole team to collaborate rather than coordinate individuals
guide rather than direct
focus on business value deliery rather than deadlines and technical options
do the right thing for the business right now vs driving
Examples
What new connections are you making
What had real meaning for you from what you've heard?
What suprised you?
What challenged you?
What's missing from this picture so far?
What is it we're not seeing?
What has been your major learning, insight or discovery so far?
What is the next level of thinking we need to do?
What do we need more clarity about?
What hasn't been said that would help us reach a deeper level of understanding and clarity?
What would you do if success were guaranteed?
Co-Active Coaching Toolkit | Business & Executive Coaching Tools
2.6 Collaborate with other teams
The team should:
Integrate their work often with other teams on the ART (at least multiple times per iteration)
system team on automated system-level tests
https://www.scaledagileframework.com/system-team/
system architect and the patterns we want to use
success metric - teams outside SE don't come to us last minute to call out a dependency on us
CoP - Agenda item. Pair up with another scrum master - go to one of their scrum events. Report back to CoP things about your experience you will incorporate to your practise
Scrum of Scrums
ARTs continuously coordinate dependencies through SoS
Held weekly or more frequently if needed
Timeboxed but is followed by a meet-after for problem-solving
RTE - Syncronize and keep the train on the tracks
2.7 Resolve team conflicts
Influence pyramid - Pettis Yussuf
https://latterdaysaintmag.com/article-1-10399/
team set a comon vision, goals and values
Scrum Master should spend more time helping things go right than dealing with things that are going wrong
Others to see their team mates as human beings instead of obstacles
set a common vision goals and values
educate on achieving consensus
build relentless collaboration
master proven conflict resolution techniques
define as a team what consensus looks like
why it's important
decompose the disagreement
what precisely do they disagree with - can this portion be modified
ask those who disagree to propose a modification
Lesson 3: Experiencing PI Planning
3.1 PI Planning basics
2 days every 8-12 weeks
Everyone plans together
Development teams own Story planning and high-level estimates
Architect/Engineering and UX work as intermediaries for governance, interfaces and dependencies
PI Planning process
Input - program backlog and top 10 features
Output - Team and Program PI objectives and Program Board
Features broken down to Enabler stories and User Stories during PI planning
Personas to better understand users
Story writing
INVEST in a good story
Negoitable - story scope can be negotiated
Valuable - stories are valuable to the customer
Estimatable - Stories can be estimated
Small - stories can fit in an iteration
Testable - Stories are testable
Independent - stories can be developed seperately
Writing good stories
Card - written on a card or in the tool that annotates notes
Conversation - the details are in a conversation with the Product Owner
Confirmation - Acceptance criteria confirm the sotry correctness
BDD
Behaviour described in general terms and can be ambiguous
specific examples of behaviour provide a better understanding
Examples can directly become tests or they can lead to specific behaviours which then are transformed into tests
Discovery of behaviour - forulate specific tests - automate the tests
Splitting stories
https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/#flowchart
Enabler stories
Infrastructure
Architecture
Exploration
Spike
Compliance
signoffs
regulatory submissions
approvals
verification and validation
documentation
Add these types of issues to JIRA
Spikes and refactors
Refactors are a systematic approach to iproving the system without changing ovservable system behaviour
Improving maintainability, performance or scalability
Spikes are research activities to reduce risk, understand a functional need, increase estimate reliability or define a technical approach
Functional or technical spikes
Estimation
represents a singular number that represents
complexity: how hard is it
Knowledge: what do we know
uncertainty: what's not known
Volume how much is there
Strategies to estimate
Triangulating
Story - how big is it compared to other stories
Stories that when estimated progressed as expected in the Iteration
Squads should be brought into triage forum to do planning poker estimates
https://www.pointingpoker.com/
3.2 Draft PI plans
https://bit.ly/Video-PIPlanningOverview
p87 of the guide - Simulation Planning requirements - SM responsibility to set up the iteration planning board
PI objectives
Uncommitted objectives - we still plan for our uncommitted objectives but aren't extra things we do 'just incase we have time'
If there's many unknowns, move it to an uncommitted objective and put in early spikes
Could use this for how we clasify discovery time in a sprint
Velocity
1 point story wall for comparison
scrum of scrums every hour
Management review - 'Dear Leader' board - we don't have xxx, we need more information on yyy
What did we learn
Where do we need to adjust? vision? Scope? Team assignments?
Where are the bottlenecks?
What Features must be de-scoped?
What decisions must we make between now and tomorrow to address these issues?
3.3 Final plans and business value
Teams are sticky - we don't move people around, we move work to the team with the skill set
Day 2
BV - Business Value
AV - Adjustment to Vision
What's the thing that we are least confident in. Uncommitted objectives still need to have stories in your Increments. They aren't about 'if we had time' we'll bring it in
3.4 Final plan review and PI Objectives
RTE needs to be across the Risks and asking for them during Scrum of Scrums
Program risks
Resolved
Owned - someone has taken responsibility
Accepted - Nothing more can be done. If risk occurs, release may be compromised
Mitigated -
RISK TEMPLATE
There is a Risk that [WHAT].
If it happened the impact is [IMPACT].
Feature [FEATURE]
Team [TEAM]
Confidence vote: Team and ART
By team first - 2 or less we stop and have a conversation
1-5
All in ART vote - 3 or more is good
committing to objectives not user stories
Run a retro
RTE Takeaway: Integrated PI objectives
Objective across the Release Train then roll it up to the PI Objectives to look at the accurate representation of the objectives
3.5 Facilitating PI Planning
Distributed planning and teams
Shared pain
Planning when you should be sleeping
timezone differences
remote vs in person planning
very difficult to do hybrid
suggestion is to do one or the other
disagree - should be a participant choice
breaks - Pretty Agile do a good job of 10min break every hour
Have agreed behaviours at the start of PI planning?
It's not about committing to userstories it's about commiting to objectives. UserStories can be burned and re-written and changed.
https://prettyagile.com/2022/05/the-safe-scrum-masters-guide-to-success-pi-planning/
https://videos.scaledagile.com/watch/QSoJ5BFrr6CXAi6XrmsTmg?login_complete=true
https://vimeo.com/497667872
Lesson 4: Facilitating Iteration Execution
4.1 Plan the Iteration
https://share.vidyard.com/watch/hTpJvcjr7ZVx49gjR8W9VB
Planning flow
5 steps
Establish capacity
Apply capacity allocation to the backlog
quantify upcoming iteration capacity
PO to work with the team to make decisions
time off and leave acknowledged
Story analysis
look at upcoming features for the next iteration and future iterations
PO presents the stories in priority
Each story discussed and analysed, acceptance criteria defined and refined and estimated
Tasking stories
Who would be the best person to accomplish
How long would it take
what dependencies might it have to other stories
use it only for a short period of time as it create dependencies on xyz tasks. Why do we need tasks if we could create really good userstories - anyone should be able to pull one from our backlog and execute it
Detail stories
Iteration goals
align to the common PI objectives and manage dependencies
Transparency and management information
Align the team to a common purpose
Commit to the Iteration Goals
A team meets it's commitment if they do everything they said they would do OR
If it is not feasible, they must immediately raise the concern.
4.2 Track the Iteration progress
DSU - Daily standup
Have the goals up - ask the team to talk to the goals - what i did, what i will do today, impediments
Meet-after agenda
Kanban board but scrum team with points
add point constraints to your columns - if you have no WIP limits then the squad brings everything in too early
WIP limits per dev and test filters - e.g. 1 story in dev and 1 story in test
less context switching when you have WIP limit. Squad can pickup testing
highest throughput for a flow based system
- (more important than velocity), the count of stories that the team gets to done
less about points and more about story count
large stories become riskier
breaking them down to smaller stories has higher throughput
Burn-down and Burn-up
CFDs and Burn-ups are preferred
https://www.scaledagileframework.com/metrics/
4.3 Backlog refinement
https://vimeo.com/337783229/fa3cde973f
4.4 Facilitate the Iteration Review
demonstrate the working software
New story in the backlog as things crop up that weren't as expected
https://bit.ly/Video-IterationReview
1-2 hours
Review preparation should be limited and minimize the presentation. Work from the repository of Stories
Discuss stories not completed and why
2 views - how we did, how we are doing in PI:
did we meet the goal
Story-by story review
Review PI Objectives
Review remaining PI
PO should have iteratively seen the progress and accepted stories as complete
The 'Team Demo' - anti-pattern
4.5 Facilitate relentless improvement
Retro
https://bit.ly/Video-IterationRetro
Be creative
Ideas
https://amzn.to/3Bck4Wm
https://www.tastycupcakes.org/
https://www.funretrospectives.com/
https://retrospectivewiki.org/
Questions to surface as constraints to the team's performance
Moving to Automated testing
Cojmmunication with remote teams, SMEs, common blockers
Team's skill set
NFR testing
Bubble up - retro of retros
https://prettyagile.com/2013/06/the-bubble-up-approach-to-scaling-retrospectives/
Iteration metrics
Functionality metrics
Number of Stories loaded at beginning of iteration
Quality and test automation
% SC with test available/test automation
Defect count at start of iteration
defect count at end of iteration
Focus on 3 metrics as a tem - team to decide and pick
https://www.scaledagileframework.com/metrics/
4.6 Support DevOps and release on demand
https://share.vidyard.com/watch/eM4WBHsac7Cmb2uYqp4Bat
Maximise speed and agility
CALMR approach to DevOps
Culture Establish a culture of shared responsibility for development,depoloyment and operations
Automation - automate the continuous delivery pipeline
Lean flow - keep batch sizes small, limit WIP, and provide extreme visibility
Measurement - measure the flow through the pipeline. Implement full stack telemetry
e.g. lead time from start to delivery
NPS
Recovery - Architect and enable low-risk releases. Establish fast recovery, fast reversion and fast fix-forward
https://www.scaledagileframework.com/calmr/
https://amzn.to/3tAsB4b
Lesson 5: Finishing the PI
5.1 Coach the IP Iteration
Innovation and Planning
Innovation: Opportuntity for innovation, hackathons, and infrastructure improvements
Planning: Provides for cadence-based planning
Estimating guard band for cadence-based delivery
We could add in this effort to our PI Planning week
Example IP Iteration calendar
5.2 Prepare the team for an inspect and adapt event
The PI System Demo
Final reveal
Invite everyone to celebrate
Led by Product Management, POs and the System Team
should require very little prep
This is where planned vs actual business value is rolled up to the program predictability measure
(80-100% is awesome) Sum the planned bv up to uncommitted objectives, vs actual business value and roll up to program ART Predictability measure
3-4 hours per PI
Problem-Solving Workshop
5 whys
Agree on the problem to solve - in the ART PI
http://bit.ly/IAandRootCause
Identify the biggest root-cause using Pareto analysis
Restate the new problem for the biggest root cause
Brainstorm solutions
Identify improvement backlog items
Design thinking might be useful tool for this
Attendees: Teams and stakeholders
Lesson 6: Practicing SAFe
https://support.scaledagile.com/s/article/Exam-Details-SSM-SAFe-Scrum-MasterExam-Details-SSM-SAFe-Scrum-Master?language=en_US
90 days in slack and then it goes
30 days to take the exam
study guide and practise exam are similar
take practise exam until you confincingly pass and then do the real exam. You can do multiple times with the practise, only once with the real one
practise with 90 minute
choose the best of the bad answers. or the answer that makes the most sense
10 days - take the main exam
Tag Nic and Adrienne that we've passed in LinkedIn
Lesson 1: Introducing Scrum in SAFe
1.1. Basic Agile development concepts
Incremental delivery = 16 weeks, 8 iterations (sprints), 2 weeks each
Resources on Multitasking and inneffectiveness
https://www.apa.org/research/action/multitask
https://hbr.org/2010/05/how-and-why-to-stop-multitaski.html
https://blog.rescuetime.com/context-switching/
Quality Software Management: Systems Thinking: Vol 1
https://amzn.to/3Ez82I0
Agile frameworks
Practises
Information radiator
'Information refirgerators' - open and close the tool
Information up on walls we use to display information about our delivery - e.g. Jira boards, blockers, working agreements.
Agile manifesto
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Work In Process - Context switching - bring to the forefront of our team's mind. There's a difference between work on one thing and try and get it done and jumping to another thing.
1.2 Scrum basics
Scrum Values
Courage
Commitment
Focus
Respect
Openness
share our progress
stakeholders openess
HAVE THIS IN our CoE
Pillars
Transparency
Inspection
Adaptation
10 week Program Increment
Daily Standup every 24 hours
Iteration retrospective
Iteration review
PDCA cycle
Plan - during iteration planning
Do - Iteration execution
Check - system demo in the iteration review
Adjust - Iteration retrospective
Have this in our CoE
If it's not in the backlog it doesn't exist
Spike
Story - as a user I can log in to the system
log in with correct credentials
log in errors
stop graduates accessing
1.3 The Agile Team in a SAFe Enterprise
We need a 'Program Backlog' for our stakeholders and Product Managers and Solution Architects to add to
Core Values
Built-in Qualtiy
what are our quality standards
compromise on scope not quality
re-work and defect fixing are examples of low quality - metrics
Program execution
Alignment
We're all understanding of the vision the strategy - can we communicate it - every team member
We're synchronised
Transparency
Act with integrity in times of difficulty
short term visible commitments
a board to represent our efforts visually
SAFe Lean-Agile Principles
Take an economic view - shortest viable lead time and cost
Apply systems thinking
Assume variability; preserve options - SDLC practises are all about requirements and design, but we need to have changes
Build incrementally
Base milestones on objective evaluation of working systems
Visualise and limit WIP, reduce batch sizes, and manage queue lengths
Apply cadence, synchronise with cross-domain planning
Teams
Squad no more than 9
userstories and acceptance criteria
It's about the team taking ownership to write the stories. Not just the Product Owner
Jay patter??- user story mapping. Read more on this
https://www.userstorymap.io/user-story-mapping-in-scaled-agile-safe/
Scrum Master
Coach
Product Owner
vision and roadmap
Team questions on what the customer wants
Prioritises the backlog
SME for the team and creates stories
They may or may not have technical knowledge and need the team to contribute
Built in quality practises
Technical agility
BDD Behaviour driven development
eXtreme Programming (XP)
Paired programming
Code quality
Design patterns and practisces
Agile modeling
Lean and Agile priciples and practises
Scrum and Kanban for team agility
ART - Agile Release Train
5-12 teams 50-125+ individuals
Synchronised on a common cadence - a Program Increment
Aligned to a common mission via a single Program Backlog
ART Events
PI Planning - 2 days team commit to a set of objectives to be delivered in the PI
ART Sync - 1 hour the teams on the ART sync regarding the progress of the PI
System Demo - 1 hour deliverables are reviewed with stakeholders who provide feedback
'Cocktail hour' - Pretty Agile specific - every morning leadership standup, then team standup, then
https://prettyagile.com/2014/03/communication-cadence-the-heartbeat-of-scaled-agile/
Inspect and Adapt - 1/2 day the ART reviews and improves it's prcess before the next PI
