Slow Down To Go Faster Than Ever, But How?

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.

----
I presented it as the keynote talk at GrowIT Conference 2018 at Novi Sad, Serbia.

Transcript

1. to go faster but how? slow down PRACTICES TO BUILD SOFTWARE FASTER THAN EVER LEMi ORHAN ERGiN co-founder @
2. to go faster but how? slow down PRACTICES TO BUILD SOFTWARE FASTER THAN EVER LEMi ORHAN ERGiN co-founder @ speakerdeck.com/lemiorhan @lemiorhan LEMi ORHAN ERGiN agile software craftsman co-founder @ Craftbase ex Sony, eBay, acm, iyzico founder of Turkish Software Craftsmanship Community
3. 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
4. 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.
5. rushing makes us neither faster, nor more productive rushing increases stress, distracts focus and destroys productivity. we need creativity, effectiveness, and focus instead.
6. 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.
7. incompetency 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
8. 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. LEGACY SOFTWARE works perfectly validated by unit tests already deployed to prod but it has a bad smell do you get it?
10. LEGACY SOFTWARE
13. SLOWING DOWN the only way of going faster with sustainable pace is
14. Professionalism 
 and Craftsmanship Adaptation and Efficiency Automation and Quality 3 MAIN AREAS OF SLOWING DOWN PEOPLE PROCESS PRODUCT
15. 3 MAIN AREAS OF SLOWING DOWN PEOPLE PROCESS PRODUCT 11 practices to slow down, take a deep breath and invest on mastery
16. 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 Make them believe what you believe Model the behavior you want to see PEOPLE 1
17. 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
18. 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 OSS and communicate with the community PEOPLE 3
19. BROWN BAG SESSION PEOPLE
20. BROWN BAG SESSION PEOPLE GRAND RETROSPECTIVE
21. PEOPLE learn together Organize Brown Bag / Lunch & Learn Sessions Gather feedback via Team & Grand Retrospectives 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 BROWN BAG SESSION GRAND RETROSPECTIVE 4
22. 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 PROCESS 5
23. collect data and analyze Visualize processes, successes and failures Monitor SDLC, CI/CD metrics Allow every developer access product & code metrics Make decisions based on data, not gut feelings PROCESS 6
24. 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 7
25. 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 8
26. 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 9
27. PRODUCT
28. 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 10
29. PRODUCT HELL DEPENDENCY OF MICROSERVICES
30. PRODUCT
31. ports business adapters mysql adapter stripe adapter rest api web ui domain
32. 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
33. ports adapters notification payment billing order basket restaurant scheduling caching search mail account messaging stripe adapter rest api mysql adapter web ui domain business
35. a SEARCH
36. a c SEARCH PAYMENT
37. c a SEARCH PAYMENT ACCOUNT
38. 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 11
39. PEOPLE PROCESS PRODUCT
40. Professionalism 
 and Craftsmanship PEOPLE hire better talents do together practice together learn 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
42. 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.
43. @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.