Let me help you both: **Summary of What Extreme Programming (XP) Is:** Extreme Programming (XP) is an agile software development methodology that emphasizes improving software quality and responsiveness to changing customer requirements through a focus on teamwork, communication, and technical excellence. Key aspects of XP include: - **Core Values:** XP is built on five foundational values: - **Communication:** Encouraging open, direct, and continuous dialogue among team members and stakeholders. - **Feedback:** Obtaining regular feedback from customers and team members to guide development. - **Simplicity:** Striving for the simplest solution that works, avoiding unnecessary complexity. - **Courage:** Facing challenges head-on, including adapting to changes and refactoring code. - **Respect:** Valuing each team member's contributions and fostering a supportive environment. - **Practices and Techniques:** - **Short Development Cycles:** Implementing frequent iterations (often one to two weeks) to deliver functional software quickly and receive early feedback. - **Incremental Planning:** Developing a flexible plan that evolves with the project's needs, allowing for adjustments as requirements change. - **Flexible Scheduling:** Prioritizing features based on business value and allowing for re-prioritization as needed. - **Automated Testing:** Using tests written by programmers, customers, and testers to ensure code quality and catch defects early. - **Continuous Integration and Evolutionary Design:** Regularly integrating code changes and continuously improving the system's design. - **Collaborative Teamwork:** Promoting close collaboration among team members, including pair programming and shared code ownership. - **Customer Involvement:** Including business-oriented individuals as part of the team to provide ongoing input and clarification of requirements. - **Risk Management:** XP addresses various risks in software development by: - Delivering the most valuable features first to maximize business value. - Maintaining a deployable system at all times to prevent accumulation of defects. - Adapting quickly to changing requirements or business conditions. - **Cultural and Social Change:** - **Embracing Vulnerability:** Encouraging team members to be open about their capabilities and limitations. - **Continuous Improvement:** Fostering an environment where individuals strive to improve their skills and contribute to team goals. - **Human-Centric Approach:** Recognizing that good relationships and humane work practices enhance productivity and job satisfaction. In essence, XP is about combining effective technical practices with a supportive team environment to produce high-quality software that meets customer needs. It involves letting go of outdated habits, embracing collaboration, and continuously adapting both the process and the product for optimal results. Or in my words: "Its one way to implement the Agile Manifesto for smaller development teams"
It's easy enough to find out More group and pair programming, no PRs, more face to face, less typey typey, more talky talky Programmers used to love that stuff until the scrum and agile coaches got involved
"Old school" XPer here, first working with it in 2000, and I couldn't agree more! I'm actually seeing a resurgence of interest in the technical practices now that the bloom is finally off the rose that was Scrum.
I liked the discussion, but I don't get what you mean with "The Reason Extreme Programming Works Better Than Anything Else". Joy at work? I sure like that. Strong relationships? That, too. Like it a lot. The video is a bit unclear about it. From the title I expected something else.
I once consulted with a team, whose "founder/cto" was doing all the code reviews. And he was only allocating his Sunday mornings for the code reviews. So his team was each time waiting for a full week before they got the feedback telling them what should be fixed, and then waiting for another week to get a confirmation that it is okay to deploy. Once I verbalized this to the whole team, they instantly understood the problem themselves. So many people simply don't understand how to "look at things" correctly.
I had a similar problem, but not with CTO. It was my architect. I had to practically beg him to review my PRs. Without prodding, he'd do it at the end of the sprint.
Regardless, there are just some that don't want to believe and prefer the tried-and-true Chaos programming method because they have experience with that one the most. The reasons why they wanted to ignore XP or Scrum, or any Agile process, they'd tell me that: "That's the always the way the projects go regardless of planning", "Agile isn't designed for projects with deadlines", "It's always been done this way and for 20 years it has worked successfully, so why change it?" Oh, I'm sure we've all heard these and more! Come on Comment section, don't disappoint me, let's hear some good old fashioned war stories from work! LOL
scrum has all the technical stuff removed. just by answering a small multiple choice test anyone, even managers, can easily become scrum masters and/or pos. i believe that the first offering of scrum certifications, just one year after the agile manifesto, was the beginning of the end of agile.
@@m13v2 "scrum has all the technical stuff removed." not really In the very first book on scrum, it was stated that the best way to use scrum, was in collaboration with XP. So they saw it as complimentary.
It would be awesome to have James Bach on the Engineering Room. He has worked in Apple in the late 80s and, if not the one, is one of the most influential testers in the industry throughout the decades.
We have been using XP for five years now as I (as an architect) have actively fought Agile within my area of our org. Oddly enough, I didn't even term it as Extreme Programming when I first promoted it, but discovered the term for it by watching your channel. The slow speed of delivery of our development groups were due to large amounts of disparate legacy code/languages/projects and not their processes. However, the *velocity of value* difference for our Agile vs. XP teams is very obvious.
IMO, pair programming works, even if the "pair" is seemingly "mismatched"". If they aren't idiots. They will end up with, we agree to hate each other, and now: Let's not talk tasks, let's talk goals. Then, who needs to do which task, when, to get there. And then restart hating each other again, if we can manage to do so, when the job is done.
Ha! Thx! The pull request is the worst moment to make a code review. And the dark role git has here, oh dear. Bad coders with the intelligence to dominate projects to get those stucked are having a big long party.
But the main product of software engineering is not a learning. Just like the main product of civil engineering is not learning how to build bridges but a bridge.
No one explains what Extreme Programming actually is in this video!
Exactly. Disappointed.
Let me help you both:
**Summary of What Extreme Programming (XP) Is:**
Extreme Programming (XP) is an agile software development methodology that emphasizes improving software quality and responsiveness to changing customer requirements through a focus on teamwork, communication, and technical excellence. Key aspects of XP include:
- **Core Values:** XP is built on five foundational values:
- **Communication:** Encouraging open, direct, and continuous dialogue among team members and stakeholders.
- **Feedback:** Obtaining regular feedback from customers and team members to guide development.
- **Simplicity:** Striving for the simplest solution that works, avoiding unnecessary complexity.
- **Courage:** Facing challenges head-on, including adapting to changes and refactoring code.
- **Respect:** Valuing each team member's contributions and fostering a supportive environment.
- **Practices and Techniques:**
- **Short Development Cycles:** Implementing frequent iterations (often one to two weeks) to deliver functional software quickly and receive early feedback.
- **Incremental Planning:** Developing a flexible plan that evolves with the project's needs, allowing for adjustments as requirements change.
- **Flexible Scheduling:** Prioritizing features based on business value and allowing for re-prioritization as needed.
- **Automated Testing:** Using tests written by programmers, customers, and testers to ensure code quality and catch defects early.
- **Continuous Integration and Evolutionary Design:** Regularly integrating code changes and continuously improving the system's design.
- **Collaborative Teamwork:** Promoting close collaboration among team members, including pair programming and shared code ownership.
- **Customer Involvement:** Including business-oriented individuals as part of the team to provide ongoing input and clarification of requirements.
- **Risk Management:** XP addresses various risks in software development by:
- Delivering the most valuable features first to maximize business value.
- Maintaining a deployable system at all times to prevent accumulation of defects.
- Adapting quickly to changing requirements or business conditions.
- **Cultural and Social Change:**
- **Embracing Vulnerability:** Encouraging team members to be open about their capabilities and limitations.
- **Continuous Improvement:** Fostering an environment where individuals strive to improve their skills and contribute to team goals.
- **Human-Centric Approach:** Recognizing that good relationships and humane work practices enhance productivity and job satisfaction.
In essence, XP is about combining effective technical practices with a supportive team environment to produce high-quality software that meets customer needs. It involves letting go of outdated habits, embracing collaboration, and continuously adapting both the process and the product for optimal results.
Or in my words: "Its one way to implement the Agile Manifesto for smaller development teams"
It's easy enough to find out
More group and pair programming, no PRs, more face to face, less typey typey, more talky talky
Programmers used to love that stuff until the scrum and agile coaches got involved
It's completely explained in the relatively short book "Extreme Programming explained"
"Old school" XPer here, first working with it in 2000, and I couldn't agree more! I'm actually seeing a resurgence of interest in the technical practices now that the bloom is finally off the rose that was Scrum.
I liked the discussion, but I don't get what you mean with "The Reason Extreme Programming Works Better Than Anything Else". Joy at work? I sure like that. Strong relationships? That, too. Like it a lot. The video is a bit unclear about it. From the title I expected something else.
I once consulted with a team, whose "founder/cto" was doing all the code reviews. And he was only allocating his Sunday mornings for the code reviews. So his team was each time waiting for a full week before they got the feedback telling them what should be fixed, and then waiting for another week to get a confirmation that it is okay to deploy. Once I verbalized this to the whole team, they instantly understood the problem themselves. So many people simply don't understand how to "look at things" correctly.
I had a similar problem, but not with CTO. It was my architect. I had to practically beg him to review my PRs. Without prodding, he'd do it at the end of the sprint.
it‘s called waterfall: working in phases separated from each other.
Regardless, there are just some that don't want to believe and prefer the tried-and-true Chaos programming method because they have experience with that one the most.
The reasons why they wanted to ignore XP or Scrum, or any Agile process, they'd tell me that: "That's the always the way the projects go regardless of planning", "Agile isn't designed for projects with deadlines", "It's always been done this way and for 20 years it has worked successfully, so why change it?" Oh, I'm sure we've all heard these and more!
Come on Comment section, don't disappoint me, let's hear some good old fashioned war stories from work! LOL
Scrum just had a better marketing team.
@Rcls01 ah the Betamax v VHS war all over again!
scrum has all the technical stuff removed. just by answering a small multiple choice test anyone, even managers, can easily become scrum masters and/or pos.
i believe that the first offering of scrum certifications, just one year after the agile manifesto, was the beginning of the end of agile.
@@m13v2 "scrum has all the technical stuff removed." not really
In the very first book on scrum, it was stated that the best way to use scrum, was in collaboration with XP.
So they saw it as complimentary.
Dragan is awesome
Getting to the point isn't part of the method apparently.
It would be awesome to have James Bach on the Engineering Room. He has worked in Apple in the late 80s and, if not the one, is one of the most influential testers in the industry throughout the decades.
Great guest, Dave!
We have been using XP for five years now as I (as an architect) have actively fought Agile within my area of our org. Oddly enough, I didn't even term it as Extreme Programming when I first promoted it, but discovered the term for it by watching your channel. The slow speed of delivery of our development groups were due to large amounts of disparate legacy code/languages/projects and not their processes. However, the *velocity of value* difference for our Agile vs. XP teams is very obvious.
XP does follow the agile philosophy though...
@@Software.Engineer agile, Not Agile(tm).
IMO, pair programming works, even if the "pair" is seemingly "mismatched"". If they aren't idiots. They will end up with, we agree to hate each other, and now:
Let's not talk tasks, let's talk goals. Then, who needs to do which task, when, to get there. And then restart hating each other again, if we can manage to do so, when the job is done.
The nicest combo is XP, Kanban, CI/CD and ORSC 😮
Ha! Thx! The pull request is the worst moment to make a code review. And the dark role git has here, oh dear. Bad coders with the intelligence to dominate projects to get those stucked are having a big long party.
You probably mean GitHub.
But the main product of software engineering is not a learning. Just like the main product of civil engineering is not learning how to build bridges but a bridge.
the learning comes in earlier: finding out what it is that needs to be build.