Slow Down To Go Faster

I can call it as the version 1.1 of my "Slow Down to Go Faster" talk. Here is the abstract:

Software development has evolved so quickly throughout the years. New tools, methodologies, practices, even new disciplines and principles have been introduced. From single individuals to tens of inter-connected development teams, from co-located teams to fully-remote distributed teams, software development professionals have developed new ways of doing their professions to achieve one single target: Building successful products.

Regardless of the technologies we use and the structures we build, our biggest challenge remain still: Catching deadlines, building high-qualified software that lasts long and being in the market earlier than our competitors. Going fast without control could be the biggest enemy of software development. After working as Agile Practice Lead for years and touching hundreds of teams in my career, I now believe the only way to go fast is going slow efficiently.

Going slow could destroy your career, your product, even your company, but it is the only way to go faster to succeed. In this talk, you will learn:
* how to build a development culture that builds software faster than ever.
* the principles and techniques behind slowing down under control.
* the myths and fallacies of development practices and the realities behind.
* real life examples of establishing an environment for efficient continuous delivery.

By the end of the talk, you will be able to know how you can change the way you and your team should work to go faster than ever.

Transcript

1. to go faster slow down PRACTICES TO BUILD SOFTWARE FASTER THAN EVER LEMi ORHAN ERGiN co-founder @
2. being fast is vital not only being first on the market is important, but also responding to customers by adding new features and eliminating bugs fast keep customer satisfaction high. in so!ware world
3. but we all have a problem with speed we assume going faster and smarter and efficiently is related with giving deadlines for the targets. we think that we go faster by working more and with more people. therefore we either add new people or do overtime to gear up production.
4. rushing makes us neither faster, nor more productive rushing increases stress, distracts focus and destroys productivity. we need creativity, effectiveness, and focus instead.
5. so!ware development is damn hard & complex we cannot get rid of complexity. we have to live with it. the need for speed creates an unstable, unsustainable environment, makes us stressed, less focused and less productive. it just don’t work.
6. incompetence is reality deadlines ignores delivery times have direct dependency with people, the efficiency of processes and the quality of output. and developers give deadlines for themselves, without any real need. are imaginary team capacity velocity estimation deadline masterplan fixed hours
7. we got legacy so!ware and inefficient processes the pressure of deadlines combining with incompetency leads to legacy so"ware, the dead-end for a working so"ware. at the end of the day
9. SLOWING DOWN the only way of going faster with sustainable pace is
10. Professionalism 
 and Craftsmanship Adaptation and Efficiency Automation and Quality 3 MAIN AREAS OF SLOWING DOWN PEOPLE PROCESS PRODUCT
11. 3 MAIN AREAS OF SLOWING DOWN PEOPLE PROCESS PRODUCT 13 practices to slow down, take a deep breath and invest on mastery
12. hire better talents Talent hiring is the most critical function in your company Look for passion, discipline and motivation Do not allow ego enter the team, always be an apprentice Never work with genius jerks and lovable fools. Work with doers. Prepare a craftsmanship roadmap for all developers Do not believe in titles. Never! Make them believe what you believe Model the behavior you want to see PEOPLE 1
13. Tech Marketing INCEPTED Job Interviews INTERVIEW ED Position Offering OFFERED Initial Onboarding STARTED Pre-Arrival Preparations ARRIVAL Long Time Onboarding ONBOARDED Apprenticeship CRAFTSMAN Mastering 
 Practices FOREMAN
14. do together Never allow silos to occur Do in pairs and mobs, review together Sit together, closely Let the responsibility shared Define team standards PEOPLE 2
15. practice together Organize code retreats, radoris and coding dojos Spend 30 mins of each working day for practicing Force yourself to use shortcuts, and console Dedicate time for open source software and communicate with the community PEOPLE 3
16. PEOPLE learn together Organize Brown Bag / Lunch & Learn Sessions Organize lightening talks, open space meetups Be a speaker and give back to the community Document what you have learnt to a central wiki Invest in yourself, spend time and money for your career 4
17. PEOPLE collect feedback Visualize progress, and current status Gather feedback via Team & Grand Retrospectives Have kudo-walls to share positive feedback Ask for feedback, do not wait from people Learn how to give negative & positive feedback Share SDLC metrics and information radiators 5
18. PEOPLE improve together Facilitate retrospective meetings Search for better ways of doing your job Switch your pair if you feel you do not improve yourself Share links, posts, videos with your colleagues Question your beliefs, publicly Define definition of fun together with your team 6
19. do plan and revise often Plans are nothing, but planning is everything Create multi feedback loop channels, like review & demo Never give up daily alignment Have short iteration length Define short term goals and long term purposes Focus on products, not projects PROCESS 7
20. collect data and analyze Visualize processes, successes and failures Monitor SDLC, CI/CD metrics Allow every developer access product & code metrics Improve your domain knowledge and analyze processes regularly Make decisions based on data, not gut feelings PROCESS 8
21. PROCESS eliminate waste Detect waste in the office, in code and in processes Follow the boy scout rule Obey your definition of done and eliminate 99% done tasks Never allow long living branches Do not verify your code by manual testing Developers documents a world unintentionally 9
22. push the defects down Stop building the features and focus to eliminating bugs Fix bugs after reproducing via tests Continuous bug fixing and support: Batman and Robin Use pull requests and master code review capabilities Never deploy unreviewed code to production PRODUCT 10
23. release frequently Commit early, commit often, perfect later, publish once Trunk based development with Feature Toggling Devops is not having a cloud expert in team, know it Version everything, everything you write Decrease the need for manual testing PRODUCT 11
24. PRODUCT
25. test first and refactor Develop by TDD, have just enough tests and simple design Stop calculating code coverage Use 20% of time for eliminating technical debt Delete your brittle tests, rewrite tightly coupled code Multi level testing helps you validate functionalities Mono repository is for refactoring PRODUCT 12
26. PRODUCT HELL DEPENDENCY OF MICROSERVICES
27. PRODUCT
28. ports business adapters mysql adapter stripe adapter rest api web ui domain
29. ports adapters domain 3rd party apps command line soap calls admin gui batch jobs mobile apps other hexagons cache provider elastic search mail server database sms provider message queue other hexagons business mysql adapter stripe adapter rest api web ui
30. ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business
32. a SEARCH
33. a c SEARCH PAYMENT
34. c a SEARCH PAYMENT ACCOUNT
35. keep your design simple Any design decisions taken before it is required is wrong Yeah, microservices are great. But are you ready for it? Loosely coupled, high cohesive designs by Ports & Adapters Stop doing big upfront-design Follow the 4 rules of simple design PRODUCT 13
36. PEOPLE PROCESS PRODUCT
37. Professionalism 
 and Craftsmanship PEOPLE hire better talents do together practice together learn together collect feedback improve together Adaptation and Efficiency PROCESS do plan & revise often collect data & analyze eliminate waste Automation and Quality PRODUCT push defects down release frequently test first & refactor focus on simple design
39. Working software does not have to be well-crafted. Only good professionals can build well-crafted software. Only well-crafted software lets you build features faster than ever.
40. @lemiorhan LEMi ORHAN ERGiN Working software does not have to be well-crafted. Only good professionals can build well-crafted software. Only well-crafted software lets you build features faster than ever.