Pure Agile: Building a Culture Without Scrum, Kanban and XP

Why do we always estimate the size of tasks? Can't we catch the deadlines without estimating anything? Why do we push the teams to be small? Can't we succeed with big teams? Why do we give status reports every single day in front of a wall? How come many companies build successful products and achieve to be agile without calling themself doing Scrum, Kanban, or XP. Is doing Scrum means being agile? Do Agile Manifesto really explain what agility is? As Allen Holub in his blog, "Parroting the practices of some framework without knowing why they’re important and what problems those practices solve usually leads to an ineffective and empty faux Agile". It is time to talk about what agile is without doing Scrum, Kanban, and XP.

Transcript

1. PURE BUILDING A CULTURE without SCRUM, KANBAN AND XP AGILE CRAFTED BY LEMI ORHAN ERGIN CO-FOUNDER OF CRAFTGATE
2. LEMi ORHAN ERGiN Co-Founder, Cra ft gate active programmer, since 2001 with love alumni, Sony Europe, eBay Turkey scrum and xp practitioner, since 2007 community founder, Software Craftsmanship Turkey unforgettable memories, apple root bug, 2017 co-founder, Craftgate: “One-Stop Shop” Payment Gateway @lemiorhan lemiorhanergin.com craftgate.io/en
3. one day while we were in the room for hours doing poker planning...
4. Customers cannot pay their baskets. 
 What the heck are you doing? 
 I don’t care whatever you do Scrum or not. 
 I care if the system operating properly. Leave the darn room and fix it! the manager slammed the door with full of hate and anger
5. that made me think what agile was and what agile was really for
6. Splitting big tasks into small pieces Writing each small task down on post-its Running sprints (1-3 weeks) Doing regular plannings Doing estimations (poker planning) Measuring lots of metrics (velocity, burndown chart) Having small teams (4-6 members) Doing Daily Scrums to align Having a Scrum Master in your team Obeying the rules of Scrum written in the book BEING AGILE IS ABOUT FOLLOWING 
 THE WELL-KNOWN FORMULA I THOUGHT, I’ve been working in Scrum teams since 2007
7. Which real problems are we trying to resolve? Do we focus fake problems that we created? How do we define success in our product? Are we able to deliver high quality output fast? Are customers happy with the product? Do we care about customer satisfaction? I COULD NOT SEE WHAT ARE 
 THE REAL PROBLEMS OF 
 PRODUCT, CUSTOMER & TEAM BUT, we have answers, but what are the questions ? where is the context ?
8. ELIMINATING WASTE AND 
 MANAGING THE FLOW 
 EVOLVE US GRADUALLY THEN I THOUGHT, Limit work-in-progress Visualize the flow of work Manage flow Make process policies explicit Implement feedback loops Evolve experimentally
9. Simple concepts, impressive purposes, reasonable explanations but hard to get benefit in short term, even in long term. Why? If something is difficult to master, how can it be helpful to an organization having tons of important problems to resolve. Do you really think shortening daily Scrum to 15 minutes is more important than the problems your product has? SIMPLE TO UNDERSTAND BUT DIFFICULT TO MASTER, WHY? do we have to hire a coach or get consultancy from others ?
10. Test Driven Development Pair & Mob Programming Refactoring Automated Testing Continuous Integration Continuous Delivery Pipeline Code Review Evolutionary Architecture Static Code Analysis WITHOUT TECHNICAL EXCELLENCE 
 IT’S NOT POSSIBLE TO BE AGILE Monoliths / Microservices Trunk Based Development Design Principles Feature Toggling Consumer Driver Contract Testing Acceptance Driven Development Behavior Driven Development Unit Testing Continuous Deployment THEN I THOUGHT,
11. Test Driven Development Pair & Mob Programming Refactoring Automated Testing Continuous Integration Continuous Delivery Pipeline Code Review Evolutionary Architecture Static Code Analysis Monoliths / Microservices Trunk Based Development Design Principles Feature Toggling Consumer Driver Contract Testing Acceptance Driven Development Behavior Driven Development Unit Testing Continuous Deployment I CANNOT ACHIEVE WITH INDIVIDUAL EFFORT 
 CONVINCING WHOLE TEAM SEEMS IMPOSSIBLE technical excellence needs a lot of technical knowledge and a different mindset
12. AGILE = DOING THE RIGHT THINGS RIGHT ? is agile “the correct way” to do things ? AGILE = THE BEST ?
13. AGILE = DOING THE RIGHT THINGS RIGHT ? agile product management agile project management agile management agile development agile remote development agile talent management agile sales agile teams agile tools agile boards agile titles agile transformation agile methodologies agile frameworks agile business agile testing agile retrospectives agile meetings agile delivery agile coaches agile certifications agile companies agile metrics agile mindset agile delivery agile organization agile executives agile leadership world loved it
14. Agile AT TRAININGS & BOOKS 
 WHAT WE’RE TAUGHT 
 ABOUT AGILE AND 
 AGILITY IS USUALLY 
 HOW TO IMPLEMENT 
 SCRUM, KANBAN, XP Scrum Values Sprints Scrum Roles Overview Scrum Master Product Owner Development Team Daily Stand-Up Meeting Sprint Planning Meeting Sprint Review Meeting Sprint Retrospective Backlog Refinement User Stories Acceptance Criteria Release Planning Story Points Product Backlog Sprint Backlog Working Agreements Definition of Ready Definition of Done Poker Planning Product Increment Task Estimating Team Velocity Burn-down Chart Burn Up Chart Spikes, Epics, Tasks typical agenda of an agile training
16. product management project management management development remote development talent management sales teams tools boards titles transformation methodologies frameworks business testing retrospectives meetings delivery coaches certifications companies metrics mindset delivery organization executives leadership agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile agile WHAT THEY CARE IS NOT AGILE
17. WHAT THEY CARE IS PRODUCT, TEAM 
 AND CUSTOMERS 
 AT ANY SCALE product management project management management development remote development talent management sales teams tools boards titles transformation methodologies frameworks business testing retrospectives meetings delivery coaches certifications companies metrics mindset delivery organization executives leadership
18. Agile is Dead (Long Live Agility) https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html Reference: Dave Thomas The author of Agile Manifesto Co-Author of The Pragmatic Programmer Instead, let’s use a word that describes what we do Let’s abandon the word agile 
 to the people who don’t do things
19. I trained people about Scrum, Kanban and XP but I am not a follower of Scrum, Kanban or XP I am not against Scrum, Kanban or XP I won’t say Scrum, Kanban or XP doesn’t work I say following them doesn’t mean being agile execution is a totally different world 

20. 2001 Agile Manifesto 1992 Crystal Family of Methodologies 1994 Dynamic System Development Method 1995 Scrum 1996 Rational Unified Process 1997 Feature Driven Development 1999 Extreme Programming 1999 Adaptive Development 2003 Lean Software Development 2005 Large Scale Scrum (LeSS) 2007 Kanban Method 2007 Disciplined Agile 2011 Scaled Agile Framework (SAFe) 2011 Continuous Delivery 2012 Spotify Model 2015 Nexus 2018 Scrum@Scale 1960s Iterative&Incremental Development 1970s Waterfall Model 1970s Prototyping 1980s Spiral Model 1980s Evolutionary Delivery 1980s Rapid Application Development AGILE NOT INVENTED BY AGILE MANIFESTO It’s been already there for tens of years 
 with different names and styles 
 describing new ways of working The authors of Agile Manifesto 
 were the ones who were experienced in 
 building successful projects/products They extracted the winning mindset 
 and coined the term agile for describing them
21. ALL WORK PERFECTLY UNDER SPECIFIC CONDITIONS Scrum without XP is fine Scrum with XP is also fine SAFe is not evil and fits perfectly Half Scrum, half Kanban are all fine Doing Scrum by the book is fine Kanban, ScrumBan, ScrumBanXP are all fine WORKS FOR YOU DOES NOT MEAN WORKS FOR EVERYONE AND VICE VERSA 2001 Agile Manifesto 1992 Crystal Family of Methodologies 1994 Dynamic System Development Method 1995 Scrum 1996 Rational Unified Process 1997 Feature Driven Development 1999 Extreme Programming 1999 Adaptive Development 2003 Lean Software Development 2005 Large Scale Scrum (LeSS) 2007 Kanban Method 2007 Disciplined Agile 2011 Scaled Agile Framework (SAFe) 2011 Continuous Delivery 2012 Spotify Model 2015 Nexus 2018 Scrum@Scale 1960s Iterative&Incremental Development 1970s Waterfall Model 1970s Prototyping 1980s Spiral Model 1980s Evolutionary Delivery 1980s Rapid Application Development
22. BEING AGILE WITHOUT TALKING ABOUT AGILE 2020s PURE AGILE MOVEMENT 2001 Agile Manifesto 1992 Crystal Family of Methodologies 1994 Dynamic System Development Method 1995 Scrum 1996 Rational Unified Process 1997 Feature Driven Development 1999 Extreme Programming 1999 Adaptive Development 2003 Lean Software Development 2005 Large Scale Scrum (LeSS) 2007 Kanban Method 2007 Disciplined Agile 2011 Scaled Agile Framework (SAFe) 2011 Continuous Delivery 2012 Spotify Model 2015 Nexus 2018 Scrum@Scale 1960s Iterative&Incremental Development 1970s Waterfall Model 1970s Prototyping 1980s Spiral Model 1980s Evolutionary Delivery 1980s Rapid Application Development to the basics it’s time to go back
23. NO PRESCRIBED RULES NO FORMULA FOR SUCCESS KEEP FOCUS ON CUSTOMER, TEAM & PRODUCT REGULARLY EVALUATE YOUR NEEDS & PROBLEMS SHAPE WHAT YOU DO BASED ON YOUR NEEDS DO IF RESOLVES A REAL PROBLEM STOP GENERATING FAKE PROBLEMS GET BENEFIT FROM ALL EXISTING FRAMEWORKS NOW IT’S TIME TO CREATE YOUR OWN MODEL PURE AGILE MOVEMENT 2001 Agile Manifesto 1992 Crystal Family of Methodologies 1994 Dynamic System Development Method 1995 Scrum 1996 Rational Unified Process 1997 Feature Driven Development 1999 Extreme Programming 1999 Adaptive Development 2003 Lean Software Development 2005 Large Scale Scrum (LeSS) 2007 Kanban Method 2007 Disciplined Agile 2011 Scaled Agile Framework (SAFe) 2011 Continuous Delivery 2012 Spotify Model 2015 Nexus 2018 Scrum@Scale 1960s Iterative&Incremental Development 1970s Waterfall Model 1970s Prototyping 1980s Spiral Model 1980s Evolutionary Delivery 1980s Rapid Application Development 2020s
24. CULTURAL MODEL PRACTICES the behaviors PRINCIPLES the guidelines
25. WELL-CRAFTED, UNIQUE CORE PRINCIPLES TO DESIGN “YOUR OWN” CULTURAL MODEL
26. AGILE DON’T TALK ABOUT The very first rule of being agile: Never talk about it! The term agile is too abstract to describe concrete practices and guidelines, like the words "winning" or "the best". In reality, it is a reaction agains traditional methods and mindsets. Teams should aim for the values and principles by focusing on the product, customer and the team, not the term agile in any sense. PRINCIPLE
27. AGILE DON’T TALK ABOUT The very first rule of being agile: Never talk about it! Stop sharing wise quotes having "agile" in it Stop creating fake problems and reasons to realize rituals Start learning how others succeed and compare with yours Start referencing your values, your principles, your goals Start talking about the needs of product, team & customer PRINCIPLE
28. Improvement starts with good observations and pragmatic analysis. That can only be achieved when 
 you know your team, your team’s competence and capabilities, weaknesses, exceptional situations, 
 personal preferences, knowledge level & priorities well. 
 Your own model should be suited for your team. Know your team well and trust! Every team is special and unique KNOW YOUR TEAM WELL PRINCIPLE
29. KNOW YOUR TEAM WELL Know your team well and trust! Every team is special and unique PRINCIPLE Earn trust by supporting them even in harsh conditions Work/chat with everyone in your team almost in daily basis Be with the team while doing the execution with them Ask feedback from team about strengths and weaknesses You can never succeed if you don’t know your team well
30. Get management’s support and direct facilitation It’s one for all, all for one The management should be the main supporter and sponsorship of your model due to its power. Individual teams or people can trigger the change but can never cultivate an overall cultural evolution without the help of management. If management does not want to change, bottom-up initiative has little chance to win. GET MANAGEMENT’S SUPPORT AND SPONSORSHIP PRINCIPLE
31. GET MANAGEMENT’S SUPPORT AND SPONSORSHIP Get management’s support and direct facilitation It’s one for all, all for one PRINCIPLE Managers should know the pain of being in the kitchen Managers should be accessible at any time, in any condition Managers should be the role model for spreading wisdom Managers should be a team member getting the things done
32. Direct team’s focus to 
 an inspiring purpose Motivation starts with a purpose Loyalty, motivation, accountability, collaboration, ownership, etc. all start with an inspiring purpose, the purpose that directs the whole team’s focus on. If what you build is only projects, stop hoping to be agile. Completing projects on time is a goal, not a purpose. HAVE AN INSPIRING PURPOSE PRINCIPLE
33. SAMPLE PURPOSE As the gateway on top of banks, virtual pos providers and alternative payment methods, we aim to deliver solutions to businesses getting online payments by • providing high quality features from domain experts • providing fast support from the creators of the product • providing developer-friendly, easy & single integration • maximizing success rates to a level of above-expectancy the strengths of the team and product what we really do who we target having it should make you feed proud of
34. Direct team’s focus to 
 an inspiring purpose Motivation starts with a purpose HAVE AN INSPIRING PURPOSE PRINCIPLE Stop setting purposes like agile/microservice transformation Stop aiming to finish all the tasks you get in a sprint Stop aiming “be the winner” and “dominate market” Purpose should contain business vision and team’s strengths
35. Define the base line of your culture Culture cannot be built. It changes all the time by a newcomer or leaver. But it can be guided and shaped. You should draw a baseline for your product and your team that they can use as a reference point. DEFINE CORE VALUES AND PRINCIPLES PRINCIPLE
36. what you do in reality what you don’t do toxic behaviors you allow the crisis you handle REAL COMPANY CULTURE FAKE 
 COMPANY CULTURE values and practices written on walls, 
 company culture books 
 and twitter PR posts 
 that nobody cares WELCOME TO THE DESERT OF THE REAL
37. DEFINE CORE VALUES AND PRINCIPLES PRINCIPLE Hire the people increasing the social cohesion of the team Never lose focus from increasing diversity and ethics Be transparent about organization’s expectations and goals Culture is shaped by the behaviors you don’t do Base line is drawn harder with every crisis you face Define the base line of your culture
38. Do you have a real need to run sprints or you just follow what the books say? Evaluate what problems or need you really have regularly with the team and don’t do anything if any read problem is solved or any real need shows itself. DOING IF NOT REALLY NEEDED STOP PRINCIPLE Take action in case of a real need Stop proposing fake problems for rituals and evaluate regularly
39. DOING IF NOT REALLY NEEDED STOP PRINCIPLE Evaluate the real need before practicing a methodology Start from a blank paper and add one by one gradually Rituals and methodologies are tools, not the goals/purposes Know what actions you can take in case of a need Evaluate your current needs and change model accordingly Take action in case of a real need Stop proposing fake problems for rituals and evaluate regularly
40. 6 CORE PRINCIPLES
41. WELL-CRAFTED, UNIQUE CORE PRACTICES “YOUR OWN” CULTURAL MODEL TO SHAPE hundreds of practices, rituals and methods you can use in your model including the ones in Scrum, Kanban and XP
42. with the whole team continuously responding to change TO satisfy customers FAST FOR CORE PRACTICES THE ULTIMATE GOAL wait a minute ! isn’t it the meaning of agility ?
43. with the whole team continuously responding to change TO satisfy customers FAST Each part of the goal has different meanings from different perspectives and contains set of concrete practices. You should have a real reason, need, problem to start doing any practice. 
 If not, never touch it. FOR CORE PRACTICES THE ULTIMATE GOAL
44. responding FAST Deliver FAST LEARN FAST PROVIDE SUPPORT FAST decisions should be taken fast develop FAST MAKE IT LIVE FAST ORGANIZATION LEVEL TEAM LEVEL TASK LEVEL FROM TEAM MEMBERS FROM CUSTOMERS FROM PRODUCT COMMUNICATE Fast UNDERSTAND FAST RESOLVE FAST
45. responding FAST LEARN FAST FROM TEAM MEMBERS work closely together retrospectives (grand, regular, ad-hoc), brainstorming sessions, review meetings, open space internal seminars/panels, code katas, book clubs, workshops pair/mob prog, collaboration with product team during BDD, collaboration with Test/QA experts during kickoffs office chit-chats, 1-1 meetings, off-site gatherings spend time together discuss together share together
46. responding FAST Deliver FAST Develop FAST always BE READY TO DEPLOY be domain expert, have test suite, spread knowledge via pair/mob programming be master at your tools and techs, refactor continuously automated acceptance tests, have test suite, feature toggles, microservices, micro-frontend, git branching models, infra-as-code 4 rules of simple design, SOLID principles, coupling-cohesion, boy-scout rules, bug-fixing procedures, refactoring techniques KEEP EASY TO BE CHANGED know where to change produce/develop fast
47. SUSTAINABLE FOCUS continuously SUSTAINABLE PACE SUSTAINABLE QUALITY SUSTAINABLE HEALTHY COMMUNICATION SUSTAINABLE IMPROVEMENT SUSTAINABLE THROUGHPUT SUSTAINABLE PRODUCTIVITY PEOPLE & TEAM QUALıTY DECISION QUALITY PRODUCT QUALITY FOCUS TO PROCESS FOCUS TO PRODUCT FOCUS TO GOALS & PURPOSE
48. continuously SUSTAINABLE QUALITY PEOPLE & TEAM QUALITY GROW LEADERS improve hiring process, make job interviews a win-win, hiring is too important not to leave it to human resources, stop making mediocre programmers employable mentorship sessions, pairing sessions, coaching sessions, stop micro-management start listen-and-trust stop giving seniority levels, focus on competence-not working years, allow to experiment HIRE A-PLAYERS CLOSE MENTORSHIP
49. continuously SUSTAINABLE HEALTHY COMMUNICATION aGREE ON TEAM STANDARDS daily alignment, instant alignments, plannings, status meetings, 1-1 meetings, company gatherings small teams, modular architecture, microservices, do not split without real need, keep cognitive load small no seniority levels in titles, team defines the guidelines, share both positive and negative feedback, retrospectives align on a shared goal ADAPT TO CONWAY’S LAW
50. KEEP TRACK OF PROGRESS keep the flow deterministic be ready for the change initiate and iterate the change prioritize change to change CHANGE IN PRODUCT CHANGE IN PROCESS CHANGE IN PEOPLE & TEAM
51. be ready for the change to change CHANGE IN PRODUCT BE READY TO EXPERIMENT low coupling-high cohesion, modular architecture, separation of concerns, hexagonal architecture, solid principles, continuous refactoring, tdd feature toggles, trunk based development, continuous delivery pipelines, continuous integration, automated testing automatic provisioning, multi-environments, test containers, git branches, feature toggles BE READY FOR EXTENSION Be READY FOR RELEASE
52. meet expectations surpass expectations IDENTIFY EXPECTATIONS TO satisfy customers For PROJECTS FOR PRODUCTS
53. surpass expectations TO satisfy customers DELIGHT WITH COMMUNICATION deliver high quality product fast, keep feature list as short as possible, be the domain expert release frequently, resolve bugs fast, low technical debt, let the team initiate change hear customers’ expectations, fast-honest-transparent communication, answer with domain expertise DELIGHT WITH PRODUCT DELIGHT WITH DELIVERY DELIGHT WITH COLLABORATION everyone in the team touches customers, sit together with customers
54. IMPROVE accountability & OWNERSHIP improve competence improve teamwork with the whole team cultivate professionalism do not manage people manage the flow
55. with the whole team cultivate professionalism OWN YOUR CAREER keep calm under stress, be ethical, be storyteller, always be kind, be passionate and disciplined, be eager to learn and share, show respect admit that always someone knows better than you, ask for feedback, practice new techniques, focus on fundamentals never allow toxic behavior to spread, leave before you lose your self-respect, invest in yourself BE THE ROLE MODEL BE AN APPRENTICE
56. Event Storming Impact Mapping Prototyping Pair Programming Microservices Daily Scrum Mutation Testing Architecture Brainstorming Lightening Talks Kanban Boards Burn-up Charts Happiness Index Sprints Product Backlog Unit testing Planning Game Test Driven Development Sustainable Pace Mob Programming OKRs and KPIs Limit WIP War Room Replenishment meeting Portfolio Management Retrospective Meetings Resilient Architecture Clean Code Poker Planning Definition of Urgency Spikes and Prototypes Fast Lane Community of Professionals Weekly Rotating Support Sit Together Feature Toggling Trunk Based Development with the whole team continuously responding to change TO satisfy customers FAST
57. CREATE YOUR OWN MODEL STOP CHASING SUCCESS FORMULAS YOU ARE SPECIAL, YOU ARE UNIQUE KNOW YOUR TEAM, FEEL YOUR PURPOSE, 
 IDENTIFY YOUR REAL NEEDS, SELECT PRACTICES TOUCHING YOUR OWN NEEDS START TODAY
58. THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: lemi@craftgate.io
59. THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: lemi@craftgate.io