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

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

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.

Lemi Orhan Ergin

October 13, 2022
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Technology

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. 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
  4. 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
  5. 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 ?
  6. 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
  7. 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 ?
  8. 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,
  9. 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
  10. AGILE = DOING THE RIGHT THINGS RIGHT ? is agile

    “the correct way” to do things ? AGILE = THE BEST ?
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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 

  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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 ?
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. 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
  45. 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
  46. 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
  47. IMPROVE accountability & OWNERSHIP improve competence improve teamwork with the

    whole team cultivate professionalism do not manage people manage the flow
  48. 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
  49. 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
  50. 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