によって Alex Ostreiko 3日前.
2916
もっと見る
there is no reason to cling to management practices of the industrial age
there are a number of social advances and scientific discoveries made that aren't very compatible with those old ideas about organization of labour
implmented by Taichi Ohno in 1953
70 years ago
1985
almost 40 years ago
Procter & gamble
Coca-cola
Sustain
Sift
Standardize
Sort
Sweep
can be used as weapons
get rid of all sharp knives until mature
flow based model
Kanban has fewer rules
whole organization has to be aligned
slicing heuristics
The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe by Alex Yakyma
Leading Change by John P. Kotter
The Five Dysfunctions of a Team by Patrick Lencioni
Out of Crisis by W. Edwards Deming
The Goal by Eliyahu Goldratt
Lean Product and Process Development by Allen Ward and Durward Sobek II
The Lean Machine by Dantar Oosterwal
Principles of Product Development Flow by Don Reinertsen
Speed of Trust by Stephen Covey
illustration
Integrity
Intent
Capabilities
Results
author of The 7 Habits of Highly Effective People
Managing Transitions by William Bridges
Ron Jeffries, Nature of Software Development
Lean Thinking by James P. Womack, Daniel T. Jones
Turn the ship around by David Marquet
135 captains on the same ship
nuclear submarine captain doesn't need to give orders
Start with Why: How Great Leaders Inspire Everyone to Take Action
Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation
SAFe 4.0 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering
The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®
The Ancient Origins of Consciousness by Todd Feinberg and Jon Mallatt
Jon Mallatt on Brain Science podcast
Liftoff
12 rules for life: how to overcome chaos
breaking open the head
cosmic serpent
The Fruit, the Tree, and the Serpent by Lynne Isbell
Altered Traits by Daniel Goleman
George Lakoff - Living in Metaphors (sp)
Joy Inc
coaching Agile teams by Lyssa Adkins
turn the ship around
are your lights on
art of problem solving
communication gaps
on becoming a counselor
Agile Adoption Mistakes You Must Avoid By Faisal Mahmood
Facts and Fallacies of Software Engineering
lean Hospitals
recommended readings
Product Ownership
by Bob Galen
Scrum Mastery by Jeff Patton
devops handbook product mastery and product development flow
Product Mastery
Product Samourai
Deadline by Tom DeMarco
5 dysfunctions of a team
Software Endgames: Eliminating Defects, Controlling Change, and the Countdown To On-Time Delivery by Robert Galen
how buildings learn by Stewart Brand
Competing on Internet Time
we sometimes remove good tools because they are being misused
how is it similar to
Milestone Schedule
Backlog
Statement of Scope
SOW
WBS
Jama?
they are simple and static enough to build them manually
tech roadmap vs product roadmap
what about culture?
Portfolio for Jira
aha.io
in Atlassian store
Mockups for prototyping
The Responsive Manifesto
The Responsive Method
similarity with the Laloux Model
stackoverflow
Dockerizing Jenkins: Deployment with Maven & JFrog Artifactory
jenkins + maven in docker
jenkins + maven also in docker
Jira Workflow
the setup
keep simple
draft on whiteboard
Use Workflow Designer after
involve everyone who will be affected
components
Resolutions
why an issue transitioned
e.g. retired/lost/completed/damaged
issue can change hands, become unassigned
who
Transitions
Properties
Assignees
Post Functions
Validators
Conditions
workflow permissions
e.g. only reviewer can change status
how issue moves from status to status
Statuses
may reccur
where
resolved/unresolved
Workflow Diagram
statuses and transitions that a status goes through
multiple teams in Jira
parallel sprints
multiple boards with their own sprints looking at the same project
distinguish issues by components or labels
Use components/labels & filters to distinguish between teams
Great Gadgets Add-on
charts are based on issue filters
Structure Add-On
Smart Checklist
Custom Fields
Results not visible in new popup style issue view
another ticket
No mandatory items
Some limitations
Manual config
Checklist Tracker
Checklist grouping by activity
Attach Checklists
tasks/subtasks
More Detailed
Issue Checklist
Search by checklist status
Checklist grouping into categories
Templates, default checklists
Server only
Checklist for Jira
Mandatory items
Templates
we want to use the tool to get the job done easier, not as a monitoring tool for the customer
cards in Trello are useful for the team/person who are using it, it's not a reporting tool
usually it's too complex or incompatible
developers have access to customer, not customer accessing developers
PO moves the card/changes the status
testability
release
sprint
story
task
at tn LRM?
decision point
in surgical ward it's before entering (where the check happens)
e.g. wash hands in healthcare or bus driver
connection to business
when behaviour becomes internalized we focus on the new behaviour
must understand why
reduced variability
abstract away the same things to not repeat yourself
DRY
code normalization
Fowler?
code reuse
immutable code
agreement amongst doctors
Fewest elements
You Aren't Gonna Need It
No duplication
Reveals intention
Passes the tests
Extended Dreyfus model for Incident Lifecycles
refer actions for further work
evaluate corrective actions
okay to decide that more work needed
brainstorm corrective actions
potentially vote
review list of contributing causes
brainstorm contributing causes
systemic
not investing in reliability
under-training
GitLab
understaffing
ETTO
Efficiency-Thoroughness Trade-Off Principle
Second Story
details and systemic factors that led to the situation being possible
First Story
simple cause and effect
What hindered resolution?
TTR
What hindered diagnosis?
What hindered detection?
TTD
look at communication
How did it happen?
What about the system that let this issue being possible?
dig deeper
discuss what went well
items
Did our safety measures prevent the issue from being worse?
How did responders figure out what was wrong, and remediate it?
Were processes followed?
Was everything tested according to procedure?
Was detection timely?
mention that
things go right the vast majority of the time
we do have a well managed system
now how do we build on our strenghts?
How are we already monitoring, responding, anticipating, and learning?
During the incident, and the events leading up to it, how did we actively create and sustain success?
What aspects of our system and teams contributed to our success here?
what are your positive expectations from this meeting?
incomplete section: dev team
contributing factors
interrupted work incurred
Hardbeets
thought it would be easier to write our own regex than to find it in the code
GitLab is tough to navigate
enterprise version has elastic search
can we just grep a monorepo?
facilitator or the Incident Commander from the incident
"to shepard the document"
Root Cause is a myth
say "contributing factor" instead
Swiss Cheese model
when holes line up there is an opportunity for failure to slip through
layers of the system are slices of Swiss Cheese
image
attribution to a single root cause is fundamentally wrong
incidents in a complex system require multiple failures
How Complex Systems Fail
paper by Dr Cooke
ask for descriptions of what people experienced, not explanations of what they did
focus on how, not why
Safety 2
it is more useful to focus on why things go right than on why things go wrong
there is no clear division between the system working and being broken
there is just normal functioning where some things go as expected, and others don't
Safety 1
combine this with Safety 2
assumption that systems are safe unless something or someone breaks something
is wrong
in reality, errors are a routine part of any complex system
the goal
build a system that is better able to respond, monitor, learn, and anticipate
more than just trying to stop errors
build in positive attributes that actively create resilience
use the opportunity to learn how the system really works
after realizing that it acts differently from our expectations
increase the system's and the teams' resilience
not to fix something, but to learn
incidents aren't unusual
multiple actors making decisions that are entirely rational, which they judge to be safe
it's the interactions between the people and the technology
that form the overall system that we are investigating
actions during the incident are part of our normal functioning
present elsewhere
complex systems have various failures from time to time
Incident Retrospective
turn on cameras
David Farmer
I am asking people, if they can, to switch on their camera. If they prefer not to, or if they are busy, that's fine.
but with this kind of session, it's always really good to see people and to interact
you need to be more expressive because people can't see your face
say more about what you think and/or turn on the camera
Identify Protect Detect Respond Recover
DevOps/architecture
epics
roadmaps
intertwining with product roadmap
architecture stories
3 ways
Culture of Continual Experimentation and Learning
Amplify Feedback Loops
System Thinking
Shift left
DevOps chapter at the Dude
on each board
cards different colour
what are our challenges?
admin
chat, Jira, etc
areas
Experimentation
Collaboration
Enhance productivity
Process
deliver value
increase efficiency
eliminate waste
People
collaborate, align
detailed
Deploy & Debug
Monitor & Test
Branch & Deploy
Build & Version
Code & Commit
Similar infrastructure
consider the whole organization when implementing procedures
Goals
CI/CD
summary
what is agility
get products out faster, and get feedback
categorization
McKinsey
Shared Values
Structure
Staff
Strategy
Skills
Style
environment
teams
individuals
leading agile
systems
practices
generate ideas
Human systems agility & Business agility
Integral Agile Transformation Framework
teams that can coordinate and deliver predictably enough for the organization to be able to make commitments to the clients
enough to meet a release-level commitment
do no harm
get people to take classes on Nexus or another framework
agile
celebrating failure buiylds trust and safety
pairing builds empathy
shared understanding
retros
mindset
startup
emergent behaviour
x-team
everybody locally optimizes
Why Agile works
sustainable pace
origins
deliver code
in changing reqs
fast
integral
ask PO if there are repercussions for tasks not delivered
on a scale from 1-10, how would you rate this Sprint?
we celebrate successful delivery
Sprint Review anti-patterns
Sprint Review Template
Have a rotating presenter
the demo is by the team, not individual developers
Get Feedback
Share Progress
Closure Event for Timebox
MIT Media Lab
pre "official" Scrum
demo or die
why we do planning
we are going into the future on our own terms
who sets the schedule?
our predictability, our say/do ratio represents our ability to work with other teams
and we can always do a little better
we can do more together than alone
if something it not working we try differently
this is learning, and it requires planning
teams coordinate their activities, which requires planning
as long as we have an outcome in mind we need a plan
if you have two people, and one is visualizing an outcome, and the other is not
who's more likely to achieve the desired outcome?
must be proactive
it's in attitude
or, are we going to passively stumble into, or let things happen to us?
we have a goal: we want to improve, we want to be an excellent, high performing team
are we actively trying to shape our future?
do we have a future state in mind
don't wait to react
we know some things will happen
don't be unprepared for something that you could be
that's the credibility
we can prepare for those
we can be skillful
we can shine
we need to be predictable and reliable
we set the expectations for the other teams
we are an integral part in a larger system
other teams must be able to count on us
give shape to the shapeless
what are you seeing there in the fog in the next two weeks?
go from the chaotic domain to complicated
we need to move away from the culture of being passive receivers of work/tasks
Impact Mapping
PO Key skills
Guidelines
when User Stories are high level, the team has more flexibility in identifying tasks
percentage of tasks identified
identify 2/3 of tasks
planning poker
possible, but not advised to play with a part of the team
estimates usually converge by the second round
rarely > 3
high and low estimators should share their reasons
Team's definition of Ready
Testable
Small
Estimable
Valuable
Negotiable
Independent
debrief at the end of a meeting
leader (team) can only break ties when everyone had weighed in
disagree and commit
if people don't weigh in, they don't buy in
Patrick Lencioni
exercise: silence as disagreement
participatory decision making
formal commitment to resolutions
"No" is the gateway to yes
counterfeit "Yes"
structural dynamics of dialogue "stuckness"
may be passive-aggressive
response to a persion who cares too much about themselves
David Kantor's Structural Dynamics
ask you to lean in to being
open, respectful, etc.
anyone not on board with that
ice-breakers
acknowledge others
have everyone list the desired team characteristics
good communicator
productive
kudos
add to 4Ls?
why are we here?
share a story or an idea why this work is important
mystery game
anonymously write down something personal about yourself
the team guesses who it is
I did figure skating when I was a kid
knowing each other doesn't mean there is a strong connection
anonymously pick a photograph online that describes, for example, what you did last weekend
then have the team guess who sent what picture
a bit like werewolf because the person who sent the picture would have to pretend
2 truths and a lie
also Retro
define acceptance criteria for what makes a good meeting
post-meeting evaluation
follow-up plans
detailed minutes
periodic process checks
effective member behaviours
clarity about decision-making options
delegation board?
set of group norms
minute taker
timekeeper
chairperson
facilitator
process notes
tools and techniques
agenda
7 types of meeting goals
do not mix types
overall goal vs meeting goal
Provide Input
Make Decisions
what decision rule will we use?
Build Capacity
Build Community
Improve Communication
Advance the Thinking
Identify Critical Success Factors (CSFs)
Evaluate options
Sort a list of ideas into themes
Identify underlying patterns
Analyze a problem
Define a problem
Share Information
note
dynamics of presenter and audience are "numbing"
use quick conversations in pairs to help digest
Law of Mobility
it is your responsibility to remove yourself from a meeting if you are not benefiting and not contributing
your time is valuable
meeting components
initiate action
analyze results
generate confidence
anticipate change
Questions
How should the next meeting be different?
Whom do I need to make follow-up meetings with?
How will this change the way I work?
Hopefully it will, otherwise this isn't useful
I don't know, but this is a great opportunity to make improvements
outcomes (deliverables)
heart
hands
head
Power Start
Engagement
WIIFM
Outcome
IDOARRT
Time
Rules
Roles
Desired Outcome(s)
Intention
meeting design tool
natural flow
what obstacles were you able to remove since the last check-in?
what are the obstacles?
who can help with that?
format helps inspect/adapt & planning
Dunbar number leads to ~2.5 minutes for the right size team
but the point is that the 2.5 minutes is an observation that HP teams arrive at this
it is common for PO to update priorities before the meeting starts
announcements also go there
e.g. if there is a new P1 or a SEV or some other constraint
SM
suggestions to the team
pain points
move Jira cards
be an example to each other
try out parking lot
write topic on whiteboard to be discussed after
use whiteboard that Team can see to accentuate aspects, one at a time
develop culture that what you said yesterday matters
it's a planning tool that shows Team where it is going, and letting it make course corrections
each person picks who goes next instead of just the next person
you are always next
standup poker
at end of standup
rate likelihood of achieving Sprint Goal
Objectives
create continuity
each person's report is not a static snapshot, it's a vector with direction
forecast completions, avoid vagueness
small version of the inspect/adapt loop that is sprint
besides whether it helps reach SG, the angle should be towards getting the most impact
Benefits
basic cadence for inspect/adapt cycles
routine is the foundation for higher level work
morning standup is a retrospective & review in one
reasons to have standups
being a team
dynamic necessary for DDOs
seeing how a combined effort could
discover/convert an unknown into a known
spreading and sharing and maintaining common values
identifying common goals
we work very closely together, and our paths cross many times every day
better understanding of daily rhythm and life of the company
a sync would open up a dimension (order of magnitude) of possibilities
knowing what each person is up to today would help everyone in the course of the day
Refinement
specification by example
top down vs bottom up requirements elicitiation
requirements spoilage
intro with
pre-populate plan for next Sprint
refine User Stories
easier to do relative estimation
relative weight
parking lots
easier to estimate size of smaller items
e.g. car vs building
add new User Stories
prioritize PB
goals of Refinement
definition of READY
criteria
example
Who? Children What? Feed children Why? So that they can go to school.
3. Feed chidren
2. Make breakfrst
1. Go to the store and buy eggs
should be valuable to someone
sequence?
manage dependencies
context
not big: should be able to finish in one Sprint
otherwise break it down into different User Stories
Description should be clear to developers
they should understand what is their job to do
Answers questions who?, what, and why?
Acceptance Criteria
entry/exit criteria
INVEST
estimate business value before estimating effort
expected benefit is a constraint on the nature of the solution
knowing the value allows us to pick a more appropriate solution
cost of delay
e.g. if making a Santa Claus app
if you were making a website, consider two customers with vastly different expectations for profit from their websites
delay writing acceptance criteria until you know that the User Story will be scheduled
makes little sense to write ACs for a User Story that won't get scheduled for months or maybe never
Ready
must be actionable
Checklist
Identify & Resolve/Plan for
concerns
constraints
assumptions
known unknowns
Testability
Feasibility
How do we prioritize?
ask people to read the article
each meeting has a goal and a deliverable
the goal determines
who is present
format
do not mix meeting types
standups that run forever
separate planning from problem solving
that's why we have parking lots
because it will mix the goals
data dumps (information sharing)
unidirectional
problem-solving
gather to solve a specific issue
does mobbing fit here?
decision
establish options, agree on path forward
diverge-converge
consensus building
general agreement before moving forward
e.g. goal of standup is to coordinate activities
what to do and when
status
sync up
report on progress
team members describe where they are, report their progress
to an authority figure
destabilizing
wasteful
to each other
useful
What positive change did you introduce?
How often should this happen?
Each metric associated with a question from the model
Quantitative level
Clarify goals
asking the right questions
Objective model to assess achievement of goals
Operational level
Conceptual level
btw
Jobs To Be Done
correct decision and action = desire + reason
Aristotle
Hume
SMART
start with the "why"
areas (from Leading Agile)
Portfolio Financials
Portfolio Health
Product Quality
Program Health
Technical Quality
Team Health
Give example
Team can meet release level commitments
resources?
team stability index
stable velocity?
velocity variance
frequent delivery?
completed/committed User Stories
OKRs at Google
OKR meeting templates & more
Google, LinkedIn, Twitter, etc.
Atlassian
Confluence add-on
President of Intel in 1970s
imagine the bullet hitting the bull's eye
Set 3-5 high level objectives
should be > 70%
at that point move on to another
measure achievement 0% to 100% (or 0 to 1)
instead of following instructions, we are aligned
developers are most valuable
don't break the money-printing machine
express intent, and then deliver that intent
write code like the next developer is a sociopath with your home address
intent-revealing code
communicates vision to the future devs
intent breaks the test, and communicates a global, holistic goal in regard to the whole system
Marquet?
create a need/problem, and then solve it
create future state, and work towards it
in Agile, we pivot continuously, and release more often
a lot more testing to do
in waterfall we put off testing till the last stages of the project
because as code gets changed testing would have to be redone
don't use Maven Release plugin
turn snapshots into versions
use build counter
maven version plugin
not suitable for CD environment
tools
invoke those plugins individually (from Jenkins?)
mvn checkstyle:checkstyle
mvn findbugs:check
mvn pmd:check
Findbugs
Checkstyle
PMD
typical flow
don't do mvn deploy, do mvn install and use Jenkins Artifactory plugin
Real-World Strategies for Continuous Delivery with Maven and Jenkins
write code like the next guy reading it is a sociopath with your home address
CQRS
different model for reading than for updating
CRUD?
read from cache, write to master?
Command/Query Responsibility Segregation
don't mix getters and setters
Collective code ownership
isolated problem solver with a bunch of magic tools to
focus on achieving a business outcome
a collaborative problem solver
a communicator
extends to
all problem solving?
support
“never make a decision that does not need to be made; let the project evolve because at some point that decision may prove to be irrelevant or unneeded”
“causality” is not possible to assess in a complex system
“responsible” is undefined and therefore not measurable or assessable
“last” is undefinable and therefore not actionable
“Responsible” still remains undefinable IMHO, “Last…Moment” doesn’t exist, so LRM is still a hoax
subjective risk/damage preferences of a self-aware team
iteration
timebox does not change to help with predictability and estimation
how many units of work in a unit of time
plan aftex x number of planned work items completed
dependency on PO
scope creep
less autonomy for teams
restructuring Sprint interferes with Team's autonomy, and washes down the SG
teams should be able to self-organize
predictability and ability to deliver on what was forecast less important with weak SG
demos longer, different things
multiple anchor stories
weaken SG
we are not delivering an increment every Sprint
weak Sprint Goals
Student syndrome
padding at the front instead of the back
cascading sprints testing
tougher for new teams to start on the pro track
training wheels
need guardrails
just like we can't expect a new team to do XP -- mindset & culture change take time -- hardening sprints is a temporary crutch to get all the things in line
goal
continuously reduce the need for HS till we don't need one
not part of Core Scrum
anti-pattern
ScrumButt
meant for large scale product development
Hardening Sprint at the end of ART
DA
hardening the product in Transition Phase
meant to be phased out as team matures
aka
Spring Cleaning Sprint
dev priorities
Stabilization Sprint
Release Readiness Sprint
action connected to business case
value stream map to show bottlenecks
where is Herbie?
is it going to help us remove dependencies
changes in
Systems
Practices
used in change management when someone doesn't share paradigm
e.g. Theory X vs Theory Y
acronym
Partner
Agree
Empathize
Listen
videos
We see most resistance when #change is inflicted. Key is to bring stakeholders in the eye of the hurricane with you & create change together
create change together instead of subjecting them to change
Diagrams
Alternative Path to Agility
alternative path to agility
LeanKanban
KMM: Alternative Path to Agility
Detailed description of the framework
Q&A on the Book Kanban Maturity Model: Evolving Fit-for-Purpose Organizations
everyone writes down 5-10 things they're working on
answer
where will it go when I'm done with it?
where was it just before I got it?
where is it now?
what type of work it is?
could be done in pairs
step 2
things
Improve Collaboratively
Make Process Policies Explicit
Limit WIP
story from Richer
then they walked parts in different parts of the factory to see if the factory is configured correctly
1-2 day chunks
"a handful of them can be delivered in a Sprint"
prioritized
no dependencies outside team
autonomy to decide how the work is done
some degree of autonomy
ask the team where the pain is
take it to the team
remove unnecessary practice
save time
e.g. developers working on other story
it could be a
spike
team wellness story
pepsi clear
macdonalds - macspaghetti
coors spring water
Your Brain on Scrum
nod to Your Brain at Work by David Rock
Michael de la Maza
Udemy course
includes 2 one-on-one calls with de la Maza
use to resolve disagreements with command-and-controlnics?
"Robust Product Owner"
if it is necessary for the product vision, PO connects to whoever
is not passing requirements, it is passing on the responsibility & the problem
industrial-age mindset when higher output coincides with better outcome
hence referring to people as "resource"
people might see themselves as less empowered when referred to as fungible cogs
PO cannot maximize output, forced to work with value
User Proxy
Client on Site
Product Champion
what game to play vs how to win
get them into a rhythm
we are outside of it
do not pass on irregularities
everyone is a peer
if a PO is not on the same level, then it's not a team meeting
say no to customer
set product direction
represent the company
gather new requirements
understand the customer's wishes
understand the company's strategy & perspective
episode 41 on quadrants
alignment with the team
shift Product Backlog to amplify teams' strengths
consider team's feedback to
r&d
automating
refactoring
defect repairs
sense amount of technical challenge by sprint
what stage of mastering the new tool are we at?
interesting & challenging work
adjust as required while keeping business goals
situational awareness
to extract most value
loyalty to the team
Individual leadership
connection to the team
Goal Setting
PO suggests/approves Sprint Goal
Converge and align with release expectations
reality of delivery
stakeholder needs
Road-Mapping
conversations
integration milestones
unknowns
risk mitigation
column for each iteration
up to 12 iterations
(usually) team distributes the work
populate from backlog
from XP
Backlog refining
Integration & scope management
LDUF
design as you go
because it depends on validated learnings
prove your design with working code
Lean Design Up Front
Just enough strategy
Just In Time
framework for architecture & design
Align stakeholder expectations with team capacity
Milestones
demonstration goals
integration points
tags
Embed testing in backlog
Continuous improvement of PBIs via inspect/adapt every sprint
Externally facing part of the PO role
Marketing
Sales channels
ROI models
Pricing
Agile Marketing
Andrea Fryrear
Product Mission & Vision
Product champion
roles belong to the system
Homeless guy directing traffic after earthquake
power knocked out, street lights not working, chaos
except for the corner Kearny and Pine streets
San Francisco, Oct 17, 1989
levels
some systems base their communications on failure states
realize that there are more successes than failures
Appreciative Inquiry
learn to represent the successes in communications
i.e. only communicating about how things fail when they fail
creates negative associations and expectations
"it's not luck"
Diamond Agile
Scrum is 5% of what Agile is
Ambiguity
Complexity
Uncertainty
Volatility
double loop
adopt TDD instead of hiring more QAs
go check if temperature changes because window is open
single loop
add QAs to increase quality
hill climbing
thermostat
same way to satisfy customer
we are creating structure and creating conditions for the structure to exist
as we use organizational and problem solving skills to solve project issues
we need to come together and use these skills to solve team issues
red work & blue work?
system of delivery and system of transformation
drawing on it and reproducing
when you call a vote you produce structure
use it or lose it
likely to repeat in the future
producing & reproducing
change oil
clean the counter
technology vs requirements
how vs what
all star basketball players don't play well because they aren't used to playing with each other
a wicked problem cannot be resolved from the same level of consciousness that created it
if all solutions could be wrong, who decides which one to take?
everyone commits and feels responsible
hippo?
solution
pad (local buffer) at the end, not at the beginning
starting a task too late
Operational Changes
Internal Project
Business Project
make changes at the same pace as the need for change is discovered
Tim Snyder
on LinkedIn
how often does something happen
what events exist in your work cycle
then align the processes to it
Tacit Knowledge is a curious Agile concept to consider. When we do hand-offs, and skimp on face-to-face interaction, we lose ~50% of knowledge with each hand-off
flow debt
How much code that is not currently making money do we have?
incurring until walking in tar
always expediting
cultural debt
technical debt
Technical Debt Quadrant
Martin Fowler
do compensation schemes support shared commitment?
actionable agile metrics Jira addon
instead of utilization
we are all always working on something
what are you working on now?
business value, impactfulness, or priority level of what the person is working on
Slack is necessary to respond to change
Fire engines
How does Fedex do overnight deliveries?
they always have planes flying everywhere even if they are empty
Reporting time
how would you feel having to report hours?
against principle 7
working software is primary measure of progress
against principle 5
trust motivated individuals
relay race
focus on the baton, not on the racers
outcome over capacity utilization
should be < 70%
in order to deliver maximum value, teams will arrive at the appropriate utilization on their own
no need to measure utilization, measure outcome
limit variability
with stealth bombers
with tacos
diverging
converging
scientific studies
Agile Uprising podcast
wrong solutions
treating symptoms
free frozen yogurt
yoga room
address work/life balance
not addressing the root issue
which is pursuing too many issues at the same time
focus on efficiency of individuals
how many projects/initiatives are currently in-progress?
Agile practices
reduce WIP
reduce batch size
scale Scrum and Kanban practices throughout organization
use Backlogs
rank-order work activities by outcome (like in a Backlog)
focus on outcomes not outputs
start less finish more
stop starting and start finishing
make reality visible
put in limits
set boundaries
visible when moving boxes, but not in knowledge work
outside of our brains
similar to
gambling?
credit card overspending
then you can prioritize
otherwise the boundaries will come and find you unexpectedly
what is our natural capacity?
check scientific studies
Kronos 2017 study
employee churn one of the top problems for the polled companies
unrealistic expectations + overtime is the main reason for leaving
1/5 of the 600 companies polled said they will not do anything about it because of competing priorities
WIP Limit
illusions
culture rewards productivity
busyness makes us feel productive
shield from fear of failure
cuture rewards outputs not outcomes
productivity confused with busyness
there is plenty of research, and yet companies find it difficult to change
it's hard to see the cost of context switching
we can capacity-plan by cutting up people's time
e.g. spend 20% of your time today on each one of the 5 projects doesn't add up to 100%
start everything is good
cultural/organizational/corporate influence
because teams haven't finished work in the past
"managers" throw on as much as possible in hopes that at least something will stick
out of concern that the teams will have nothing to do?
known maximum capacity of a team is not known/respected
everything is the highest priority
creates pressure to start, not to finish
cost of multitasking
lower quality
performance
the term "high performer" acquires a new meaning when we realize that the barriers to performance are organizational
may be solving the wrong problem
pressure to move forward
prevents deeper analysis when it might be prudent
when only 40% of mental capacity is available, the quality of decisions will suffer
skipping meetings
inattentive at meetings
skipping debriefs
when multitasking we are not necessarily doing the most important/impactful thing
selection of the next task may be prioritized by
relative difficulty
exhaustion from switching
time to completion
depends on complexity of task
cost of doing two tasks is 40%
60% for three tasks
cost is time and efficiency
we can perform multiple tasks well, but there is a price
mental capacity
Zeigarnik Effect
mental exhaustion without visible results
executive function
we can perform only one executive task at a time
context switching or prioritization
no value produced
analysis
problem solving
context switching
rule activation
goal shifting
we tend to plan the activities of a functional silo rather than delivery of the product
plan delivery of features rather than execution of activities
focus on outcomes, not output
process maps vs value stream maps
differences
process map looks at steps within process
value stream focuses on handoffs between processes
Leading Agile podcast episode
cumulative flow diagram shows the WIP
cumulative flow diagram
The Goal
Herbie
each scout could be
scheduler step (e.g. Airflow)
column on kanban board
an area of work
administrative
extrinsic cognitive load
communicating internally
escalating
researching
following up
responding
trying to be more efficient anywhere else than the bottleneck is a waste
Lean Wastes
Lean Waste 5
review or approval process
where process is not appropriate
where person is unavailable (bottleneck)
documentation phases
activities that do not validate or invalidate decisions/requirements
waiting for tools or staff to start any work
time between creation of action items and when work begins
Lean Waste #4
Handoffs/Transportation
each handoff loses 50% of information
a dysfunctional example: Client->PO->Devs->Testers
tacit knowledge
how much tacit knowledge is lost when passing a task/project to someone mostly via documents?
e.g. riding a bike, or blowing a bubble with bubble gum, designing a system
avoid silos
Lean Waste #3
Relearning/Reprocessing
switching between unfinished tasks
knowledge sharing mechanisms
brown-bags, pairing, useful code reviews
repeating a value adding activity
the first instance did not provide the value
extra processes that don't bring value
pure overhead
e.g. searching for documentation
Lean Waste #2
Overproduction/Extra Features
Small batches, often
LRM
MVP
Lean Waste #1
Inventory/Partially done work
excess of incomplete work
management issues
warehousing costs
DIP
Design in Process
incomplete work == WIP
overburden (muri)
unevenness (mura)
7 lean wastes (muda)
APQP
waterfally?
PM Podcast
similar to DFSS (Design For Six Sigma)
mostly used in manufacturing
Advanced Product Quality Planning
think in terms of flow
flow trumps waste removal, value trumps flow
Flow efficiency
a 2 hour problem 2 months to solve?
looks too slow from the point of view of a custoimer
"solve the problem for a customer fast enough so that they don't have time to change their minds"
identify bottlenecks
"System does not end at the factory gates" (Chris Chapman?)
same for teams
create pull systems
focus on process not results
to achieve better performance focus on learning
achieving goal doesn't lock in behaviour
be slow like tortoise
e.g. don't go to gym too much
do only the work that brings value
teamsize 9-15
opens up a whole new horizon of what teams can be high performing at compared to the 5-9 size
CD Patterns for Contemporary Architecture
Deliver it! on Flow
flow & bottlenecks
water bottle upside down
bottle with a straw
bottle with vortex
static bottle
lots of activity, but rate of flow not increased
Entropy Vector
from steam trains to maglevs
turmoil inside the system
system is captive of its own internal processes
internal processes do not add value
unproductive conflicts
repetition of stop-start flow
to let air in to let out water
Team Dimensions
Activities
Keep Doing it
Do it On-Time
Do it Right
Do it Fast
Areas
Responsiveness
Mean Time to Fix
Mean Time to Release
Average Impediment Lifetime
Queue/Batch Size
Lead time per Story
Cycle Time per Story
Predictability
Feature Comparison
from Lessons Learned?
Cycle Time per Story Point
Velocity Variance
Say/Do ratio
Average Age
Velocity
Quality
Auto Functional Test Coverage
Unit Test Coverage
Defect Arrival/Kill rate
Issue reintroduction rate
Defect Density
Maintenance Complexity Trending
Employee Satisfaction
Retrospective Outcomes
Attrition Rates
Surveys
Customer Satisfaction
Repeats/Renewals
Net Promoter Score
evaluate best iteration length
calculate additional effort
delays
increased with siloing
extra communications
status updates, confirmations that we are still working on it
relearning
context switching between partially done tickets
"parked inventory"
siloing
rigidity
if performance drops as load increases then it's too high
probabilistic forecasting
if you absolutely need to get to work for 9 am, what time should you leave?
Monte Carlo simulations
Dan Vacanti's tool
Troy Magenis' tools
e.g. 10,000 iterations with given data
forecasts are based on previous data
Step Two: use probability calculations to base projections on real data with real confidence
Choose percentile of confidence by drawing a line on a scatter plot
Step One: Estimate till you have enough data
graph both
unit of time per unit of value
units of value per unit of time
People/Team: The Human Elements
Technical/Code Metrics
Product Development Metrics
Release Metrics
Process Health
SDPI
Scorecard Index
Jurgen Appelo
measure work not worker
cycle time
defect rate
dependencies
rework
handoffs
defect rate doesn't affect amount of work done, but does affect progress towards business objectives
number of defects could be subtracted from velocity?
depends how we use velocity
measure the four types of work
Phoenix Project
unit of time for unit of value, unit of value per unit of time
define value
moving towards goals
SAFe metrics
street lights
how do you forecast your trip when street lights are semi random
Monte-Carlo simulation
estimate delivery
focused objective
Use metrics as feedback to improve yourself, not as a lever to change someone else's behaviour
"Inspire pull and resist the push"
then it must be measured
amount of ready backlog
stable delivery team
stable velocity
dependencies, handoffs, stage gates
number of outstanding bugs
blockers
active risks
risk burndown chart
active issues
average overtime
staff changes
happiness
employment insurance applications
cupcakes eaten
could be a leading indicator for health
horses out of the barn
closed tickets
completed work
BMI/weight
state of economy is a leading indicator for employment
unemployment is a lagging indicator for economy
could be both
e.g. a team's velocity may be a lagging indicator for a team, but a leading indicator for the company
there are things that impact these primary leading indicators, and they can be measured too
business objectives & strategic goals
help to determine likelihood of completion of the main goals
predictive
success is defined by how close to the plan the execusion was
smart people plan then less smart people execute
adaptive
e.g. FedEx: tracking is the most expensive part of the service
what it would change
bad
shaming developers for unresolved bugs caused them working on bugs only
a la the electronic whip @Disney hotels
Works as intended for 1 month, then becomes rubbish
Result: we don't know how many defects we have
Testers stopped reporting bugs to not make teams look bad
people started skipping the system, telling developers about bugs directly
actively losing data
value driven work vs fixing bugs - responding to wall of shame, and not to customer
code that would have been refactored with addition of new features was instead refactored to fix bugs, and no new features
value not delivered
good
if we measure velocity, people start splitting stories
more finely grained stories
more detailed stories, higher quality
choose metrics on their ability to lead to a better decision, not ease of measurement
improve in a very specific area
we need to generate insights that would get us to improve
obscuring important information
The Carmelo Anthony effect
he is swarmed by other team's players, and they block him
the metric informs strategy: pass when you 're blocked
he scores more, but he also misses more than others
the film Moneyballed
everyone looked at how well individual players score, while Oakland (baseball) realized that there was another metric
what besides money affects win/loss ratio?
the other metric is team behaviour during games (players get on base more)
as opposed to how much a player is paid
completely wrong
especially valuable
new member
remote
we all have different perspectives and blind spots
we all have the ability to see outside each other's focus
blind spots
we want to have a more complete picture
be aligned
we selected areas that matter to us
we want to be on a team that has those things
our values
4 blind men and an elephant
consider the situation when there is a disagreement about how much team is learning
this exposes an interesting area to explore
things that are measured get improved
just consider the perennial example with call centres and duration of calls
opportunity
to identify areas for improvement, and bring them into focus
if we don't talk about our problems then we won't solve them
instead of hiding
to be heard
Douglas
rules are for Douglas, they assume that everyone is a Douglas
a hypothetical person who does everything wrong
people misrecognize metrics for that
see Amdahl's Law in the free course on Agile Physics
Cycle time planned and unplanned histograms
Weekly trend of throughput, cycle-time and WIP in one chart
Net flow (number of items completed – number of items started) per week
Unplanned work percentage rate
Planned and Unplanned Throughput trend and histograms
Throughput
Excel charts
Destroy
restructure
Energize
hold space, guide, direct
Enrich
help to grow
Peace
creating safe environment
not one "right" way, but one consistent way
we exist in the product community
we can make a team 2 times more productive in a month
it is more challenging with making individuals 2 times more productive
J Sutherland
the best team members are the ones that make the whole team perform better
teams are expected to adjust when instead teams should be protected at any cost
starting less requires authority
authority comes from commitment
vulnerability-based trust
Lack of psychological safety at work makes us hide mistakes, and play blame games
Hiding mistakes, hesitating to ask for help, playing the blame game makes #teams less efficient, & points to lack of psychological #safety.
yin
Hiding mistakes, hesitating to ask for help, & playing the blame game are all signs of lack of psychological safety,
merit money is more fair than collective "celebrating together" where someone else decides how everyone is going to spend money/celebrate
Why not go all the way, and do temperament inventories too?
VIA Institute
Predictive Index
MBTI & Keirsey
DISC
use to pair
helps get out of silos
Robert Kegan's levels
interdependent
dependent
Nietzsche's stages
Child
new innocence
play, experimentation, learning
Lion
assert
Camel
learn, copy, absorb, follow
do you know when others know how you feel?
can you tell when you are making another person uncomfortable?
do you know what the other person is feeling?
pre/trans fallacy
confusing pre and post
continuum
dependent (pre)
independent
interdependent (trans)
Robert Kegan
5 stages of development
5. Self-Transforming Mind
lead together
4. Self-Authoring Mind
see from other perspectives
need to write User Stories
3. Socialized mind
mature to be on a team
2. Imperial Mind
child
1. Impulsive Mind
infant
SOI (subject-object interview)
3-day course @ $3,000
ASOI
autodidact
one of the worst things to do is to start delivering cultural messages about Agile, get teams to start doing the practices while
ignoring org impediments and dependencies that the teams cannot remove on their own
how much agility will the ecosystem allow?
therefore
besides/instead of teaching Agile
systematically remove barriers to Agile
setting teams up to fail
we know 80% - 90% of what will get in the way before we even start
install compensating controls
break dependencies over time
start removing the compensating controls
we can enumerate those things
teams should be built around buriness capabilities, not projects
value streams vs business capabilities
dependencies within the business architecture make it difficult for teams to own their work
system of transformation
teams know how fast they should be going
dependencies dictate their schedule
temporary compensating controls
why are we special and important to the company
cohesive team
shared
vision
goals
working agreements
definition of done, ready
admit when we are the impediment (courage as value)
when we meet
estimation is more accurate when extraneous and intrinsic cognitive load is reduced
Yerkes-Dodson Law
stress hormones
stress response to interpretation of situation as
a social evaluative threat
not under one's control
unpredictable
novel
minor stress necessary to form long-term memories
upside down U-shaped (bell?) with memory
tasks require different levels of arousal for optimal performance
relationship between arousal and performance
Germane
manage by decreasing other loads
solving a business problem
tasks relevant to the goal
repetition and context variation allow learner to apply skills in different situations
Extraneous
manage by reducing irrelevant distractions
unfamiliarity with tools
incomplete documentation
loud environment
tasks irrelevant to the goal
Intrinsic
manage by breaking tasks down into smaller ones
syntax for lambda functions in Python
juggling 6 balls is more difficult than 3
inherent complexity of the task
quality engineers
quality assistance
"like SM for quality"
Unplanned Work
Changes
goes into Business Projects
Internal Projects
Business Projects
did you research us
here is what we are trying to build
what have you been up to
questions/topics
how do you deal with context switching?
Visualize work
WIP
time management
What do you dislike about your previous job?
What tasks do you not like doing?
one of our values is honesty
how did you apply this value?
what does it mean in the context of work
Company that you admire
ITIL
dream job
why startup?
we wear many hats
describe how your previous company built products
treated people
if you were hiring for your team, what do you look for in your team?
what would you like to learn
tech
from resume
Javascript
Python
MySQL
VirtualBox
Docker
start/stop
access console of a virtual machine
CentOS & Ubuntu
depending on tech knowledge
create a bucket
check for a file in S3
start a webserver in a docker container in 5 minutes
archive/compress a file and back
what process is consuming CPU?
locate logs
use scp/sftp to copy a file
use ssh to log in to a remote machine
files
permissions
change
cron
FinTech
BigData
Cloud
relationship with developers
book instrumental in choice of career
ideal support system
tell us about the professional journey that brought you here
interview games/activities
tell stories about past experiences from each job
how did he grow
what he learned from it
how it impacted
ideal day/week
take turns drawing it?
candidate provides direction
sailboat
discuss, capture items in discussion, then do it again silently
risks and concerns
by interviewers?
anchor/rocks
what type of support will you need at your dream job?
wind
perform an exercise together
then do a retro
cards game
one person orders, one person draws shapes, and one person colours
turn a word into a story
Job Interview Techniques for Agile Teams with Jason Tice
Agile Amped
The Agile Factor
activities, insights
Jason Tice
skills assessment matrix
48 agile jobs cards
cut out parts of job description, rank them, then move ones that need more/less work
structured collaboration framework
moving motivators
STAR Behavioural Interviews
Management 3.0 interview activities
interview questions
on hiring
Bridgewater
to be a one in 10,000 kind of a company, we need to hire one in 10,000 kind of people
#noresume
ask the candidate to send a video instead
ask if they would want to redo the interview
strong recruiting pipeline
goes off the rails?
what can you deliver in 2 weeks
types of conversations
decisions aren't expected to be made
next steps are optional
closure not needed
synergy not important
facilitation isn't critical
no decisions
Brainstorming
List making
Information sharing
decisions are expected to be made
closure and clear next steps are needed
people need to build on each other's thoughts
facilitation is important
clear process needed
decisions
types
Relationship building
Problem solving
Planning
healthy debates vs dysfunctional arguments
create targeted norms
examples of safety norms
people and issues will be handled with sincerity
confidentiality
all ideas are listened to with respect
positive intention to improve the team and workplace
ask
What rules are needed for today's conversation to ensure that everyone can confidently share what's on their mind?
buy in
coaching on 2 levels
interteam?
individual
Scrum Master
Daniel Goleman
leadership styles
Lyssa Adkins
coaching styles
also
reaching
modeling
advising
Ri
coaching
Ha
teaching
Shu
What can your team count on from you?
Co-responsibility and accountability create empowered systems
Each person is co-responsible in creating the experience or culture you want for the team
What will you each commit to for one another?
What would help the team to flourish?
How do you want to behave together when things get difficult?
What are the team's conflict protocols?
what is the culture, space or atmosphere do you want to create in the team?
What values do you want to live by as a team?
How do you want it to feel?
How would you know that you have that?
why are we here
how do we bring value to the organization?
intro
teams that have clear expectations outperform teams that do not have such agreements
addressing these issues will
create the foundational platform
ground rules for treating each other
for interactions on the team
how
this meeting is about YOU
not how you want other people to be or feel
how can you commit to be
what
we will openly discuss
what values do you want the team culture to express
how do you want to feel on the team, in meetings
what we want our relationship and culture to be
we are all in the same boat
what are the expectations and agreements between team members?
how should we behave towards each other?
alliance with each other
this meeting is about the team culture
because they are then not independent, disinterested, they have a stake
start speech
once upon a time
person to person
start telling a story about
archetypes
quality of life
stories are about people
how I changed after learning/talking to someone
trained as kids
state a weird fact
e.g. more people living today than have ever died
ask a question that unites the audience
retro format
5-step format
was extended with 2 more additional phases to help start and conclude the meeting in the context of Software Development
first 3 phases
decide
now what?
analyze
so what?
what?
Virginia Satir Interaction Model
how we respond to things
Human Systems Dynamics Institute
Liberating Structures
What? So What? Now What?
Adaptive Action format
Institute for Cultural Affairs (Canada)
ORID
Decision
Interpretation
Reflection
Observation
The Art of Focused Conversation
check-in, set context, gather data, generate insights, make resolutions
diverge, converge
Kerth's prime directive
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
--Norm Kerth, Project Retrospectives: A Handbook for Team Review
retrospect on this
Items for retro
retro is a fundamentally vulnerable exercise
because we give feedback
appreciations
everyone here is a hero: you contributed something special, something from the heart this last Iteration
each person can take turns giving their appreciations
pick one item to resolve
prioritize quickly then spend more time on resolutions
invisible work
workflow improvements
experiments
Own and Improve Team Processes
how healthy are these processes?
what processes do we have on the team
communication w/client
planning
QA
How Intrinsic Motivation is supported
identify pains that you are living with and come up with ways to address it for yourself and for others
3 Pillars of Empirical Process Control
inspection
code reviews
burnup charts
adaptation
retros are bottom up opportunities to figure out ways for improvement
secret sauce in everything is taking a look at what you are doing
Josh Anderson
Remote
1-2 remote team members
have an advocate in the room
the hands of the remote person
put up stickies, etc.
AKA "sticky buddies"
PO's role in Retro
do not dominate discussion
bottleneck when everyone is waiting for you to solve issues
we want Team to learn to find solutions
poke at the problem
refrain from offering the "how" unless impasse
did I do everything to capitalize on the strengths of the team
e.g. capacity
were my stories small enough for the team?
when filling 4Ls talk about how to improve your work, not theirs
listen & watch
Read between the lines
what can we do to make it easier for them in short and long term?
Patterns
retro patterns from XP
article in French
My Worst Nightmare
Prioritize
20/20 Vision
Shape
Show and Tell
Give them a Hot Tub
Discover
Actions Centered
Product Box
Prune Product Tree
Tools
Realtimeboard
Deekit
Conteneo
Retrium
Scatter Spoke
Exercises
Herculean Donut
Jira Team Playbook
mad sad glad
Empathy Map
Hot Tub
nice step-by-step description
have team arrange stickies into categories, then dot-vote (3 each)
Similarity to SWOT
Buy a Feature
Agile Chairs
split group into managers and workers
then switch workers & managers, and trust workers to do the stepping in their own
what were the managers doing when they weren't micromanaging?
managers tell workers where to step (one at a time), count steps
the facilitator is a moving obstacle
Remember the Future Retrospective game
converse of a pre-mortem
backcasting
Thinking in Bets by Annie Duke
"working backwards"
Future Press Release
Customer Letter Technique
CEO congratulating team on success
apply to
personal/professional development
product
Mining the Timeline for Gold
Create Safety
Pre-Mortems
analyze a fictional future project that went wrong
Define Success
retro frameworks from Weave
Games from tastycupcakes.com
Agile Bang for the Buck
grid with value and cost in Fibonacci numbers on both
a planning model
agile games from BoxUK
presentation slides
sprint as movie plot of favourite genre
Treasure Island
decide on what the "treasure" is first
choose out of 3
similar to Sailboat
soup and circles game
based on Stephen Covey’s book Seven Habits of Highly Effective People
variation with "concern" instead of "soup"
from Diana Larsen
team controls
team influences
the soup
gather impediments
play online
Sample Retrospective
Sample Retro Plan
listing of phases
Close the Retro
debrief
Decide What to Do
diverge/converge on top 3 items
each person debriefs
open discussion 5 minutes
or vote
decide if continue
each person talks 1 minute
Generate insights
vote on them
dot voting in Miro
put a star in Google Docs
group them
list important items
A table in Google Docs
Zoom whiteboard
Miro
Jamboard
Trello
call them like there were a person at the whiteboard (like we did pre-pandy)
Gather Data
Iteration Report
Set Stage
check in
What were some of your neighbour's victories in the last two weeks?
how was it for the person next to you?
heroes
something that person next to you did that was helpful
Agenda
Items
summarize
process updates
learnings
all docs
update Runbooks to reflect changes in process
learn workflow
keep WIP to a minimum
recurring craftsmanship meetings
core protocols to decide
how do we efficiently decide/vote
all work should be reperesented in Jira cards
workshop
TRIZ
Agile Starfish
use Google Drawing
Remember the Future
review Radar chart together
Start-Stop-Continue
space for Ideas and Actions
Sailboat
particularly useful to strengthen team identity
chunk down
use SMART
team spirit is good, but not actionable
everyone present at Standup on time is specific and actionable
first define success
1-2-4-All
practice organizing into groups and solving a problem
similar to counting to 20
Check-In
options
say something personal
hobby
siblings
first job
pets
one positive observation
Count to 20 as a group w/out repeating
paying attention
coordination
each number must be said only once
1 word
pick a feeling from NVC inventory
Intro
Double Diamond
leadership is part of the job
you are all leadears
do experiments
ask questions
you are empowered by your responsibilities
your authority comes from our shared commitment to the success of this team and this organization
great values and opportunities to improve, still flexible
Prime Directive
4Ls
write on sticky notes
10 minutes
keep private!
add 5th column
Gratitude/Appreciation
Liked
things you really liked
What went better than expected?
Learned
Lacked
things you have seen the team doing, but consider that could be done better.
Longed For
something you desired or wished for
vote on issues, decide trys
gather data
metrics
Scope changes
stop/start work on a story
number of points
number of stories
defect count
velocity
charts
events
meetings
decision points
team membership
celebrations
new technologies
starting
Introduce Tree metaphor
Update Team Agreement
The agreement is owned by the Team. The Team enforces it.
no phones during standup
do not create tech debt
boy scout rule
write down a movie character
Harry Potter
Captain Lorca
Forrest Gump
Darth Vader
write down 1 word on how you feel about the sprint
thrilled/bored/curious, etc.
talk about privacy and safety
a dirty laundry meeting
find patterns
related
Virginia Satir's interaction model
Abilene Paradox
theories involved
Structural Dynamics
Structural Intervention
Model Building
Team Communication Anti-Patterns
Covert Opposition
Point-counterpoint
devil's advocate
Courteous Compliance
groupthink
polite during forming stage
Serial Moves
feeling of progress when overcommitting?
starting lots, not finishing
Building Trust & Cohesiveness
Accelerated Team Performance Model
the model
Communication Domain (how we speak)
domains
Affect
unlock trust and motivation
emotional side
chunk up
Power
construct actions not allowing other options
telling people what to do
personal motivation/emotion
Rule of Order (Operating System)
personal paradigm of how conversations should be
systems of conversation
Random
lose interest fast
puppies become dogs
why follow rules
individualistic
Closed
rely on negative or balancing feedback
authority & hierarchy
tradition
Open
everyone can contribute
process, participation, teamwork
may become dysfunctional
leader steps in
positive & negative feedback
consensual & unregulated
four player model
use
don't get stuck in one role
scaffold on each other's ideas
inquiry
generative dialogue
recognize difference (or re-frame) between Oppose & Bystander
do not confuse a mere comment with an Oppose structural act
Actions Domain (action propensities)
four structural acts
Bystander (comment?)
become a bystander when there isn't one
need enabled bystander
w/out an enabled bystander, the system can eliminate the Opposer
reality check
bridge differences
add perspective
Follow
Oppose
Move
measurements
psychometric instruments
same fundamental structure in all verbal communication in closed systems
team dynamics
Tuckman Model
stuck at a stage
Where Did You Learn To Behave Like That?: A Coaching Guide For Working With Leaders by Sarah Hill
Reading the Room: Group Dynamics for Coaches and Leaders by David Kantor
Dialogix
TeamCatapult
courses
Marsha Acker
Making Change Happen
is a theory of face-to-face communication
aka Structural Dynamics for Dialogue
David Kantor
Face-to-Face Communication study
studied transcripts of recorded conversations of young couples in the 1950s
voting
converge
time to process -- mental break
sleep on it
first ask clarifying questions
meeting people where they are at
the management wouldn't even consider trying out a weekly x-team sync similar to Scrum of Scrums
yet a top-down status meeting is accepted, and within minutes gets converted into a standup because of
the culture allows such behaviours
information was useful
self-organization
some people's habits
values need to change
we failed the executives
by letting them keep their thought orthodoxy
Coercive/Commanding
at the expense of motivation and creativity
short term improvements
leaves a detrimental effect on work culture
top-down
Pacesetting
often competitive
set high performance standards
Democratic
get buy-in from employees
consensus
collaboration
Affiliative
build trust with the firm
create emotional bond
manage conflict
Coaching
mentor
increase overall performance
employee/department
employee development
Visionary/Authoritative
useful in crisis/change
Scrum Master is PO of the team?
self-organizing teams
take responsibility for their own delivery
ideally not needed at standups
what matters is what happens when you are not there
help them to be awesome
you want me when you don't need me, you need me when you don't want me
the goal could be to (in)validate assumptions
provides valuable learning
reduces risk
Sprint Goal, seen as commitment, implies zero-sum game with stakeholders. When it's a forecast, we work together to extract the most #value.
When work in Sprint Backlog is seen as commitment, a zero-sum game is implied. As a forecast, we work together to extract the most #value
us vs them makes people game the system
a commitment/forecast
authority comes from commitment and resolve
be a facilitator, people are too complicated
same principles
delegate responsibility
strategic vs tactical
CI
make yourself dispensable
do not worry about how the team is playing the game
worry about removing impediments
worry about whether the team knows how to win
coach's responsibility is
understand context
understands what "winning" is
this way when they come back, and say we are done, it will be the same as the manager's/client/s vision
continues to follow the rules
make sure the team knows the rules
Personal Development
work is the best place to practice and improve
better results
burns people out - apathy and resentment
you think leadership is about telling people what to do?
so, what do you do when something goes wrong?
tell them more, with feeling?
treat teams as startups
foster leadership
treat team members like entrepreneurs
not every person would want to think of themselves as entrepreneur, but the idea is to recognize their interests and get them engaged
people in management think they have to be bullies
modelled after drill sergeants
Alan Dayley
How You Lead Is What You Get: Empowerment is not enough
similarity to
Cynefin
Teal Organizations
Shu Ha Ri
structure
co-lead
catalyst
leader finds out that a problem was discovered & solved
inspires co-leaders
empower
steward
empowers professionals
coordinator
delegates agents
manager
instruct
supervisor/manager
commands labourers
PM Knowledge Areas
communication
risk management
planning & scheduling
estimating
e.g. Scope & Cost Management
documentation
stakeholders
if everyone agrees with data/perspective/estimate/assessment
de Tocqueville on how the indirect effects of juries is the main purpose
except that he stated that the true purpose should be hidden
then there would be less discussion, less investigation
mobbing/pairing skill "sine" waves complement each other
whole greater than sum of parts
Kantor
blindspots
error correction
columns
Joint Risks
Joint Resources
Joint Commitments
Joint Objectives
forward pass and backward pass
create items in the first two columns from the items in the last two
starting a difficult conversation
I'd like to talk to you about something that is affecting me
but I am worried that in doing so I'll communicate disrespect judgement or intolerance of you
that's not what I want or how I feel
I just want to find a solution that works for you and me
is there a better way to do what you are doing?
what can we do to increase your quality of life?
specific goals for the next week
1 thing I can do to make you more effective
1 thing that I don't do frequently enough that you'd like me to do more often
1 thing that I do that you'd like me to continue to do
feeling fulfiled every day
know when someone is called away for an urgent task
maintain team presence
helps to focus
esp. if your work is related
even in the order of execution (e.g. I will help you with this when I am done with that)
helps to keep pace
know when to stop, don't overload yourself
each musician mostly listens to others
~6 people
managers assigning people to teams like work to people
self-sorting does this automatically
move authority to information
Rituals create community
lorry drivers in NZ
ritual reduced accidents by 75%
giving them heated belts that take 10-15 minutes
most accidents in the offloading dock
thinking as drivers
Core Protocols Intro
add fifth question to standups
how do I feel
Team Emotional Intelligence
high performance is subset of this
Amy Edmonsdon
Psychological Safety at Workplace
Primer from Hubspot
HBR Podcast
TED talk
in a Knowledge Economy
high correlation between the behaviours and performance
difficult to reproduce and measure causation in a complex system
stack of observed behaviours
Any sort of methodology
Scrum, Kanban, etc.
Productivity
alignment towards the same goal
Connections
self-aware individuals build on the other layers to create a cohesive whole
Self-Awareness
admit mistakes & learn
check-in
Freedom/Autonomy
no one is coerced
everything is a choice
everything is opt-in
Positive Bias
Assume Positive Intent (API)
Appreciative Inquiry (AI)
Most Respectful Interpretation (MRI)
assume everyone is doing a good job
unconditional positive regard
Carl Rogers
started
project to reproduce high performance
observed 100s of teams for many years
HPT @ MS
blew Borland out of the water
created Visual C++
Richard Kasperowski
The Core Protocols: A Guide to Greatness
Jim & Michelle McCarthy
Check Out
similar to escape valve from Brene Brown?
Pass
Decider
vote
flat means "support-it"
thumbs-up/down/flat hand
must bring in all outliers to a "yes" or "support-it"
use Resolution Protocol to bring outliers in (the "nos")
What will it take to get you in?
Response: short declarative sentence with precise modification
withdraws proposal
proportion of "no" and "support-it" too high
anticipated gain less than cost of Resolution
~50% "support-it"
absolute "no"
a member cannot be part to proposed
Check In
Commitments
get a permission to disclose personal details
be silent during another's Check In
pay attention, don't look at your phone
state feelings only as they pertain to yourself
state feelings without qualification
Team says "Welcome"
acknowledge shared goals
acceptance
I'm in
shared goals
I feel [one or more of MAD, SAD, GLAD, AFRAID]
Try to go deeper and describe more than one emotion
don't diminish your emotional state
e.g. no "little mad", just MAD
All emotions are expressed through MAD, SAD, GLAD, AFRAID
e.g. "excited" is GLAD & AFRAID
optionally say "I pass"
only works in large groups (>5)
Pass Protocol
may provide a brief explanation
Law of diminishing returns
increase a single factor of production
Fred Brooks
Mythical Man-Month
Slack message
*Crocker's Rules* 1. Accept full responsibility for the operation of one's own mind 2. (a corollary) If I become offended it's my own fault ```Declaring yourself to be operating by "Crocker's Rules" means that other people are allowed to optimize their messages for information, not for being nice to you. Crocker's Rules means that you have accepted full responsibility for the operation of your own mind — if you're offended, it's your fault.``` https://en.wikiquote.org/wiki/Lee_Daniel_Crocker
2. If I become offended it's my own fault
1. Accept full responsibility for the operation of one's own mind
benefits are indirect
removing all emotional content from communication is harmful
it is still important to consider how the information is received
this is the meaning of the communication
benefits
respect
treat people like they are responsible and capable of handling their interpretations
MRI
courage
foster trust
focus on problem not person
quote
Declaring yourself to be operating by "Crocker's Rules" means that other people are allowed to optimize their messages for information, not for being nice to you. Crocker's Rules means that you have accepted full responsibility for the operation of your own mind — if you're offended, it's your fault.
multiple teams cadence
Never verified, only invented to illustrate an idea
Forming, Storming, Norming, Performing Four-Stage Model
Performing
Personal & interpersonal development
Disagreements resolved within team positively
No instructions or assistance necessary
More clear on why
Norming
Shared leadership
team molds its processes
Commitment and unity
social activities
Less/no guidance from an external leader
Shared vision
Team is strategically aware: what and why
Storming
Relationship, trust, emotional issues
Focus on each other/processes more than on work
Size each other up
Forming
Processes are unclear
Purpose, objectives are unclear
Little agreement on team goals
Need guidance
used to avoid stagnation
reteam to discover the right chemistry -- don't break up teams that already have good chemistry
ways to minimize drop in productivity associated with changes in membership
velocity dips
case against heroes
from Kent Beck
red-green & TDD
social responsibility
to promote fairness, safety, self-actualization
autobahn
get out of the way
ensure safety
guardrails, etc.
make sure surface is smooth
help individuals grow personally and professionally
evolutionary/servant leadership
similarity with Satir Interaction Model
Response
Significance
Meaning
Intake
the loop
Act
Decide
Orient
Observe
the advantage is in having a faster loop than another system
adversary
organization
market
F86 vs MiG-15
not heavy artillery, but rapid response to change
1:6 kill ratio
Col John Boyd
Energy-Maneuverability theory
Via Negativa
fix by subtracting rather than adding
smoking
paperwork
rules
usually less dangerous
adding new processes has its own overhead
does it make the boat go faster?
used in Catholicism to define what God is not
neti-neti
Sanskrit for negating everything that is not Brahman
Daryl Kulak
Nassim Taleb
MVC
a change experiment
validate untested assumptions
smallest possible change that maximizes learning and buy-in necessary to executing a viable change program and its change tactics
smallest product increment that can accelerate the learning necessary to develop a sustainable business model
value the learning, the product itself is less important because it will certainly change
take the best guess, and then iterate
agile institutions
start with user needs, not the institution needs
build hospitals to make patients comfortable, not to make doctors' time more efficiently utilized
governments
cities
hospitals
agility on every level of company
TreeHouse
GitHub
Buffer
it is more important to be able to measure and validate a solution than to come up with one
"more important to improve work than to do work"
from TPS?
there could be many plausible good ways to organize work
we should have smooth mechanisms (like CI/CD) to quickly analyze and adapt
we should be able to experiment and adjust based on feedback
although there are processes that can help
similar to Jeff Patton's metaphor to eat lots of trout instead of one elephant
it is about solving complex problems
Steve Denning(?)
business architecture
cross-funcitonal teams
set direction
clear deliverables, expectations, objectives
expectations
participation
project goals and objectives
ask each person
skill/will ratio
style/preference
working alone or in a group
goals for being on the team
is this an opportunity to develop professionally?
do you enjoy the topic?
personal growth?
what specialized skills
defined by scope
do we have all the required expertise to complete the project?
what is the scope?
higher chance of success
contrast to
a medical team that's nothing but radiologists
a baseball team only with catchers
an orchestra with only trumpets
ignoring benefits of cross-functionality
they know how to deliver on their functionality, but they miss on
dependencies & comms with other parts of organization
overall value
sales/marketing/IT
all functional
release manager is an anti-pattern
PO/Product manager is responsible for the whole scope
local optimization
blindness to bottlenecks
project managers focusing on a segment of business
everything else is side effects of putting professionals together?
contribute to the "pull"
important because they serve to align everyone in a company
achieve the decentralized decision making nirvana
pass information, not instructions
where people are helping you achieve outcomes instead of following instructions
laying bricks vs building a cathedral
example of Nike?
Why Small Batches?
when we make commitments/predictions, we place a bet that we can honour the commitments
if there is a way to prove that our bet was solid and that it will pay off, we should do it
therefore we should endeavour to prove as quickly as possible, to strengthen our conviction...
cf Dijkstra's requirement for provability of code
deficiency gratification
we are deficiency motivated
we will seek environment that will gratify that deficiency
psychological needs similar to physiological needs
what is good for the individual will also be good for the organization
if you create environments that are good for people, you will create outcomes that are great for organizations
e.g. high trust environments
unfulfilled needs of individuals result in reduced org health and performance
balance Project to Product and Kotter's Accelerate
Dean Leffingwell
nod to RUP
2 operating systems
innovate and grow and maintain and support
explore and exploit?
hierarchies may be necessary
encapsulate all three in the growth mindset
How
Lean
What
Why
Design Thinking
customers don't know what they want even when they say they do because things change
we enter a partnership with the customer where we work to deliver most value by
measuring something real: how they interact with us and with the product instead of something fake: what they say they want
Kodak & GM thought they were doing well until the bottom fell out
giving the customer access to the senses they may have not had before
delivering a little bit and getting feedback
Heart of Agile
a fractal
a better adaptive organism
not following Agile Manifesto principles is risky, but best practices may not be best for everyone equally
focus on completion
is a hospital more interested
need clear goal
which hospital would you trust more as a patient?
EBM
in keeping the staff 100% utilized
filling all the beds
in quick recovery for the patients
in healing patients fast
solve half of the problems rather than creating half-solved problems
project vs product
people are fungible resources
working on multiple projects at once reduces productivity
instead: bring work to people, not people to work
may work in a factory
upfront contingencies for risks
padding for potential risks bloats budgets and schedules
ask upfront for everything that will be needed for the project
need instead: fast learning, frequent feedback, pivoting
embracing change
disincentive to explore, experiment, and innovate
project approach ignores tech debt because
projects end, while product maintenance & new features become someone else's problem
optimize flow not resources
productivity is a team metric
push authority to where the information is
Exploitation
short term
refine existing processes
production
Exploration
long term
activities
risk taking
innovation
research
discovery
Layered architecture
BPEL - Business Process Execution Language
SOA & BPM (business process management) to align IT with business
book Team of Teams by
Gen. Stanley McChrystal
changed strategy in fighting Al-Qaida
know future
illusion of
control
stability
8 steps
Keep improving
Validate with team
Generate roadmap
may use Portfolio for Jira
Smart releases
Estimate
Granulate into epics
populate backlog
Identify initiatives
contribute to strategic themes
Vision - big picture
strategic themes
create mission tests
during retros
measure how well we're achieving these missions
scaling
identify processes (5-10)
who will be responsible (monitor and alert the rest, not a dictator)
start with Big Hairy Audacious Goals
break down to 5, 3, 1 years
down to every week
work on top 3 things to meet monthly/quarterly goal
similar to lean
rhythm
data
priorities
by Verne Harnish
Scaling Up
mastering rockefeller habits
skill transfer vs KT
giving information is insufficient
be ready to learn that we were going in the wrong direction
admit that we can use more learning, that we don't know everything
cognitive domain
working back from Creating to Understanding
the simplest prototype is nil, so we start with that, and immediately see where it doesn't fit, so we create a better prototype, and increase our acceptance criteria
is red-green cycle similar to MapReduce?
seed in MapReduce cycle
draw a prototype, see where it doesn't fit
Bloom's Rose
Evaluating
Synthesizing
Analyzing
Applying
Comprehending
Remembering
make people awesome
use scaffolding
guidance-fading effect
PBL
full permission to push back against the barriers that are holding them back
narcissistic wound
promotes narcissism
System of Delivery and System of Transformation
delivery
1 backlog
testing, CI
ownership of technology stack
predictability - stable velocity
stable, cross-functional teams
ritual & habit
like oral hygiene
transformation
can't run marathon
stages
removing impediments
e.g. Scrum will expose dysfunctions
can't rely on an external force
like management removing obstacles for "resources"
respect for individuals
help them mature
people must be there and ready to continually remove obstacles
when there are no opportunities to apply their passions at workplace, people volunteer outside of work
Ehime Maru and USS Greenville collision
emergency ballast blow exercise
Team
"had too much respect for the captain" to point out that he is not following rules
Captain
didn't see Ehime Maru 2km away
skipped procedure steps
because schedule
took over periscope
seeing oneself as a victim of a culture rather than creator of the culture
culture is intentional
doesn't just happen
what we permit and what we promote
instead of leaders making decision with information supplied by people in the field, it's people in the field making decisions based on the information they receive from the leaders
idea from Team of Teams
delegating authority
Scrum is a value system
it's hard and a map is always helpful
we need people to be
on board
engaged
immersed
participative
we transform
more than technical practices and culture
the organization
how and what is measured
how continuous improvement is implemented
how mistakes are treated
how decisions are made
governance
how teams are formed
technical practices
e.g. TDD
how we work
who we are
nurturing
nourishing
during argument
I'd like to switch to your side and argue for your perspective for a moment
Rapoport's Rules
this will
give me a more complete picture
let me experience the situation from your perspective
when fear/bravado/heroism is a significant contributor to the culture of a software development organization then inaccurate estimates, skewed and sugar-coated for the higher-ups will result in more escaped defects and outages that would have to be supported
this causes support departments to grow bigger
saying "yes" to everything, and then telling everyone that we are "working on it" is not the best strategy to gain credibility
SCARF model
slide
the acronym
Fairness
be fair
not understanding need for fairness
fair exchange vs unfair exchange
Relatedness
show trust
create human bond
forgetting to connect on human level
openness
ingroup/outgroup
design to avoid silos
people we haven't connected yet are perceived as threat
oxytocin generated on bonding (introduction)
encourage to make decisions
delegate
micromanagement
choice
reduces stress
Certainty
clear expectations
unclear expectations
ambiguity is threatening
brain is certainty-creating machine
Status
do
point out areas where people are good
turn up the good
too much feedback/guidance
people argue when receiving feedback
life threat
get people to self-assess
status increase
tools to give oneself critical feedback
increase == reward
loss == pain
carrot and stick approach doesn't work because it's extrinsic
look below conscious awareness
organizing principle of the brain
evolutionary adaptation (principle?)
minimize danger -- maximize reward
away vs towards
why do we exist?
at the heart of our core purpose is something grand and aspirational
not rote and technical
all organizations exist to make life better for someone
the lens through which we look when making decisions
Openness in Scrum
sprint review
sharing progress with stakeholders
openness to feedback
Transparent Product Backlog
openness with stakeholders
SG is fixed, but plan how to meet it is different
limited sprint
openness to changing direction
do not remove connection to the goal when passing messages
pass full understanding: transparency
admit when change is needed
make decisions as a team
feel heard
share perspectives
offer help
ask for help
Transparency + courage
pillar of empirical process control
Respect in Scrum
respect other teams
deliver quality code
respect all opinions
assume they have good intentions
doing their best
people are motivated
backgrounds and skills
people are resourceful
review Done items only
respect for stakeholders
Sprint Backlog is owned by Team
respect for Team's knowledge and skills to decide their own work
entire team attends meetings
respect for all roles
Focus in Scrum
Timeboxing creates urgency, helps focus on the purpose
Product Backlog orients towards what's next
SG
Events and artifacts focus on inspecting progress
e.g. burnup chart
Done Increment every Sprint
product vision
overall outcome
accept uncertainty
analysis paralysis
know what to tackle first
focus on undone work together
we are a team
we share the same SG
courage as a value of XP
In XP & #Scrum courage is a key value. It keeps us going. A proper balance of #courage & #safety makes for most productive workplace dynamic
courage to go forward knowing that there will be mistakes (that's why we go in small steps, then inspect)
from Dave Thomas
necessary on the level of the company as well as individual
Courage in Scrum
permission to say no
Dev Team
accountable for quality
say no to cutting quality
accountable for value
allowed to say no to low value features
Sprint reviews & retros limit damage, allow small experiments
timebox
assumption that it's okay to change direction
inspect-adapt
Admit our mistakes
Engage in a productive disagreement (conflict)
Go into the unknown, and build something new
embrace uncertainty
Admit our assumptions were wrong, and change direction
Hold others accountable to meet commitments to the team
Admit when we don't know something
Not to show undone work
Transparent about progress under pressure
the evil twin of compliance
self-induced multitasking
institutionalize w/out bureaucratizing
status-chaser antipattern
whoever asks for status becomes the client
separation
from blame to power
blame vs accountability
blame addiction
blame cycle
XP practices foster product thinking
Does this expand your intellectual horizon?
Karl Popper-ish
one of the key things that we do is exercise good judgement while applying professional standards
leads to innovation
flexibility to implement innovation
product success/happy customer
invalidate assumptions
stop reacting and start doing (creating?)
prevent sliding back
culture is habits
know what's important and have a permission to do it
orgs become smart if they are healthy
unhealthy org will
not recognize opportunities
make worse quality decisions
get stuck
if you give people freedom they will surprise, delight, and amaze you
common language
word clouds
consists of
terminology
taxonomy
common goal
when QA is behind
be in flow together
be effective together
we are united by the same goal: to deliver
everybody's job is Product Development
generalizing specialists
patient in surgery metaphor
insufficient collaboration
the whole team must help deliver the outcome for the Sprint Goal
only fully Done work items bring value
use Flow Efficiency and Flow Metrics
not Resource Efficiency
move towards excellence
can we still improve, or are we already perfect?
fulfilled
happy at work
proud of their work
mastery, autonomy, purpose
focus
the mission itself
the process of how to do it
the person telling you what to do
common
interpretation
sense of priority
values
understanding of context
Time Out
exercise
what can we do?
obstacles
relation to strategic storyline
discuss what is desirable
each team member writes a few words
propose a situation
ask "What would you do in this case?"
generalize from a recent experience
exhaustive regularization is not possible
behaviour is contextual
Industrial management
less useful for complex interactions
instead of management telling people where to go, people with the information tell management where they see the system emerging
the "right thing" keeps on changing
best fit for ordered systems
checklist
workflow
if the developer has to jump through too many hoops, and get it okayed by the PO
from Modern Agile podcast (?)
is this the same as spiking?
the hoops
make it into a story, put it in backlog, have PO prioritize it
we must make it safe to do such experiments
they might decide not to try
People don't buy WHAT you do, they buy WHY you do it
Start with Why by Simon Sinek
value based thinking
better & more insights
faster decisions
or one that is not seen as such by management
dangers of best practices
we stop adapting
and inspecting
codification leads to inflexible processes
secondary, it comes from effectiveness
acknowledge need to inovate
not a hybrid
maintain legacy that is profitable while planning to adapt
Gartner
empty cup in order to fill it
Interactive
talk & collaborate with change
retrospective
active
copy & tweak
talk to other companies
passive
watch from afar
do not interact with change
e.g. check it out on the internet
Sharpen the saw
Seek first to understand, then to be understood
Think win-win
Put first things first
Begin with the end in mind
Proactive
all the heart and soul, blood, sweat and tears poured into it must be worth it
confusion about responsibilities
no longer done by HR
onboarding
career development and goal-setting
performance management
96% of HR managers gave their own performance evaluation system C, D, or F
if a team member has a question about configuring environment
HR can't teach how to be on the team, only point to standards
knowledge of the subject matter is needed
self-organizing
soldiers using electrical tape for additional magazines
firefighters
they are intracting with the people that can help--their teammates
is having onboarding done by HR helping teams to self-manage or is it subtracting from it?
ownership and accountability
comes from when "resources" were frequently switched between teams for diff projects
when HR tracked career development
long-lived teams
design the reward structure that works
still instrumental in setting the culture
Agile methodologies focus on the right values, and on leading
progression through shu-ha-ri?
are
busts out
discovers new rules
finds the cheese
learns rules
employees want
happy
place of learning
contribute
belonging
be part of something I enjoy
learn new skills
make a difference
be valuable
have an impact
grow my career
hiring managers want
alignment
effectiveness
order
increase the momentum for the company goals
increase momentum
e.g. culture shift
create order amongst people
create cohesion
bring skills we lack
increase resources
increase production
reporting hours considered harmful
timesheets vs burn rate
however the team organizes internally to get the work done is up to the team
as long as the team regularly, reliably, and predictably completes work that is given by the organization
prevents collaboration
all the information that is necessary is available w/out forcing devs to do this
erodes connections between teammates
promotes selfishness
when people are thought of as inanimate resources it is
you are the only problem solver
you are the active component with agency
everyone is passive
more difficult to expect them to be proactive
is the company for the peoaple, or are the people for the company
sovereign
which one is an end and a means?
power over
other types of relationships
power among
catalyst --> co-leaders
power with
steward --> professionals
power for
coordinator --> agents
"power over" is the only possible relation when people are seen as resources
supervisor --> labourers
resources are similar to machinery: must be utilized
on measuring utilization
books
Actionable Agile Metrics for Predictability
The Agile Mind-Set (page 29, 86, 185)
offer other metrics
this will reduce performance
focus should be on results not on utilization
surgery nurses, FedEx, firemen
efficiency
saying to a surgeon: "Why are you not cutting? I am not payingyou to stand there."
capacity utilization vs impact maximization
machines are utilized to do labour
individuals organize to make things happen
commitment vs compliance
you can't get commitment from a machine
that's why tayloristic orgs don't like commitment
the degree of commitment that is required for a striving business requires more than just "resources"
Accounting for Slavery
How Slavery Inspired Modern Business Management
"task master" commonly used in connection to slavery
The first value
individuals and interactions over processes and tools
treating individuals as tools makes this value lose meaning, showing how inapplicable Taylorist thinking is
The fourth principle
Providing motivated individuals with the environment and support they need and trusting them to get the job done
better one
As individuals on the team, we want assistance from an Agile Coach in building a happy and healthy org, so that we can grow personally and professionally
badly formed User Story
the "who" shouldn't be the same person who is doing the work
seeing developers as "labour" promotes the Theory X prespective
benefits of pairing become hidden
maximizing capacity utilization
People First
customers will never love a company until the employees love it first
Sinek
people first
intrinsic motivation and happy and healthy teams
On blaming individuals for the shortcomings of systems
organizational structure produces behaviours
Milgram, Asch
Stanford Prison Experiment
Blameless: Let’s really try and understand what happened to prevent it from happening again?
Blaming: Person “X” caused the incident (note: this is not blameless, it’s just nameless).
Blameless: Where did the system fail to allow this to happen?
Blaming: Who’s fault is this?
Blameless: Why did this problem occur?
Blaming: Who caused this problem?
Along with the change in culture goes the change in language. Consider these examples:
Blameless Culture is the concept that recognizes that behaviour is a function of the environment. This is known as the Lewin's equation: B = f(P, E). A number of organizations went further than just recognizing this, they built it into their culture (e.g. Google). When something goes wrong they look at why it happened, not who is to blame.
never blaming the people for their troubles
acknowledge pain and work to fix it because we are empowered via our commitment to success
people and interactions over processes and tools
Respect for people in Lean/Kanban
Cockburn article
First order non-linear component of software development
SRE
Problem Management
focus on preventing incidents from happening
incident management focuses on restoring servicet, recovery
invoked when
Ticket resolved, but root cause undetermined and service desk suspects it is likely to recur
Trend analysis of logged incidents reveals pattern
Analysis of an incident indicates that a problem is likely to exist
Confirmed by another team
Incident management cannot match an incident to existing problems
CALMR
Recovery
Measurement
Lean Flow
Automation
Culture
The Rugged Manifesto
Rugged DevOps
7 habits of Rugged DevOps
emphasis on security
in reference to the term rugged landscape?
The 3 ways
Continuous Learning
repetition is prerequisite to mastery
mastery through practice
learn from failures
culture encourages experimentation
right feedback at the right time
feedback will optimize the value stream
feedback loop
amplify feedback loop
shorten feedback loop
create an upstream feedback loop
quality at the source
improving daily work is more important than doing daily work
understand customers' needs (internal and external)
Flow
never allow local optimization to cause global degradation
never pass defects downstream
increase flow
understand flow
value stream
work only flows downstream
what are the drama triangles on this team?
types of feedback
yes and
I am on your side and we have an obstacle to overcome
critique
ask powerful questions
objective
why
why not
directive
reactive
get feedback on my feedback
continuous peer reviews with context (OKRs?)
consider OSKRs
John Doerr's book has great resources
Continuous Performance Management
use CFRs to process OKRs
CFRs
Conversations, Feedback, and Recognition
various types of performance discussions
similar to paper Richard wrote
for OKRs
annual performance evaluations
if a person's salary/raise/promotion, etc. is on the line
their focus is not on getting better
they will focus on getting laudatory feedback
it's just feedback, don't call it assessment or evaluation
if it is important, we should not wait one whole year to provide feedback
shift focus from evaluating to helping to get better, to succeed
assessments missing the context
Lewin's equation
performance is function of environment
backleading
Agile is a collaborative approach to work
ROTI
see J Rothman on measuring value of meetings
Return On Time Invested
it is possible that the degree of collaboration
is not "normal" for managers and/or team members
uncomfortable with pair-programming
needed to realize the benefits of Agile
moving to self-organization requires self-organization
Mike Cohn
command & control vs autonomy & alignment
Agile Manifesto Value 4
Responding to change over following a plan
upset that someone is late to a meeting
stable environment
complex domains
VUCA
No plan survives first contact with the enemy
Moltke
Plans are nothing planning is everything
Eisenhower
OODA Loop
empiricism
trust data over plan
anti-totalitarian
ignoring changes in the business reality
unaddressed risks
missed opportunities
Agile Manifesto Value 3
Customer collaboration over contract negotiation
infinite game
not zero-sum game
contract negotiation enough to support customer collaboration
focus on value and work
similar to #2
collaborative space
from Leading Agile
how turning a relationship between individual into a transaction reduces trust & collaboration
when whoever is best suited to address the issue does it instead of checking whose job it is, work flows
embrace change
understanding and meaning of requirements will change on both sides
business environment changes
communication is important to deliver value
contracts do not replace communication
Agile Manifesto Value 2
Working software over comprehensive documentation
Documentation still important but as part of the outcome, not the output
quick results & request for feedback is better than a Gantt chart
these documents are meant to reduce risk, and the assumption is that they will catch defects, implying that the delivery team is not trusted (possibly because increments are too large)
some forms of documentation are meant to reduce risk
based on the third-party contractor model where there is minimal trust
finite game
the amount of delays introduced by the stage-gate (approvals, etc.) and other types of documentation is staggering
approvals & change requests reduce agility
customers aren't paying for documentation
no value in delivering documentation alone
Agile Manifesto Value 1
Individuals and interactions over processes and tools
what's important is that people work together well, what tools they use is secondary
difficult to accept for people who treat individuals as resources
"fool with a tool is still a fool"
independence vs interdependence
teams vs groups
Principle 12
Reflect and adjust at regular intervals
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
then tunes and adjusts its behaviour accordingly
empowers team
in Scrum implemented as retro resolutions
the "adapt" part of inspect-adapt
the team reflects on how to become more effective
the team, not the manager
retrospectives
the "inspect" part of inspect-adapt
requires transparency, which requires safety
At regular intervals
product management is a continous effort
focus on team getting skills, not on a short-term project
iterative everything
plan to ride a bike around the building
iterative, continuous post mortems/lessons learned
Principle 11
The best architectures, requirements, and designs emerge from self-organizing teams
from self-organizing teams
not order-takers
escape room
must collaborate to make sense of multiple clues
similarity to emergencies when the whole team works together
quote from Gen. Patton
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”
have all the skills to deliver the complete solution
motivated
self-directing
autonomous
flat
have agency to direct themselves
not waiting to be told what to do
emerge
shared purpose
for a solution to emerge, there needs to be alignment
each User Story tacitly points towards the goal
shared ownership
shared responsibility
your opinion matters
evolutionary
experimentation
The best architectures, requirements, and designs
involved in every aspect (phase) from the beginning
solutions
ideas
Principle 10
Simplicity--the art of maximizing the amount of work not done--is essential
there will always be more ideas/features/requirements than time/money to build it
therefore: maximize the amount of work not done
This is Lean
how did they build fully outfitted, seaworthy merchant ships in 2 days?
requires seeing the big picture
maximize the stakeholders' return on investment
focus on goals
prioritize
is essential
essence of what creates value
the art of maximizing the amount of work not done
output vs outcome
pathological
looking busy
gold plating
finish sooner and get the feedback faster
then iterate
what is unnecessary?
Simplicity
clarity
understood by all
easily communicated
no obfuscation
Principle 9
Continuous attention to technical excellence and good design enhances agility
quality & speed
high quality allows to go faster
enhance agility
necessary to react to change
good design
product management
technical excellence
technology is changing
sharpen the saw
Continuous attention
always learning
safe to be a novice
state of flow
Principle 8
Maintain a sustainable pace
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain constant pace indefinitely.
indefinitely
game theory
finite vs infinite games
we want to stay in business indefinitely
regardless of a "phase"
ther are no phases
should be able to maintain a constant pace
explore vs exploit
allocate time for
rest
consider accumulation of tech debt
variability
flow
The sponsors, developers, and users
harmony
cross-functional
systemic view
optimizing the whole
Agile processes promote sustainable development
respect for people
understanding needs of stakeholders
social responsibility for teams
overtime
burnout
Principle 7
Working software is the primary measure of progress
is the primary measure of progress
matter
outcome
Done work
don't matter
acting busy
output
number of tickets
hours
effort
Working software
Iteration Review
Acceptance tests
plans and promises don't count
delivered functionality
solved problems
the only thing that really counts is that problems are resolved for customers
Principle 6
Face-to-face conversation is the most efficient and effective method of conveying information
The most efficient and effective way of conveying information to and within a development team is face-to-face conversation
is face-to-face conversation
whiteboard
full bandwidth
93% non-verbal
details about future direction
to and within a development team
frequent and efficient validation
effective communication with stakeholders
understanding and alignment with business
The most efficient and effective method of conveying information
ownership and responsibility to communicate well
active role in creating and directing information
bring authority of decision-making to information
Principle 5
Trust motivated individuals to do their jobs
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
intrinsic motivation factors
Plot Productivity by Fear/Indifference - Love/Concern
x/y axes
inverse
productivity
mutual vs individual responsibility
love
concern
"too soft"
ignore bad behaviour
allow people to get away with stuff
neglect is not love
commitment low/high not related to love
low commitment leads to permissiveness
logical flaw
agape ~ charity
y
commitment
mutual responsibility (hi love)
compliance (hi fear)
x
fear & indifference vs love & safety
Marc Bless
Drive-driven personality
Scott Ambler (DA)
trust them to get the job done
focus on why and what, the team will focus on how
aligned on the objectives
and support they need
equipment
cross-functional teams
The environment
recognize need for flow
flow of work
psychological
healthy vs unhealthy climate
behaviour is a function of the system, not individuals
e.g. Stanford prison experiment
Give them
supporting structure vs reporting structure
respect for the people
Build projects around motivated individuals
help people grow
intrinsic motivation is stronger
find passionate people who love their jobs
Principle 4
Business people and developers must work together
Business people and developers must work together daily throughout the duration of the project
requirements will be wrong and assumptions will become invalidated
look where you are going
e.g. riding a bicycle around the block to get ice cream
we learn more
the situation changes
we have to be able to get answers from the business (product) people
2 minute rule for questions
teams are expensive
Daily
awareness of and connection to business value to the company
PO must be available every day
Must work together
no silos
Developers
includes designers, BAs, testers, etc.
whoever creates the solution
Business people
customer-on-site
Product-centric, not implementation centric
Principle 3
Deliver working software frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for shorter scale
with a preference for shorter scale
path for improvement
from a couple of weeks to a couple of months
short iterations
easy to plan
easy to pivot
manageable
small batches
from Lean
frequently
feedback
course corrections
working software
confirm that there is a problem that is solved
tangible value, not paperwork
Deliver
commitment and courage
have something finished
concrete feedback
small OODA loop
Principle 2
Welcome changing requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
we don't know what we want: we need to refine it as we go
we shouldn't keep on doing something if we find out that it is wrong
need constant feedback
any impediment in the way of getting the feedback will be detrimental
trust
gives rise to contractual issues
traditional change management == change prevention
agile change management
requirements change like the Product Backlog changes
Backlogs are always changing
Agile processes harness change for the customer's competitive advantage
understanding of what is valuable is required
value drives everything, not schedule
excessive focus on schedule ignores human factors
awareness of the business value of work items
constant connection and understanding of the customer
who is the customer?
user of product
PO is voice of customer
even late in development
incremental vertical slices prioritized by value
last responsible moment
changing requirements
flux
reality changes
Red Queen
accept change in every aspect of work
Welcome
it's not "accept" or "acknowledge"
openness and calm
Principle 1
Deliver early and often to satisfy the customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
dissect
valuable software
value defined by customer (or PO) who prioritizes work by value
continuous delivery
swarm
better to deliver frequently than in batches
WIP limit
Little's Law
e.g. one today and one tomorrow or two tomorrow
get constant feedback
maintain relationship
early delivery
quick feedback
the customer
the user of the product
voice of the customer is represented by PO
what type of support department would best solve the customers' problems in the long and short term?
satisfy
acceptance tests
definition of done
highest priority
understand the principal way we bring value
Our
we are a cross-functional team
for CS
CS knows best what customers want
deliver value continuously
architecture
strategy
leadership
culture
people are trustworthy and have good judgement
the problems are almost never in technical knowledge or in ability to do strategic planning
speed of trust
eBay
consider two children (bet on the future of one of two kids)
product of apathy and dysfunction
raised in a solid, loving home
consider two children
the key is not access to knowledge and resources
it's health of the environment
the problems are in organizational health
see Just Culture by Sidney Dekker
"you can't adequately design anything without in-code experimentation and implementation"
Bob Galen
No more single wringable neck
is this related to blameless?
"They are all chickens", Melissa Perri
Developer who managed to delete prod DB on the first day, and got fired for it
Incident at Delta Airlines
wheel fell off of a 737 because the bearing was for a 757
cause?
the old approach would be to punish individual workers
the process produced a defect
0.003/inch difference
Is there an organizational equivalent of self-regulation or willpower that is necessary to delay gratification for tasks such as implementing TDD?
Is there a similarity to gambling
a solid measure of code quality
offers a working code guarantee
akrasia
higher order volition
willpower to delay gratification
immediate satisfaction vs preparation
self-regulation
second order desires
Est-ce que le TDD augmente la vitesse de développement ?
sorties in Afghanistan
improved after instituting a daily meeting with squadron commander stating (among other things) what mistakes he made
Blue Angels debrief after every performance with the "boss pilot" stating
how he contributed to the problems
what went wrong
what went well
safety
transparency
push down authority
retros & standups
based on Lisa Lahey and Robert Kegan
ITC map
people don't like change, they need change
immune system rejects transplants
when diagnosed with life threatening heart disease 100% agree to change their lifestyle (which would cure them), only 13% do (1 in 7)
Contributor Safety
Airplane pilots in WW2 were allowed to choose whom they fly with because they died so often
Otto Sharmer
Organized irresponsibility
nothing can stop this team from moving towards excellence
in delivering the best product and the best value for the customer
quantitative (performance) accountability
behavioural accountability
leading indicator
long before quantitative results are seen
hold people accountable out of love
help each other improve
pick one: obedience or engagement
remember a time when you were completely in charge of your next steps forward
reproduce it
space between stimulus and response
Victor Frankl
process
steps
denial
blame
justify
weather/culture/economy
shame/guilt
obligation
procrastination is side effect of obligation
trapped
responsibility
saying "no"
I am free, powerful, and at choice
place of power
access to all the probabilistic reasoning
generative mental state
a greater want
pre-responsibility stages have very simple logic
we get stuck
normal process, we all go through it multiple times every day
operates with
confront yourself
awareness
will
intention
be an agent, have agency
like digestive or circulatory system
go to our defensive/resistent mind
mental pattern that we repeat when things go wrong
when you blame the outside world, no progress can be made
adjusting the sails vs blaming the wind
being responsible vs taking responsibility
accountability vs responsibility
overcome angst, frustration, upset
self-awareness
"first step"
Emotional Intelligence
came out of
research program in 1991
studies on personal responsibility in teamwork
ownership to each other on a team
Scrum 2020
3 commitments
Definition of Done
Sprint Goal
Product Goal
we have rights so that we can fulfill our responsibilities
I must give you the space so that you could make your contribution autonomously
intrinsic drivers
we have authority so that we can do our jobs
increase local autonomy
built-in support
Retrospective
continuous improvement
Standups
commitment to each other
commitment to transparency
DoD
source of authority
dedication to doing our best
commit to the success of the team
commit to fulfill SG
commit to be professionals
commitment to quality & continuous improvement
commitment == resolve
distinction between commitment and its evil twin compliance
see Peter Senge
in regards to selected work, it's a forecast
"...recognize the inherent uncertainty in building software of any real value and complexity"
forecast, not commit to deliver specific work items
cannot hold developers accountable for things outside of their control
easy scapegoat
scope may be renegotiated
priorities may change
teams solve complex problems
by analyzing and coming up with a unique solution
the same approach should be applied to the development of the team itself
processes crystallize and become non agile
from hero culture towards team culture
what are the forces that put in place and maintain hero culture
we are built to maximize success of what we are responsible for
you don't need a boss telling you what you are doing wrong all the time
from Jerry Weinberg
you just learn to not be seen
a manager decides what needs to be done, and someone else will be held accountable for doing it
Esther Derby?
not as a peer to peer decision
cat & dishwashing machine
don't
learn error & develop bad coding habits
accept invalid requests
ignore missing environment variables or configuration
swallow exceptions
safe to fail
TDD, CI, etc.
fewer bugs go into production
expose issues quickly and visibly
Agile culture
reduce uncertainty and variability
worse options
fail silently
workaround
delay failure
there will always be bugs & design flaws
fail early, fail often
phenomenon when small exposure to a destructive agent brings benefits and strengthens the whole system
hormetic response
are we a turkey?
butcher feeds turkey
from turkey's standpoint the reversal of butcher's behaviour is a black swan event
some perspectives have black swan cohfusions
not for the butcher
statistically each day the certainty that butcher loves feeding turkey grows
overprotective parents
monoculture
we state in our rule book that discrimination is bad, so we did our part, there is no discrimination
our website will never be hacked, so let's not even talk about it
Fukushima nuclear reactor was built to withstand up to the previously recorded levels of earthquakes
not preparing for the next one, but for the last one
robust
bitcoin only goes up
housing prices only go up
race to the bottom
network
hierarchies
shouldn't block communication
need someone to strategize
hierarchy of competence
friction/culture clash between the teams and the organization
top management prioritizes bottom line
team prioritizes customer
customer
a customer focused organization
don't sacrifice customer for safety
net promoters goal
how customers perceive they are being responded to
PO
proxy for all customers
voice of the customer
quick feedback loop
feeds the team engagement
autonomy, mastery and purpose
instead of everyone looking at their boss, they look at the customer
like the revolution in astronomy
the earth moves around the sun
can't have a little bit of either one
delighting customer is the new boss
obsession with delivering value to customer
every person should be able to answer
how will this delight the customer?
why am I doing this?
give everyone a clear line of sight to the customer
orient everyone in the organization
team
in principle should coordinate & communicate
managers have a huge role in coordination
in practice not seeing big picture & interactions between teams
Microsoft
now they update once/twice a week
connection to customer
fast feedback
7 million users in user group that will test your new code in 1 day
used to take 3 - 4 years before updates
you will not get real feedback for the code you wrote for 3 - 4 years
statistically ~15% only are passionate
disengaged workforce
small increments
small team
there is more and more decision making power in the hands of developers
design, architecture, etc. choices depend on due diligence of research, etc.
create the environment where they can be trusted
align
forcing function
similar to art of doing the least work
reusability
what is the percentage of your code that is actually reused?
"walking through tar" (Amitai?)
""Never use words like 'Manager', 'Data' or 'Agent' in variable names"
organize, leave affordances to allow for flexibility & further optimization
functional purity (side effects make caching impossible, etc.)
decouple
if there were a program that did more reading (e.g. i/o) than writing, to optimize it we would focus on reading
in 1978, 32K program on 32 chips
independent via vtables (polymorphism - containing pointers to functions)
a monolith where a single change offsets the rest, and all chips have to be replaced
Undeployed Code
Undocumented Code
Untested Code
Unsynchronized Code
Uncoded Documentation
interferes with other work
unintegrated code
untested code
becomes obsolete before finished
solve yesterday's problem
whatever steps achieved become less valuable
Types of waste
Task Switching
Delays
Handoffs
Relearning
Extra Features
Partially Done Work
Dev(Sec)Ops
vulnerability is a form of a defect, falls on QA
security should be built in, not bolted on
what is the user interface
code
imagine using a complex website where instead of interface widgets we use code
developers are the end users of the code, and of each others' work
Amitai
website
developer
codebase
clean codebase can make a developer a lot more productive
website visitor
UI & UX of website
well thought out interface can make conversions faster
optimize for
reading more code
writing more code
Theory X?
"ugly code"
reduces productivity
internal (code) quality increases productivity
Engineer eXperience
User eXperience
cutting corners possible with external quality
being paid for outcomes, not volume of work
requires value based thinking
delivering watermelons
green on the outside red inside
programmers aren't paid for time at the keyboard
if yesterday's code is lost it takes about 40 minutes to type it up by memory
their work involves research, testing, prototyping, envisioning, and collaborating
imagine a manager being paid by the number of new policies/meetings/documents
insight problem
insights per hour
how fast can I think of an idea & add it to the code?
move problem
cornercutting foundational to solving the "move problem"
"move that coal over there"
talking about it in a removed, hypothetical manner
because they don't see it happening
what can be done to satisfy impatient clients and have high quality
chapters
continuously improve
measure current levels of expertise
make stronger chapters
different types of wireframing
training
reusable modules
modularization, encapsulation
TDD
clear NFRs
better communication with clients/devs
culture, mindset
microservices
automated testing
"clients will walk away if we don't offer something super early"
they will always sacrifice quality if it's not measured
partially done work
overpromising
similar to unsound investments
short term positive impact
leads to underperformance
what can go wrong when WIP is low?
Teams can only achieve what we allow them to achieve
Out of Crisis
Essential Deming
3 sides
Schedule
Cost
Scope
Waterfall
Putting projects before teams, missing the importance of stable long-lived teams
schedules
trade-offs
resources
Agile
always the same quality
more efficient through trust and continuity
flexible
scope
fixed
cost (resources)
time (schedule)
consistent cadence
iterations
doing the same work (same specs) with the same team should take the same amount of time
could it be that BDUF is the reflection of the lack of trust and consensus?
clients pay for value, not estimates, but estimates can secure bids
in order to organize we learned to overlook leaders' flaws
As humans we learned to overlook flaws of our ingroup in order to organize. Is this type of #bias preventing us from making good #estimates?
estimates consist of two parts - actual work, and organizational preparedness
we are bad at estimating dysfunction of our organization because we always spin, we have to
hard to test
specify what the system does, not what it doesn't do
essential complications
intrinsic cognitive load
accidental complications
extraneous cognitive load
usually padded
hard to estimate
actual work
germane cognitive load
ideal time
requirements are guesses to experiment on
Hypothesis Driven Development
When CS becomes bazaar haggling we lose precision of science
farmer's almanac vs weather radar
Planning fallacy
Optimism bias
stronger for negative events
the valence effect
Pollyanna principle
pleasing and agreeable information is remembered more precisely
overly optimistic bad for survival
reduced coding of undesirable information about the future
e.g. it won't happen to me
Hofstadter's law
It always takes longer than you expect, even when you account for this
Consensus forecast
use different methodologies to arrive at an estimate
Base rate fallacy
reference class forecasting
disregard of distributional information
everyone is special
highest source of error
remedy with "outside view"
use distributional information from previous similar ventures
caused by "inside view"
focus on specifics instead of similar ventures
tendency to
overestimate
certainty
benefits of the plan
safety, etc.
underestimate
costs
completion times
human judgement (e.g. estimates)
insufficient consideration of distributional information about outcomes
i.e. betting on a "nanochance"
overconfident
overly optimistic
from
Amos Tversky
Daniel Kahneman
if something is not clear, make that visible
by being as clear as possible
comparative deletions
e.g. more efficient
negative requirements
vagueness
problem centric user stories
vs action-centric
allow the team to solve problems
and let them keep the credit
increase focus on the what, not the how
risks
building the wrong thing
PO less in control
find solution together with team
careful to not make everything look like bugfixing
question
what does our backlog look like?
identifying problem
remove obstacles
what's hindering a benefit of something?
examples
buy a car vs get to work
lose weight vs fit into pants
makes acceptance criteria more clear
in 1 month we will start working with this technology
4 types of work
infrastructure
regression testing
unless we have automated tests
up to 30%
68%-70% in the requirements phase
>80% errors happen in the initial stages i.e. requirements & design
smaller batch size
fewer handoffs
Story Map is not binding
refinement, Sprint Planning
cycles faster because authority to make changes is pushed to the trenches
no separate scope or SOW document necessary
10 steps
cakewrecks.com
what is the MVP of getting ready for work/school in the morning?
the dude
Jira add-on
Trello Example
why?
requirements should be written from the perspective of the customer
implementing a solution or solving a problem?
requirements must not be prescriptive
there are many other ways to authenticate (e.g. SSO)
a login form by itself is not valuable
customers do not pay for login forms, they pay for secure access to their data
Examples of the same User Story
three
As a user, I want to log in, so that I can access my data.
focus on value
two
As a user, I want to enter my credentials, so I can log in.
focus on activity
one
As UserAPI, I want to receive the user's credentials, so that the user can be authenticated
focus on internal process
aberration from acceptance criteria
conditions of satisfaction not met
types of defects
in-house
escaped
caused by requirements
are bugfixes stories
defects are different from user stories
Another perspective: there is always uncertainty in User Stories
an overconfident manager might think that there is less uncertainty in User Stories because users know what they want
trivial or fully unknown
can't estimate alongside regular User Stories
distinguish from stories to track number of bugs?
they have story points
As Agile Coach I want to build and maintain a happy and healthy organization so that people can grow both personally and professionally
wouldn't work with "resource"
IDEO's Design Thinking
what about BDD scenarios
confirmation
brief
fits on back of index card
conditions for satisfaction
conversation
card
Agile-Lean clash
having assignments reduces collaboration between team members
how about tasking out in real time?
digging into the how
JIT
self-management
teammates may decide to switch tasks depending on
learning
experience
capacity
in Kanban there is no Sprint timebox
no need to convert to hours
impairs the pull next item approach
by tasking out in hours we create a mini-Gantt chart
Which User Stories to drop mid-sprint
the ones that have most hours on tasks
Sprint Planning
Once the who is determined, the how long becomes available
time constraints affect the SG
from complex to complicated/simple
creating
Tasks
known knowns and known unknowns
how long?
the who
the how
relative size estimation
the what
requirements exploration
scenarios
narrative
points
counting hours is like counting lines of code
splitting stories
plane parts made in cardboard to see if they can be transported easily along the turns on the factory floor
car prototype made in plastic to deliver optimal wind resistance
SPIDR
Team owns Sprint Backlog
it is there for the team, not the customer
a team should not have to look at multiple boards
WIP is per team, not customer/project
the board is meant to help manage the team's time and tasks, not to request features and report bugs
they use it to coordinate their work to reach Sprint Goal
valuable visual tool
anchor stories
turn upside down - normal distribution
probability distribution
bell curve
bucket with one big rock
backlog size = 3 x team's velocity
depending on the industry?
leadership hands objectives to the team
problems they are trying to solve
the team (with PO) decomposes the objectives into stories
65% of PBIs are never built or never used by customers
Jeff Sutherland
sequenced in time
milestones
timeline
wbs
testing
quality
risk loaded
WBS for agile projects
more than a prioritized list of requirements
DEEP Product Backlog
Prioritized
Emergent
Estimated
Detailed Appropriately
Task Independence
Central Limit Theorem
The sum of a number of independent samples from any distribution is approximately normally distributed
misunderstood examples
the actor in the User Story must be the user, not the service provider
jobs-to-be-done
Choice set
Catalysts
Constraints
Unmet Desires
nobody asks the question "does chess work?"
it's not a game of chess if you change the rules (or drop them)
we choose to try and become Agile because of the outcomes that it will bring
you will not have the experience and the outcomes of a game of chess if you change key characteristics
a basis of Systems Theory is that the whole is greater than sum of its parts
aligned and empowered teams
emergent qualities of a team
difficulty saying "no"
unempowered team
science of Agile
a matheme
tension between need and desire? and the request?
balance between risk and uncertainty
balance between predictability and creativity
lowest common denominator
see the Spotify drawing on alignment
marching soldiers vs improv troupe
manage scope to converge on the outcomes that we want
we vary the scope to maximize outcomes
fixing time and cost on these 2-week intervals
while constantly negotiating with the PO to maximize value
that will cause velocity to stabilize
2 ways
negotiate with PO (every 2 weeks or less) the Acceptance Criteria on each User Story
leave out things that are less vaulable
maximize amount of work not done
when we leave Sprint Planning the PO has a good idea of what they will get
PO prioritizes backlog
because the focus is on outcomes and not on utilization or individual work packages
all team members must know how their work contributes
predictability is not about following requirements
it's about achieving the desired outcomes through
using the requirements as guardrails
responding to change
negotiating the scope and requirements
we know that our planning horizon is
12 week Release
2 weeks Sprint
gives us cost
get a predictable throughput
the organization needs a reliable system
hope as strategy does not build trust
the team becomes untrustworthy
just say "no"
unrealistic hopes
do not overcommit
start telegraphing to the organization
where we will be and when
establish stable velocity
negotiating with PO
use Sprint Planning to tune
start being predictable
I am making Sprint commitments over time
INVEST model
I know the velocity of my team
I can start to stabilize the velocity over time
I know the size of my backlog
if you want the team to be predictable you need to create the context for them to flourish
soup from a stone
you can't drive stick like it was automatic
cross-functional team of T-shaped people
capable of delivering an increment every 2 weeks
iron triangle
orgs want all 3
the truth is somewhere in the middle
traditional PM gives you the illusion of certainty
on some level we know that it will always be wrong
but for a period of time we have
because someone made us a promise
shifted the weight of responsibility onto someone who says "yes"
abdicated responsibility
plausible peace of mind
sometimes Agile says that none are fixed
because people on delivery/product teams are not aligned, not participating it all dies right there
SAFe
PI timebox 8-12 weeks
Scrum of Scrums
Agile Release Train
teams power the train
train carries cargo -- new features
each train has a known velocity
each train delivers increment every 2 weeks
ART aligns teams to a common mission, and helps to manage risk and variability of solution development
Sprint Planning 1 and 2
first with representatives of all teams
strategy map
fractaling out through the organization
connect strategic objectives to customer objectives
start at the top, and make all departments have balanced scorecard downward
four dimensions
Collaborate, Deliver, Verify, Improve
similar to PDCA
podcast
by Tom Peters & Robert Waterman
The 3 Horizons
Innovation Sandbox
refine set of offers by understanding the problem space
use business models to identify solutions
test assumptions
identify plausible offers
Horizon 2
Opportunities discovered through experimentation for Horizon 3
ready business to make these Horizon 1 revenue generatorrs
Horizon 3
Portfolio must include offerings to meet future customer need
future business exploration
learn future needs through lean experiment cycle
Horizon 1
Optimization of current business through interaction (alignment) with customer
Iterative & Incremental Techniques (Agile)
Escape Velocity by Geoffrey Moore
Institute Change
Create sense of urgency
ebook
Review progress on mother strategies towards True North every quarter
quarterly steering
guide day-to-day work
Rocks
Bucket filling instructions
Fourth, put in water
Third, put in sand
Second, put in pebbles
First, put in rocks
from Mastering the Rockefeller Habits
Mother Strategies
Focus areas that will help us approach the True North
True North
guides decision making
Single Goal
Getting the Right Things Done by Pascal Dennis
achieving a good fit with the environment
closing gap with the desired state
local goals and gaps
authority goes to the information
aligned agents (teams/individuals)
identify local gaps based on their goals
Create a cadence of accountability
what can I do to make the biggest impact on the scoreboard
personal promise
and next week
team meetings where team members hold each other accountable
Keep a compelling scoreboard
designed for and by players
emotional engagement
Follow Lead Measures
leading indicators
Focus on what's important
Narrow your work to what you want to significantly improve
WIG (wildly important goal)
or a psychotic guy or an anorexic
it's like being a therapist
how do we get them in shape is what Agile Coach does
Mike Cottmeyer
5. Culture follows structure.
4. As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3).
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
how about
and that work is a lot more exciting & meaningful than rote bug fixing because it requires creativity, hones mastery, and connects us to the outcomes
look for previous successes and distinguish agile patterns
e.g. meetings that already happen
otherwise it could be seen as extra work
reaction to change depending on set of beliefs
immovables
movables
movers
Synergy/Antagonism
from Jason Little
when incrementing only the final product is not evolving
make safe mistakes quickly
cheap to fail, quick to learn
evolution is iterative because it learns from mistakes
Wright Brothers didn't 3D print the first flying plane
execution
current sprint
maturation
acceptance criteria
story mapping
~2 sprints ahead
ideation
prototypes
epics and features
4+ sprints ahead
—Don Reinertsen
Saying "Yes" to everything is not a strategy
Eric Willeke
When every person in company is working towards these goals, they can be trusted to not pick the wrong kind of work
Every activity must go through the test of alignment to our business goals
Some work may not be promoting our business goals
strategy formulation must be based on facts
continuous dialogue
stage gates
balanced scorecard
multiple POs
a feature might be only 70% - 80% completed
e.g. measuring call duration instead of quality of service in a call centre
Program Board in SAFe
program level vs team level
developers must understand the strategy
where the rubber hits the road
Employee advocacy
Talent management
Recruitment marketing
Payroll
ADKAR
Reinforcement
Ability
Knowledge
Desire
Awareness
Kotter 8 steps
Institute change
Sustain acceleration
Generate short term wins
Enable action by removing barriers
Enlist a volunteer army
Form a strategic vision and initiatives
Build a guiding coalition
Create a sense of urgency
outline what we are doing to
support each need/process
empirical process control
Adaptation
Transparency
psych safety
information radiators
Inspection
needs/motivators/values
Autonomy
delegation boards
say in the matter
consulted when decisions are made
career path
ownership
empowerment
find another word?
Mastery
visible progress
invite consultants
webinars
learning log
pay for courses & certifications
Purpose
how do we make the world a better place?
family
needs
future state
systems thinking
filling a lack
processes
"meet them where they are at"
emergent
complexity theory
incremental
show distance, let the driver make his own decisions
"This is how they park 500,000 pound airliners on a dime"
DIKW Pyramid
Knowledge Management Cognitive Pyramid from US Army
Biggest mistakes that product managers make
Rian van der Merwe
2 ways to get better
unlearn bad habits
learn new things
connect to a business outcome
capability to do something
promote safety by
acknowledging that continuous learning makes everyone a beginner
emphasize continuous learning and growth
recognize changing circumstances
legacy/old
a medal earned: no need to keep on trying
not quite fair because this could be said about Best Fit models as well (e.g. Agile Fluency)
aligned and stable to benefit from experimentation
additional dimension allows for 5 perspectives
e.g. owner/designer/builder
table
reification transformations
Instantiation
Functioning
Configuration
Detailed
Specification
Physical
Representation
Logical
Definition
Conceptual
Identification
Scope Model
Contextual
primitive interrogatives
Motivation (Why)
Time (When)
People (Who)
Network (Where)
Function (How)
Data (What)
diagram
e.g.
Mature teams do not need the same lifecycles as new teams
DA accounts for that
full video
Part 2
Part 1
There are Spotify detractors and not flexibility came at a cost to efficiency, but Spotify still outperformed Fitbit
Since Spotify, Spotify adopted SAFe?
Marty Kagan
do a full thin slice
similar to walking skeleton
from Pragmatic Programmer
more than mere Agile teams in IT
recreate startup attitudes in a mature organization
DevOps
not a person
pipeline
start with SAFe (waterfall compatible), evolve to LeSS
e.g. start w/Scrum, evolve to Lean
product management is a process of exploration, discovery, and growth
interview on Agile Uprising
mentioned on Agile Amped
5th focus
identify quick wins
KPIs
Changes Canvas/Board
Define Scope
Business Case for changes that we are going to be making
from CA
