Podcasts about extreme programming xp

BONUS: Software Engineers are Paid to Solve Problems, Not Write Code! With John Crickett In this BONUS episode, we explore a thought-provoking LinkedIn post by John Crickett that challenges a fundamental misconception in software engineering. John shares insights on why engineers should focus on problem-solving rather than just coding, how to develop business context understanding, and why this shift in perspective is crucial in the age of AI. Beyond Writing Code: Understanding the True Value of Software Engineering "A lot of us come to software engineering because we care about building, and missed the goal: solving a problem for a customer." John Crickett explains the fundamental disconnect many software engineers experience in their careers. While many enter the field with a passion for building and coding, they often lose sight of the ultimate purpose: solving real problems for customers. This misalignment can lead to creating technically impressive solutions that fail to address actual business needs. John emphasizes that the most valuable engineers are those who can bridge the gap between technical implementation and business value. In this section, we refer to John's Coding Challenges and Developing Skills websites. The Isolation Problem in Engineering Teams "We have insulated people from seeing and interacting with customers, perhaps because we were afraid they would create a problem with customers." One of the key issues John identifies is how engineering teams are often deliberately separated from customers and end-users. This isolation, while sometimes implemented with good intentions, prevents engineers from gaining crucial context about the problems they're trying to solve. John shares his early career experience of participating in the sales process for software projects, which gave him valuable insights into customer needs. He highlights the Extreme Programming (XP) approach, which advocates for having the customer "in the room" to provide direct and immediate feedback, creating a tighter feedback loop between problem identification and solution implementation. In this segment, we refer to the book XP Explained by Kent Beck. The AI Replacement Risk "If all you are doing is taking a ticket that is fully spec'ed out, and coding it, then an LLM could also do that. The value is in understanding the problem." In a world where Large Language Models (LLMs) are increasingly capable of generating code, John warns that engineers who define themselves solely as coders face a significant risk of obsolescence. The true differentiation and value come from understanding the business domain and problem space—abilities that current AI tools haven't mastered. John advises engineers to develop domain knowledge specific to their business or customers, as this expertise allows them to contribute uniquely valuable insights beyond mere code implementation. Cultivating Business Context Understanding "Be curious about what the goal is behind the code you need to write. When people tell you to build, you need to be curious about why you are being asked to build that particular solution." John offers practical advice for engineers looking to develop better business context understanding. The key is cultivating genuine curiosity about the "why" behind coding tasks and features. By questioning requirements and understanding the business goals driving technical decisions, engineers can transform their role from merely delivering code to providing valuable services and solutions. This approach allows engineers to contribute more meaningfully and become partners in business success rather than just implementers. Building the Right Engineering Culture "Code is always a liability, sometimes it's an asset. The process starts with hiring the CTO—the people at the top. You get the team that reflects your values." Creating an engineering culture that values problem-solving over code production starts at the leadership level. John emphasizes that the values demonstrated by technical leadership will cascade throughout the organization. He notes the counter-intuitive truth that code itself is inherently a liability (requiring maintenance, updates, and potential refactoring), only becoming an asset when it effectively solves business problems. Building a team that understands this distinction begins with leadership that demonstrates curiosity about the business domain and encourages engineers to do the same. The Power of Asking Questions "Be curious, ask more questions." For engineers looking to make the shift from coder to problem-solver, John recommends developing the skill of asking good questions. He points to Harvard Business Review's article on "The Surprising Power of Questions" as a valuable resource. The ability to ask insightful questions about business needs, user requirements, and problem definitions allows engineers to uncover the true challenges beneath surface-level requirements. This curiosity-driven approach not only leads to better solutions but also positions engineers as valuable contributors to business strategy. In this segment, we refer to the article in HBR titled The Surprising Power of Questions. About John Crickett John is a passionate software engineer and leader on a mission to empower one million engineers and managers. With extensive expertise in distributed systems, full-stack development, and evolving tech stacks from C++ to Rust, John creates innovative coding challenges, insightful articles, and newsletters to help teams level up their skills. You can link with John Crickett on LinkedIn.

What happens when a college software design course ditches traditional lectures and embraces Mob Programming? In this episode of the Mob Mentality Show, we sit down with Ben Kovitz, a former software developer turned professor at Cal Poly Humboldt, to explore his innovative approach to teaching software design through mobbing. Topics Covered: ✅ From Industry to Academia: Why Ben left software development to become a professor and how he discovered mob programming. ✅ Redefining Software Education: Instead of 30 traditional lectures on software design, Ben's students learn by doing—designing software while coding. ✅ The Power of Mobbing in the Classroom: How students collaborate in the mob of 8, rapidly sharing knowledge and tackling challenges together. ✅ Fast Learning vs. Lectures: Why mobbing enables faster knowledge transfer compared to passive lectures. ✅ Strong-Style Navigation: How rotations and fast timers helped to stimulate a highly effective learning environment. ✅ The Role of the Navigator: How students help each other navigate, learn C++ and the QT framework, and document key lessons from each mob session. ✅ Real-World Software Challenges: Simulating legacy code maintenance, evolutionary design, and design patterns like MVC (Model-View-Controller). ✅ Overcoming Student Struggles: What happens when students don't know how to navigate? How asking for help and learning together fosters growth. ✅ Teaching Through Experience: Letting students experiment with flawed solutions before introducing better design principles. ✅ Assessment & Engagement: How Ben measures student participation, engagement, and learning outcomes in a mobbing environment. Why This Matters: Traditional software design education can leaves students unprepared for the realities of refactoring real code and collaborative development. By integrating Mob Programming, refactoring techniques, and hands-on problem-solving, Ben Kovitz is equipping the next generation of developers with practical, real-world skills and deeper design insights.

En este episodio conversamos con Ricardo Guzmán Velasco, Tech Lead & Tech Coach, y Ángel Siendones Sillero, Senior Software Engineer en Voxel, sobre la industria del videojuego y su relación con el desarrollo de software. Exploramos cómo las prácticas de Extreme Programming (XP) pueden aplicarse en este mundo, los desafíos que enfrentan los equipos de desarrollo y las diferencias entre la creación de software tradicional y los videojuegos. ¿Qué podemos aprender de este sector? ¿Cuáles son las mejores prácticas que pueden adoptarse en otros entornos? Acompáñanos en esta emocionante charla.

Explore the exciting intersection of human collaboration and artificial intelligence (AI) in software development with this insightful episode of the Mob Mentality Show. Recorded for the 2024 UACon Winter: The Future of Product Development Summit on December 10, 2024, Aaron Griffith and Parker Barrett joins Austin to dive deep into how Mob Programming and AI are reshaping the way we build and test software. This episode is packed with practical insights, real-world examples, and actionable strategies for leveraging AI with a mob programming style. Whether you're an AI enthusiast, a software developer, or just curious about the future of collaboration, this session has something for you. What You'll Learn in This Episode:

Have you ever wondered why Extreme Programming (XP) isn't commonly taught in schools? In this engaging episode of the Mob Mentality Show, we dive into this intriguing question brought to us by the mob programming community.

In this episode of the Mob Mentality Show, we dive into our Software Professional Resources Board, a dynamic Trello-based hub designed for software professionals looking to enhance their learning and collaboration in the industry. Join us as we share the board's origin story and our journey in creating a comprehensive resource for everything from Extreme Programming (XP), mobbing, and leadership to cloud infrastructure, agile retrospectives, lean principles, and much more. ### What Makes Our Board Unique? We start by exploring why we chose **Trello** for our resource board and how it has become a cornerstone for organizing, sharing, and discovering knowledge. With its flexibility, Trello enables us to create an easily navigable environment, where resources are not only organized but can also be searched, linked, and explored across various software domains. Our conversation touches on other similar boards we've seen, like our popular "Retrospective Techniques for Coaches, Scrum Masters, and Facilitators" board, as well as spin-offs we've created for specific topics. ### A Variety of Topics Our board covers a broad spectrum of topics that are essential for modern software professionals, including **mobbing**, **refactoring**, **leadership**, **Infrastructure as Code (IaC)**, **agile** practices, and more. With resources curated for both technical and strategic learning, the board has become a go-to reference for articles, blog posts, videos, academic papers, book links, and quotes on various disciplines within software development. ### How We Use the Board for Continuous Learning Discover how we leverage the board not only to organize information but to foster continuous learning. We discuss Chris' “community-supported learning binges” and our process for capturing insightful book quotes and key takeaways, turning the board into a knowledge-sharing powerhouse for software teams and individual contributors alike. ### Refactoring the Mind: Evolving the Board to Stay Relevant Our discussion also delves into the concept of "refactoring my mind by refactoring the board"—an idea about how reorganizing knowledge can improve our mental clarity and adaptability in complex projects. This involves regularly revisiting, reshaping, and expanding board content to reflect the latest insights and trends in software development, keeping it a living, breathing resource for our community. ### The Impact of Public Knowledge Sharing One of the most inspiring aspects of this board is its role in **public knowledge sharing**. We highlight feedback from the community, stories of how others have used the board in their professional journeys, and our own experiences with learning in public. By sharing this resource openly, we invite others to benefit from it, create connections, and add to the body of knowledge that supports software development excellence. Whether you're a developer, coach, Scrum Master, or technical leader, this episode offers valuable insights into how to create and use a resources board to drive personal and team growth. Listen in for tips on organizing knowledge, capturing valuable insights, and using community feedback to make a resource board that truly enhances your software development journey. ### Topics Discussed: - The board's origin story and why we chose Trello - Organizing, searching, and sharing resources in Trello - Similar boards, including "Retrospective Techniques for Coaches, Scrum Masters, and Facilitators" - Variety of topics: mobbing, XP, leadership, IaC, agile, cloud, business, tech, retrospectives, and more - Types of media: articles, blogs, videos, book quotes, academic papers, and beyond - Spin-off boards and community learning sessions - Feedback from the community and lessons for public knowledge sharing **Subscribe on YouTube or your favorite podcast platform to catch this episode and more!** Video and Show Notes: https://youtu.be/GmfWWiIeaVY 

In this Mob Mentality Show episode, we dive into the journey of Jeff “Cheezy” Morgan, a coach in Continuous Delivery (CD) and lean thinking. Known for his role in advocating for CD within companies, Jeff shares how his experiences with software development and his recent shift into the café business have shaped his philosophy on people and just-in-time. This discussion explores how Jeff's approach to Agile and CD evolved, his journey into Extreme Programming (XP), and how mob programming impacted his perspective on teamwork and Continuous Integration (CI).  **Jeff's Agile and CD Journey** We start with Jeff's introduction to Agile, discussing the early days of his career when dev practices didn't include CD and the impact of adopting CD in high-stakes projects like Y2K. Jeff describes how learning from Thoughtworks influenced his views on XP and CD, and how he became an advocate, eventually taking CD to different organizations. He also shares what it was like discussing with Woody Zuill and Llewellyn Falco and reflects on the transformative role mob programming has played in his career. **From Pairing to Mobbing**   For Jeff, mob programming was not initially appealing, but over time it became his preferred approach for helping teams. We explore how mobbing enhances CI, tightens communication, and fosters collective learning. Jeff explains how mobbing enables "just-in-time" discussions that align teams on what to build and how it allows real-time feedback on other team members' learning. Jeff also examines the transition from pairing to mobbing, the challenges of mob programming with CI/CD, and why mobbing helps him “get the whole system in the room” for tackling complex problems. **Quality Without QA?**   We dive into the controversial idea of achieving high quality without traditional Quality Assurance (QA). Jeff opens up about years spent wrestling with the role of QA in Agile/CD environments and shares experiments with “test-infected” developers—who took full ownership of quality. He reflects on the pitfalls of relying on “heavyweight” traditional QA processes and automated tests, which often create lean waste, add handoffs, and introduce brittle, flakey tests. Jeff and hosts Austin and Chris discuss whether “shift left” is merely a shift away from QA, the Deming Red Bead experiment's relevance, and whether there's a happy journey for QA professionals on CD teams. **Applying Lean to Cafés**   Outside the tech world, Jeff has found a second passion—running cafés. We discuss how owning two cafés influenced Jeff's perspective on Lean thinking and Agile principles. From supply chain issues during COVID to needing backup suppliers, Jeff discusses if “just-in-time” challenges in the café world mirror software development. He shares valuable insights about hiring, managing consistent delivery, and applying Lean principles to run a resilient business. Additionally, Jeff and Chris exchange stories on chip shortages and if Lean can help address real-world supply chain issues. **More from Jeff**   Finally, we tackle some big questions: What does DevOps mean in today's Agile world? Should “DevOps” be responsible for shielding organizations from developers? How does Test-Driven Development (TDD) factor into DevOps scripts, and can mobbing help break down silos that traditionally separated devs, ops, and QA? Join us for this wide-ranging conversation with Jeff “Cheezy” Morgan to uncover actionable insights for anyone involved in Agile, CD, DevOps, or Lean. Whether you're in software, QA, or running a small business, this episode is packed with valuable takeaways on quality, learning, and resilience.  Video and Show Notes: https://youtu.be/OJ5d6qLIQRY   

In this episode of the Mob Mentality Show titled **"Nothing in Tech Matters Except XP? A Hot Take,"** We take on the controversial discussion of the ever-changing landscape of technology and the role of Extreme Programming (XP). Are industry "best practices" in languages, front-end frameworks, and meta-architecture mere trends destined to fade away? Come hear a provocative stance that challenges the importance of these things, arguing that they are volatile, trendy, and often miss the mark when it comes to delivering true software excellence. We explore how many tech trends are built on the assumption that developers will inherently write unsafe code unless they are constrained by strong type systems, impenetrable boundaries (like microservices), and restrictive frameworks. But what if consistently following XP principles makes these safeguards superfluous? Can language, frameworks, tools, and even meta-architectures lose their high significance when XP is at the core of software development?  Throughout the episode, we draw on personal experiences, asserting that our developer satisfaction remains consistently high when XP values and principles are the guiding force, regardless of the technology stack. Without good XP practices, even the most advanced tools can't solve the deeper, underlying problems that plague software projects. We delve into the ongoing debate of Majestic Monolith vs. Microservices, questioning whether the choice of meta-architecture matters as much if XP is practiced. How do these choices affect agility, and can agility be seen as a reward for technical excellence?  Another key topic is the influence of societal factors on willpower and habits, and how these meta-problems impact developers' ability to consistently follow XP practices. Can a focus on XP help overcome the challenges posed by trendy tech choices and shifting industry standards? Chris poses a utopian question: If everyone adhered strictly to XP principles, would other factors like programming language, framework, or meta-architecture even matter? We explore this thought experiment, considering whether an XP-driven world could render other tech decisions less critical. But it's not all theory. Austin reaches out to Chris for "Apathy Counseling" for developers facing burnout or disillusionment with tech trends, and offers community analogies linking dev health to "Tech Dishes"—a metaphor for the routine maintenance needed to keep your codebase clean and healthy. Finally, we tackle the nuances of infrastructure and database management, offering qualifications on the time and effort needed to support different setups. Whether you're grappling with microservices or maintaining a monolithic architecture, the focus remains on how XP can guide you through these challenges. Don't miss this thought-provoking episode that pushes the boundaries of conventional wisdom in tech. Video and Show Notes: https://youtu.be/MZUUemSJMjs  

In this episode, Max and Jeremy identify artifacts that are used in adaptive projects. Then we discuss the components of different adaptive methodologies (e.g., Scrum, Extreme Programming (XP), Scaled Adaptive Framework (SAFe®), Kanban, etc.). Next, we cover the success criteria of adaptive projects and wrap up how to prioritize tasks in adaptive project management. --- Support this podcast: https://podcasters.spotify.com/pod/show/vets2pm/support

In this episode, we delve into the world of feedback in software development. We explore how feedback, in the context of Extreme Programming (XP) values, goes beyond traditional human communication. We uncover the various sources of feedback, from pair programming to CI/CD pipelines, and how it plays a pivotal role in improving code quality and project management.

In this episode, we delve into the world of Extreme Programming (XP) values, with a particular focus on communication as key. We discuss the importance of effective communication in software development, especially in a remote work environment.

"Wie groß ist ein Epic?" oder "Ab wann ist eine User Story ein Epic?" - mindestens eine dieser beiden Fragen hören wir tatsächlich in quasi jedem Training, wenn es um die Arbeit mit User Stories oder Product Backlog Management geht. Offenbar besteht einiges an Unsicherheit rund um dieses Thema. Also haben sich Tim und Dominique das Thema "Epic" in dieser Episode mal vorgeknöpft. Sie klären nicht nur den Unterschied zu User Stories, sondern erzählen auch vom historischen Hintergrund des Begriffs. Die Frage lautet nämlich eigentlich viel eher: Warum gibt es keine Saga und Novel mehr? ...zumindest in Jira haben es diese anderen Begriffe nicht geschafft. Tim folgt eher die These (von Mike Cohn): "eine Story ist eine Story, ist eine Story..." Demnach ist ein Epic nur ein Label oder Kunstbegriff für eine sehr große Story. Aber andersrum: Wenn wir Stories aufteilen bzw. splitten, entstehen daraus doch ja auch nur wieder Stories. Und selbst wenn diese nochmals geschnitten werden müssen, kommen doch wieder nur (kleinere) Stories dabei heraus. Warum wir "nach oben" denn dann so ein "mythischer" Begriff verwendet. Dominique nutzt hingegen gerne Epics und berichtet im Gespräch davon ausführlich. Auch ein Umgang mit Epics in Jira wird von ihm entsprechend erläutert. Besonders spannend dürfte sein, was er macht, wenn nicht alle User Stories eines Epics umgesetzt werden. Einig sind sich beide, dass ein Epic einen Wert liefern muss. Es sei der Hinweis erlaubt, dass es im Skalierungs-Framework SAFe explizit den Begriff Epic verwendet. Dort ist es eine "significant solution development initiative") und es werden Business Epics und Enabler Epics unterschieden. Eine weitergehende Erklärung gibt es hier: https://scaledagileframework.com/epic/. Tim und Dominique gehen in dieser Episode aber bewusst nicht näher auf den Epic-Begriff in SAFe ein, sondern konzentrieren sich auf die aus dem Extreme Programming (XP) stammende Herkunft des Begriffes. Lieber beleuchten die beiden nämlich, welche Vorteile, aber auch welche Herausforderungen in der Arbeit mir Epics gibt. Und es ist auch spannend zu diskutieren, was denn fehlen würde, wenn man ganz auf die Verwendung von Epics verzichten würde. Wie in unserem Format üblich schließt die Folge mit einigen Tipps & Tricks zu diesem Thema. Passende Podcast-Folgen zum Thema "Epic": - Erfolgreich mit User Stories arbeiten - User Story Splitting: Wie geht das "richtig"? - Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? - Feature Breakdown: schnell User Stories finden und grob schätzen In der Produktwerker Box (https://produktwerker.de/box/) findest du zu den typischen Herausforderungen von Product Ownern von uns empfohlene Literatur, Artikel, Videos, Tools, Übungen etc. - ein Blick in folgende Themenbereiche lohnt sich im Kontext dieser Episode: - Gute User Stories schreiben bzw. formulieren - User Story Splitting: Anforderungen schneiden Wie sind deine Erfahrungen mit Epics? Hast du vielleicht eine andere Sicht oder arbeitest ganz anders mit Epics als wir berichtet haben? Vielleicht hast Du auch spezielle Tipps zum Umgang mit Epics in den diversen Tools: Jira, Azure DevOps (Team Foundation Server), Redmine, Trello, Asana, ... Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

 In part one of this three-part series, Andy and Mon-Chaio attempt to provide a research-supported answer on whether culture is important for your tech organization. They also dig into the details of whether a company should hire for cultural fit. Opening quote from "A Review Paper on Organizational Culture and Organizational Performance". References: A Review Paper on Organizational Culture and Organizational Performance - https://ijbssnet.com/journals/Vol._1_No._3_December_2010/4.pdf Some Social and Psychological Consequences of the Longwall Method of Coal-Getting - https://doi.org/10.1177/001872675100400101 Kurt Lewin's Force Field Analysis - https://www.ifm.eng.cam.ac.uk/research/dstools/force-field-analysis/ Extreme Programming (XP) - https://www.agilealliance.org/glossary/xp/ Organizational culture, person-culture fit, and turnover: a replication in the health care industry - https://doi.org/10.1002/(SICI)1099-1379(199903)20:23.0.CO;2-E London School of Economics: Should you hire for culture fit? - https://blogs.lse.ac.uk/businessreview/2022/05/05/should-you-hire-for-culture-fit/ American Psychological Association: What is Cognitive Behavioral Therapy? - https://www.apa.org/ptsd-guideline/patients-and-families/cognitive-behavioral --- Send in a voice message: https://podcasters.spotify.com/pod/show/tactics-tech-leadership/message

STOP saying Agile is a "Project Management Methodology" or a methodology or.....plain WRONG stuff like Agile and Scrum are the same thing!

1995 begann das Chrysler-C3-Projekt. Es wurde als erstes Projekt nach dem Extreme-Programming-Paradigma (XP) umgesetzt - einem radikalen Ansatz, der eine wichtige Rolle für Agilität gespielt hat. In dieser Episode sehen wir uns die Techniken des XP an und beleuchten XP kritisch. Gleichzeitig betrachten wir den enormen Einfluss von XP auf agile Software-Entwicklung und die heutigen Ansätze. Links Epsiode mit Prof. Dr. Christiane Floyd Remote Mob Programming mit Jochen Christ, Franziska Dessart, Simon Harrer, Martin Huber Welchen Sinn hat agiles Coaching? mit Johannes Link Buch Kent Beck, Cynthia Andres: Extreme Programming Explained - Emnbrace Change Buch Matt Stephens,Doug Rosenberg: Extreme Programming Refactored: The Case Against XP

Dragan Stepanović is a Senior Principal Engineer at Talabat. Dragan has experience working at different sizes of companies, from small to large corporates. He became interested in Extreme Programming (XP) early on in his career. Then, he started diving into architecture, Domain Driven Design (DDD) and LEAN as tools to enable engineers to maximise their throughput for their stakeholders.Renato Rodrigues de Araujo is a Senior Software Engineer at Form3. Renato is part of the Tooling Team, which is responsible for making the lives of engineers easier by maintaining internal tools.Our  .tech series invites guests inside and outside of Form3, discussing current trends in the engineering world alongside shedding light into some of the engineering practices here at Form3. Get in touch with us via this short form if you'd like to be  a podcast guest. 

When planning iOS work and writing iOS code, how fast are your feedback loops? How much fun are you having in your work? Are the two things related? Join Chris and Austin as they discuss with Jon Reid how fast feedback and fun in iOS development was greatly amplified for him. They first dive into discovery trees for visualizing work. Then after some "hot takes" on the state of architecture and design in iOS development, they jump into the impact of technical practices and Extreme Programming (XP) in that iOS world. Lastly, Jon shares on the joys of finally being on a full XP team.  Video and Show Notes: https://youtu.be/ndxjPNDWUjs  

Today on The Rabbit Hole we are talking about extreme programming and to help us with this we welcome our very own Kevin Thomas. Kevin is a consultant at Stride and a strong proponent of extreme programming! During the conversation we'll cover the values that typify XP and unpack the importance of each of these after looking briefly at a definition for the term.

Guest Mr. Brian Tan Seng (98Labs, Inc) of YoungCTO Rafi Quisumbing Application Developer, Linux Systems Administrator, Software Architect, and Project Manager in a wide array of business applications. Particularly interested in systems optimization, and Agile software development. Also interested in conducting training and advising corporations in adopting Agile methodologies. https://www.linkedin.com/in/briantans... Specialties: Agile Software Development, Scrum, Extreme Programming (XP), Lean Software Development, Java (Spring Framework, Hibernate, Struts 2), Groovy & Grails

Scrum, Kanban, Spotify Model e tantos outros métodos, frameworks e modelo na moda. E o eXtreme Programming (XP)? Aliás, você já ouviu, de fato, alguém falar sobre XP? Neste episódio gravado ao vivo numa live do Pravaler, Lula bate um papo descontraído com CFC, Daniel Wildt, Ceci Fernandes e Daniel Cukier sobre esse método essencial para equipes de desenvolvimento de software que buscam o True Agile. Ah, segue nosso insta: https://www.instagram.com/lovetheproblem/ E é claro que você também pode acessar nosso backstage para saber de tudo sobre este episódio e muito mais sobre o Love the Problem: http://k21.link/lovetheproblem

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. From the focus on Value and Product Vision to the aspect of growing great PO’s. Two aspects that Scrum Masters must keep in mind at all times.  The Great Product Owner: Sharing and evolving the product Vision at all times Great Product Owners aren’t afraid to share their Vision for the product or service they work with. But they also exhibit an interest in what other stakeholders (including the team) can bring to the product, and even change their Vision if that is needed. In this conversation with John, we discuss the focus on value, and how great PO’s focus the team on delivering value at all times.  In this episode, we refer to a previous episode on Lean and Agile Financial Planning, as well as the 2020 version of the Scrum Guide (PDF LINK). The Bad Product Owner: Helping grow great Product Owners. In this segment, we talk about how Scrum Masters can have a big influence on the role of the Product Owner. We discuss how that influence can derail the team, and the PO by focusing the PO on aspects that are not critical for the success of the team and the PO. We then discuss what Scrum Masters can do to help PO’s, starting from the perspective and experience they have at that time. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About John Albrecht Agile Person, for the team by the team, used to be a developer. Got into Agile 03/04 via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. When we discuss success with John, he brings up the idea that Scrum Masters that are successful have the ability to go off and do something else (outside the team) while the team focuses on their own goals and Sprint. In this episode, we also describe 7 characteristics of great Scrum teams. Featured Retrospective Format for the Week: Scrum Builders The Scrum Builders game that John Albrecht developed, is about helping teams reflect on their actions during the Sprint. John was working with a team at the time that was constantly overcommitting and needed to reflect on what was pushing them towards that anti-pattern. Listen in to learn how to use the game to help your teams reflect on their behavior during the Sprint. Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experiences: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!  About John Albrecht Agile Person, for the team by the team, used to be a developer. Got into Agile 03/04 via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. “Everything we do is about change.” This is the phrase we start the episode with. John shares his experience on how to bring and support change in organizations and teams. In particular, we hear the story of a startup, and how bringing people together to a shared goal was the task at hand.  In this episode, we talk about the Google Design Sprint as well as the NoEstimates book. About John Albrecht Agile Person, for the team by the team, used to be a developer. Got into Agile 03/04 via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. Conflict is a natural process in teams. How teams handle, and survive conflict becomes therefore a critical aspect of their work. In this episode, we explore some of the skills/tools that help teams survive and benefit from (constructive) conflict, instead of suffering and being destroyed by (destructive) conflict. Featured book of the Week: One From Many, The Rise Of The Chaordic Organization by Dee Hock In One From Many, The Rise Of The Chaordic Organization by Dee Hock, John found a book that gave him a different perspective of organizations and the role of “order” and “control” in management. In this real-life story about the creation of VISA (the credit card and payment processing organization), John found many ideas that help us navigate complex organizations. In this episode, we also talk about Wardley Maps, Complexity, and the Cynefin framework. About John Albrecht Agile Person, for the team by the team, used to be a developer. Got into Agile 03/04 via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. The story that John shares with us, starts when Project Management transformations were a thing. He went through a PRINCE2 adoption process, which led to the emergence of the inevitable silos. John started searching for better alternatives and found Extreme Programming, Scrum and Kanban. As he tried to play the servant leader role that comes with Scrum, however, he discovered that there’s a good and a bad way to be a servant leader. Listen in to learn when to stop serving, and when to be a true leader!  About John Albrecht Agile Person, for the team by the team, used to be a developer. Got into Agile 03/04 via Extreme Programming (XP), then Kanban, then Scrum. Some of his key ideas are Principles over Practices, #noestimates, love working with teams and organizations, the softer side, finding what they and customers need and what works for them.

In this episode Hannes Färberböck shares his rich, 20+ year history of agile and its various methodologies with us. Hannes is the Managing Director of Nagarro's Austrian operations and the had of their Testing Business Unit. He first started his journey by learning and applying Extreme Programming (XP), and then conducting trainings for other teams on XP. Hannes recalls hearing about the first ever XP conference, where many of the signatories of the Agile Manifesto were in attendance (before it actually existed). Looking back over time and seeing how agile has evolved, here are some of the changes that Hannes reflects on:+ There is more than one process you can use to be agile+ Companies can (and should) adapt those processes to meet their needs+ DevOps significantly helps reduce silos between dev teams and operations (he sees the next best version as DevTestOps). - Continuous Delivery: while it has the right goals, it can unintentionally turn "burndown charts" into "burnout charts" where teams never get a moment to take a breath. To that last point, we discussed the importance of NOT ignoring or delaying your continuous improvement focus. Whether it be a technical area like refactoring code, or a more interpersonal area like building trust on the team, these things cannot be delayed because we have too many things to deliver. Instead, we need to make them a routine that becomes part of the fabric of the organization.

Kent Beck is an American software engineer, writer and thought leader. He has been, and remains, one of the most influential figures in the field of software development over the past 20 years. He is best known as the creator of the eXtreme Programming (XP) software development methodology and proponent of Test Driven Development (TDD). In 2001 he was one of 17 signatories of the Agile Manifesto that started a movement which revolutionised the world of software development around the world. He first visited South Africa in 2005 as a guest of the JCSE. This initiated a long association between Kent and the software engineering community of South Africa and Africa. In this episode Kent is in discussion with Prof Barry and his co-host Kerryn Gammie. If life is a relay race, what is the baton he will hand over to Kerryn and her generation of Africa's future digital leaders.

Kent Beck is an American software engineer, writer and thought leader. He has been, and remains, one of the most influential figures in the field of software development over the past 20 years. He is best known as the creator of the eXtreme Programming (XP) software development methodology and proponent of Test Driven Development (TDD). In 2001 he was one of 17 signatories of the Agile Manifesto that started a movement which revolutionised the world of software development around the world. He first visited South Africa in 2005 as a guest of the JCSE. This initiated a long association between Kent and the software engineering community of South Africa and Africa. In this episode Kent is in discussion with Prof Barry and his co-host Kerryn Gammie. If life is a relay race, what is the baton he will hand over to Kerryn and her generation of Africa’s future digital leaders.

“Agile is a devastated wasteland. The life has been sucked out of it.” Those are the words of Kent Beck, creator of Extreme Programming, and co-signer of the Agile Manifesto. According to Kent, many development teams have adopted Agile methodologies without understanding their purpose. In today's episode, we've recruited Aaron Foster Braylin and Steve Solomon for a deep dive into Agile, with a special focus on comparing Extreme Programming (XP) and Scrum. We begin by exploring what stand-ups mean for each guest before discussing Scrum's openness to incorporate processes, so long as they work.

In today’s episode, Jeffrey Palermo is joined by a really exciting guest; Robert C Martin, better known as Uncle Bob Martin!   If you don’t already know Bob, he is a software engineer, instructor, and best-selling author. He is most recognized for developing numerous software design principles and for being a founder of the incredibly influential Agile Manifesto. Bob is the author of a number of Clean Code related books including his latest, Clean Agile: Back to Basics, where he reintroduces Agile values and principles for a new generation of programmers and nonprogrammers alike. In the past, Bob was also the editor-in-chief of C++ Report magazine and served as the first chairman of the Agile Alliance.   In this episode, Jeffrey and Bob talk all things Agile and Extreme Programming (XP). Bob shares his insights on what would be on his shortlist if he was building an Agile team today; shares key takeaways from his book, Clean Agile: Back to Basics; and speaks about what XP looks like in 2020. He also touches on clean architecture, clean code, his predictions for the future of the software industry, and offers some timely tips for young developers!   Topics of Discussion: [:38] Be sure to visit AzureDevOps.Show for past episodes and show notes. [:46] About The Azure DevOps Podcast and Jeffrey’s offer to speak at virtual user groups. [1:42] About today’s episode with Bob Martin. [2:10] Jeffrey welcomes Bob to the podcast. [2:20] Bob shares some background about who he is as well as the proudest moment in his career. [4:09] Why did Bob decide to write Clean Agile: Back to Basics? [5:28] If someone was building an Agile team today, what would be on Bob’s shortlist of recommendations? [7:38] What does Extreme Programming (XP) look like in 2020? What are the concrete practices? [9:32] What does Bob see as the current best standard for a programmer in this COVID world? [12:31] Bob defines the practice of continuous integration. [14:58] Is Bob a fan of feature branches? [15:29] A word from Azure DevOps Podcast’s sponsor: Clear Measure. [16:00] Bob’s journey with getting started with clean architecture. [19:23] Is there a way to do clean architecture with the modern tooling available? Or are there things available to attempt to get closer to it? [21:32] Bob shares the origin of literate programming. [23:11] The modern struggle with tooling. [25:15] Bob talks ‘DLL Hell’. [26:00] Bob shares why it is so incredibly important to keep clean code; code that is free from dependencies. He also explains how to get to that point and offers some advice to young programmers. [31:55] Bob shares his predictions on the future of the software industry. [37:13] Jeffrey thanks Bob for joining the podcast!   Mentioned in this Episode: Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! bit.ly/dotnetdevopsebook — Click here to download the .NET DevOps for Azure ebook! Jeffrey Palermo’s Youtube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! The Azure DevOps Podcast’s Twitter: @AzureDevOpsShow Robert C. Martin Clean Agile: Back to Basics, by Robert C. Martin Robert C.Martin’s Amazon Book Page @UncleBobMartin (Bob Martin’s Twitter) Clean Coders Extreme Programming Explained, by Kent Beck Clean Architecture: A Craftsman's Guide to Software Structure and Design, by Robert C. Martin DLL Hell   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.  

Episode 40 of the Modern Agile Show features an interview with Elisabeth Hendrickson, a veteran tester, developer, agilist, trainer, author and former executive of Research and Development at Pivotal. We discuss how Elisabeth first got into agile development and what a paradigm shift Extreme Programming (XP) was for her. We discuss her definition of agile and how she has applied agile principles to her work. We discuss how the testing community first reacted to practices like Test-Driven Development. We also discuss Exploratory Testing, the impact it's had on agile development and Elisabeth's book on the subject, called Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing.

Craig and Tony are at YOW! Conference in Brisbane and have a rockstar moment and catchup with Kent Beck, the creator of Extreme Programming, the pioneer of xUnit and author of numerous books including “Extreme Programming Explained” and “Test Driven Development“: Extreme Programming (XP) was born at Chrysler by letting go of conventional wisdom and … Continue reading →

I recently read a very well written blog post about using Domain driven design to determine whether teams should be set up in a feature or component-based teams. Philippe Bourgau, the author of the blog was kind enough to spare a few minutes and come on to talk to us about eXtreme Programming (XP) and…… Continue reading Episode 8: Is XP the middle child of Agile? with Philippe Bourgau

Sponsors KendoUI Sentry use the code “devchat” for $100 credit Clubhouse Panel AJ O’Neal Aimee Knight Joe Eames Charles Max Wood Special Guest: James Shore Episode Summary James Shore is a developer who specializing in extreme programming, an Agile method. He also used to host a screencast called Let’s Code Test-Driven JavaScript. They begin by discussing the core of Agile development, which James believes is being responsive to customers and business partners in a way that’s sustainable and humane for the programmers involved. It prioritizes individuals and interactions over processes and tools. More can be found in The Agile Manifesto. James delves into the historical context of the immersion of Agile and how things have changed from the 90’s. Now, the name Agile is everywhere, but the ideals of agile are not as common. There is a tendency to either take Agile buzzwords and apply them to the way it was done long ago, or it’s absolute chaos. James talks about ways to implement Agile in the workplace. He believes that the best way to learn Agile is work with someone who knows Agile, or read a book on it and then apply it. James recommends his book The Art of Agile Development: Pragmatic Guide to Agile Software Development for people who want to started with Agile development. The panelists talk about where people often get stuck with implementing Agile. The hosts talk about their own processes in their company. They discuss how people involved in the early days of Agile are disappointed in how commercial it has become.They agree that what’s really the most important is the results. If you can respond to a request to change direction in less than two weeks and you don’t have to spend months and months preparing something, and you do that in a way where the people on the team feel like their contributing, then you’re doing Agile. James thinks that the true genius of Agile is in the way the actual work is done rather than in the way your organize the work. Links Agile Scrum Waterfall Feature Driven Development Extreme Programming (XP) Jira Bamboo Confluence Atlassian stack Cowboy Mock objects Grows Method by Andy Hunt Picks AJ O’Neal: Origin by Dan Brown Searching Aimee Knight: Hacker News Interview Questions Thread. Joe Eames: The Ballad of Buster Scruggs on Netflix Charles Max Wood: Getting up early John Sonmez Kanbanflow video Drip James Shore: Lost in Space on Netflix Star Citizen PC game Jame’s Agile book online

Sponsors KendoUI Sentry use the code “devchat” for $100 credit Clubhouse Panel AJ O’Neal Aimee Knight Joe Eames Charles Max Wood Special Guest: James Shore Episode Summary James Shore is a developer who specializing in extreme programming, an Agile method. He also used to host a screencast called Let’s Code Test-Driven JavaScript. They begin by discussing the core of Agile development, which James believes is being responsive to customers and business partners in a way that’s sustainable and humane for the programmers involved. It prioritizes individuals and interactions over processes and tools. More can be found in The Agile Manifesto. James delves into the historical context of the immersion of Agile and how things have changed from the 90’s. Now, the name Agile is everywhere, but the ideals of agile are not as common. There is a tendency to either take Agile buzzwords and apply them to the way it was done long ago, or it’s absolute chaos. James talks about ways to implement Agile in the workplace. He believes that the best way to learn Agile is work with someone who knows Agile, or read a book on it and then apply it. James recommends his book The Art of Agile Development: Pragmatic Guide to Agile Software Development for people who want to started with Agile development. The panelists talk about where people often get stuck with implementing Agile. The hosts talk about their own processes in their company. They discuss how people involved in the early days of Agile are disappointed in how commercial it has become.They agree that what’s really the most important is the results. If you can respond to a request to change direction in less than two weeks and you don’t have to spend months and months preparing something, and you do that in a way where the people on the team feel like their contributing, then you’re doing Agile. James thinks that the true genius of Agile is in the way the actual work is done rather than in the way your organize the work. Links Agile Scrum Waterfall Feature Driven Development Extreme Programming (XP) Jira Bamboo Confluence Atlassian stack Cowboy Mock objects Grows Method by Andy Hunt Picks AJ O’Neal: Origin by Dan Brown Searching Aimee Knight: Hacker News Interview Questions Thread. Joe Eames: The Ballad of Buster Scruggs on Netflix Charles Max Wood: Getting up early John Sonmez Kanbanflow video Drip James Shore: Lost in Space on Netflix Star Citizen PC game Jame’s Agile book online

Sponsors KendoUI Sentry use the code “devchat” for $100 credit Clubhouse Panel AJ O’Neal Aimee Knight Joe Eames Charles Max Wood Special Guest: James Shore Episode Summary James Shore is a developer who specializing in extreme programming, an Agile method. He also used to host a screencast called Let’s Code Test-Driven JavaScript. They begin by discussing the core of Agile development, which James believes is being responsive to customers and business partners in a way that’s sustainable and humane for the programmers involved. It prioritizes individuals and interactions over processes and tools. More can be found in The Agile Manifesto. James delves into the historical context of the immersion of Agile and how things have changed from the 90’s. Now, the name Agile is everywhere, but the ideals of agile are not as common. There is a tendency to either take Agile buzzwords and apply them to the way it was done long ago, or it’s absolute chaos. James talks about ways to implement Agile in the workplace. He believes that the best way to learn Agile is work with someone who knows Agile, or read a book on it and then apply it. James recommends his book The Art of Agile Development: Pragmatic Guide to Agile Software Development for people who want to started with Agile development. The panelists talk about where people often get stuck with implementing Agile. The hosts talk about their own processes in their company. They discuss how people involved in the early days of Agile are disappointed in how commercial it has become.They agree that what’s really the most important is the results. If you can respond to a request to change direction in less than two weeks and you don’t have to spend months and months preparing something, and you do that in a way where the people on the team feel like their contributing, then you’re doing Agile. James thinks that the true genius of Agile is in the way the actual work is done rather than in the way your organize the work. Links Agile Scrum Waterfall Feature Driven Development Extreme Programming (XP) Jira Bamboo Confluence Atlassian stack Cowboy Mock objects Grows Method by Andy Hunt Picks AJ O’Neal: Origin by Dan Brown Searching Aimee Knight: Hacker News Interview Questions Thread. Joe Eames: The Ballad of Buster Scruggs on Netflix Charles Max Wood: Getting up early John Sonmez Kanbanflow video Drip James Shore: Lost in Space on Netflix Star Citizen PC game Jame’s Agile book online

Today, Phil chats with James Shore. James teaches, writes and consults on Agile development processes. He is a recipient of the Agile Alliance’s Gordon Pask Award for Contributions to Agile Practice, co-creator of the Agile Fluency Model, and co-author of “The Art of Agile Development”. James has also been named as one of “the most influential people in Agile” by InfoQ. KEY TAKEAWAYS: ­­­(0.31) – Phil started by asking James to tell everyone a bit more about himself. James explained that he started his I.T. career as a programmer. In 1999, he was introduced to what was known as Extreme Programming (XP), which is the most prominent of the Agile software development methodologies. At first, James was not convinced, but when he tried it, he was hooked. So much so, that he decided he could not work any other way. At the time, he could not find anybody else working the XP way, so he decided to teach the method himself. That is how he became an Agile consultant. (2.45) – Phil and James discuss the fact that Agile is not new. It has been around for just over 20 years now and the movement is really gathering pace. However, James does point out that “a lot of what people call Agile is not really Agile.” The quality of implementation varies quite a bit. (3.26) – Phil asks James to share a unique IT career tip. James responded by saying you need to “make a point of understanding the business impact of what you're doing." He went on to remind everyone that a typical software team costs circa $1 million to run. A cost that has to be covered by the value the team adds to the business. He highlighted the fact that a 5% improvement in a team’s performance is worth at least $50,000. When you ask for something to improve efficiency remember to make the business case and explain the cost savings clearly. (4.44) – Phil asked James to share a business experience from which he learned something important. For James that happened 20 years ago. At the time he was working for the firm that provided the robots used by Intel to move silicone around on its chip production line. James was part of a team who worked on a distributed system that had multiple services running on different computers. Each service worked in its own environment, but when they hooked it all up the problems began. At the time, the waterfall or phase gate development method was the norm for software development. It was supposed to be a flawless development process. But, in reality, it was not. That project and several others James worked on that followed the standard “waterfall” method were disasters. At that point, James realized the futility of a development method that tried to predict everything in advance, lock things down and come up with the entire design. He also saw how dangerous it was to wait to the very end to validate the work and make the biggest decisions. It was then he understood the flaws of the way development was managed 20 years ago. It was this experience that helped him to recognize the true value of Agile development methods when he was introduced to them. (8.51) – Phil asks what James considered to be his best career moment. James explained that about two years ago he consulted for a start-up that had just gone public and had growing pains. They had 40 teams, so keeping tabs on what they were all doing was impossible. Plus, there was a lot of interdependency between teams, so everything took forever. James discovered that waiting around for another team to do something was causing 95% of the delays. On one project, during a 3-month period, only 3 or 4 days of real work could be done. This stop-start, multitasking way of working, was terrible for focus too. James minimized the teams and got the firm to start by working on the smallest projects that added value, first. These changes minimized the amount of inter-team dependency and got everyone working together and actually delivering working projects fast. He also encouraged teams to solve more of their problems internally. The net result of his changes was that they reduced the delays from 95% to 0%. Most MMFs were completed in just a week or two. The company thrived and grew very quickly. (12.49) – Phil wants to know what excites James about the future for the IT industry. James explains that the fact the industry is so young is exciting because it means change is possible and can happen quickly. Agile is the exact opposite of the Waterfall way of working, yet in less than 20 years people have adopted this new way of working. That is a 180-degree change. In an older industry that just would not happen. In I.T you can suggest new ideas and people will actually be willing to try them.  (15.05) – What is the best career advice you have been given? James responded with three words “be well-rounded”. (15.11) Phil asks if you were to begin your I.T. career again, right now, what would you do? James says that he would focus on networking and finding a mentor. (15.20) – Phil asks James what he is focusing on, right now. James says he is really focused on his business The Agile Fluency project. (15.29) – What is your most important non-technical skill, the one that has helped you the most in your career, so far? James says my “curiosity, flexibility, and a desire and willingness to experiment.” (15.40) – Phil asks James to share a final piece of career advice. James says that if you are working somewhere that does not enable you to do your best work you should try to change that from within. If you discover that is not possible, you need to move on and work for another organization. BEST MOMENTS:  (3.13) - James - “A lot of what people call Agile is not really Agile.” "The actual implementation tends to vary in quality by quite a bit." (3.25) - James - "One of the most valuable things that you can do for your career is to make a point of understanding the business impact of what you're doing." (11.50) - James - "We went from 95% delay for most teams we got it down to zero delays, no delay at all." (12.12) - James - "It's a big cultural mindset change. And making that sort of change requires making sure that everybody's involved and understands how they benefit from this change." (13.15) - James - "Every single company of any size whatsoever needs software. Anybody that's larger than tiny needs custom software." (13.25) - James - "It's a young industry. It's open to new ideas and ways of working." (13.37) - James - "Best practices, at the time, was waterfall, which is basically the exact opposite of agile and now 20 years later, agile has taken over the world." (16.08) - James - "Don't put up with mediocrity. Don't put up with a lousy work environment, just because it's got a great salary."   CONTACT JAMES SHORE:   Linkedin – https://www.linkedin.com/in/james-shore-7475b6/ Twitter – https://twitter.com/jamesshore@jamesshore Website – www.agilefluency.org Personal Website – www.jamesshore.com  

Today on The Rabbit Hole we are talking about extreme programming and to help us with this we welcome our very own Kevin Thomas. Kevin is a consultant at Stride and a strong proponent of extreme programming!

(@KevinTrethewey) and Danie Roux (@danieroux) joined Ryan Ripley (@ryanripley) to discuss the Spine Model and how to use it effectively with agile and scrum teams.Kevin Trethewey  [featured-image single_newwindow=”false”]Danie Roux Presenting[/featured-image] In this episode you'll discover: What the Spine Model is. How to use the Spine Model with your agile teams Use the Spine Model to find common ground Applying system thinking to team dynamics Links from the show: The Spine Model website – http://spinemodel.info/wiki.html Kevin Trethewey’s Site – https://kevintrethewey.com/ Danie Roux’s Site – http://www.danieroux.com/ Agile 2015 Talk on the Spine Model – http://spinemodel.info/news/agile2015talk.html Team Tourism – https://kevintrethewey.com/projects/teamtourism/ How to support the show: Thank you for your support. Here are some of the ways to contribute to the show: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for Humans Rate us on iTunes and leave an honest review Join the mailing list – Check out the form on the right side of the page Take the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested in Leadership Gift Program Make a donation via Patreon Book of the Week: [callout]Accountability. Transparency. Responsibility. These are not words that are often applied to software development. In this completely revised introduction to Extreme Programming (XP), Kent Beck describes how to improve your software development by integrating these highly desirable concepts into your daily development process. The first edition of Extreme Programming Explained is a classic. It won awards for its then-radical ideas for improving small-team development, such as having developers write automated tests for their own code and having the whole team plan weekly. Much has changed in five years. This completely rewritten second edition expands the scope of XP to teams of any size by suggesting a program of continuous improvement. Click here to purchase on Amazon.[/callout] [reminder]Which topic resonated with you? Please leave your thoughts in the comment section below.[/reminder] Related Episode: Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. Help promote the show on iTunes: One tiny favor.  — Please take 30 seconds now and leave a review on iTunes. This helps others learn about the show and grows our audience. It will help the show tremendously, including my ability to bring on more great guests for all of us to learn from. Thanks! Agile Dev West conference offers you the perfect opportunity to get away from distractions to immerse yourself and improve your agile skills in hot areas such as agile and lean development, scaled agile development, agile teams and leadership, digital transformation, and more. Agile for Humans listeners use code “AFH18” to receive 10% off their conference registration. Check out the entire program at adcwest.techwell.com. You'll notice that I'm speaking there again this year. Attendees will have a chance to participate in my half-day sessions on advanced scrum topics called Coaching Workshop: Taking Your Scrum to the Next Level, as well as Rethinking Your Retrospectives. I hope to see many Agile for Humans listeners in Las Vegas – June 3-8, for this great event. The post AFH 090: Walking the Spine Model appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

In dieser Folge sprechen wir mit Daniel Hommel. Seit Daniels achten Lebensjahr ist Softwareentwicklung sein Steckenpferd. Ab 2005 begann er die Praktiken des Extreme Programming (XP) immer ernsthafter anzuwenden und fing an, sich mit Software Craftmanship und Clean Code zu befassen. Nach über 10 Jahren als Entwickler wurde er 2011 in die Rolle des ScrumMasters gerufen. Heute brennt er als Agile Coach vor allem dafür, Veränderungsprozesse zu begleiten, um die versteckten Potenziale in Unternehmen zu heben. Hier sind die Key Take-aways aus dem Podcast: Key Take-aways: Passion braucht Balance [...] Ja, das hat für mich eher etwas mit so einer Balance zu tun. Also, ich glaube gerade, wenn man etwas Großes erreichen möchte, was ein bisschen länger dauert, muss man halt auch auf seine Energiereserven und auf andere Dinge, die einem/ So etwas wie eine Familie ist ja auch Support. Ja, unterstützt ja auch. Gibt auch Halt. Auf solche Dinge muss man dann umso mehr achten. Finde ich. Also, für mich bedeutet Passion nicht unbedingt blind links irgendwo rein zu rennen, bis ich komplett verbrannt bin. [...] Ein gutes Team ist wie ein Piratenschiff [...] Also so, man segelt gemeinsam singend auf unbekanntes Gewässer raus, um irgendwie einen Schatz zu heben oder zu finden oder zu klauen. Ja? Und legt sich dabei durchaus auch mal mit dem einen oder anderen Königreich an. Also so, das ist die andere Metapher. Dieses Piratenschiff, was mir da noch eingefallen ist. [...] Passionierte Teams brauchen Feedback [...] Ja. Ich denke, was daran spannend ist, wir hatten am Schluss so als Fazit, dass alle agilen Methoden irgendwie darauf ausgelegt sind, Feedbackloops herzustellen oder zu verkürzen. Im sozialen, technischen Bereich, im Businessbereich, überall eigentlich. Das bringt mich wieder zurück zu dem Thema Feedback. Also ich kann eigentlich nicht genug Feedback in meinem Team leben und irgendwie schauen, dass ich an so viel wie möglichen Stellen anbringe. [...] Passionierte Teams brauchen passionierte Menschen Jetzt kann man sich schon fragen, gerade als Coach: Ist das nicht der erste Schritt? Also, im agilen Manifest steht ja: Build teams arround motivated individuals. Ist der erste Schritt vielleicht auch den Leuten einen Weg aufzuzeigen, dass jeder individuell seiner Passion vielleicht nachgeben kann, um daraus dann passionierte Teams aufzubauen. Mal so eine grüne These in den Raum gestellt.   Links: Shower of appreciation (http://www.miarka.com/shower-of-appreciation-or-talking-behind-ones-back/) Link zur Havard Business Review (https://hbr.org/cover-story/2017/09/work-and-the-loneliness-epidemic)

Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Esta metodologia foi criada por Kent Beck durante seu trabalho na Chrysler, onde se tornou líder de um importante projeto em março de 1996 e onde também começou a refinar o método que estava utilizando nos projetos.O método de Kent Beck em Outubro de 1999 se tornou o livro Extreme Programming Explained, o primeiro e mais famoso livro sobre XP.Extreme Programming vem fazendo sucesso e seus objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que serão tema do Papo de Casal de hoje.Baixe o episódio aqui!

The FAST Agile is a combination of Open Space Technology, Scrum, Extreme Programming (XP), and Story Mapping. After watching hundreds of participants use open space technology to organize and hold a conference, Ron decided that such self-organization practices could also be applied to software development.Rather than relying control mechanisms like SAFe and LeSS, FAST Agile is a scalable agile framework that relies and individuals and interactions along with pulling work in to teams. Utilizing a 2 day sprint, FAST Agile implicitly requires teams to break their work down in to small chunks and to swarm the work in a #MobProgramming fashion.

Hosts Ryan Ripley, Ron Quartel Discussion Ron Quartel (@AgileAgitator) is an agile coach, blogger (blog.agileagitator.com) and the creator of the FAST Agile framework. The FAST Agile (www.fast-agile.com) is a combination of Open Space Technology, Scrum, Extreme Programming (XP), and Story Mapping. After watching hundreds of participants use open space technology to organize and hold a conference, Ron decided that such self-organization practices could also be applied to software development. Rather than relying control mechanisms like SAFe and LeSS, FAST Agile is a scalable agile framework that relies and individuals and interactions along with pulling work in to teams. Utilizing a 2 day sprint, FAST Agile implicitly requires teams to break their work down in to small chunks and to swarm the work in a #MobProgramming fashion. Documentation on the FAST Agile framework can be found at (www.fast-agile.com). We then moved on to the pain points of agile coaching, including: Fixing bad scrum implementations over and over again Lack of XP usage on scrum teams Mis-understanding of what makes scrum work Especially surprising is the low adoption rates of XP on scrum teams. According to the Scrum Alliance State of Scrum Survey 2015, only 16% of scrum teams also practice XP. The Version One survey had the usage rate even lower. Ron is giving a talk at Agile 2015 about using Scrum and XP for Hyper-productivity. If you're going to be in DC for the “big conference” this is a must see session. Finally, we wrapped up with a conversation about agile certifications. While the classes are good, Ron questions the value of “certifying” CSM's after a 2-day course. He started the #SayNoToAgileCertifications and hopes to see improvements in this area. And then…we called it a night. Resources, Plugs, and More Ryan – http://agileanswerman.com Extreme Programming Explained – Kent Beck Scrum – Jeff Sutherland Ron – http://blog.agileagitator.com FAST Agile Thinking Fast and Slow by Daniel Kahneman Wisdom of Crowds by James Surowiecki The People's Scrum by Tobias Mayer Agile 2015 Talk – Scrum and XP for Hyper-productivity The Land That Scrum Forgot – Bob Martin The post AFH 010: FAST Agile with Ron Quartel [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Jade Meskill: Hello, and welcome to another episode of the Agile Weekly Podcast, I'm Jade Meskill.

This is the first of two episodes where Arno and Alex discuss eXtreme Programming in se-radio's development process track. eXtreme Programming (XP) revolutionized the way of thinking about software development methodologies and helped to make the agile movement popular. In this episode they discuss the very basics of XP, its value system, principles and the basic practices used in an XP project. The second episode will continue the introduction adding the missing practices and how to introduce XP into projects.

This is the first of two episodes where Arno and Alex discuss eXtreme Programming in se-radio's development process track. eXtreme Programming (XP) revolutionized the way of thinking about software development methodologies and helped to make the agile movement popular. In this episode they discuss the very basics of XP, its value system, principles and the basic practices used in an XP project. The second episode will continue the introduction adding the missing practices and how to introduce XP into projects.

This is the first of two episodes where Arno and Alex discuss eXtreme Programming in se-radio's development process track. eXtreme Programming (XP) revolutionized the way of thinking about software development methodologies and helped to make the agile movement popular. In this episode they discuss the very basics of XP, its value system, principles and the basic practices used in an XP project. The second episode will continue the introduction adding the missing practices and how to introduce XP into projects.

Extreme Programming (XP) ist eine seit einigen Jahren immer populärer werdende Methode zur Entwicklung von Software in kleineren Teams. Die teilweise radikalen Änderungen im Vergleich zur "traditionellen" Vorgehensweisen erfordern umfangreiches Umdenken in technischen und sozialen Prozessen, bieten aber die Möglichkeit der Beherrschung zuvor schwer zu bändigender Dynamiken. Ängste, mangelnde Offenheit und Kommunikation sowohl auf Seiten des Auftraggebers als auch der Entwickler sind häufig bereits der Anfang vom Ende jeder erfolgreichen Softwareentwicklung. Extreme Programming begegnet diesemn Problemen durch kooperative Entwicklungsmodelle (Pair Programming), iterative Verfeinerungen der Aufgabenstellung undJ Konzentration auf schnelle Releasesyklen und Testbarkeit von Systemen. Pavel berichtet aus seinen jahrelangen und mehrheitlich positiven Erfahrungen in der konkreten Anwendung von Extreme Programming im Unternehmen und erläutert, welche Schritte nötig waren, um diese Umstellung zu einem Erfolg zu führen, welche langfristigen Effekte das hatte.