2001 with love alumni, Sony Europe, eBay Turkey/GittiGidiyor, ACM, iyzico 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
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
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
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 ?
contract between hard-pushing managers and developers needing time to think and explore. Twitter https://twitter.com/TotherAlistair/status/1405260113431171076 Reference: Alistair Cockburn The author of Agile Manifesto Creator of Hexagonal Architecture “
GRADUALLY THEN I THOUGHT, Limit work-in-progress Visualize the flow of work Manage flow Make process policies explicit Implement feedback loops Evolve experimentally
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 ?
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,
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
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
to drive fast to react fast to increase team competency to improve product quality to keep focus on goals to support fast to collaborate closely to communicate efficiently to surpass expectations to improve teamwork to align with people involved to be productive to keep the flow deterministic you need
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 “
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
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 practitioners were already there organizational anarchists, with deep experience
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 Manifesto for Agile Software Dev. 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
of Agile Manifesto Co-Author of The Pragmatic Programmer No rules are universal “ Rules need context All experts telling you what to do and how to do are wrong unless it was written for your team, company, project
a product owner doing pair programming doing daily alignment meetings using jira scrum or kanban boards writing tasks on post-its scrum, kanban or xp accordingly learning and changing it is 2001 Manifesto for Agile Software Dev. 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
Take a small step towards your goal • Adjust your understanding based on what you learned • Repeat 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 “
to the basics it’s time to go back 2001 Manifesto for Agile Software Dev. 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 is dead Long live agility - Dave Thomas
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 2020s 2001 Manifesto for Agile Software Dev. 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: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
SUSTAINABLE IMPROVEMENT SUSTAINABLE THROUGHPUT SUSTAINABLE PRODUCTIVITY PEOPLE & TEAM QUALıTY DECISION QUALITY PRODUCT QUALITY FOCUS TO PROCESS FOCUS TO PRODUCT FOCUS TO GOALS & PURPOSE
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
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
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
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
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
lemiorhan
naoki_0531
mochizuki875
handy
fujisawaryohei
kkamegawa
ysakotch
axelmizu
shujisado
syossan27
kniino
lycorptech_jp
jinoketani
rocio
garrettdimon
gr2m
tenderlove
sonatard
lara
eileencodes
bluesmoon
danielanewman
wjessup
trallard
aki_iinuma
