"Modern" agile

Talk done at Spotify for the whole CSAT Tribe.
The goal was to reflect "agile" beyond the current mainstream, too focused on Scrum and tools.
Some topics discussed: Lean, Kanban, eXtreme Programming, #NoEstimates, technical excellence (TDD, pair programming), trunk-based development, MVP, simplicity, etc.

Transcript

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

   View Slide

2. Disclaimer
   

   View Slide

3. View Slide

4. View Slide

5. What is “agile”?
   

   View Slide

6. 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”
   

   View Slide

7. eXtreme Programming (2000)
   

   View Slide

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

   View Slide

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

   View Slide

10. 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.
    

    View Slide

11. 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”
    

    View Slide

12. “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
    ●
    

    View Slide

13. Agile
    Scru
    m
    Kanban Lean
    NoEstimate
    s
    XP
    SW crafters
    

    View Slide

14. 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
    

    View Slide

15. ● Avoid silos
    ● Avoid bottlenecks
    

    View Slide

16. ● 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
    

    View Slide

17. 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
    

    View Slide

18. Pair/mob programming BY
    DEFAULT
    Cowboy/cowgirl
    mode
    

    View Slide

19. 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
    

    View Slide

20. 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
    

    View Slide

21. No need for on-call (seriously)
    

    View Slide

22. Distributed team
    “One in remote, all in remote”
    

    View Slide

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

    View Slide

24. “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 :-(
    

    View Slide

25. 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
    

    View Slide

26. 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
    

    View Slide

27. 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...
    

    View Slide

28. View Slide

29. View Slide

30. 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
    

    View Slide

31. 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
    

    View Slide

32. 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)
    

    View Slide

33. #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…
    

    View Slide

34. Collective ownership of the
    PRODUCT
    

    View Slide

35. 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)
    

    View Slide

36. 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
    

    View Slide

37. View Slide

38. View Slide

39. View Slide

40. Alternative to estimates
    

    View Slide

41. View Slide

42. View Slide

43. #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
    

    View Slide

44. 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
    

    View Slide

45. 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 :-)
    

    View Slide

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

    View Slide

47. 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.
    

    View Slide

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

    View Slide

49. 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
    

    View Slide

50. 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
    ●
    

    View Slide

51. 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)
    

    View Slide

52. 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)
    

    View Slide

53. 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/
    

    View Slide

54. 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)
    

    View Slide

55. Books for mastering your craft
    (I)
    

    View Slide

56. Books for mastering your craft
    (II)
    

    View Slide

57. Books for mastering your craft
    (III)
    

    View Slide

58. Books
    

    View Slide

59. Books
    

    View Slide

60. Books
    

    View Slide

61. View Slide

62. Thanks for the feedback!!
    https://islomar.typeform.com/to/okWW69
    

    View Slide

63. View Slide