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

Hyper Agylity - way of working based on hackathons

Hyper Agylity - way of working based on hackathons

Telefonica Developer Conference 2016. This presentation shows how hackathons can be applied to software projects to exhibit Agility.
From Agile methods today to the root of what developing software should be about : programming.

53eaf4a8485500cb61099a1286e230e3?s=128

Ruben Gonzalez Blanco

June 07, 2016
Tweet

More Decks by Ruben Gonzalez Blanco

Other Decks in Programming

Transcript

  1. HYPER-AGILITY? A Way of Working based on Hackathons

  2. This presenta7on is a Defense Statement PROGRAMMERS AND PROGRAMMING

  3. Digital World is based on SoEware

  4. SoEware is Programmed

  5. But the Industry, specifically Enterprises, do not know how to

    deal with soEware programming
  6. Dealing with SoEware - Evolu7on SoEware Crisis So6ware Engineering No

    Silver Bullet Agile Manifesto Cra6smanship Manifesto CraEing Incremental 1960 1970 1980 1950 1990 2000 2010 Waterfall Itera7ve Rapid Prototyping CMM Evolu7onary Agility?
  7. We never reach “Plateau of Produc7vity” hZps://en.wikipedia.org/wiki/Hype_cycle

  8. Trough of Disillusionment with “Agile” AGILE is DEAD DARK SIDE

    OF AGILE hGp://programming-motherXYZ.com/ Dave Thomas hZps://pragdave.me/blog/2014/03/04/7me-to-kill-agile/ PROGRAMMING MOTHER FXYZ
  9. The problem we have (I think): NOT A MATCH create

    systema7c approaches = “Procedures” and “Methodologies” for developing soEware
  10. Insights about SoEware Development

  11. INSIGHT 1 SoEware Development is about PROGRAMING SOFTWARE Implies Wri7ng

    Code/ Deploying /Running / Tes7ng
  12. PROGRAMMING !!!! EVERYTHING ELSE IS SUPPORTING

  13. ProvocaTon : If you do not PROGRAM then your role

    is not Fundamental when it comes to create products and services based on soEware Probably your role is important, but not fundamental Managers UX Designer Analysts Solu7on Architects Business Developers …
  14. FACTS A team made of Managers, Analysts, UX Designers, Solu7on

    Architects… etc can define a Product based on soEware, but they can not deliver it … EXCEL PPT VIDEO UI SKETCH PAPERWARE
  15. FACTS A team made of So6ware Programmers only, can define

    and deliver a Product based on SoEware Google Facebook TwiZer SOFTWARE Florian Weber Jack Dorsey tw#r facemash Mark Zuckerberg googol Sergey Brin Larry Page
  16. INSIGHT 2 SoEware execu7on is Uncertain CAN NOT BE PREDICTED

    (by humans)
  17. HW calcula7on power is higher than Humans Picture: from Hans

    Moravec 1997, When will computer hardware match the human brain? hZp://www.transhumanist.com/volume1/moravec.htm
  18. INSIGHT 3 SoEware programming is a CreaTve ac7vity

  19. OBSERVING A PROGRAMER

  20. ISRF cycle Inten7on Realiza7on Feedback Synthesis Idea Coding Running Tes7ng

  21. OBSERVING AN ARTIST

  22. ISRF cycle Inten7on Realiza7on Feedback Synthesis Idea Pain7ng Picture Evalua7ng

    (by seeing)
  23. The Ar7st aZributes Knowledge Mastery Talent Mo7va7on Crea7vity Inspira7on Passion

    Genius The SW Programmer
  24. INSIGHT 4 SoEware has Structure and Run-Time behavior

  25. Perhaps SoEware is like Music Structure and Dynamic (Tme) dimensions

  26. Program vs Pentagram

  27. Computer vs Music Player

  28. Programming vs Composing

  29. Perhaps Programming SoEware in a Team is like Jazz Original

    Dixieland Jass Band Melodies are improvised/created on top of a shared Harmony created by a composer (so?ware architect) Everybody is a Composer The Harmony (architecture) provides consistency
  30. New Job 7tle: SoEware Composer

  31. INSIGHT 5 SoEware Programming is full of Complexity Inherent complexity

    RelaTve to the Problem/Hardware Accidental complexity created by Humans
  32. Provoca7on: You, Programmer, can easily be an Accidental Complexity generator

    Libraries, Frameworks, Technologies, Paradigms, Style, Tools, …
  33. INSIGHT 6 Both the Problem and its SoluTon have to

    be figured out at the same 7me!! Both Problem definiTon and one of its SoluTon EMERGE in parallel
  34. INSIGHT 7 Plans, Designs, Specs must be treated as INTENTIONS

  35. INSIGHT 8 A SoEware Program is a form of Knowledge

    Reflects the prac7cal understanding of Problem and one of its Solu7ons
  36. SOFTWARE CODE = ASSET

  37. INSIGHT 9 SoEware Development requires humans (PROGRAMMERS) with a lot

    of knowledge, crea7vity and passion
  38. INSIGHTS SUMMARY 1.  SoEware development is about Programming !!!! 2. 

    SoEware program execu7on is uncertain 3.  SoEware programming is a creaTve ac7vity 4.  SoEware has structure and dynamic (runTme) dimensions 5.  SoEware development is full of complexity 6.  Both the problem and a soluTon have to be figured out in parallel 7.  Requirements, Plans, Designs must be treated as IntenTonal 8.  SoEware code is a Form of Knowledge (code is an asset) 9.  SoEware development requires high skilled, high knowledge, crea7ve and passionate PROGRAMMERS
  39. We need a way of working centered on Programming

  40. hZp://www.wired.com/2012/02/ff_hackathons/all/1 A hackathon (also known as a hack day, hackfest

    or codefest) is an event in which computer programmers and others involved in soEware development and hardware development, including graphic designers, interface designers and project managers, collaborate intensively on so6ware projects
  41. Observing a Hackathon: Exhibits True Agile Values

  42. Applying hackathons to your projects HACKING SCRUM AN EXAMPLE OF

    HOW WE HAVE HACKED SCRUM IN MY TEAM
  43. Typical Sprint Planning: The Theory

  44. Typical Sprint Planning: The Prac7ce TOOLS and PROCESSES

  45. From Sprint Planning to Sprint Hackaning No Sprint “Planning” ,

    instead start with a Hackathon (2-3days) that delivers a MVP (working soEware) Sprint Hackaning Sprint Planning
  46. The Sprint Hackaning delivers a real MVP (working soEware) that

    is grown and hardened over the next days and weeks M T W T F Hackathon M T W T F ISRF Cycles RELEASE 0 MVP S S Growing and/or Hardening(features, architecture, design, quality) Hackaning
  47. From Daily Mee7ngs to Direct CollaboraTon (Avoid most of the

    typical Mee7ngs)
  48. only 1 Weekly Review

  49. Weekly Review To Release or not To Release

  50. From Planned Sprints to MicroSprints (Weekly) (make soEware emerge) M

    T W T F S S M T W T F S S M T W T F S S …. …. M T W T F S S M T W T F S S MSP-N Week1=MSP1 MSP2 MSP3 MVP Hackathon Weekly Review Weekly Review Weekly Review RELEASE M T W T F S S Delivery Hackathon MSPN-1 MVP RFS MVP Hackathon MVP •  Release docs •  Checkout, Install, Run •  Opera7on procedures •  Set Context •  Targets & Priori7es •  Issues & Risks This is an Example!!!
  51. Hacking + Growing AND/OR Hardening M T W T F

    S S M T W T F S S M T W T F S S …. …. M T W T F S S M T W T F S S MSP-N Week1=MSP1 MSP2 MSP3 MVP Hackathon Weekly Review Weekly Review Weekly Review RELEASE M T W T F S S Delivery Hackathon MSPN-1 MVP RFS MVP Hackathon MVP Growing Hardening Growing and Hardening Hacking This is an Example!!!
  52. Type of Hackathons (Sample) •  MVP Hackathon •  Integra7on Hackathon

    •  DevOps Hackathon •  Architecture Hackathon •  … Uncertainty? Hackathon!!!
  53. From Control Roles to Suppor7ng Roles From Product Owner to

    Customer/User Proxy From Program Manager (Control) to Program Facilitator From Architect to others programmers Enabler
  54. Making the soEware Emerge in an “environment” not aware of

    SoEware
  55. Making the soEware Emerge in an “environment” not aware of

    SoEware
  56. Making the soEware Emerge in an “environment” not aware of

    SoEware ISOLATION/TRANSLATION LAYER ROADMAP LAYER (PROGRAMMING CENTERED) Business Stakeholders Customers ENABLING LAYER Tech Architects Release Management Opera7ons Program Management Business Development Product Management Tools Solu7on Architects
  57. Remember: PROGRAMMING !!!! EVERYTHING ELSE IS SUPPORTING

  58. Remember

  59. None