"Modern" agile - Speaker Deck

Slide 1

Slide 1 text

“Modern” agile CSAT Lunch & Learn, 15.11.2018 @islomar

Slide 2

Slide 2 text

Disclaimer

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

What is “agile”?

Slide 6

Slide 6 text

Scrum (1986?) “The New New Product development game” (Hirokata Takeuchi, 1986) OOPSLA 1995: presented by Jeff Sutherland and Ken Schwaber The Scrum guide (November 2017): ● It’s a FRAMEWORK (not a methodology, not a method) ● Only mentions “software” as one of several contexts (“for developing, delivering, and sustaining complex products”) ● Values, team, events, artifacts, DoD. ● Push system Best book ever about Scrum: “The people’s Scrum”

Slide 7

Slide 7 text

eXtreme Programming (2000)

Slide 8

Slide 8 text

Agile manifesto (2001) http://agilemanifesto.org/principles.html

Slide 9

Slide 9 text

… and more... ● Crystal (Alistair Cockburn) ● FDD (Feature-Driven Development)

Slide 10

Slide 10 text

What is “agile” for me? 1. People first a. Antimatter principle (Bob Marshall): “Attend to folk’s needs” 2. Risk management a. “Inspect and adapt”... so fast as possible.

Slide 11

Slide 11 text

Spotify Engineering Culture (2014) Spotify Engineering Culture (Henrik Kniberg 2014) “However, a few years later, we found out that some of the standard Scrum practices were actually getting on the way, so we decided to make all this optional”

Slide 12

Slide 12 text

“Modern” agile real case ● 15 years old company (Telecommunications sector) ● Company with VERY positive EBITDA ● “Huge” codebase (33 µservices, 80 customers, ~2.500 containers in Prod) ● 25 people in the whole company ● Engineering team: 6-8 people ●

Slide 13

Slide 13 text

Agile Scru m Kanban Lean NoEstimate s XP SW crafters

Slide 14

Slide 14 text

Mission, Vision, Values... Values come first… … then the principles… … and THEN the practices IO Vision 2018 (Operations Tribe): based in Google re:Work ● Core Values, Purpose, Vision, Strategy, Goals

Slide 15

Slide 15 text

● Avoid silos ● Avoid bottlenecks

Slide 16

Slide 16 text

● The product is a consequence of the team. ● The goal is not to create a product, but to create a team who can handle the/any product

Slide 17

Slide 17 text

Communication is KEY ● Talks, workshops and sessions to improve our communication skills: ○ Feedback ○ Non Violent Communication ○ Writing ● Feedback given every month (besides retrospectives): ○ everybody gives feedback to everybody in an open and transparent way ○ Simple Spreadsheet, matrix based on our values and other topics (e.g. business- orientation) ● Retrospectives: ~ 1 - 1.5 hours ● Investing in time for synchronizing and communicating is the

Slide 18

Slide 18 text

Pair/mob programming BY DEFAULT Cowboy/cowgirl mode

Slide 19

Slide 19 text

TDD/BDD/ATDD for the win!! ● TDD/BDD by default. ● It's not (only) about testing, but about FOCUS and KISS. ● Simplicity, flow, quick feedback... ● Though not always was done. Some exceptions: ○ Spikes ○ Legacy code where it was not so easy to understand things

Slide 20

Slide 20 text

Aiming for Technical excellence ● 4 rules of simple design (test, reveal intent, DRY, less is more) ● Clean code, refactoring, scout rule. ● SOLID principles, Object calisthenics, DRY, KISS, DAMP, etc. ● Design patterns ● Hexagonal/onion/clean architecture ● TDD/BDD (“Interaction-Driven Design”) ● Continuous learning culture: ○ talks, meetups, conferences, coding dojos, books, videos, etc. ○ 20% of our time (every Friday) ● DELIBERATE PRACTICE: ○ You won’t improve much as a SW Eng. just coding at work N hours/day

Slide 21

Slide 21 text

No need for on-call (seriously)

Slide 22

Slide 22 text

Distributed team “One in remote, all in remote”

Slide 23

Slide 23 text

Your own space ● Whiteboards around ● Monitor with dashboards ● No need to worry about bothering other squads ● Communication

Slide 24

Slide 24 text

“Radical” transparency ● One of our values as a team: taken VERY seriously ● Feedback: open, everybody to everybody ● No private conversations to “convince” someone or “win allies” for anything ● Or not so radical: not open salaries :-(

Slide 25

Slide 25 text

Branching strategies 1. No Version Control System (VCs) at all: floppy disks. 2. CVS 3. SubVersion a. Creating a branch was highly costly 4. Git a. Feature branching: https://martinfowler.com/bliki/FeatureBranch.html b. GitFlow i. Master, Develop, Feature, Release and Hotfix branches

Slide 26

Slide 26 text

Why do people do Pull Requests? ● For feeling safer ○ Peer review: Someone else can take a look to it and detect problems ● For rising the code quality (e.g. design solution) ● For sharing/spreading knowledge ● For getting the control: ○ "Safe" way to accept contributions from other people/teams

Slide 27

Slide 27 text

Problems with Pull Requests ● It completely breaks the flow ○ You are NOT doing Continuous Integration, let alone Continuous Delivery/Deployment ○ You better wait for that PR to be merged before creating a new one… or fight with Git ● It’s too late: ○ Someone already worked several hours (days?) on it. Waste. ● You don’t have the context of the person for every decision made ● Review hundreds of lines and tenth of files… are you kidding? ● Merge race...

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

Trunk-based development for the win!! ● Pushing to Master. Yep. Mean it when saying “Continuous Integration”. ● It's not about PR vs TBD... ● ...but about PR vs TDD + Pair programming + TBD ● If you don't trust your code enough… then you know where to focus ● Still branching: ○ Spike, too much uncertainty: ■ Done 3-4 times in 2 years ■ After the spike, start from scratch with the new knowledge in master

Slide 31

Slide 31 text

Some other important practices (not only) for TBD ● Canary releases ○ https://martinfowler.com/bliki/CanaryRelease.html ○ First, deployed only to some representative environment ● Feature toggles (a.k.a “feature flags”) ○ https://martinfowler.com/articles/feature-toggles.html ● Parallel changes ○ https://martinfowler.com/bliki/ParallelChange.html ○ Feature toggle ○ Branch by abstraction ○ Postel’s law: “Be conservative in what you do, be liberal in what you accept from others” ○ Strangler Application ○ Anti-Corruption Layer

Slide 32

Slide 32 text

When do pull requests make sense? ● Distributed team with very different time zones ○ Not really possible to do pair programming ● For some exceptional reason, someone worked on their own (though we usually made code reviews in local instead of PR)

Slide 33

Slide 33 text

#NoLabels ● No QA, Architect, Technical Lead, Tech Owner nor any other distinction ● Role !== Position ● The only “label” (not officially): one person more focused on product (~PM) ● Engineering FLAT team: “specialized generalist”, T-shape ● No boss, no project manager, no Scrum Master, no Agile Coach…

Slide 34

Slide 34 text

Collective ownership of the PRODUCT

Slide 35

Slide 35 text

Lean-Kanban style ● Visualize EVERYTHING in a Trello board ○ E.g. also the action from the retros. ● Limit WIP ○ Little’s law ■ Throughput time = flow units in process x cycle time ■ Cycle time: average time between 2 slow units ● Avoid waste ● Lead time, Cycle time, Cumulative flow, throughput ○ Disclaimer: we didn’t measure it… we didn’t “need” it ● Flow efficiency vs Resource efficiency ● Pull, not push (Sprint)

Slide 36

Slide 36 text

Estimations ● Man-days (sorry) ● Ideal man-days ● Ideal man-days weighted (technology, complexity, etc.) ● Story points ● T-shirt sizes ● Yesterday’s weather ● Monte Carlo simulation ● Throw dice

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Alternative to estimates

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

#NoEstimates Most of the time, estimations are not REALLY needed (usually because someone else asks for it). In 2 years, we “estimated”... 2, 3 times? Alternative? ● Split in small chunks. Really small. What’s the most simple thing that we can build next, so that we can learn and deliver some value? ● Talk a lot. Clarify very well expectations, uncertainties, etc. ● Prioritize continuously. ● Limit WIP

Slide 44

Slide 44 text

Some more things... ● Some tools like “Story mapping” can help ● If you really “need” to measure something… go Lean: ○ count “stories” ○ Cumulative flow ○ Lead time ○ Cycle time

Slide 45

Slide 45 text

MVP… SERIOUSLY ● From both the business and technical point of view ● Evolutionary design. ○ Example with new product persistence: first InMemoryRepository, then File, then Postgres. ○ A monolith is OK at the beginning… and probably for a (very) long time :-)

Slide 46

Slide 46 text

First, make it work … then, make it right … then, make it fast … then, scale it

Slide 47

Slide 47 text

How to determine salaries without a boss? ● No open salaries :-( ● https://management30.com/practice/merit-money/ ● Poker chips: https://medium.com/coding-stones/reparto-de-pasta-con-conversaciones-2c4 661338e8 ● Self setting salaries: ○ https://blog.makersacademy.com/self-setting-salaries-1851aacbe4bc ○ http://www.businessinsider.com/how-zappos-determines-salaries-in-holacracy-2015-7 ● No long term solution. Short term: formula for raising more those with lower salaries.

Slide 48

Slide 48 text

Offboarding https://medium.com/@raulvillares/retrospectiva-de-despedida-5568290f 3799

Slide 49

Slide 49 text

Things to be improved ● No Continuous Deployment, "only" Continuous Delivery ● Lost of service for 10 seconds in the website (no Blue-Green deployment) ● Not enough rotation in pairing ● Not all the company was “so agile” ● Missing architecture documentation ● Missing company-wide retrospectives

Slide 50

Slide 50 text

Main key points (I) ● KISS / MVP: think about the business/customer... ● Technical excellence AS IF YOU MEAN IT: e.g. TDD, SOLID, clean code… ● Pair/mob programming by default ● Trunk-based development by default ● Continuous Delivery/Deployment ●

Slide 51

Slide 51 text

Main key points (II) ● Investing lots of time communicating and synchronizing ○ No silos ○ It really pays off in the long term ● Radical transparency ● LONG TERM VISION: probably you need to slow down temporarily… to keep a good long term sustainable pace (without suffering)

Slide 52

Slide 52 text

Resources ● NoEstimates ○ https://www.industriallogic.com/blog/stop-using-story-points/ ○ https://blog.jbrains.ca/permalink/a-farewell-to-noestimates ○ #NoEstimates (Allen Holub) ○ The State of NoEstimates (Woody Zuill)

Slide 53

Slide 53 text

Resources ● Trunk-based development ○ https://www.infoq.com/news/2018/04/trunk-based-development ○ Escape merge hell: why I prefer TBD over feature branching and GitFlow ○ https://www.continuousdeliveryconsulting.com/blog/organisation-antipattern-integration- feature-branching/ ○ http://kean.github.io/post/trunk-based-development ○ https://trunkbaseddevelopment.com/

Slide 54

Slide 54 text

Resources ● https://martinfowler.com/articles/agile-aus-2018.html ● https://jeronimopalacios.com/kanban/ ● https://benjiweber.co.uk/blog/2015/04/17/modern-extreme-programming/ ● http://manifesto.softwarecraftsmanship.org/ ● The speed vs quality fallacy discussion ● 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development (JBrains)