Agile Schizophrenia - Fred George

(https://www.youtube.com/watch?v=jh7du2TfCQU)

disruptor: challenges thinking in a organisation

teams that are different

---

misalignment

Model: Uncertainty of requirements defines whether to work waterfall, agile or beyond agile

graveyard: agile does not work

"if a project was in the graveyard I walked away"

simple

managers teach the best practices

agile has no value here

Complicated problems

experts are expensive

get a team to do what the experts tell

"harvest their knowledge, turn it into stories"

Complex problems

there are no experts

"hire a bunch of bright people, turn them loose and say: figure it out"

try something, try something else

if something stops working, try something else

we're learning to solve fuzzy problems

Model: Agile Processes are a temporary tool to break old habits and for new ones

process to break 'bad habits' from waterfall

but once those habits are broken, we want to remove those processes

Agile practices:

purpose: get used to regularly delivering software

problem: let's pick a task that fit's in the rest of the slot

group tasking a story, but only 1-2 people will work on it

fear: estimates (depends on who I work with)

improve today!

once you get into the habit of taking work from a kanban wall, you don't need a standup anymore

everyone makes mistakes

microservice of only 100 lines of code

how certain are you about the requirements

fuzzy or very solid?

how experienced is my team at agile

does it need all the practices to get used to the processes?

or has it learned all those processes and can we start to relax them

What type of problem do I have

What type of team do I have?

slightly fuzzy, novice team

fuzzy: recomendation engines, google adverbs, financial markets

payroll, supply chain

larger companies

full range of problems

We're assuming everyone is novice

We're assuming it's traditional agile

fuzzy on the edges, not really pinned down

hardened the edges

very precise process

where is your velocity chart

mismatch

multiple teams:

How do we solve this mismatch?

Back to the basics

then cause practices and roles

fuzzy domains

story level

agile lives here

works well for traditional problems

does not work for fuzzy problems

feature level

customer: teach the domain

what is important

what does success mean?

I can test for that, measure that

teach us the problem to solve, not what to do next

---

experiment constantly

don't wait for retro

when failures happen, we go faster

less processes

Cycle time

avg team size = 1 dev

avg project length = 4 hours

Testing

no bugs => production system

nobody would die

we may lose some sales, we may lose some google ads

continuous delivery

new set of processes

still matching same principles

what really happened:

BA: you don't need me anymore

no experts in fuzzy problems

helped recruit in a competitive market

next level agile

"in XP pushing everything to the extreme"

traditional

fuzzy

---

case

traditional team

supply chain

transactions

=> waterfall

traditional agile

iterations

ship every 2 weeks

=> traditional agile

kiosk in the store

"scan clothes and send to your house"

ship twice a day

=> fuzzy

---

case: recommendation engine

very fuzzy

new team, new people => pair, standups

after a while, these processes need to get more fuzzy

different teams have different processes, matching their environment

---

Q&A

Across a large org, lots of different processes, does that work?

it works quite well

teams need to be visible about their processes

novice teams, need help selecting processes to fit their context

Very fuzzy, hard to convince that time boxing is not that easy

in fuzzy problems, competitive advantage is always going faster

deployment process, metrics, ...

not fond of timeboxing, innovation is very difficult with timeboxing

why did we run out of time?

timeboxing for experimenting with new technology

Team Envy: comparing processes, interesting tasks, freedom

you need to blow apart high performing teams with highest experience after a while

how well are you in pairing, and those things?

tomorrow that could be you if you work hard at it

Past, every programmer was an expert in the business domain. Is this still possible now?

yes

we are capable of understanding the business domain

not everyone in the team needs to

fuzzy problems: what are the metrics for success? (eg. google ads = ratio value of keywords, not hard to understand)

hard domain: particle physics -> teach physicists to be programmers