Lean and Agile
Transformations
Deloitte's transformation
Peter Block
Transformation comes more from pursuing profound questions than seeking practical answers.
The answer to How is Yes
Agile Fluency Model
A Brief Guide to Success with Agile
Path to Agile Fluency -- Fit to Purspose
Agile Transformation Roadmap from CA
Transformation Planning Cards
Presentation slides
Transformation Paths
KPIs, Outcomes, Activities
from CA
Roadmap
Business Case for changes that we are going to be making
Define Scope
Changes Canvas/Board
KPIs
identify quick wins
5th focus
Transformation Dimensions
KPIs, Outcomes, Metrics
Frameworks
The Flow Framework
projecttoproduct.org
project vs product infographic
mentioned on Agile Amped
interview on Agile Uprising
in the product mindset the focus is on helping the team acquire skills and master the fields needed to build a better product in the longer term
product management is a process of exploration, discovery, and growth
Mik Kersten
book
Disciplined Agile
decision process framework
maturity model
e.g. start w/Scrum, evolve to Lean
start with SAFe (waterfall compatible), evolve to LeSS
LeSS
SAFe 4.5
SAFe Distilled has the same info, even though it's sometimes called 4.0
new in 4.5
DevOps
pipeline
not a person
recreate startup attitudes in a mature organization
Business agility
more than mere Agile teams in IT
GROWS Method
Tracer Bullet Development
from Pragmatic Programmer
similar to walking skeleton
do a full thin slice
Practices Map by Stage
FAST Agile
DSDM
XP
Spotify
Spotify vs Fitbit
Marty Kagan
Since Spotify, Spotify adopted SAFe?
There are Spotify detractors and not flexibility came at a cost to efficiency, but Spotify still outperformed Fitbit
Spotify engineering culture
Part 1
Part 2
Modern Agile
Agility Scales
Holacracy
Tactical
full video
Governance
RAGE
Recipes for Agile Governance in the Enterprise
startup@scale Transformation Framework
Agile frameworks
they spent a lot of time, money and energy trying to get this right; it's been field tested with tens of thousands of teams, and now it is offered to us for free
Their marketing strategy conceals the real picture, trying to reduce change to a repeatable process.
e.g.
Mature teams do not need the same lifecycles as new teams
DA accounts for that
Zachman Framework (reification)
enterprise architecture framework
a classification schema for an ontology of Enterprise Architecture
schema format
table
primitive interrogatives
reification transformations
Zachman Cube
additional dimension allows for 5 perspectives
e.g. owner/designer/builder
Maturity Models vs Capability Models
organizational alignment
factors
mixing up levels of the DIKW pyramid
Biggest mistakes that product managers make
2 ways to get better
learn new things
unlearn bad habits
Rian van der Merwe
DIKW Pyramid
Knowledge Management Cognitive Pyramid from US Army
everyone must understand what is business value for the work
Pass information not instructions
David Marquet
e.g. parking
show distance, let the driver make his own decisions
"This is how they park 500,000 pound airliners on a dime"
partner with HR
map processes and needs
processes
"meet them where they are at"
incremental
complexity theory
emergent
needs
future state
filling a lack
systems thinking
outline what we are doing to
support each need/process
needs/motivators/values
Purpose
family
how do we make the world a better place?
Mastery
pay for courses & certifications
learning log
webinars
invite consultants
visible progress
Autonomy
empowerment
find another word?
ownership
career path
say in the matter
consulted when decisions are made
delegation boards
empirical process control
Identify areas/dimensions along which to work
each change to be reinforced with
Kotter 8 steps
ADKAR
moving motivators address Autonomy, Mastery, & Purpose
along departments in org
Payroll
Recruitment marketing
Talent management
Employee advocacy
formulation of strategy towards execution of strategy
same as DevOps?
developers make strategy into reality
where the rubber hits the road
developers must understand the strategy
focus on delivering stories or delivering features
a feature might be only 70% - 80% completed
program level vs team level
Program Board in SAFe
e.g. measuring call duration instead of quality of service in a call centre
multiple POs
alignment is the result of successful execution of strategy
strategy formulation must be based on facts
stage gates
balanced scorecard
continuous dialogue
Saying "Yes" to everything is not a strategy
Some work may not be promoting our business goals
Every activity must go through the test of alignment to our business goals
When every person in company is working towards these goals, they can be trusted to not pick the wrong kind of work
Eric Willeke
Principle of Alignment: There is more value created with overall alignment than with local excellence.
—Don Reinertsen
~We don't go Agile just to go Agile. We do it to achieve a set of organizational goals, and execute a business strategy.
Eric Willeke
Agile Pipeline
3 horizons
ideation
4+ sprints ahead
epics and features
prototypes
maturation
~2 sprints ahead
story mapping
acceptance criteria
execution
current sprint
from PMI-ACP training
iterative vs incremental
Wright Brothers didn't 3D print the first flying plane
evolution is iterative because it learns from mistakes
make safe mistakes quickly
cheap to fail, quick to learn
when incrementing only the final product is not evolving
Change management
Change Graph
from Jason Little
Synergy/Antagonism
reaction to change depending on set of beliefs
movers
movables
immovables
use existing rituals to introduce new principles
otherwise it could be seen as extra work
e.g. meetings that already happen
look for previous successes and distinguish agile patterns
We aren't adding more work, we are creating an executive alignment as to what work we want to do
Eric Willeke
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
Larman's Laws of Organizational Behavior
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
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.
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.
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).
5. Culture follows structure.
organizations are like a fat guy on a couch that wants to run a marathon
how do we get them in shape is what Agile Coach does
Mike Cottmeyer
or a psychotic guy or an anorexic
it's like being a therapist
4 Disciplines of Execution
make sure your people are playing a game they can win
disciplines
Focus on what's important
WIG (wildly important goal)
Narrow your work to what you want to significantly improve
Follow Lead Measures
leading indicators
Keep a compelling scoreboard
emotional engagement
designed for and by players
Create a cadence of accountability
team meetings where team members hold each other accountable
what can I do to make the biggest impact on the scoreboard
and next week
personal promise
elevator pitch
approach
aligned agents (teams/individuals)
identify local gaps based on their goals
local goals and gaps
authority goes to the information
success
closing gap with the desired state
achieving a good fit with the environment
Instruments
True North & Mother Strategies
Getting the Right Things Done by Pascal Dennis
diagram
True North
Single Goal
guides decision making
Mother Strategies
Focus areas that will help us approach the True North
Rocks
from Mastering the Rockefeller Habits
Bucket filling instructions
First, put in rocks
Second, put in pebbles
Third, put in sand
Fourth, put in water
guide day-to-day work
Review progress on mother strategies towards True North every quarter
quarterly steering
Kotter's 8 Steps
ebook
Create sense of urgency
Build a guiding coalition
Form a strategic vision and initiatives
Enlist a volunteer army
Enable action by removing barriers
Generate short term wins
Sustain acceleration
Institute Change
McKinsey Three Horizons Model
Escape Velocity by Geoffrey Moore
Horizon 1
Iterative & Incremental Techniques (Agile)
Optimization of current business through interaction (alignment) with customer
Horizon 3
Portfolio must include offerings to meet future customer need
learn future needs through lean experiment cycle
future business exploration
Horizon 2
Opportunities discovered through experimentation for Horizon 3
ready business to make these Horizon 1 revenue generatorrs
Innovation Sandbox
identify plausible offers
test assumptions
refine set of offers by understanding the problem space
use business models to identify solutions
diagram
Turner & Crawford
ADKAR
McKinsey 7-S framework
by Tom Peters & Robert Waterman
podcast
diagram
Standish Group
Change Canvas
Alistair Cockburn
Collaborate, Deliver, Verify, Improve
similar to PDCA
financial metrics do not properly reflect the value of intangible assets
balanced scorecard
four dimensions
start at the top, and make all departments have balanced scorecard downward
strategy map
connect strategic objectives to customer objectives
fractaling out through the organization
ideas, patents, etc.
Milosevic & Srivannaboon
scrum
empirical process control + lean (measure + trust)
Scaling
coordinate multiple teams
LeSS
SAFe
executives can very well have a proper vision and a set of goals, but it breaks down when it comes to projects
Predictability
(Leading Agile)
ability to make commitments
iron triangle
orgs want all 3
sometimes Agile says that none are fixed
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
plausible peace of mind
abdicated responsibility
shifted the weight of responsibility onto someone who says "yes"
because someone made us a promise
prerequisite
cross-functional team of T-shaped people
capable of delivering an increment every 2 weeks
if you want the team to be predictable you need to create the context for them to flourish
you can't drive stick like it was automatic
soup from a stone
what to do?
start being predictable
establish stable velocity
get a predictable throughput
science of Agile
manage scope to converge on the outcomes that we want
we know that our planning horizon is
2 weeks Sprint
gives us cost
12 week Release
we vary the scope to maximize outcomes
predictability is not about following requirements
because the focus is on outcomes and not on utilization or individual work packages
2 ways
PO prioritizes backlog
negotiate with PO (every 2 weeks or less) the Acceptance Criteria on each User Story
fixing time and cost on these 2-week intervals
balance between predictability and creativity
balance between risk and uncertainty
a matheme
tension between need and desire? and the request?
what gets in the way
difficulty saying "no"
unempowered team
nobody asks the question "does chess work?"
it's not a game of chess if you change the rules (or drop them)
you will not have the experience and the outcomes of a game of chess if you change key characteristics
emergent qualities of a team
a basis of Systems Theory is that the whole is greater than sum of its parts
aligned and empowered teams
we choose to try and become Agile because of the outcomes that it will bring
requirements
User Stories
Job Stories
jobs-to-be-done
Unmet Desires
Constraints
Catalysts
Choice set
misunderstood examples
the actor in the User Story must be the user, not the service provider
Product Backlog
Task Independence
Central Limit Theorem
The sum of a number of independent samples from any distribution is approximately normally distributed
DEEP Product Backlog
Detailed Appropriately
Estimated
Emergent
Prioritized
more than a prioritized list of requirements
WBS for agile projects
risk loaded
quality
testing
sequenced in time
wbs
timeline
milestones
65% of PBIs are never built or never used by customers
Jeff Sutherland
leadership hands objectives to the team
the team (with PO) decomposes the objectives into stories
problems they are trying to solve
backlog size = 3 x team's velocity
depending on the industry?
Sprint Backlog
anchor stories
bucket with one big rock
turn upside down - normal distribution
bell curve
probability distribution
Team owns Sprint Backlog
they use it to coordinate their work to reach Sprint Goal
valuable visual tool
it is there for the team, not the customer
a team should not have to look at multiple boards
the board is meant to help manage the team's time and tasks, not to request features and report bugs
WIP is per team, not customer/project
Story Splitting Patterns
SPIDR
splitting stories
car prototype made in plastic to deliver optimal wind resistance
plane parts made in cardboard to see if they can be transported easily along the turns on the factory floor
hours vs story points
counting hours is like counting lines of code
Stories vs [sub]Tasks
User Stories
requirements exploration
points
narrative
acceptance criteria
scenarios
the what
relative size estimation
Tasks
the how
the who
how long?
known knowns and known unknowns
Sprint Planning
creating
the how
the who
from complex to complicated/simple
Once the who is determined, the how long becomes available
time constraints affect the SG
Which User Stories to drop mid-sprint
the ones that have most hours on tasks
Agile-Lean clash
by tasking out in hours we create a mini-Gantt chart
impairs the pull next item approach
in Kanban there is no Sprint timebox
no need to convert to hours
self-management
teammates may decide to switch tasks depending on
capacity
experience
learning
JIT
how about tasking out in real time?
digging into the how
having assignments reduces collaboration between team members
3Cs
card
conversation
confirmation
conditions for satisfaction
acceptance criteria
brief
fits on back of index card
Are Use Cases Anti-Agile?
what about BDD scenarios
Unarticulated Needs
IDEO's Design Thinking
stories are operating systems of our mind
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"
Defects
are bugfixes stories
they have story points
distinguish from stories to track number of bugs?
defects are different from user stories
trivial or fully unknown
can't estimate alongside regular 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
types of defects
caused by requirements
escaped
in-house
aberration from acceptance criteria
conditions of satisfaction not met
outcomes vs outputs
Examples of the same User Story
one
two
three
why?
User Story Mapping
User Story Mapping in Trello
Trello Example
Jira add-on
Cardboard
Mastering Business Analysis podcast episode 81 with David Hussman
the dude
Essentials of Agile User Story Mapping at Twitter
User journeys (scenarios of usage)
Jeff Patton walking through a story map
Story map example of getting ready in the morning (2 minutes)
what is the MVP of getting ready for work/school in the morning?
process of story mapping from Jeff Patton
cakewrecks.com
Wardley (Value Chain) Mapping
10 steps
Agile "create WBS" process
shared documents aren't shared understanding
materials
Carnegie-Melon study
>80% errors happen in the initial stages i.e. requirements & design
68%-70% in the requirements phase
21 top tips for writing an exceptionally clear requirements document
Release Planning
glue stories
up to 30%
e.g.
regression testing
unless we have automated tests
infrastructure
4 types of work
a 3 month technology lookahead
e.g.
in 1 month we will start working with this technology
Meta-Cast episode
guidelines
viewing stories as problems to be solved
makes acceptance criteria more clear
examples
lose weight vs fit into pants
buy a car vs get to work
identifying problem
what's hindering a benefit of something?
remove obstacles
question
what does our backlog look like?
risks
careful to not make everything look like bugfixing
PO less in control
find solution together with team
building the wrong thing
increase focus on the what, not the how
allow the team to solve problems
and let them keep the credit
problem centric user stories
vs action-centric
use Natural Language Processing
e.g.
vagueness
negative requirements
comparative deletions
e.g. more efficient
reduce risk
making requirements too detailed implies that the people who implement it lack understanding
iterative vs incremental
Wright Brothers didn't 3D print the first flying plane
evolution is iterative because it learns from mistakes
make safe mistakes quickly
cheap to fail, quick to learn
Estimates
estimation issues
reference class forecasting
from
human judgement (e.g. estimates)
overly optimistic
overconfident
insufficient consideration of distributional information about outcomes
i.e. betting on a "nanochance"
tendency to
underestimate
completion times
costs
risks
overestimate
benefits of the plan
safety, etc.
certainty
caused by "inside view"
focus on specifics instead of similar ventures
remedy with "outside view"
use distributional information from previous similar ventures
disregard of distributional information
highest source of error
everyone is special
Base rate fallacy
Consensus forecast
use different methodologies to arrive at an estimate
Hofstadter's law
It always takes longer than you expect, even when you account for this
Optimism bias
stronger for negative events
e.g. it won't happen to me
the valence effect
reduced coding of undesirable information about the future
Pollyanna principle
overly optimistic bad for survival
pleasing and agreeable information is remembered more precisely
Planning fallacy
an estimate is not a number, it's a distribution
estimation as hypothesis
farmer's almanac vs weather radar
Hypothesis Driven Development
When CS becomes bazaar haggling we lose precision of science
requirements are guesses to experiment on
3 parts
actual work
ideal time
germane cognitive load
accidental complications
hard to estimate
usually padded
extraneous cognitive load
essential complications
intrinsic cognitive load
caveats
negative requirements
hard to test
specify what the system does, not what it doesn't do
Natural Spin
clients pay for value, not estimates, but estimates can secure bids
in order to organize we learned to overlook leaders' flaws
we are bad at estimating dysfunction of our organization because we always spin, we have to
estimates consist of two parts - actual work, and organizational preparedness
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?
upfront design serves to achieve consensus between stakeholders
could it be that BDUF is the reflection of the lack of trust and consensus?
Productivity & Quality
The Iron Triangle
diagram
diagram
iron triangle (triple constraint)
doing the same work (same specs) with the same team should take the same amount of time
Agile
fixed
time (schedule)
iterations
consistent cadence
cost (resources)
flexible
scope
more efficient through trust and continuity
always the same quality
Waterfall
fixed
scope
flexible
resources
schedules
trade-offs
Putting projects before teams, missing the importance of stable long-lived teams
3 sides
Scope
Cost
Schedule
Sprint Duration
the part of the car that allows you to go fast the most is the brakes
Statistical Quality Management
Deming
Quality begins in the boardroom, Deming
Teams can only achieve what we allow them to achieve
quality vs quantity
High WIP
what can go wrong when WIP is low?
overpromising
leads to underperformance
short term positive impact
similar to unsound investments
partially done work
"false opposition" GeePaw Hill
discussion with devs on quality vs deadlines
2 types (perspectives?) of problems
move problem
insight problem
insights per hour
value and work
being paid for outcomes, not volume of work
imagine a manager being paid by the number of new policies/meetings/documents
programmers aren't paid for time at the keyboard
their work involves research, testing, prototyping, envisioning, and collaborating
if yesterday's code is lost it takes about 40 minutes to type it up by memory
requires value based thinking
delivering watermelons
external & internal quality
external
cutting corners possible with external quality
User eXperience
internal
Engineer eXperience
internal (code) quality increases productivity
"ugly code"
reduces productivity
optimize for
writing more code
Theory X?
reading more code
Agile
who is the user?
website visitor
UI & UX of website
developer
codebase
what is the user interface
website
code
imagine using a complex website where instead of interface widgets we use code
Amitai
developers are the end users of the code, and of each others' work
code quality
Externalized quality assurance is a pathology of non-agile practice, and can lead to unnecessary delay and waste.
Dev(Sec)Ops
The Seven Wastes of Software Development
Types of waste
Partially Done Work
Extra Features
Relearning
Handoffs
Delays
Task Switching
Defects
Partially Done Work
becomes obsolete before finished
interferes with other work
examples
monorepo advantages
Code Patterns
in 1978, 32K program on 32 chips
Code Craftsmanship
we read code much more than we write code (GeePaw)
if there were a program that did more reading (e.g. i/o) than writing, to optimize it we would focus on reading
organize, leave affordances to allow for flexibility & further optimization
""Never use words like 'Manager', 'Data' or 'Agent' in variable names"
bad quality code prevents Agile practices & blocks growth of Agile mindset
What is good code?
reusability
what is the percentage of your code that is actually reused?
best (only?) way to get quality is to go fast
similar to art of doing the least work
forcing function
developers make tons of microdecisions
align
create the environment where they can be trusted
there is more and more decision making power in the hands of developers
design, architecture, etc. choices depend on due diligence of research, etc.
unplanned work == anti-work
anti-patterns
Anti-Patterns Catalogue
Culture & Process
extract unifying commonalities
3 laws
team
small team
small increments
statistically ~15% only are passionate
disengaged workforce
Microsoft
used to take 3 - 4 years before updates
you will not get real feedback for the code you wrote for 3 - 4 years
now they update once/twice a week
7 million users in user group that will test your new code in 1 day
fast feedback
connection to customer
in principle should coordinate & communicate
in practice not seeing big picture & interactions between teams
managers have a huge role in coordination
customer
obsession with delivering value to customer
orient everyone in the organization
give everyone a clear line of sight to the customer
every person should be able to answer
why am I doing this?
how will this delight the customer?
instead of everyone looking at their boss, they look at the customer
delighting customer is the new boss
like the revolution in astronomy
the earth moves around the sun
can't have a little bit of either one
PO
voice of the customer
quick feedback loop
feeds the team engagement
autonomy, mastery and purpose
proxy for all customers
a customer focused organization
net promoters goal
how customers perceive they are being responded to
don't sacrifice customer for safety
network
friction/culture clash between the teams and the organization
team prioritizes customer
top management prioritizes bottom line
hierarchy of competence
hierarchies
need someone to strategize
shouldn't block communication
Steve Denning
J-curve model
turns into a staircase of Ls if we don't wait long enough for change to become adopted
race to the bottom
people get to the bottom of the J, and do another change
caterpillar becomes a cocoon before it turns into a butterfly
Antifragility
antifragile software manifesto
fragility
housing prices only go up
bitcoin only goes up
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
our website will never be hacked, so let's not even talk about it
we state in our rule book that discrimination is bad, so we did our part, there is no discrimination
monoculture
overprotective parents
the turkey problem
butcher feeds turkey
statistically each day the certainty that butcher loves feeding turkey grows
from turkey's standpoint the reversal of butcher's behaviour is a black swan event
not for the butcher
some perspectives have black swan cohfusions
are we a turkey?
hormesis
hormetic response
phenomenon when small exposure to a destructive agent brings benefits and strengthens the whole system
forest fires
light distraction
fail fast
fail early, fail often
there will always be bugs & design flaws
worse options
delay failure
workaround
fail silently
reduce risk
reduce uncertainty and variability
expose issues quickly and visibly
Agile culture
fewer bugs go into production
TDD, CI, etc.
safe to fail
don't
swallow exceptions
ignore missing environment variables or configuration
accept invalid requests
learn error & develop bad coding habits
agile development
vaccines are robust, but in the right direction
no failure, only feedback
weightlifting vs car
cat & dishwashing machine
how does it relate to criticality
pain
Scrum Repair Guide
points to areas that need improvement
Scrum exposes the gap between current state & desired state
trust blockers
a manager decides what needs to be done, and someone else will be held accountable for doing it
not as a peer to peer decision
Esther Derby?
you don't need a boss telling you what you are doing wrong all the time
you just learn to not be seen
from Jerry Weinberg
cultural shift
“How to build successful products by prioritizing team happiness above everything else” by Rian Van Der Merwe
ruthlessly deliver value in short increments
we are built to maximize success of what we are responsible for
from hero culture towards team culture
what are the forces that put in place and maintain hero culture
What's your process to change your process?
processes crystallize and become non agile
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
Commitment in Scrum
in regards to selected work, it's a forecast
distinction between commitment and its evil twin compliance
see Peter Senge
commitment == resolve
commitment to quality & continuous improvement
commit to be professionals
commit to fulfill SG
commit to the success of the team
dedication to doing our best
source of authority
built-in support
we have rights so that we can fulfill our responsibilities
Scrum 2020
3 commitments
Product Goal
Sprint Goal
Definition of Done
Responsibility Process
came out of
studies on personal responsibility in teamwork
ownership to each other on a team
research program in 1991
self-awareness
Emotional Intelligence
"first step"
being responsible vs taking responsibility
overcome angst, frustration, upset
accountability vs responsibility
when you blame the outside world, no progress can be made
adjusting the sails vs blaming the wind
process
space between stimulus and response
Victor Frankl
remember a time when you were completely in charge of your next steps forward
reproduce it
pick one: obedience or engagement
embrace accountability
hold people accountable out of love
help each other improve
behavioural accountability
leading indicator
long before quantitative results are seen
quantitative (performance) accountability
nothing can stop this team from moving towards excellence
in delivering the best product and the best value for the customer
Otto Sharmer
Organized irresponsibility
4 Stages of Psychological Safety
Contributor Safety
Airplane pilots in WW2 were allowed to choose whom they fly with because they died so often
Immunity to Change
when diagnosed with life threatening heart disease 100% agree to change their lifestyle (which would cure them), only 13% do (1 in 7)
immune system rejects transplants
people don't like change, they need change
ITC map
based on Lisa Lahey and Robert Kegan
DDOs end up acting according to the Agile Manifesto principles
retros & standups
push down authority
transparency
safety
Blue Angels debrief after every performance with the "boss pilot" stating
what went well
what went wrong
how he contributed to the problems
sorties in Afghanistan
improved after instituting a daily meeting with squadron commander stating (among other things) what mistakes he made
TDD
We tend to ask wrong questions. They are too general, and it is wrong to expect simple and direct answers. Instead, armed with patience and purpose, we can ask more specific and simple questions that can be empirically verified (although empiricism is sometimes a fad), and use the verified responses to plot a course that stakeholders can have more confidence in.
blameless
Incident at Delta Airlines
Developer who managed to delete prod DB on the first day, and got fired for it
No more single wringable neck
"you can't adequately design anything without in-code experimentation and implementation"
see Just Culture by Sidney Dekker
the problems are almost never in technical knowledge or in ability to do strategic planning
people are trustworthy and have good judgement
no one gets to say "it won't work here" - Jez Humble
culture
leadership
strategy
architecture
Agile Manifesto
Principle 1
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
for CS
dissect
Our
we are a cross-functional team
highest priority
understand the principal way we bring value
satisfy
definition of done
acceptance tests
the customer
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?
the user of the product
early delivery
quick feedback
continuous delivery
maintain relationship
get constant feedback
swarm
better to deliver frequently than in batches
e.g. one today and one tomorrow or two tomorrow
WIP limit
Little's Law
valuable software
value defined by customer (or PO) who prioritizes work by value
Deliver early and often to satisfy the customer
Principle 2
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
dissect
Welcome
openness and calm
it's not "accept" or "acknowledge"
changing requirements
accept change in every aspect of work
reality changes
Red Queen
flux
even late in development
last responsible moment
incremental vertical slices prioritized by value
Agile processes harness change for the customer's competitive advantage
who is the customer?
PO is voice of customer
user of product
understanding of what is valuable is required
constant connection and understanding of the customer
awareness of the business value of work items
value drives everything, not schedule
excessive focus on schedule ignores human factors
traditional change management == change prevention
agile change management
requirements change like the Product Backlog changes
Backlogs are always changing
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
gives rise to contractual issues
trust
need constant feedback
any impediment in the way of getting the feedback will be detrimental
Welcome changing requirements
Principle 3
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for shorter scale
small OODA loop
concrete feedback
dissect
Deliver
have something finished
commitment and courage
working software
quality
tangible value, not paperwork
confirm that there is a problem that is solved
frequently
feedback
course corrections
from a couple of weeks to a couple of months
small batches
from Lean
short iterations
manageable
easy to pivot
easy to plan
with a preference for shorter scale
path for improvement
Deliver working software frequently
Principle 4
Business people and developers must work together daily throughout the duration of the project
dissect
Business people
PO
Product-centric, not implementation centric
customer-on-site
Developers
whoever creates the solution
includes designers, BAs, testers, etc.
Must work together
no silos
Daily
PO must be available every day
awareness of and connection to business value to the company
requirements will be wrong and assumptions will become invalidated
we have to be able to get answers from the business (product) people
teams are expensive
2 minute rule for questions
the situation changes
we learn more
look where you are going
e.g. riding a bicycle around the block to get ice cream
Business people and developers must work together
Principle 5
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Trust motivated individuals to do their jobs
Principle 6
The most efficient and effective way of conveying information to and within a development team is face-to-face conversation
dissect
The most efficient and effective method of conveying information
bring authority of decision-making to information
active role in creating and directing information
ownership and responsibility to communicate well
to and within a development team
effective communication with stakeholders
understanding and alignment with business
frequent and efficient validation
is face-to-face conversation
full bandwidth
details about future direction
93% non-verbal
whiteboard
Face-to-face conversation is the most efficient and effective method of conveying information
Principle 7
Working software is the primary measure of progress
dissect
Working software
the only thing that really counts is that problems are resolved for customers
solved problems
delivered functionality
plans and promises don't count
DoD
Acceptance tests
Iteration Review
is the primary measure of progress
don't matter
effort
hours
number of tickets
output
acting busy
matter
Done work
outcome
Principle 8
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain constant pace indefinitely.
dissect
Agile processes promote sustainable development
burnout
overtime
respect for people
social responsibility for teams
understanding needs of stakeholders
The sponsors, developers, and users
systemic view
optimizing the whole
cross-functional
harmony
should be able to maintain a constant pace
flow
variability
consider accumulation of tech debt
explore vs exploit
allocate time for
learning
rest
indefinitely
regardless of a "phase"
ther are no phases
game theory
finite vs infinite games
we want to stay in business indefinitely
Maintain a sustainable pace
Principle 9
Continuous attention to technical excellence and good design enhances agility
dissect
Continuous attention
state of flow
ideal time
flow of work
quality
always learning
safe to be a novice
technical excellence
sharpen the saw
always learning
technology is changing
good design
product management
enhance agility
necessary to react to change
quality & speed
high quality allows to go faster
Principle 10
Simplicity--the art of maximizing the amount of work not done--is essential
dissect
Simplicity
no obfuscation
clarity
easily communicated
understood by all
the art of maximizing the amount of work not done
what is unnecessary?
finish sooner and get the feedback faster
then iterate
pathological
gold plating
looking busy
output vs outcome
is essential
essence of what creates value
prioritize
focus on goals
maximize the stakeholders' return on investment
there will always be more ideas/features/requirements than time/money to build it
therefore: maximize the amount of work not done
requires seeing the big picture
This is Lean
how did they build fully outfitted, seaworthy merchant ships in 2 days?
Principle 11
The best architectures, requirements, and designs emerge from self-organizing teams
Principle 12
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
Reflect and adjust at regular intervals
Agile Manifesto Value 1
Individuals and interactions over processes and tools
teams vs groups
independence vs interdependence
what's important is that people work together well, what tools they use is secondary
"fool with a tool is still a fool"
difficult to accept for people who treat individuals as resources
Agile Manifesto Value 2
Working software over comprehensive documentation
customers aren't paying for documentation
no value in delivering documentation alone
some forms of documentation are meant to reduce risk
approvals & change requests reduce agility
the amount of delays introduced by the stage-gate (approvals, etc.) and other types of documentation is staggering
based on the third-party contractor model where there is minimal trust
finite game
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)
Documentation still important but as part of the outcome, not the output
Agile Manifesto Value 3
Customer collaboration over contract negotiation
Agile Manifesto Value 4
Responding to change over following a plan
Agile is a value system that, when applied, results in reduced risk
self-organization needs structure
command & control vs autonomy & alignment
moving to self-organization requires self-organization
Mike Cohn
Agile is a collaborative approach to work
Feedback
backleading
annual performance evaluations
assessments missing the context
Lewin's equation
performance is function of environment
shift focus from evaluating to helping to get better, to succeed
if it is important, we should not wait one whole year to provide feedback
it's just feedback, don't call it assessment or evaluation
if a person's salary/raise/promotion, etc. is on the line
they will focus on getting laudatory feedback
their focus is not on getting better
continuous peer reviews with context (OKRs?)
John Doerr's book has great resources
for OKRs
various types of performance discussions
similar to paper Richard wrote
CFRs
Conversations, Feedback, and Recognition
Continuous Performance Management
use CFRs to process OKRs
consider OSKRs
get feedback on my feedback
types of feedback
reactive
directive
critique
why not
why
objective
ask powerful questions
yes and
what are the drama triangles on this team?
DevOps
The 3 ways
Flow
understand flow
work only flows downstream
value stream
increase flow
never pass defects downstream
never allow local optimization to cause global degradation
Feedback
understand customers' needs (internal and external)
quality at the source
improving daily work is more important than doing daily work
feedback loop
create an upstream feedback loop
shorten feedback loop
amplify feedback loop
right feedback at the right time
feedback will optimize the value stream
Continuous Learning
The Rugged Manifesto
in reference to the term rugged landscape?
emphasis on security
Rugged DevOps
7 habits of Rugged DevOps
CALMR
SRE
Problem Management
invoked when
focus on preventing incidents from happening
resources
People First
Cockburn article
First order non-linear component of software development
Respect for people in Lean/Kanban
people first
people and interactions over processes and tools
intrinsic motivation and happy and healthy teams
never blaming the people for their troubles
acknowledge pain and work to fix it because we are empowered via our commitment to success
blameless
On blaming individuals for the shortcomings of systems
customers will never love a company until the employees love it first
Sinek
seeing developers as "labour" promotes the Theory X prespective
maximizing capacity utilization
benefits of pairing become hidden
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"
badly formed User Story
the "who" shouldn't be the same person who is doing the work
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
Agile Manifesto
The fourth principle
Providing motivated individuals with the environment and support they need and trusting them to get the job done
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
Accounting for Slavery
How Slavery Inspired Modern Business Management
"task master" commonly used in connection to slavery
the degree of commitment that is required for a striving business requires more than just "resources"
commitment vs compliance
you can't get commitment from a machine
that's why tayloristic orgs don't like commitment
resources are similar to machinery: must be utilized
individuals organize to make things happen
machines are utilized to do labour
efficiency
capacity utilization vs impact maximization
output vs outcome
saying to a surgeon: "Why are you not cutting? I am not payingyou to stand there."
on measuring utilization
surgery nurses, FedEx, firemen
this will reduce performance
focus should be on results not on utilization
offer other metrics
books
The Agile Mind-Set (page 29, 86, 185)
Actionable Agile Metrics for Predictability
power over
"power over" is the only possible relation when people are seen as resources
supervisor --> labourers
other types of relationships
power for
coordinator --> agents
power with
steward --> professionals
power among
catalyst --> co-leaders
is the company for the peoaple, or are the people for the company
which one is an end and a means?
sovereign
when people are thought of as inanimate resources it is
more difficult to expect them to be proactive
you are the active component with agency
everyone is passive
you are the only problem solver
reporting hours considered harmful
promotes selfishness
erodes connections between teammates
all the information that is necessary is available w/out forcing devs to do this
prevents collaboration
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
timesheets vs burn rate
in complex situations there are often unknowable things, but with our bias for certainty we tend to listen to people who promise clarity and certainty, we turn a blind eye
hiring
hiring managers want
employees want
two types of mice
are
finds the cheese
learns rules
busts out
discovers new rules
progression through shu-ha-ri?
HR moving from being a policeman to a cruise director
Agile methodologies focus on the right values, and on leading
still instrumental in setting the culture
design the reward structure that works
onboarding by HR is an antipattern
long-lived teams
comes from when "resources" were frequently switched between teams for diff projects
when HR tracked career development
self-organizing
ownership and accountability
is having onboarding done by HR helping teams to self-manage or is it subtracting from it?
they are intracting with the people that can help--their teammates
e.g.
firefighters
soldiers using electrical tape for additional magazines
HR can't teach how to be on the team, only point to standards
knowledge of the subject matter is needed
if a team member has a question about configuring environment
performance management
96% of HR managers gave their own performance evaluation system C, D, or F
no longer done by HR
career development and goal-setting
onboarding
confusion about responsibilities
onboarding by silo/chapter is an antipattern
life is too short to build stuff that is not appreciated
all the heart and soul, blood, sweat and tears poured into it must be worth it
Covey's First Principles (7 habits)
Proactive
Begin with the end in mind
Put first things first
Think win-win
Seek first to understand, then to be understood
Sharpen the saw
Organizational Learning
Uncertainty Reduction Theory
passive
e.g. check it out on the internet
do not interact with change
watch from afar
active
talk to other companies
copy & tweak
Interactive
retrospective
talk & collaborate with change
knowledge destroyed by not sharing
unlearning
empty cup in order to fill it
bimodal IT
Gartner
not a hybrid
maintain legacy that is profitable while planning to adapt
acknowledge need to inovate
efficiency
secondary, it comes from effectiveness
dangers of best practices
knowing the "why"
tactical component that doesn't see themselves as a strategic piece in a bigger picture
or one that is not seen as such by management
orients individual players
allows to delegate responsibility to experts
faster decisions
better & more insights
lean
value based thinking
Golden Circle Model
Start with Why by Simon Sinek
People don't buy WHAT you do, they buy WHY you do it
Experiments are great in times of uncertainty, but other times tasks or high risk interventions might make more sense
can a single developer do an experiment on a slice of live customers in production?
if the developer has to jump through too many hoops, and get it okayed by the PO
they might decide not to try
we must make it safe to do such experiments
the hoops
make it into a story, put it in backlog, have PO prioritize it
is this the same as spiking?
from Modern Agile podcast (?)
culture is a verb
Aligned Autonomy
Industrial management
best fit for ordered systems
less useful for complex interactions
the "right thing" keeps on changing
instead of management telling people where to go, people with the information tell management where they see the system emerging
Time Out
behaviour is contextual
exhaustive regularization is not possible
exercise
propose a situation
generalize from a recent experience
ask "What would you do in this case?"
each team member writes a few words
relation to strategic storyline
discuss what is desirable
obstacles
what can we do?
common
understanding of context
values
sense of priority
interpretation
focus
the person telling you what to do
the process of how to do it
the mission itself
common goal
move towards excellence
mastery, autonomy, purpose
fulfilled
proud of their work
happy at work
can we still improve, or are we already perfect?
when QA is behind
the whole team must help deliver the outcome for the Sprint Goal
use Flow Efficiency and Flow Metrics
not Resource Efficiency
only fully Done work items bring value
Product Goal
insufficient collaboration
everybody's job is Product Development
patient in surgery metaphor
generalizing specialists
we are united by the same goal: to deliver
be in flow together
be effective together
common language
consists of
taxonomy
terminology
word clouds
if you give people freedom they will surprise, delight, and amaze you
the problems are almost never in technical knowledge or in ability to do strategic planning
the problems are in organizational health
the key is not access to knowledge and resources
it's health of the environment
consider two children (bet on the future of one of two kids)
raised in a solid, loving home
product of apathy and dysfunction
speed of trust
eBay
orgs become smart if they are healthy
unhealthy org will
get stuck
make worse quality decisions
not recognize opportunities
know what's important and have a permission to do it
habits
culture is habits
prevent sliding back
stop reacting and start doing (creating?)
invalidate assumptions
fail fast
XP practices foster product thinking
leads to innovation
flexibility to implement innovation
product success/happy customer
one of the key things that we do is exercise good judgement while applying professional standards
Does this expand your intellectual horizon?
Karl Popper-ish
blame
blame vs accountability
blame cycle
blame addiction
from blame to power
developers make tons of microdecisions
status-chaser antipattern
institutionalize w/out bureaucratizing
self-induced multitasking
values
Commitment in Scrum
Courage in Scrum
examples
Transparent about progress under pressure
Not to show undone work
Admit when we don't know something
Hold others accountable to meet commitments to the team
Admit our assumptions were wrong, and change direction
Go into the unknown, and build something new
embrace uncertainty
Engage in a productive disagreement (conflict)
Admit our mistakes
built-in support
assumption that it's okay to change direction
inspect-adapt
Sprint reviews & retros limit damage, allow small experiments
timebox
permission to say no
PO
allowed to say no to low value features
accountable for value
Dev Team
say no to cutting quality
accountable for quality
courage as a value of XP
Focus in Scrum
Respect in Scrum
built-in support
entire team attends meetings
respect for all roles
cross-functional
respect for all roles
Sprint Backlog is owned by Team
respect for Team's knowledge and skills to decide their own work
review Done items only
respect for stakeholders
people are resourceful
backgrounds and skills
people are motivated
doing their best
assume they have good intentions
respect all opinions
respect other teams
deliver quality code
Openness in Scrum
Transparency + courage
pillar of empirical process control
ask for help
offer help
share perspectives
feel heard
make decisions as a team
admit when change is needed
embrace change
do not remove connection to the goal when passing messages
pass full understanding: transparency
built-in support
limited sprint
openness to changing direction
SG is fixed, but plan how to meet it is different
Transparent Product Backlog
openness with stakeholders
retrospectives
openness to feedback
sprint review
sharing progress with stakeholders
the lens through which we look when making decisions
why do we exist?
all organizations exist to make life better for someone
at the heart of our core purpose is something grand and aspirational
not rote and technical
safety
SCARF model
organizing principle of the brain
carrot and stick approach doesn't work because it's extrinsic
the acronym
slide
saying "yes" to everything, and then telling everyone that we are "working on it" is not the best strategy to gain credibility
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
orgs become smart if they are healthy
conflict
during argument
I'd like to switch to your side and argue for your perspective for a moment
this will
let me experience the situation from your perspective
give me a more complete picture
Rapoport's Rules
qualities
active
nourishing
nurturing
we can only realize the promise of Agile if
we transform
culture
who we are
technical practices
how we work
e.g. TDD
the organization
how teams are formed
how decisions are made
governance
how mistakes are treated
how continuous improvement is implemented
how and what is measured
more than technical practices and culture
we need people to be
participative
immersed
engaged
on board
it's hard and a map is always helpful
Methodologies don't work in complex systems
Scrum is a value system
empowerment
delegating authority
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
seeing oneself as a victim of a culture rather than creator of the culture
Ehime Maru and USS Greenville collision
Captain
took over periscope
skipped procedure steps
because schedule
didn't see Ehime Maru 2km away
Team
"had too much respect for the captain" to point out that he is not following rules
emergency ballast blow exercise
when there are no opportunities to apply their passions at workplace, people volunteer outside of work
2-step facet of Agile
e.g. Scrum will expose dysfunctions
people must be there and ready to continually remove obstacles
can't rely on an external force
like management removing obstacles for "resources"
respect for individuals
help them mature
System of Delivery and System of Transformation
transformation
removing impediments
incremental
stages
can't run marathon
delivery
ritual & habit
like oral hygiene
future state
stable, cross-functional teams
predictability - stable velocity
ownership of technology stack
testing, CI
1 backlog
DDOs
2 jobs, second one to hide vulnerability
promotes narcissism
narcissistic wound
viewing people as resources also fitting for narcissism
when you hit a limitation, assume that Management is unintentionally holding you back
full permission to push back against the barriers that are holding them back
DDOs end up acting according to the Agile Manifesto principles
retros & standups
push down authority
transparency
safety
Blue Angels debrief after every performance with the "boss pilot" stating
what went well
what went wrong
how he contributed to the problems
sorties in Afghanistan
improved after instituting a daily meeting with squadron commander stating (among other things) what mistakes he made
learning
Problem-based learning
PBL
guidance-fading effect
use scaffolding
Instructional Scaffolding
adult learning theory
does the company promote learning?
make people awesome
Bloom's taxonomy
cognitive domain
Remembering
Comprehending
Applying
Analyzing
Synthesizing
Evaluating
Bloom's Rose
working back from Creating to Understanding
e.g.
draw a prototype, see where it doesn't fit
TDD
seed in MapReduce cycle
is red-green cycle similar to MapReduce?
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
learning organization
admit that we can use more learning, that we don't know everything
be ready to learn that we were going in the wrong direction
embrace change
learning champions
skill transfer vs KT
giving information is insufficient
Roadmaps
Gazelles.com growth tools
mastering rockefeller habits
Scaling Up
by Verne Harnish
similar to lean
priorities
data
rhythm
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
scaling
identify processes (5-10)
who will be responsible (monitor and alert the rest, not a dictator)
decompose visions into tactical missions
create mission tests
measure how well we're achieving these missions
during retros
8 steps
Vision - big picture
strategic themes
Identify initiatives
contribute to strategic themes
Granulate into epics
populate backlog
Estimate
Smart releases
Generate roadmap
may use Portfolio for Jira
Validate with team
Keep improving
Use OKRS/OSKRS instead
Business Agility
predictive hubris
illusion of
clarity
stability
control
know future
book Team of Teams by
changed strategy in fighting Al-Qaida
Gen. Stanley McChrystal
Integrated Business Architecture
SOA & BPM (business process management) to align IT with business
BPEL - Business Process Execution Language
Layered architecture
balance allocating resources
Exploration
activities
long term
Exploitation
refine existing processes
efficiency
production
execution
short term
Manage Flow
push authority to where the information is
optimize flow not resources
productivity is a team metric
project vs product
project approach ignores tech debt because
ask upfront for everything that will be needed for the project
upfront contingencies for risks
people are fungible resources
solve half of the problems rather than creating half-solved problems
focus on completion
is a hospital more interested
in quick recovery for the patients
in healing patients fast
in keeping the staff 100% utilized
filling all the beds
EBM
which hospital would you trust more as a patient?
need clear goal
in the Agile Manifesto, we have people who agreed on best practices, and extracted very general principles from it
not following Agile Manifesto principles is risky, but best practices may not be best for everyone equally
help organization sense and adapt
a better adaptive organism
Alistair Cockburn
Collaborate, Deliver, Verify, Improve
similar to PDCA
Heart of Agile
a fractal
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
delivering a little bit and getting feedback
giving the customer access to the senses they may have not had before
measuring something real: how they interact with us and with the product instead of something fake: what they say they want
process
Why
Design Thinking
What
Agile
How
Lean
encapsulate all three in the growth mindset
balance Project to Product and Kotter's Accelerate
hierarchies may be necessary
2 operating systems
innovate and grow and maintain and support
explore and exploit?
Dean Leffingwell
nod to RUP
deficiency gratification
psychological needs similar to physiological needs
unfulfilled needs of individuals result in reduced org health and performance
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
we are deficiency motivated
we will seek environment that will gratify that deficiency
Why Small Batches?
when we make commitments/predictions, we place a bet that we can honour the commitments
therefore we should endeavour to prove as quickly as possible, to strengthen our conviction...
cf Dijkstra's requirement for provability of code
if there is a way to prove that our bet was solid and that it will pay off, we should do it
Mission Statement & Value Statement
important because they serve to align everyone in a company
example of Nike?
achieve the decentralized decision making nirvana
where people are helping you achieve outcomes instead of following instructions
laying bricks vs building a cathedral
pass information, not instructions
contribute to the "pull"
software is a way to change your customers' behaviour
Your Org is a Product
everything else is side effects of putting professionals together?
business architecture
release manager is an anti-pattern
cross-funcitonal teams
ignoring benefits of cross-functionality
sales/marketing/IT
all functional
they know how to deliver on their functionality, but they miss on
overall value
dependencies & comms with other parts of organization
contrast to
an orchestra with only trumpets
a baseball team only with catchers
a medical team that's nothing but radiologists
higher chance of success
defined by scope
ask each person
set direction
what parts of the future system do we need to change often, and which ones will stay the same for a long time?
agile started off in manufacturing, then found a home in IT, but it is not about software
it is about solving complex problems
Steve Denning(?)
instead of scaling Agile, de-scale large problems
Steve Denning
similar to Jeff Patton's metaphor to eat lots of trout instead of one elephant
business leadership strategies
Agility is a business strategy, not a methodology or a process
although there are processes that can help
it is more important to be able to measure and validate a solution than to come up with one
agility on every level of company
Buffer
GitHub
TreeHouse
agile institutions
e.g.
hospitals
cities
governments
start with user needs, not the institution needs
build hospitals to make patients comfortable, not to make doctors' time more efficiently utilized
MVP Everything
smallest product increment that can accelerate the learning necessary to develop a sustainable business model
take the best guess, and then iterate
value the learning, the product itself is less important because it will certainly change
MVC
smallest possible change that maximizes learning and buy-in necessary to executing a viable change program and its change tactics
a change experiment
validate untested assumptions
Via Negativa
from
Nassim Taleb
Daryl Kulak
used in Catholicism to define what God is not
neti-neti
Sanskrit for negating everything that is not Brahman
does it make the boat go faster?
fix by subtracting rather than adding
adding new processes has its own overhead
usually less dangerous
e.g.
rules
paperwork
smoking
OODA Loop
Col John Boyd
Energy-Maneuverability theory
F86 vs MiG-15
1:6 kill ratio
not heavy artillery, but rapid response to change
the advantage is in having a faster loop than another system
market
organization
adversary
the loop
Observe
Orient
Decide
Act
similarity with Satir Interaction Model
Intake
Meaning
Significance
Response
management as a service
evolutionary/servant leadership
help individuals grow personally and professionally
autobahn
make sure surface is smooth
ensure safety
guardrails, etc.
get out of the way
2-step facet of Agile
e.g. Scrum will expose dysfunctions
social responsibility
to promote fairness, safety, self-actualization
apply principles of programming (e.g. single responsibility) in other areas
we use fail-fast all the time in programming when we specify parameter or return types
forcing function
red-green & TDD
Teams
Team Dynamics
paint drip, t-shaped
from Kent Beck
on heroes
case against heroes
from hero culture towards team culture
what are the forces that put in place and maintain hero culture
dynamic reteaming - avoid stagnation
Tuckman Team Development Stages Model
Forming
Storming
Norming
Performing
Forming, Storming, Norming, Performing Four-Stage Model
Never verified, only invented to illustrate an idea
team cadence
multiple teams cadence
Crocker's Rules
quote
benefits
focus on problem not person
foster trust
courage
respect
treat people like they are responsible and capable of handling their interpretations
MRI
caveats
1. Accept full responsibility for the operation of one's own mind
2. If I become offended it's my own fault
Slack message
Brooks' law
Core Protocols
Check In
steps
I feel [one or more of MAD, SAD, GLAD, AFRAID]
I'm in
Team says "Welcome"
Commitments
Decider
caveats
withdraws proposal
absolute "no"
proportion of "no" and "support-it" too high
use Resolution Protocol to bring outliers in (the "nos")
What will it take to get you in?
must bring in all outliers to a "yes" or "support-it"
vote
Pass
Check Out
similar to escape valve from Brene Brown?
Core Protocols Intro
Jim & Michelle McCarthy
Richard Kasperowski
started
HPT @ MS
created Visual C++
blew Borland out of the water
project to reproduce high performance
observed 100s of teams for many years
stack of observed behaviours
Positive Bias
unconditional positive regard
Carl Rogers
assume everyone is doing a good job
Most Respectful Interpretation (MRI)
Appreciative Inquiry (AI)
Assume Positive Intent (API)
Freedom/Autonomy
Self-Awareness
Connections
Productivity
Any sort of methodology
research
ritual vs rules
lorry drivers in NZ
thinking as drivers
most accidents in the offloading dock
giving them heated belts that take 10-15 minutes
ritual reduced accidents by 75%
Rituals create community
many companies do personality tests like DISC, MBTI, Predictive Index, etc. to account for chemistry when building teams
self-sorting does this automatically
move authority to information
managers assigning people to teams like work to people
Jazz "small group"
~6 people
each musician mostly listens to others
remote coworking
helps to keep pace
know when to stop, don't overload yourself
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)
maintain team presence
know when someone is called away for an urgent task
O3s
feeling fulfiled every day
1 thing that I do that you'd like me to continue to do
1 thing that I don't do frequently enough that you'd like me to do more often
1 thing I can do to make you more effective
specific goals for the next week
what can we do to increase your quality of life?
is there a better way to do what you are doing?
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
Team Alignment Map (TAM)
forward pass and backward pass
create items in the first two columns from the items in the last two
columns
Joint Objectives
Joint Commitments
Joint Resources
Joint Risks
dissent is at the heart of why we work in teams in the first place
Working together, itself, takes work
Team does not need a Project Manager if it has Project Management knowledge
PM Knowledge Areas
leadership & management
leader/follower spectrum
instruct
supervisor/manager
commands labourers
delegate
manager
coordinator
delegates agents
empower
steward
empowers professionals
co-lead
catalyst
inspires co-leaders
leader finds out that a problem was discovered & solved
structure
diagram
similarity to
Shu Ha Ri
Teal Organizations
Cynefin
Alan Dayley
How You Lead Is What You Get: Empowerment is not enough
podcast
if playground bullies were put in charge
people in management think they have to be bullies
modelled after drill sergeants
leadership
treat team members like entrepreneurs
treat teams as startups
foster leadership
you think leadership is about telling people what to do?
sustainbale pace is humane
burns people out - apathy and resentment
Personal Development
work is the best place to practice and improve
better results
in a sports (hockey/soccer/basketball, etc.) team
coach's responsibility is
make sure the team knows the rules
continues to follow the rules
understands what "winning" is
understand context
do not worry about how the team is playing the game
worry about whether the team knows how to win
worry about removing impediments
help team solve problems instead of telling them what to do in the short term
same principles
fail fast
why?
make yourself dispensable
CI
strategic vs tactical
delegate responsibility
e.g.
easy to become hubristic when a person is looking to you for answers
be a facilitator, people are too complicated
Sprint Goal
a commitment/forecast
authority comes from commitment and resolve
us vs them makes people game the system
Sprint Goal, seen as commitment, implies zero-sum game with stakeholders. When it's a forecast, we work together to extract the most #value.
the goal could be to (in)validate assumptions
Scrum Master does not touch the board
what matters is what happens when you are not there
you want me when you don't need me, you need me when you don't want me
help them to be awesome
ideally not needed at standups
self-organizing teams
take responsibility for their own delivery
team itself is a product
Scrum Master is PO of the team?
Leadership Styles
Visionary/Authoritative
Coaching
Affiliative
Democratic
Pacesetting
Coercive/Commanding
on "meeting people where they are at"
we failed the executives
by letting them keep their thought orthodoxy
values need to change
coaching challenge
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
some people's habits
self-organization
information was useful
the culture allows such behaviours
Facilitation and Coaching
debating format
first ask clarifying questions
timebox
time to process -- mental break
sleep on it
voting
converge
Kantor Structural Dynamics
Retrospectives
Sample Retrospective
find patterns
chunk up
starting
talk about privacy and safety
a dirty laundry meeting
write down 1 word on how you feel about the sprint
thrilled/bored/curious, etc.
write down a movie character
Darth Vader
Forrest Gump
Captain Lorca
Harry Potter
Update Team Agreement
do not create tech debt
boy scout rule
no phones during standup
The agreement is owned by the Team. The Team enforces it.
Introduce Tree metaphor
gather data
events
metrics
vote on issues, decide trys
4Ls
columns
write on sticky notes
keep private!
10 minutes
Sample Retro Plan
Exercises
soup and circles game
Treasure Island
sprint as movie plot of favourite genre
agile games from BoxUK
presentation slides
Agile Bang for the Buck
a planning model
grid with value and cost in Fibonacci numbers on both
Games from tastycupcakes.com
retro frameworks from Weave
Define Success
Pre-Mortems
analyze a fictional future project that went wrong
Create Safety
Mining the Timeline for Gold
Remember the Future
Remember the Future Retrospective game
Agile Chairs
Buy a Feature
Sailboat
Similarity to SWOT
nice step-by-step description
have team arrange stickies into categories, then dot-vote (3 each)
Hot Tub
Empathy Map
mad sad glad
4Ls
Jira Team Playbook
Herculean Donut
Tools
Patterns
Discover
Prune Product Tree
Sailboat
Product Box
Actions Centered
Shape
Give them a Hot Tub
Remember the Future
Show and Tell
Prioritize
Buy a Feature
20/20 Vision
Act
My Worst Nightmare
article in French
retro patterns from XP
PO's role in Retro
Remote
1-2 remote team members
secret sauce in everything is taking a look at what you are doing
retros are bottom up opportunities to figure out ways for improvement
retrospect on this
Kerth's prime directive
retro format
check-in, set context, gather data, generate insights, make resolutions
diverge, converge
5-step format
Institute for Cultural Affairs (Canada)
The Art of Focused Conversation
ORID
Observation
Reflection
Interpretation
Decision
Human Systems Dynamics Institute
Adaptive Action format
What? So What? Now What?
Liberating Structures
Virginia Satir Interaction Model
how we respond to things
first 3 phases
gather data
what?
analyze
so what?
decide
now what?
was extended with 2 more additional phases to help start and conclude the meeting in the context of Software Development
public speaking
start speech
ask a question that unites the audience
state a weird fact
e.g. more people living today than have ever died
once upon a time
trained as kids
start telling a story about
person to person
the person doing facilitation should not be involved in decision making
DTA
intro
why are we here
what is the culture, space or atmosphere do you want to create in the team?
How do you want to behave together when things get difficult?
What would help the team to flourish?
What can your team count on from you?
stances
Lyssa Adkins
coaching styles
teaching
Shu
coaching
Ha
advising
Ri
also
modeling
reaching
Daniel Goleman
leadership styles
Scrum Master
coaching on 2 levels
team
individual
interteam?
quick facilitation plan
buy in
create targeted norms
ask
What rules are needed for today's conversation to ensure that everyone can confidently share what's on their mind?
examples of safety norms
healthy debates vs dysfunctional arguments
types of conversations
decisions are expected to be made
types
Planning
Problem solving
Relationship building
qualities
decisions aren't expected to be made
types
Information sharing
List making
Brainstorming
qualities
who are your stakeholders
what do they care about
what can you deliver in 2 weeks
5 points customer liked, 5 points customer disliked
goes off the rails?
interview
Agile Hiring
strong recruiting pipeline
ask if they would want to redo the interview
#noresume
ask the candidate to send a video instead
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
interview plan
STAR Behavioural Interviews
interview questions
Management 3.0 interview activities
interview games/activities
questions/topics
flow
did you research us
here is what we are trying to build
what have you been up to
team roles
scout
backfiller (refactoring)
pipeline
mainline
Similarity with the 4 work types
Business Projects
Internal Projects
Changes
goes into Business Projects
Unplanned Work
qa @ atlassian
quality assistance
"like SM for quality"
quality engineers
stabilizing teams
Cognitive Load
types
Intrinsic
Extraneous
Germane
Yerkes-Dodson Law
relationship between arousal and performance
tasks require different levels of arousal for optimal performance
bell curve
stress hormones
estimation is more accurate when extraneous and intrinsic cognitive load is reduced
team charter
working agreements
e.g.
when we meet
admit when we are the impediment (courage as value)
definition of done, ready
DTA
shared
goals
vision
values
cohesive team
why are we special and important to the company
identity for value streams instead of projects
teams should be built around buriness capabilities, not projects
dependencies within the business architecture make it difficult for teams to own their work
temporary compensating controls
dependencies dictate their schedule
teams know how fast they should be going
system of transformation
value streams vs business capabilities
we know that a ton of stuff will get in the way of this
we know 80% - 90% of what will get in the way before we even start
we can enumerate those things
install compensating controls
break dependencies over time
start removing the compensating controls
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
setting teams up to fail
therefore
besides/instead of teaching Agile
systematically remove barriers to Agile
how much agility will the ecosystem allow?
adult cognitive development
Robert Kegan
SOI (subject-object interview)
ASOI
autodidact
3-day course @ $3,000
5 stages of development
1. Impulsive Mind
infant
2. Imperial Mind
child
3. Socialized mind
mature to be on a team
4. Self-Authoring Mind
see from other perspectives
need to write User Stories
5. Self-Transforming Mind
lead together
pre/trans fallacy
continuum
dependent (pre)
independent
interdependent (trans)
confusing pre and post
Emotional Intelligence
do you know what the other person is feeling?
can you tell when you are making another person uncomfortable?
do you know when others know how you feel?
Shu-Ha-Ri
similarity to
Nietzsche's stages
Robert Kegan's levels
identify T-shapes
helps get out of silos
use to pair
Why not go all the way, and do temperament inventories too?
DISC
MBTI & Keirsey
Predictive Index
VIA Institute
merit money
merit money is more fair than collective "celebrating together" where someone else decides how everyone is going to spend money/celebrate
safety
Lack of psychological safety at work makes us hide mistakes, and play blame games
vulnerability-based trust
start less, finish more, and limit WIP
Lean
starting less requires authority
authority comes from commitment
solve half of the problems rather than creating half-solved problems
we speak of people as the most valuable resource in any company, and yet needs of teams are often ignored
teams are expected to adjust when instead teams should be protected at any cost
2-step facet of Agile
e.g. Scrum will expose dysfunctions
people must be there and ready to continually remove obstacles
can't rely on an external force
like management removing obstacles for "resources"
respect for individuals
help them mature
Performance management
the best team members are the ones that make the whole team perform better
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
We have autonomy but we are not autonomous
we exist in the product community
meetings and rules
not one "right" way, but one consistent way
meetings
Agile is a collaborative approach to work
it is possible that the degree of collaboration
needed to realize the benefits of Agile
is not "normal" for managers and/or team members
uncomfortable with pair-programming
ROTI
Return On Time Invested
see J Rothman on measuring value of meetings
4 karmas (amount of power used grows from 1 to 4)
Peace
creating safe environment
Enrich
help to grow
Energize
hold space, guide, direct
Destroy
restructure
Agile Metrics
Troy Magennis
metrics
Excel charts
Throughput
Planned and Unplanned Throughput trend and histograms
Unplanned work percentage rate
Net flow (number of items completed – number of items started) per week
Weekly trend of throughput, cycle-time and WIP in one chart
Cycle time planned and unplanned histograms
team size
see Amdahl's Law in the free course on Agile Physics
Andy Cleff
Measure teams not individuals
the Carmelo Anthony effect
traditional control measures were put there because of lack of trust
Measuring Team and Process Health
Define Team success
what "good" and "bad" mean
good and bad metrics
what is a "win"?
Do not rely on easy-to-get data
e.g. velocity
superficial
could be
completely wrong
obscuring important information
e.g.
the film Moneyballed
everyone looked at how well individual players score, while Oakland (baseball) realized that there was another metric
the other metric is team behaviour during games (players get on base more)
as opposed to how much a player is paid
what besides money affects win/loss ratio?
The Carmelo Anthony effect
he scores more, but he also misses more than others
he is swarmed by other team's players, and they block him
the metric informs strategy: pass when you 're blocked
it was chosen because it was available, not because it was good
choose metrics on their ability to lead to a better decision, not ease of measurement
we need to generate insights that would get us to improve
improve in a very specific area
"good" gaming of metrics
e.g.
good
if we measure velocity, people start splitting stories
more detailed stories, higher quality
more finely grained stories
bad
shaming developers for unresolved bugs caused them working on bugs only
code that would have been refactored with addition of new features was instead refactored to fix bugs, and no new features
value not delivered
value driven work vs fixing bugs - responding to wall of shame, and not to customer
value not delivered
people started skipping the system, telling developers about bugs directly
actively losing data
Testers stopped reporting bugs to not make teams look bad
actively losing data
Result: we don't know how many defects we have
Works as intended for 1 month, then becomes rubbish
a la the electronic whip @Disney hotels
common ways of gaming this metric will lead to the desired outcomes
share the "why"
People must see how it relates to them
what it would change
improve outcomes or improve control/oversight/utilization
prefer trend or distribution based metrics
data even out, become more objective
help organization sense and adapt
a better adaptive organism
in a way, if things don't have names they don't yet exist in our world, they aren't under our control, and we cannot focus on them. Let's have metrics, and inform ourselves from empirical data
information on the project is as (more) important than the deliverable
e.g. FedEx: tracking is the most expensive part of the service
2 approaches
adaptive
predictive
smart people plan then less smart people execute
success is defined by how close to the plan the execusion was
prefer leading indicators
they provide actionable information about something that will happen in the future
fix it before it becomes an issue
Primary Leading Indicators
help to determine likelihood of completion of the main goals
business objectives & strategic goals
there are things that impact these primary leading indicators, and they can be measured too
Leading & Lagging
could be both
e.g. a team's velocity may be a lagging indicator for a team, but a leading indicator for the company
state of economy is a leading indicator for employment
unemployment is a lagging indicator for economy
Lagging Indicators
e.g.
BMI/weight
completed work
closed tickets
horses out of the barn
cupcakes eaten
could be a leading indicator for health
Leading indicators
e.g.
employment insurance applications
happiness
staff changes
average overtime
active issues
active risks
risk burndown chart
blockers
number of outstanding bugs
dependencies, handoffs, stage gates
stable velocity
stable delivery team
amount of ready backlog
requirements volatility as a metric
leading indicator
metrics
would we do things differently depending on the metric?
then it must be measured
7 Deadly Sins of Agile Measurement
a discussion on Agile Metrics
Troy Magennis
focused objective
Monte-Carlo simulation
estimate delivery
street lights
how do you forecast your trip when street lights are semi random
SAFe metrics
unit of time for unit of value, unit of value per unit of time
define value
moving towards goals
measure the four types of work
Lean
Phoenix Project
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
cycle time
handoffs
rework
dependencies
defect rate
measure work not worker
Scorecard Index
Jurgen Appelo
balanced scorecard
SDPI
Five Buckets
Process Health
Release Metrics
Product Development Metrics
Technical/Code Metrics
People/Team: The Human Elements
starting point
units of value per unit of time
unit of time per unit of value
graph both
No estimates
Step One: Estimate till you have enough data
Step Two: use probability calculations to base projections on real data with real confidence
probabilistic forecasting
how do we know what our optimal capacity is?
if performance drops as load increases then it's too high
siloing
rigidity
calculate additional effort
context switching between partially done tickets
"parked inventory"
relearning
handoffs
extra communications
status updates, confirmations that we are still working on it
delays
increased with siloing
SDPI
Larry Maccherone
Impact of Agile Quantified - A De-Mystery Thriller
evaluate best iteration length
Software Development Performance Index
Areas
Customer Satisfaction
Net Promoter Score
Repeats/Renewals
Employee Satisfaction
Surveys
Attrition Rates
Retrospective Outcomes
Quality
Maintenance Complexity Trending
Defect Density
Issue reintroduction rate
Defect Arrival/Kill rate
Unit Test Coverage
Auto Functional Test Coverage
Productivity
Velocity
Average Age
Predictability
Say/Do ratio
Velocity Variance
Cycle Time per Story Point
Feature Comparison
from Lessons Learned?
Responsiveness
Cycle Time per Story
Lead time per Story
Queue/Batch Size
Average Impediment Lifetime
Mean Time to Release
Mean Time to Fix
Activities
Do it Fast
Productivity
Responsiveness
Do it Right
Quality
Customer Satisfaction
Do it On-Time
Predictability
Keep Doing it
Employee Satisfaction
Team Dimensions
Responsiveness
Productivity
Quality
Predictability
Manage Flow
resources
flow & bottlenecks
water bottle upside down
static bottle
repetition of stop-start flow
turmoil inside the system
unproductive conflicts
internal processes do not add value
system is captive of its own internal processes
lots of activity, but rate of flow not increased
bottle with vortex
bottle with a straw
Deliver it! on Flow
CD Patterns for Contemporary Architecture
avoid handoffs
teamsize 9-15
opens up a whole new horizon of what teams can be high performing at compared to the 5-9 size
Larry Maccherone
lean
do only the work that brings value
be slow like tortoise
e.g. don't go to gym too much
focus on process not results
achieving goal doesn't lock in behaviour
to achieve better performance focus on learning
think in terms of flow
create pull systems
"System does not end at the factory gates" (Chris Chapman?)
Flow efficiency
story mapping
identify bottlenecks
"solve the problem for a customer fast enough so that they don't have time to change their minds"
a 2 hour problem 2 months to solve?
flow trumps waste removal, value trumps flow
APQP
Lean Wastes
7 lean wastes (muda)
Partially Done Work
Extra Features
Relearning
Handoffs
Delays
Task Switching
Defects
unevenness (mura)
overburden (muri)
Lean Waste #1
Inventory/Partially done work
incomplete work == WIP
DIP
Design in Process
warehousing costs
excess of incomplete work
management issues
priorities
overpromising
Lean Waste #2
Overproduction/Extra Features
MVP
LRM
Small batches, often
Lean Waste #3
Relearning/Reprocessing
extra processes that don't bring value
pure overhead
e.g. searching for documentation
repeating a value adding activity
the first instance did not provide the value
knowledge sharing mechanisms
brown-bags, pairing, useful code reviews
switching between unfinished tasks
Lean Waste #4
Handoffs/Transportation
cross-functional teams
avoid silos
tacit knowledge
e.g. riding a bike, or blowing a bubble with bubble gum, designing a system
how much tacit knowledge is lost when passing a task/project to someone mostly via documents?
each handoff loses 50% of information
a dysfunctional example: Client->PO->Devs->Testers
Lean Waste 5
Delays
time between creation of action items and when work begins
waiting for tools or staff to start any work
documentation phases
activities that do not validate or invalidate decisions/requirements
review or approval process
where person is unavailable (bottleneck)
where process is not appropriate
High WIP
The Goal
trying to be more efficient anywhere else than the bottleneck is a waste
Herbie
each scout could be
an area of work
responding
following up
researching
escalating
communicating internally
administrative
extrinsic cognitive load
learning
column on kanban board
scheduler step (e.g. Airflow)
WIP
High WIP
what can go wrong when WIP is low?
overpromising
leads to underperformance
short term positive impact
similar to unsound investments
partially done work
cumulative flow diagram shows the WIP
cumulative flow diagram
mapping
process maps vs value stream maps
Leading Agile podcast episode
differences
value stream focuses on handoffs between processes
process map looks at steps within process
if we deliver in large increments then our metrics are against readiness for the release, but if we deliver continuously then our metrics become related to the client's reaction
plan delivery of features rather than execution of activities
focus on outcomes, not output
we tend to plan the activities of a functional silo rather than delivery of the product
multitasking
executive function
context switching
goal shifting
rule activation
types
planning
problem solving
analysis
context switching or prioritization
no value produced
we can perform only one executive task at a time
cost of multitasking
mental capacity
cost is time and efficiency
cost of doing two tasks is 40%
60% for three tasks
depends on complexity of task
when multitasking we are not necessarily doing the most important/impactful thing
may be solving the wrong problem
performance
lower quality
burnout
cultural/organizational/corporate influence
illusions
solutions
WIP Limit
Kronos 2017 study
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
employee churn one of the top problems for the polled companies
make reality visible
check scientific studies
what is our natural capacity?
put in limits
DoD
start less finish more
focus on outcomes not outputs
rank-order work activities by outcome (like in a Backlog)
Agile practices
how many projects/initiatives are currently in-progress?
wrong solutions
focus on efficiency of individuals
not addressing the root issue
which is pursuing too many issues at the same time
treating symptoms
address work/life balance
yoga room
free frozen yogurt
materials
Agile Uprising podcast
scientific studies
arrival & departure rates
converging
diverging
Little's Law
with tacos
with stealth bombers
limit variability
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
relay race
focus on the baton, not on the racers
outcome over capacity utilization
Reporting time
against principle 5
trust motivated individuals
against principle 7
working software is primary measure of progress
how would you feel having to report hours?
Slack is necessary to respond to change
How does Fedex do overnight deliveries?
they always have planes flying everywhere even if they are empty
Fire engines
instead of utilization
business value, impactfulness, or priority level of what the person is working on
we are all always working on something
what are you working on now?
actionable agile metrics Jira addon
do compensation schemes support shared commitment?
types of debt
technical debt
Technical Debt Quadrant
Martin Fowler
diagram
cultural debt
flow debt
always expediting
incurring until walking in tar
How much code that is not currently making money do we have?
Handoffs is a form of waste
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
figure out the cadence
then align the processes to it
how often does something happen
what events exist in your work cycle
make changes at the same pace as the need for change is discovered
Tim Snyder
on LinkedIn
measure work types
Business Project
Internal Project
Operational Changes
Unplanned Work
Student Syndrome
starting a task too late
solution
pad (local buffer) at the end, not at the beginning
12 principles, 5 buckets, 10 lenses
Systems & Complexity
Wicked Problem
hard to define
unclear if it's not a symptom
doesn't have a definitive solution
the problem is only understood after a solution is offered
any attempt to probe or solve can cause more damage
authority
if all solutions could be wrong, who decides which one to take?
explaining elctromagnetism and physics cannot be done with the vocbulary of the Middle Ages
a wicked problem cannot be resolved from the same level of consciousness that created it
Systems Thinking vs Complexity Theory
Systems Thinking identifies a desirable future state, and tries to close the gap
Complexity Theory studies the present, and uses this knowledge to evolve in small increments
turn up the good
"Ideal future vs evolutionary potential of the present"
boat metaphor
PID controller
Dave Thomas
the boat turns way after turning the wheel
move from the project based approach to the product lifecycle perspective
projects end, products go on, need experts
don't break up teams for every project
all star basketball players don't play well because they aren't used to playing with each other
fitness landscape
data points
Stacey Matrix
certainty vs agreement
technology vs requirements
how vs what
Adaptive Structuration Theory
Scott Poole
Structures & Working Arrangements
duality of structure
producing & reproducing
e.g.
clean the counter
change oil
drawing on it and reproducing
when you call a vote you produce structure
likely to repeat in the future
use it or lose it
we are creating structure and creating conditions for the structure to exist
system of delivery and system of transformation
red work & blue work?
team
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
learn how to learn first
learning
single loop
e.g.
thermostat
same way to satisfy customer
hill climbing
add QAs to increase quality
double loop
e.g.
go check if temperature changes because window is open
adopt TDD instead of hiring more QAs
learning new systems (game rules)
moving to self-organization requires self-organization
Mike Cohn
an equilibrated state is when each member is participating voluntarily, and no energy is wasted on coercion
thermodynamics
OODA Loop
Col John Boyd
F86 vs MiG-15
the advantage is in having a faster loop than another system
the loop
Observe
Orient
Decide
Act
similarity with Satir Interaction Model
in complex situations there are often unknowable things, but our bias for certainty we tend to listen to people who promise clarity and certainty, we turn a blind eye
VUCA
Acronym
Volatility
Uncertainty
Complexity
Ambiguity
Agile started as a tech practice to write code under conditions of uncertainty
Diamond Agile
Scrum is 5% of what Agile is
serendipity
luck
"it's not luck"
pattern
systems thinking
pay attention to how systems connect to each other
some systems base their communications on failure states
i.e. only communicating about how things fail when they fail
creates negative associations and expectations
realize that there are more successes than failures
learn to represent the successes in communications
Appreciative Inquiry
tunnel vision
Systems in organizations
feedback loops
levels of interactions
complexity theory
chaos theory
psychological safety and maturity
levels
types of leadership
roles
roles belong to the system
Homeless guy directing traffic after earthquake
San Francisco, Oct 17, 1989
power knocked out, street lights not working, chaos
except for the corner Kearny and Pine streets
Product Management
4 quadrants of product ownership
Product Management
Project Management
Backlog refining
Release Planning
from XP
column for each iteration
populate from backlog
(usually) team distributes the work
up to 12 iterations
conversations
efficiency
workflow
risk mitigation
unknowns
glue stories
dependencies
integration milestones
Road-Mapping
Converge and align with release expectations
stakeholder needs
reality of delivery
Leadership
Business Analysis
Meta Cast
episode 41 on quadrants
help devs to communicate directly with customer
makes devs negotiate new features
lower bandwidth
new hats
gather new requirements
understand the company's strategy & perspective
understand the customer's wishes
represent the company
set product direction
say no to customer
PO and Dev Team
no reporting structure on a team
if a PO is not on the same level, then it's not a team meeting
everyone is a peer
it is the job of the customer team to make the flow more smooth for the dev team
do not pass on irregularities
our goal is to build a high performing dev team
we are outside of it
get them into a rhythm
PO vs SM
what game to play vs how to win
POs AKA
Product Management mistakes article
DIKW Pyramid
mistaking information for knowledge
wisdom is knowledge plus judgement
PO owns the problem domain
POs maximize value
PO cannot maximize output, forced to work with value
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
saying "build me this"
is not passing requirements, it is passing on the responsibility & the problem
connected to customer, not management?
if it is necessary for the product vision, PO connects to whoever
culture
Your Brain on Scrum
Michael de la Maza
nod to Your Brain at Work by David Rock
kanban po's & product manager's bff
conductor of an orchestra
mahesh singh
PO as the CEO of the product
nonsense products
coors spring water
macdonalds - macspaghetti
pepsi clear
own the product model
product roadmap
innovation game
buy a feature
walking skeleton
story mapping
blaming engineers for not delivering value to customer
job of PO
Priorities
sometimes the next highest priority item is not in the backlog
it could be a
team wellness story
spike
priorities change depending on exetrnal conditions
e.g. developers working on other story
new name for product
Jeff Patton
software product is not consumed upon purchase, it's used, and updated continuously
Techniques
map a feature's journey from idea to production
where is the most fear?
where are the bottlenecks?
what safe experiments can we perform to shorten that time?
save time
remove unnecessary practice
ask the team where the pain is
take it to the team
a tracer?
12 week year
appeals to Lean in that you have to cut away waste
lack of execution
Pomodoro
Pomodoro is a mini Scrum
minimum for success
working, tested software at the end of the Sprint
stable velocity
DoD
stable x-functional teams
autonomy to decide how the work is done
some degree of autonomy
no dependencies outside team
refined Backlog
prioritized
1-2 day chunks
"a handful of them can be delivered in a Sprint"
without these 3 items every Scrum ceremony will break down
graph importance over urgency
Prototyping
1st C-series Bombardier was built in wood
then they walked parts in different parts of the factory to see if the factory is configured correctly
story from Richer
Kanban
Core Properties
Limit WIP
Visualize work
Manage Flow
Make Process Policies Explicit
Improve Collaboratively
cards are nouns
things
lanes are verbs
activities
start where you are now
everyone writes down 5-10 things they're working on
step 2
could be done in pairs
answer
what type of work it is?
where is it now?
where was it just before I got it?
where will it go when I'm done with it?
Kanban Maturity model
Q&A on the Book Kanban Maturity Model: Evolving Fit-for-Purpose Organizations
Detailed description of the framework
LeanKanban
KMM: Alternative Path to Agility
Diagrams
levels
Alternative Path to Agility
Change Management
Bring business partner into the eye of the hurricane with you
create change together instead of subjecting them to change
We see most resistance when #change is inflicted. Key is to bring stakeholders in the eye of the hurricane with you & create change together
LEAP Institute
videos
acronym
Listen
Empathize
Agree
Partner
used in change management when someone doesn't share paradigm
e.g. Theory X vs Theory Y
hypothesis
action connected to business case
changes in
Culture
Practices
Systems
is it going to help us remove dependencies
value stream map to show bottlenecks
where is Herbie?
Sprints/Iterations
hardening sprint
aka
Release Readiness Sprint
Mike Cohn
Stabilization Sprint
Spring Cleaning Sprint
dev priorities
DA
hardening the product in Transition Phase
meant to be phased out as team matures
SAFe
Hardening Sprint at the end of ART
meant for large scale product development
not part of Core Scrum
ScrumButt
anti-pattern
goal
continuously reduce the need for HS till we don't need one
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
tougher for new teams to start on the pro track
need guardrails
training wheels
Sprint 0
best iteration length
skewed sprint
cascading sprints testing
Longer Sprints
Student syndrome
padding at the front instead of the back
we are not delivering an increment every Sprint
weak Sprint Goals
weaken SG
multiple anchor stories
demos longer, different things
predictability and ability to deliver on what was forecast less important with weak SG
scope creep
less autonomy for teams
teams should be able to self-organize
restructuring Sprint interferes with Team's autonomy, and washes down the SG
dependency on PO
flow-based vs iteration-based cadence
games
Koans game
sorting hat
sparrow deck
Defer commitment until the Last Responsible Moment
like in Stacey Matrix, but plot doing the right thing vs doing things right
IT aligned vs IT effective
Code
on code
Collective code ownership
CQRS
write code like the next guy reading it is a sociopath with your home address
CD
Real-World Strategies for Continuous Delivery with Maven and Jenkins
typical flow
code quality
Automated Testing
in waterfall we put off testing till the last stages of the project
because as code gets changed testing would have to be redone
in Agile, we pivot continuously, and release more often
a lot more testing to do
TDD
systems thinking
create future state, and work towards it
create a need/problem, and then solve it
express intent, and then deliver that intent
Marquet?
intent breaks the test, and communicates a global, holistic goal in regard to the whole system
communicates vision to the future devs
intent-revealing code
write code like the next developer is a sociopath with your home address
developers are most valuable
don't break the money-printing machine
OKRs
Objectives & Key Results
instead of following instructions, we are aligned
Set 3-5 high level objectives
measure achievement 0% to 100% (or 0 to 1)
should be > 70%
at that point move on to another
cascading OKRs
OSKRs - with a strategy
US Army pistol shooters
imagine the bullet hitting the bull's eye
Andy Grove
President of Intel in 1970s
now used by
Atlassian
Confluence add-on
Google, LinkedIn, Twitter, etc.
resources
OKR meeting templates & more
OKRs at Google
GQM
questions
When was the last time we celebrated something?
How often should this happen?
How did you improve something recently?
What positive change did you introduce?
How did you improve yourself recently?
value stream mapping
Shigeo Shingo
Retrospective exercise
Meetings
Holacracy
Tactical
full video
Governance
meeting types
types
status
team members describe where they are, report their progress
goal
report on progress
sync up
planning
what to do and when
e.g. goal of standup is to coordinate activities
decision
consensus building
general agreement before moving forward
establish options, agree on path forward
diverge-converge
problem-solving
gather to solve a specific issue
data dumps (information sharing)
unidirectional
caveats
each meeting has a goal and a deliverable
do not mix meeting types
because it will mix the goals
e.g.
standups that run forever
the goal determines
Product Backlog Refinement
Daily Standup
meetings
IDOARRT
meeting design tool
points
Intention
Desired Outcome(s)
Agenda
Roles
Rules
Time
Power Start
Purpose
Outcome
WIIFM
Engagement
Roles
outcomes (deliverables)
head
hands
heart
Questions
How will this change the way I work?
Whom do I need to make follow-up meetings with?
How should the next meeting be different?
meeting components
anticipate change
generate confidence
analyze results
initiate action
Law of Mobility
7 types of meeting goals
Share Information
note
dynamics of presenter and audience are "numbing"
use quick conversations in pairs to help digest
Advance the Thinking
e.g.
Define a problem
Analyze a problem
Identify underlying patterns
Sort a list of ideas into themes
Evaluate options
Identify Critical Success Factors (CSFs)
Improve Communication
Build Community
Build Capacity
Make Decisions
note
what decision rule will we use?
Provide Input
overall goal vs meeting goal
do not mix types
define acceptance criteria for what makes a good meeting
agenda
process notes
roles
set of group norms
clarity about decision-making options
effective member behaviours
periodic process checks
detailed minutes
follow-up plans
post-meeting evaluation
Meeting Dynamics
ice-breakers
2 truths and a lie
anonymously pick a photograph online that describes, for example, what you did last weekend
knowing each other doesn't mean there is a strong connection
mystery game
why are we here?
acknowledge others
ask you to lean in to being
open, respectful, etc.
anyone not on board with that
David Kantor's Structural Dynamics
counterfeit "Yes"
response to a persion who cares too much about themselves
may be passive-aggressive
structural dynamics of dialogue "stuckness"
"No" is the gateway to yes
debrief at the end of a meeting
formal commitment to resolutions
participatory decision making
exercise: silence as disagreement
if people don't weigh in, they don't buy in
Patrick Lencioni
leader (team) can only break ties when everyone had weighed in
disagree and commit
Sprint Planning
Team's definition of Ready
INVEST
planning poker
Guidelines
Impact Mapping
PO Key skills
give shape to the shapeless
go from the chaotic domain to complicated
what are you seeing there in the fog in the next two weeks?
why we do planning
we need to be predictable and reliable
must be proactive
as long as we have an outcome in mind we need a plan
we can do more together than alone
we are going into the future on our own terms
Sprint Review
MIT Media Lab
pre "official" Scrum
demo or die
Closure Event for Timebox
Share Progress
Get Feedback
the demo is by the team, not individual developers
Have a rotating presenter
Sprint Review Template
Sprint Review anti-patterns
we celebrate successful delivery
on a scale from 1-10, how would you rate this Sprint?
ask PO if there are repercussions for tasks not delivered
Retrospective
Agility Chapter
DevOps Chapter topics
Goals
CI/CD
TDD
Similar infrastructure
consider the whole organization when implementing procedures
areas
detailed
Code & Commit
Build & Version
Branch & Deploy
Monitor & Test
Deploy & Debug
People
collaborate, align
Process
eliminate waste
increase efficiency
deliver value
Tools
Enhance productivity
Collaboration
Experimentation
working agreements
admin
chat, Jira, etc
what are our challenges?
DevOps chapter at the Dude
cards different colour
on each board
Shift left
3 ways
System Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
architecture stories
DevOps/architecture
roadmaps
intertwining with product roadmap
epics
Identify Protect Detect Respond Recover
if you are not using a camera
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
turn on cameras
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
David Farmer
Postmortem
Incident Retrospective
incidents aren't unusual
complex systems have various failures from time to time
actions during the incident are part of our normal functioning
present elsewhere
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
the goal
not to fix something, but to learn
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
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
Safety 1
assumption that systems are safe unless something or someone breaks something
is wrong
in reality, errors are a routine part of any complex system
combine this with Safety 2
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
Process
focus on how, not why
ask for descriptions of what people experienced, not explanations of what they did
Root Cause is a myth
How Complex Systems Fail
paper by Dr Cooke
incidents in a complex system require multiple failures
attribution to a single root cause is fundamentally wrong
Swiss Cheese model
layers of the system are slices of Swiss Cheese
image
when holes line up there is an opportunity for failure to slip through
say "contributing factor" instead
facilitator or the Incident Commander from the incident
"to shepard the document"
Hardbeets
thought it would be easier to write our own regex than to find it in the code
GitLab is tough to navigate
can we just grep a monorepo?
enterprise version has elastic search
incomplete section: dev team
interrupted work incurred
contributing factors
agenda
check in
what are your positive expectations from this meeting?
discuss what went well
What aspects of our system and teams contributed to our success here?
During the incident, and the events leading up to it, how did we actively create and sustain success?
How are we already monitoring, responding, anticipating, and learning?
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?
items
Was detection timely?
Was everything tested according to procedure?
Were processes followed?
How did responders figure out what was wrong, and remediate it?
Did our safety measures prevent the issue from being worse?
brainstorm contributing causes
questions
How did it happen?
dig deeper
What about the system that let this issue being possible?
What hindered detection?
look at communication
TTD
What hindered diagnosis?
What hindered resolution?
TTR
safety
First Story
simple cause and effect
Second Story
details and systemic factors that led to the situation being possible
ETTO
Efficiency-Thoroughness Trade-Off Principle
systemic
understaffing
capacity
under-training
GitLab
not investing in reliability
review list of contributing causes
brainstorm corrective actions
potentially vote
evaluate corrective actions
okay to decide that more work needed
refer actions for further work
Extended Dreyfus model for Incident Lifecycles
definition of done
Chris Sterling on definition of done
4 Rules of Simple Design
Passes the tests
Reveals intention
No duplication
Fewest elements
You Aren't Gonna Need It
checklist for washing your hands
agreement amongst doctors
everyone agrees on a foundation
Unit Tests Tell You When You're Done
acceptance criteria that are common for all User Stories
immutable code
code reuse
code normalization
Fowler?
DRY
abstract away the same things to not repeat yourself
common understanding improves flow
reduced variability
cannot be imposed
must understand why
DoDs evolve
when behaviour becomes internalized we focus on the new behaviour
the "done" depends on the business
connection to business
e.g. wash hands in healthcare or bus driver
"pause point"
in surgical ward it's before entering (where the check happens)
decision point
at tn LRM?
DoDs for
task
story
sprint
release
examples
testability
PO moves the card/changes the status
checklist manifesto
Tools
Communication
developers have access to customer, not customer accessing developers
usually it's too complex or incompatible
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
Jira
Checklist
multiple teams in Jira
Jira Workflow
deployment
jenkins + maven also in docker
jenkins + maven in docker
Dockerizing Jenkins: Deployment with Maven & JFrog Artifactory
Technology roadmap software
aha.io
stackoverflow
The Responsive Method
similarity with the Laloux Model
The Responsive Manifesto
Mockups for prototyping
in Atlassian store
Portfolio for Jira
tech roadmap vs product roadmap
what about culture?
they are simple and static enough to build them manually
Jama?
how is it similar to
WBS
SOW
Statement of Scope
Backlog
Milestone Schedule
Kissflow
behaviour vs tools
we sometimes remove good tools because they are being misused
Reading List
books
SAFe reading list
advanced agile practices that seem simple
Trunk Based Development
no subtasks
Count stories instead of story points
slicing heuristics
Kanban
flow based model
whole organization has to be aligned
Kanban has fewer rules
Continuous Delivery
Variable length Sprints
tools
can be used as weapons
get rid of all sharp knives until mature
The Ss
3S
Sweep
Sort
Standardize
5S
Sift
Sweep
Sort
Standardize
Sustain
OGSM
objective
goals
strategies
measures
based on Peter Drucker's Management by Objectives
developed in Japan in 1950s
users
Coca-cola
Procter & gamble
Agile approaches are not new
when was Scrum created?
1985
almost 40 years ago
Kanban
implmented by Taichi Ohno in 1953
70 years ago
enough treating these methods as something new
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