Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile (mucho) más allá de Scrum

Agile (mucho) más allá de Scrum

Charla dada en Alicante el 21 de mayo de 2019: https://www.meetup.com/es-ES/AgileAlicante/events/260459256/

Isidro López

May 21, 2019

More Decks by Isidro López

Other Decks in Programming


  1. Agenda 1. Disclaimers 2. ¿Qué es “agile”? 3. Contexto de

    la empresa y el equipo de desarrollo 4. Interacción con negocio 5. Principios y prácticas “internas” del equipo 6. Hall of shame 7. Conclusiones y recursos recomendados 8. Debate grupal
  2. Ego slide Hemos venido a jugar... Desarrollador de software @islomar

    [email protected] <titulitis> Teleco, Antropología Social y Cultural, Executive MBA, CSM… </titulitis>
  3. 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” (Tobias Mayer)
  4. Algunas aclaraciones sobre Scrum • No “User stories”, but “Product

    Backlog Items” (PBI) ◦ Origen de las US: eXtreme Programming!!! (1998) • “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;”. E.g. QA, architect, tech lead, etc. • Sí se mencionan las estimaciones, pero ningún método concreto (no “story points”) • No dice que solo se pueda/deba entregar/desplegar al final del sprint...
  5. 19 Kent Beck (XP) Mike Beedle (Scrum) Arie van Bennekum

    (DSDM) Alistair Cockburn (Crystal) Ward Cunningham (XP) Martin Fowler (XP) James Grenning (XP) Jim Highsmith (ASD) Andrew Hunt (PP) Ron Jeffries (XP) Jon Kern (FDD) Brian Marick Robert C. Martin (XP*) Steve Mellor Ken Schwaber (Scrum) Jeff Sutherland (Scrum) Dave Thomas (PP) https://twitter.com/eferro
  6. 20 “I learned from Jeff Sutherland that the first Scrum

    actually did all the XP practices. But Ken Schwaber convinced him to leave the engineering practices out of Scrum, to keep the model simple and let the teams take responsibility for the tech practices themselves. Perhaps this helped spread Scrum faster, but the downside is that a lot of teams suffer because they lack the technical practices that enable sustainable agile development.” “Scrum and XP from the Trenches” Henrik Kniberg https://twitter.com/eferro
  7. 21 “You don’t see high performing Scrum teams without XP

    engineering practices. It is difficult to scale XP teams without Scrum and Scrum solves the management interface issues for XP. Be careful about doing pieces of anything and calling it Agile.” “Deep Agile course” Ron Jeffries and Sutherland https://twitter.com/eferro
  8. 22 “eXtreme Programming is an ideal many software shops would

    love to reach, but with the constant pressures to produce software quickly, they cannot actually implement it. ... This book shows readers how to use SCRUM, an Agile software development process, to quickly and seamlessly implement XP in their shop-while still producing actual software.” “Agile Software Development with Scrum” Ken Schwaber and Mike Beedle https://twitter.com/eferro
  9. 23 “There's a mess I've heard about with quite a

    few projects recently. It works out like this: • They want to use an agile process, and pick Scrum • They adopt the Scrum practices, and maybe even the principles • After a while progress is slow because the code base is a mess” “Flaccid Scrum” Martin Fowler
  10. … and more... • Crystal (Alistair Cockburn) • FDD (Feature-Driven

    Development) • DSDM (Dynamic Systems Development Method) • etc...
  11. ¿Qué es “agile” para mí? 1. People first a. Antimatter

    principle (Bob Marshall): “Attend to folk’s needs” 2. Gestión del riesgo a. “Inspect and adapt”... so fast as possible.
  12. Contexto de la empresa (2015-2017) • Fundada en 2002, 17

    años de antigüedad (sector de Telecomunicaciones) • Desarrollo de producto • Empresa con EBITDA muy positivo • ~ 20-25 personas en toda la empresa (ahora ~ 35 personas) • Equipo de desarrollo: 6-8 personas (ahora ~ 11 personas) • “ENORME” base de código (33 µservicios, 80 clientes, ~2.500 contenedores en Prod)
  13. Estos son mis valores. Si no le gustan, tengo otros

  14. ¿Cómo se decide en qué se trabaja? Cultura del Patinete

    en la empresa http://blog.crisp.se/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-08.20.00.png Simplicidad Feedback
  15. Sin estimaciones en general ¿Cómo se decide en qué se

    trabaja? http://6.fotos.web.sapo.io/i/o2806a3ac/18197719_O8Ukt.jpeg Confianza Comunicación Simplicidad Transparencia
  16. Mínimo para varios clientes ¿Cómo se decide en qué se

    trabaja? https://i0.wp.com/autismodiario.org/wp-content/uploads/2014/06/positivo-negativo.jpg?resize=300%2C199&ssl=1 Simplicidad Valentía
  17. xDD ∀x ∈ {T, B, Ñ, etc.} Comunicación Simplicidad Feedback

  18. ¿Por qué se trabaja con Pull Requests? • Para sentirnos

    más seguros ◦ Peer review: Someone else can take a look to it and detect problems • Para mejorar la calidad del código (e.g. design solution) • Para compartir y extender el conocimiento • Para tener control sobre lo que otras personas hacen: ◦ Modo “seguro” de aceptar contribuciones de otras personas/equipos
  19. Problemas con las 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...
  20. 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 + parallel changes +.. • 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 • I forgot git complexity: only needed pull and push commands :-)
  21. ¿Cuándo pueden tener sentido las PR? • Equipos distribuidos en

    diferentes zonas horarias ◦ No es posible hacer pair programming • En casos excepcionales en que alguien trabajó solo (mejor hacer code review en local, no en PR)
  22. More 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 (plu TDD, feature toggle, etc.) • Continuous Delivery/Deployment • Kanban: pull system with continuous flow
  23. More 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)