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 as a temporary tool to break old habits and form 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