A brief and personal history of the software development process

Scrum has more than 20 years, the Agile Manifesto is 16 years old, DevOps has been around for 8 and we are living in the post-Agile era. Most tech key players are going public with their takes on how they do stuff, lessons learned turned into best practices. In spite of all this, every time I talk to people I always get sentences like: "...and then it went into the test phase and stayed there for months...", "The ops team is always chasing after some fire when I need them.", "The dev guys take us for janitors to keep cleaning this s*** in production...", "That Agile/DevOPS/Automation thing would not work here we are too big/small/complex...". The same problems over and over again.

The subject itself is old and has been discussed a lot. The insight I expect to bring is that, it is not about what you do, the sequence of steps you take to do something. But a lot more about how you do it, the attitude you put into it. Organizations must change to become more customer responsive, just adopting agile processes is makeup. The process you use to deliver something is a consequence of who you are and not the opposite. My professional experience will be driving the talk on how circumstances, business nature and context influences the development process and not the other way around.

Talk given at Pixels' Camp 2017

Transcript

1. A brief and personal history of the software development process João Malcata @ Intersection Ventures Dad, software engineer, telco, cybersecurity, web, and OSS. ~20 years using tech to build products, teams, and processes. Dude, 1st slide playing the dad card already!
2. Why • …condemned to repeat it • understand • see options • promote change • career move • the speaker is a friend don’t care if it’s a crappy talk* Disclaimer: no harm was done to ”agile”, “scrum” and other similar species during the conception of the talk
3. Why not • My precious time • Too dense • Bad accent • Don’t care • Momma said so • (good luck trying to read this) Galaxy: Context Galaxy: Practices Galaxy: Advantages/shortcomings Galaxy: Personal Insights
4. Scenario #1 - “ad hoc” end of XX century Pre-products bad customers scope creep customer feedback loop no best practices code as craft pre-bubble no formal tests apparent speed no definition of done short lived code ownership mature customers great “changing the world” customer-centric Value-base pricing innovative Iterative love the impact bipolar no progress hate error repetition high attrition rate dot-com startup
5. Scenario #2 - “waterfall” telecom IT demand mng feature freezes cross-app development cascade design concurrent waterfall cycles cost control ~4 releases / year not over ‘til it’s over design early sign off scope changes are unwelcome complex acceptance IT consolidation ITIL SOA all or nothing by application area little mobility OSS as the antichrist perf. recognition a specialist dream manual tests silos unified acceptance “huge” budget think small delivery risk slowly becoming furniture… occasional challenge
6. Scenario #3 - “waterfall++” cost rationalization consulting “slow and expensive” post-mortem joint architecture 21+ docs / project ADM 3 estimation methods tech debt growth disengaged resources metrics based penalties offshore team change requests predictable and reliable estimation gates not SW devel anymore “manage” everything powerless to change clear career path “industrial“ code locked rates CMMI Issue / risk mgmt up to strong adversity kills innovation feels low tech
7. Scenario #4 - “continuous integration” startup product code ownership standups API driven module packaging SaaS app deploy automation low backlog slow new environments slow onboarding small tech team same day hot fixes little red tape test automation + repetitive future proof timeboxing product team marketing releases design sign off internationalization new products? low attrition product expert tech as investment
8. Scenario #5 - “continuous deployment” cloud era startup code review gate top down arch automation over documentation scaleup ephemeral teams fail fast fast onboarding legacy freeze fix fast SaaS n daily deploys activity based cost week plan intra mobility fast pace no reengineering much rework talent shortage US tactical design beta features feature toggles product evolves fast Tech community aligned OSS
9. Key Dimensions • End user distance (degrees) • Empowerment & Trust • Risk & Learning • Decision making • Outsourcing & offshoring • Short term vs Long term • Hierarchy (who gets promoted?) • Tech vs IT • Size • ”Culture” sets the pace
10. Takeaway Not about what you do, the sequence of steps you follow. But, who you are and the attitude you put into everything you do. Organizations must change to become more customer responsive and deliver more value. Back to Culture.
11. Also, for the occasional rant and questions: Q & A @malcata @malcata (no way!) joao.malcata @ intersection.ventures @malcata (see a pattern?) ☑ Plant a tree ☑ Have a child ✅ Do a talk