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

    View Slide

  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

    View Slide

  3. one day while we were in the room


    for hours doing poker planning...

    View Slide

  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

    View Slide

  5. that made me think
    what agile was and
    what agile was really for

    View Slide

  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

    View Slide

  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 ?

    View Slide

  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

    View Slide

  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 ?

    View Slide

  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,

    View Slide

  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

    View Slide

  12. AGILE = DOING THE RIGHT THINGS RIGHT ?
    is agile “the correct way”
    to do things ?
    AGILE = THE BEST ?


    View Slide

  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

    View Slide

  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

    View Slide

  15. View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  24. CULTURAL MODEL
    PRACTICES
    the behaviors
    PRINCIPLES
    the guidelines

    View Slide

  25. WELL-CRAFTED, UNIQUE
    CORE PRINCIPLES TO DESIGN
    “YOUR OWN”
    CULTURAL MODEL

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  40. 6 CORE PRINCIPLES


    View Slide

  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

    View Slide

  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 ?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  52. meet expectations
    surpass expectations
    IDENTIFY EXPECTATIONS
    TO satisfy customers
    For PROJECTS
    FOR PRODUCTS

    View Slide

  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

    View Slide

  54. IMPROVE accountability & OWNERSHIP
    improve competence
    improve teamwork
    with the whole team
    cultivate professionalism
    do not manage people manage the flow

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  58. THANK YOU FOR


    SHARING YOUR TIME


    WITH ME
    speakerdeck.com/lemiorhan


    twitter.com/lemiorhan
    lemi orhan ergin
    co-founder, craftgate
    mail: [email protected]

    View Slide

  59. THANK YOU FOR


    SHARING YOUR TIME


    WITH ME
    speakerdeck.com/lemiorhan


    twitter.com/lemiorhan
    lemi orhan ergin
    co-founder, craftgate
    mail: [email protected]

    View Slide