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

Extreme Agile - Getting out of a dystopian world

mbarto
February 06, 2020

Extreme Agile - Getting out of a dystopian world

We, as developers, have created the XP techniques to increase the quality of our work, and being able to adapt to ever-changing requirements.
Then we wrote the Agile Manifesto, to better capture the challenges of a world that is moving (too) fast and try to avoid being always a step behind the real customer needs.
The main purpose was removing waste to concentrate on real value.
Suddenly Agile became mainstream and after a while, we are now experiencing a big lie: the Managers Driven Agile era.
Can we get back to what we have created and make it useful again?

mbarto

February 06, 2020
Tweet

More Decks by mbarto

Other Decks in Programming

Transcript

  1. This talk is dedicated to those of you that... …

    never heard anything about Agile … are curious about Agile, but never tried it … tried Agile and are disappointed … are enthusiastically using Agile every day So… basically anyone!
  2. A dystopic Agile world Getting out of here Contents Short

    history of Agile The past The present The future
  3. Waterfall methodology is a linear project management approach, where stakeholder

    and customer requirements are gathered at the beginning of the project, and then a sequential project plan is created to accommodate those requirements. These are the required phases: • Requirements/Analysis • Design • Coding • Testing • Maintenance The waterfall approach 5
  4. The assumptions are, most of the time, not applicable to

    software projects: • Requirements are clear and do not change over time • Software development is a linear process • Phases do not overlap Are those valid for your projects? What's wrong with waterfall? 7
  5. Three key moments Lean Extreme Programming 10 The Toyota Production

    System (TPS) is the precursor of "lean manufacturing". Taiichi Ohno and Eiji Toyoda, Japanese industrial engineers, developed the system between 1948 and 1975. The Agile Manifesto The Agile Manifesto was written in 2001 by 17 independent-minded software practitioners (Kent Beck was one of them). While the participants didn’t often agree, they did find consensus around four core values. March, 6, 1996: C3 project (The Chrysler Comprehensive Compensation System) hired Kent Beck to restore an almost failed project. He (and the other people working on the project) adopted a new set of techniques and called them Extreme Programming.
  6. The foundation of TPS is the idea of 'doing more

    with less', using the (few) resources available in the most productive way, with the goal of increasing the overall factory productivity drastically. Just after the second world war, Toyota was in a very low resources condition, as most of the Japanese industry at that time, because Japan ended the war beaten and exhausted. Lean thinking
  7. — Shigeo Shingo, Toyota Engineer “The most dangerous kind of

    waste is the waste we do not recognize.” — John Shook, Chairman Lean Global Network “There are three kinds of leaders. Those that tell you what to do. Those that allow you to do what you want. And Lean leaders that come down to the work and help you figure it out” Lean thinking
  8. Three key moments Lean Extreme Programming 15 The Toyota Production

    System (TPS) is the precursor of "lean manufacturing". Taiichi Ohno and Eiji Toyoda, Japanese industrial engineers, developed the system between 1948 and 1975. The Agile Manifesto The Agile Manifesto was written in 2001 by 17 independent-minded software practitioners (Kent Beck was one of them). While the participants didn’t often agree, they did find consensus around four core values. March, 6, 1996: C3 project (The Chrysler Comprehensive Compensation System) hired Kent Beck to restore an almost failed project. He (and the other people working on the project) adopted a new set of techniques and called them Extreme Programming.
  9. — Kent Beck, Extreme Programming Explained: Embrace Change “The XP

    philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?” Extreme Programming
  10. Planning User stories are written. Release planning creates the release

    schedule. Make frequent small releases. The project is divided into iterations. Iteration planning starts each iteration. The XP rules 18 Managing Give the team a dedicated open work space. Set a sustainable pace. A stand up meeting starts each day. The Project Velocity is measured. Move people around. Fix XP when it breaks.
  11. Designing Simplicity. Choose a system metaphor. Use CRC cards for

    design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. The XP rules 19 Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time.
  12. Testing All code must have unit tests. All code must

    pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published. The XP rules 20 Coding Integrate often. Set up a dedicated integration computer. Use collective ownership.
  13. Communication Everyone is part of the team and we communicate

    face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together. The XP values 21 Simplicity We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs. Feedback We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
  14. The XP values 22 Respect Everyone gives and feels the

    respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work. Courage We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.
  15. Three key moments Lean Extreme Programming 23 The Toyota Production

    System (TPS) is the precursor of "lean manufacturing". Taiichi Ohno and Eiji Toyoda, Japanese industrial engineers, developed the system between 1948 and 1975. The Agile Manifesto The Agile Manifesto was written in 2001 by 17 independent-minded software practitioners (Kent Beck was one of them). While the participants didn’t often agree, they did find consensus around four core values. March, 6, 1996: C3 project (The Chrysler Comprehensive Compensation System) hired Kent Beck to restore an almost failed project. He (and the other people working on the project) adopted a new set of techniques and called them Extreme Programming.
  16. — Albert Einstein “Learn from yesterday, live for today, hope

    for tomorrow. The important thing is not to stop questioning.” The Agile Movement
  17. The Agile Manifesto 25 Individuals and interactions over processes and

    tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  18. 29 What happens if We adopt Agile tools and frameworks,

    but we don't know or we forget / ignore the values behind them?
  19. 30 What happens if Agile is adopted by managers without

    a real comprehension of its values (Managers Driven Agile)?
  20. The Dystopic Agile Manifesto 36 Processes and Tools over individuals

    and interactions Comprehensive Documentation over working software Contract Negotiation over customer collaboration Following a Plan over responding to change
  21. Being Agile in 12 steps: • Admit you have a

    problem: recognize you live in the complex quadrant • Accept the uncertainty • Learn as many tools and frameworks you can in your limited time, and let them go! • Probe, sense and respond to adopt your own agility • Don't fall in love with the tools, verify them and eventually change them • Remove waste, eventually abandoning procedures that created it Anonymous Agilists method 39
  22. Being Agile in 12 steps: • Focus on value, for

    you and the customer • Share and be open • Enforce trust at all levels • Accept and collect any kind of feedback • Change your mind and adapt • Restart Anonymous Agilists method 40
  23. How to deal with: • Company internal bureaucracy • Customers

    that do not share your own values • Remote working Being Agile is challenging 43 But being Agile IS responding to challenges! So it is your choice to be or not to be!
  24. Did you like the resources on this template? Get them

    for free at our other websites. ◂ Presentation template by Slidesgo ◂ Icons by Flaticon ◂ Images & infographics by Freepik ◂ Infographics by new7ducks - Freepik.com ◂ Photos created by pressfoto - Freepik.com ◂ Content slide photo created by chokniti - Freepik.com ◂ Team slide photos created by benzoix and nensuria - Freepik.com ◂ Author introduction slide photo created by katemangostar - Freepik.com ◂ Image slide photo created by evening-tao - Freepik.com Credits