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

a

Path to Agile Fluency -- Fit to Purspose

a

Agile Transformation Roadmap from CA

a

Transformation Planning Cards

a

Presentation slides

a

Transformation Paths

a

KPIs, Outcomes, Activities

from CA

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

a

KPIs, Outcomes, Metrics

Frameworks

The Flow Framework

a

projecttoproduct.org

a

project vs product infographic

mentioned on Agile Amped

a

interview on Agile Uprising

a

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

a

decision process framework

maturity model

e.g. start w/Scrum, evolve to Lean

start with SAFe (waterfall compatible), evolve to LeSS

LeSS

a

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

a

Tracer Bullet Development

a

from Pragmatic Programmer

similar to walking skeleton

do a full thin slice

Practices Map by Stage

a

FAST Agile

DSDM

XP

Spotify

Spotify vs Fitbit

a

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

a

Part 2

a

Modern Agile

Agility Scales

Holacracy

a

Tactical

a

full video

a

Governance

a

RAGE

a

Recipes for Agile Governance in the Enterprise

startup@scale Transformation Framework

a

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)

a

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

a

2 ways to get better

learn new things

unlearn bad habits

Rian van der Merwe

DIKW Pyramid

DIKW Pyramid

a
Knowledge Management Cognitive Pyramid from US Army

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

a

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

from Jason Little

Synergy/Antagonism

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

a

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

a

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

a

True North & Mother Strategies

Getting the Right Things Done by Pascal Dennis

diagram

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

a

ebook

a

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

a

ADKAR

McKinsey 7-S framework

a

by Tom Peters & Robert Waterman

podcast

a
diagram

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

a

scrum

empirical process control + lean (measure + trust)

Scaling

coordinate multiple teams

LeSS

a

SAFe

a

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

a

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

a

The sum of a number of independent samples from any distribution is approximately normally distributed

DEEP Product Backlog

a

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

a

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

a

SPIDR

a

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?

a

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

a

they have story points

a

distinguish from stories to track number of bugs?

a

defects are different from user stories

a

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

a

Trello Example

a

Jira add-on

a

Cardboard

Mastering Business Analysis podcast episode 81 with David Hussman

a

the dude

Essentials of Agile User Story Mapping at Twitter

a

User journeys (scenarios of usage)

Jeff Patton walking through a story map

a

Story map example of getting ready in the morning (2 minutes)

a

what is the MVP of getting ready for work/school in the morning?

process of story mapping from Jeff Patton

a

cakewrecks.com

Wardley (Value Chain) Mapping

10 steps

a

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

a

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

a

guidelines

viewing stories as problems to be solved

a

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

a

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

a

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

a

use different methodologies to arrive at an estimate

Hofstadter's law

a

It always takes longer than you expect, even when you account for this

Optimism bias

a

stronger for negative events

e.g. it won't happen to me

the valence effect

a

reduced coding of undesirable information about the future

Pollyanna principle

a

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

a

farmer's almanac vs weather radar

Hypothesis Driven Development

a

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

diagram

a

iron triangle (triple constraint)

a

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

a

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

a

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.

a

Dev(Sec)Ops

The Seven Wastes of Software Development

a

Types of waste

Partially Done Work

a

Extra Features

Relearning

Handoffs

Delays

Task Switching

Defects

Partially Done Work

a

becomes obsolete before finished

interferes with other work

examples

monorepo advantages

a

Code Patterns

in 1978, 32K program on 32 chips

Code Craftsmanship

a

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"

a

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

a

Anti-Patterns Catalogue

a

Culture & Process

extract unifying commonalities

3 laws

team

small team

small increments

statistically ~15% only are passionate

a

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

a

antifragile software manifesto

a

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

a

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

a

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

a

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

a

in regards to selected work, it's a forecast

a

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

a

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

a

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

a

Principle 1

a

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

a

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.

a

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

a

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

a

in reference to the term rugged landscape?

emphasis on security

Rugged DevOps

a

7 habits of Rugged DevOps

a

CALMR

a

SRE

Problem Management

invoked when

focus on preventing incidents from happening

resources

People First

a

Cockburn article

a

First order non-linear component of software development

a

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

a

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

a

How Slavery Inspired Modern Business Management

a

"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

a

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

a

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

a

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

a

blame cycle

blame addiction

from blame to power

a

developers make tons of microdecisions

status-chaser antipattern

institutionalize w/out bureaucratizing

self-induced multitasking

values

Commitment in Scrum

a

Courage in Scrum

examples

a

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

a

PBL

guidance-fading effect

use scaffolding

Instructional Scaffolding

a

adult learning theory

does the company promote learning?

make people awesome

Bloom's taxonomy

a

cognitive domain

Remembering

Comprehending

Applying

Analyzing

Synthesizing

Evaluating

Bloom's Rose

a

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

a

mastering rockefeller habits

a

Scaling Up

a

by Verne Harnish

similar to lean

a

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

a

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

a

SOA & BPM (business process management) to align IT with business

BPEL - Business Process Execution Language

a

Layered architecture

balance allocating resources

a

Exploration

activities

long term

Exploitation

refine existing processes

efficiency

production

execution

short term

Manage Flow

push authority to where the information is

a

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

a

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

a

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

a

Observe

Orient

Decide

Act

similarity with Satir Interaction Model

a

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

a

red-green & TDD

Teams

Team Dynamics

paint drip, t-shaped

a

from Kent Beck

a

on heroes

a

case against heroes

a

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

a

Never verified, only invented to illustrate an idea

team cadence

a

multiple teams cadence

Crocker's Rules

a

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

a

Core Protocols

Check In

steps

I feel [one or more of MAD, SAD, GLAD, AFRAID]

I'm in

Team says "Welcome"

Commitments

Decider

a

caveats

withdraws proposal

absolute "no"

proportion of "no" and "support-it" too high

use Resolution Protocol to bring outliers in (the "nos")

a

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

a

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)

a

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

a

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)

a

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

a

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

diagram

a

similarity to

Shu Ha Ri

Teal Organizations

Cynefin

Alan Dayley

How You Lead Is What You Get: Empowerment is not enough

a

podcast

a

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

a

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

a

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

a

soup and circles game

a

Treasure Island

a

sprint as movie plot of favourite genre

agile games from BoxUK

a

presentation slides

a

Agile Bang for the Buck

a

a planning model

grid with value and cost in Fibonacci numbers on both

Games from tastycupcakes.com

a

retro frameworks from Weave

a

Define Success

Pre-Mortems

analyze a fictional future project that went wrong

Create Safety

Mining the Timeline for Gold

Remember the Future

a

Remember the Future Retrospective game

a

Agile Chairs

a

Buy a Feature

Sailboat

a

Similarity to SWOT

a

nice step-by-step description

a

have team arrange stickies into categories, then dot-vote (3 each)

Hot Tub

a

Empathy Map

mad sad glad

4Ls

Jira Team Playbook

a

Herculean Donut

Tools

a

Patterns

a

Discover

a

Prune Product Tree

Sailboat

Product Box

Actions Centered

a

Shape

a

Give them a Hot Tub

Remember the Future

Show and Tell

Prioritize

a

Buy a Feature

a

20/20 Vision

a

Act

a

My Worst Nightmare

a

article in French

a

retro patterns from XP

a

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

a

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

a

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

a

interview questions

a

Management 3.0 interview activities

a

interview games/activities

a

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

a

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

a

types

a

Intrinsic

Extraneous

Germane

Yerkes-Dodson Law

a

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)

a

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

a

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

a

metrics

a

Excel charts

a

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

a

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

a

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

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

a

Larry Maccherone

Impact of Agile Quantified - A De-Mystery Thriller

a

evaluate best iteration length

Software Development Performance Index

a

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

a

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

a

CD Patterns for Contemporary Architecture

a

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

a

Lean Wastes

7 lean wastes (muda)

a

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

a

Handoffs/Transportation

cross-functional teams

avoid silos

tacit knowledge

a

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

a

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

cumulative flow diagram

mapping

process maps vs value stream maps

Leading Agile podcast episode

a

differences

value stream focuses on handoffs between processes

process map looks at steps within process

a

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

a

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

a

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

a

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

a

scientific studies

a

arrival & departure rates

converging

diverging

Little's Law

a

with tacos

a

with stealth bombers

a

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

a

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

a

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

a

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

a

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

Stacey Matrix

a

certainty vs agreement

technology vs requirements

how vs what

Adaptive Structuration Theory

Scott Poole

a

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

a

Col John Boyd

F86 vs MiG-15

the advantage is in having a faster loop than another system

the loop

a

Observe

Orient

Decide

Act

similarity with Satir Interaction Model

a

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

a

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

a

episode 41 on quadrants

help devs to communicate directly with customer

a

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

a

DIKW Pyramid

a

mistaking information for knowledge

wisdom is knowledge plus judgement

PO owns the problem domain

POs maximize value

a

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

a

Michael de la Maza

nod to Your Brain at Work by David Rock

kanban po's & product manager's bff

a

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

a

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

a

appeals to Lean in that you have to cut away waste

a

lack of execution

Pomodoro

Pomodoro is a mini Scrum

a

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

a

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

a

Q&A on the Book Kanban Maturity Model: Evolving Fit-for-Purpose Organizations

a

Detailed description of the framework

a

LeanKanban

a

KMM: Alternative Path to Agility

a

Diagrams

levels

Alternative Path to Agility

a

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

a

videos

a

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

a

best iteration length

a

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

a

like in Stacey Matrix, but plot doing the right thing vs doing things right

a

IT aligned vs IT effective

Code

on code

Collective code ownership

CQRS

a

write code like the next guy reading it is a sociopath with your home address

CD

a

Real-World Strategies for Continuous Delivery with Maven and Jenkins

a

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

a

Objectives & Key Results

a

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

a

Confluence add-on

a

Google, LinkedIn, Twitter, etc.

resources

OKR meeting templates & more

a

OKRs at Google

a

GQM

a

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

a

Shigeo Shingo

a

Retrospective exercise

a

Meetings

Holacracy

a

Tactical

a

full video

a

Governance

a

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

a

Daily Standup

meetings

a

IDOARRT

a

meeting design tool

points

Intention

Desired Outcome(s)

Agenda

Roles

Rules

Time

Power Start

a

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

a

INVEST

planning poker

Guidelines

Impact Mapping

a

PO Key skills

a

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

a

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

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

a

4 Rules of Simple Design

a

Passes the tests

a

Reveals intention

a

No duplication

a

Fewest elements

a

You Aren't Gonna Need It

a

checklist for washing your hands

agreement amongst doctors

everyone agrees on a foundation

Unit Tests Tell You When You're Done

a

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

a

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

a

multiple teams in Jira

Jira Workflow

a

deployment

jenkins + maven also in docker

a

jenkins + maven in docker

a

Dockerizing Jenkins: Deployment with Maven & JFrog Artifactory

a

Technology roadmap software

a

aha.io

reddit

a

stackoverflow

a

The Responsive Method

a

similarity with the Laloux Model

The Responsive Manifesto

a

Mockups for prototyping

a

in Atlassian store

a

Portfolio for Jira

a

tech roadmap vs product roadmap

a

what about culture?

they are simple and static enough to build them manually

a

Jama?

how is it similar to

WBS

SOW

Statement of Scope

Backlog

Milestone Schedule

Kissflow

a

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

a

objective

goals

strategies

measures

based on Peter Drucker's Management by Objectives

a

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