Recommended
More Related Content
Similar to Agile - Pair-programming
Similar to Agile - Pair-programming (20)
Recently uploaded
Recently uploaded (20)
Agile - Pair-programming
- 3. DEFINITION
- 4. Definition • Agile software development technique • 2 programmers: 1 driver and 1 observer • 1 workstation (or remotely sharing a screen). • 2 input devices: 2 monitors, 2 keyboards, and 2 mouses • Switch roles frequently AGILE: PAIR-PROGRAMMING 4 Wikipedia. “Pair programming” https://en.wikipedia.org/
- 5. BENEFITS
- 6. Benefits on Quality AGILE: PAIR-PROGRAMMING 6 • Improves Code Review • Improves Design • Improves Testing • Improves Knowledge Sharing • Improves Communication and Collaboration • Reduces Risks • Reduces Errors Martin Fowler. “Pair programming” https://martinfowler.com/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 7. Benefits on Productivity AGILE: PAIR-PROGRAMMING 7 • Improves focus; Reduces distractions and interruptions • Improves morale • Reduces time at onboarding new team members • Reduces time at finding problems and catching bugs • Reduces time at designing solutions and solving problems • Keeps the team’s Work In Progress (WIP) low • Prevents silos Martin Fowler. “Pair programming” https://martinfowler.com/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 8. CHALLENGES
- 9. Introducing Pair-Programming AGILE: PAIR-PROGRAMMING 9 Challenge Solution Different skill levels Don’t assume they know everything / nothing Power dynamics and hierarchies What can you do to neutralize power imbalance? Pairing with lots of unknowns Think of pair development, not pair programming. Pairing requires vulnerability A trusted and safe environment Convincing managers and co- workers Present benefits and challenges Setting up the workspace Ensure necessary hardware and software Martin Fowler. “Pair programming” https://martinfowler.com/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 10. Maintaining Pair-Programming AGILE: PAIR-PROGRAMMING 10 Challenge Solution Pairing can be exhausting Short breaks; limit of 6 hours/day Intense collaboration can be hard How do you prefer to pair? Interruptions by meetings Limit meetings; block out no-meeting-time No time for yourself Allocate time for self-learning Skill level stagnation Rotating partners Rotations lead to context switching Balance rotations to focus and contribute properly Martin Fowler. “Pair programming” https://martinfowler.com/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 11. Maintaining Pair-Programming AGILE: PAIR-PROGRAMMING 11 Challenge Solution Misalignment with goals Ensure both work towards a common goal Communication breakdown Clear, open and honest communication Inconsistent participation Ensure commitment for participation. Martin Fowler. “Pair programming” https://martinfowler.com/ OpenAI. “Pair programming” https://chat.openai.com/chat (continued from the previous slide)
- 13. Ping-Pong: Definition AGILE: PAIR-PROGRAMMING 13 • Pair programming technique, 2 programmers collaborate on a single task • Take turns writing and testing code • Ensures equal contribution Open Practice Library. “Ping Pong Programming” https://openpracticelibrary.com/practice/ping-pong-programming/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 14. Ping-Pong: Benefits AGILE: PAIR-PROGRAMMING 14 • Improves code quality: test-driven development and code continually tested, better at catching errors. • Improves collaboration: constant communication; minimize misunderstandings • Improves productivity: maximize focus and flow; minimize distractions • Improves learning: knowledge-share of new insights and best practices • Improves morale: work as a game, constant feedback Open Practice Library. “Ping Pong Programming” https://openpracticelibrary.com/practice/ping-pong-programming/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 15. Ping-Pong: Process AGILE: PAIR-PROGRAMMING 15 • Developer A and developer B join • A writes a failing test • B makes the test pass writing only enough code to make the test pass • Both developers refactor the code • B writes the next test • A makes the test pass writing only enough code to make the test pass • A writes a new failing test • B continues and the process repeats Open Practice Library. “Ping Pong Programming” https://openpracticelibrary.com/practice/ping-pong-programming/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 17. Pomodore Technique: Definition AGILE: PAIR-PROGRAMMING 17 • Time-management method that forces developers to split their work time • 25-minute-long sessions with 5-minute breaks • 20-minute break after every 4 sessions • During session, focus on your task and preferably undisturbed • After session, really take a break and switch driver and observer roles Martin Fowler. “On Pair Programming”. https://martinfowler.com/articles/on-pair-programming.html Medium. “Pair programming with tomatoes”. https://medium.com/ingeniouslysimple/pair-programming-with-tomatoes-fba29ed23be3 OpenAI. “Pair programming” https://chat.openai.com/chat
- 18. Pomodore Technique: Benefits AGILE: PAIR-PROGRAMMING 18 • Improves productivity: focused intervals, avoid distractions or interruptions • Improves time management: manageable chunks, prioritize tasks, set realistic goals, avoid procrastination • Reduces burnout or injuries: rest for mind and body to stay productive • Improves focus: one task at a time, avoid multitasking • Improves collaboration: structure to provide support and feedback Open Practice Library. “Ping Pong Programming” https://openpracticelibrary.com/practice/ping-pong-programming/ OpenAI. “Pair programming” https://chat.openai.com/chat
- 19. Summary We believe that pair programming is often avoided because it can create friction, but we would ask you to give it a chance. If you work on getting better at it, you will gain on quality and efficiency, ending up with a more resilient team. AGILE: PAIR-PROGRAMMING 19 Martin Fowler. “On Pair Programming”. https://martinfowler.com/articles/on-pair-programming.html OpenAI. “Pair programming” https://chat.openai.com/chat
- 20. 19/3/2023 20 AGILE: PAIR-PROGRAMMING THANK YOU Carlos Miguel Seco miguelsc@tcd.ie linkedin.com/in/carlosmiguelseco
Editor's Notes
- Pair programming is “an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.” (en.wikipedia.org, 03-03-2020) In other words, Pair programming is a software development technique where two programmers work together on the same codebase, on the same computer. In this approach, one programmer, known as the driver, writes the code while the other programmer, known as the navigator, reviews and provides feedback in real-time. The roles can be switched at any time, allowing both programmers to take turns writing and reviewing the code.
- Pair programming can have several benefits on the quality of software development. Here are some of the ways in which pair programming can improve the quality of software development: Increased code review: With two people working on the same code, pair programming can provide an increased level of code review, which can lead to improved code quality. Reduced errors: Because two people are working on the same code, errors can be caught and corrected more quickly, leading to higher-quality code. Better design: Pair programming encourages developers to think through problems and design solutions together, leading to better-designed software and more effective problem-solving. Improved testing: Pair programming can lead to more effective testing, as developers can work together to design and execute tests, catch errors, and ensure that code meets the necessary requirements. Knowledge sharing: Pair programming can help to spread knowledge and expertise across the team, leading to a more skilled and knowledgeable development team overall. Overall, pair programming can lead to higher-quality software development by promoting effective code review, reducing errors, improving design, and facilitating knowledge sharing. By improving the quality of software development, pair programming can help to reduce bugs, improve customer satisfaction, and increase the overall value of the software. Improved code quality: Better solutions, defect reduction and more motivation With two people reviewing and testing the code, errors and bugs are caught more quickly, leading to higher-quality code. When two minds understand and discuss a problem, we improve the chances of finding a good solution. Different experiences and perspectives will lead to the consideration of more alternatives. It forces us to discuss approaches and solutions, instead of only thinking them through in our own head. Saying and explaining things out loud pushes us to reflect if we really have the right understanding, or if we really have a good solution. It also keep the pair mutually motivated to find the best solution to the problem at hand. We have 4 eyes on the little and the bigger things as we go, more errors will get caught on the way instead of after we’re finished. It improves quality by doing the thing right. Reduced risk: Pair programming reduces the risk of code being lost or forgotten, as two people are working on the same code and are constantly reviewing each other's work. Better communication: Pair programming promotes better communication and collaboration among team members, leading to more effective problem-solving and faster feedback cycles. Knowledge sharing, teamwork, collective ownership and prevent silos Knowledge sharing: Pair programming allows developers to share their knowledge and expertise with each other, leading to a more knowledgeable and skilled team overall. Having two people work on a piece of work helps the team spread knowledge. Your staff’s interpersonal skills will be increased due to more collaborative teamwork. If you keep working in the area that you feel most comfortable in, you will miss out on learning new things. Pair working alone does not guarantee you achieve collective ownership. You need to make sure that you also rotate people through different pairs and areas, to prevent knowledge silos. Collective ownership abandons any notion of individual ownership of modules. The work is owned by the entire team and anyone may make changes anywhere. This increases the chances that anyone on the team feels comfortable improving processes almost anywhere.
- Pair programming can also have several benefits on the productivity of software development. Here are some of the ways in which pair programming can improve productivity: Reduced ramp-up time: New team members can learn from more experienced developers through pair programming, reducing the amount of time it takes to become productive. Improved problem-solving: Pair programming can lead to more effective problem-solving, as two people can work together to think through problems and come up with solutions more quickly. More efficient code development: Pair programming can often be more efficient than working alone, as two people can work together to write code, catch errors, and ensure that code meets the necessary requirements. Real-time feedback: With two people working on the same code, pair programming provides real-time feedback, allowing developers to catch and correct errors more quickly. Increased focus: Pair programming can help to reduce distractions and increase focus, as developers can work together to stay on task and avoid interruptions. Reduced time spent on bug fixing: Because errors are caught more quickly with pair programming, less time is spent on bug fixing, leading to improved productivity. Overall, pair programming can lead to improved productivity by reducing ramp-up time, improving problem-solving, providing real-time feedback, increasing focus, enabling more efficient code development, and reducing time spent on bug fixing. By improving productivity, pair programming can help to deliver software more quickly and within budget, leading to increased customer satisfaction and value. Better communication: Pair programming promotes better communication and collaboration among team members, leading to more effective problem-solving and faster feedback cycles. Increased productivity: Keeping focus, reduced distraction and interruption cost Increased productivity: Although two people are working on the same code, pair programming can often be more productive than working alone because of the benefits of real-time feedback and reduced errors. It’s a lot easier to have a structured approach when there are two of you. Each of you has to explicitly communicate why you are doing something and where you are heading. You can help each other stay on track. Make plans together. Discuss your task at hand and think about which steps you need to make to reach your goal. Talk about what you are doing and demand explanations from each other. It improves discipline and effectiveness by doing the right thing. Keeps the team’s WIP low Limiting work in progress is one of the core principles of Kanban to improve team flow. Having a Work in Progress (WIP) limit helps your team focus on the most important tasks. Overall team productivity often increases if the team has a WIP limit in place, because multi-tasking is not just inefficient on an individual, but also on the team level. Especially in larger teams, pair working limits the number of things a team can work on in parallel, and therefore increases the overall focus. This will ensure that work constantly flows, and that blockers are addressed immediately. Improved morale: Pair programming can be a fun and rewarding experience, leading to improved job satisfaction and team morale. Reduced ramp-up time: Fast onboarding of new team members Reduced ramp-up time: New team members can learn from more experienced developers through pair programming, reducing the amount of time it takes to become productive. There is an increased onboarding efficiency since pairing facilitates knowledge sharing. New joiners can get to know the project, the business and the organisation with the help of their pair. Changes in a team have an impact on the team flow. People just need some time to get to know each other. Pair working can help to minimize that impact, because it forces people to communicate a lot more than they need when working solo.
- Pairing can be exhausting Pairing forces you to keep focus for potentially longer stretches of time, and find common ground with the other person’s rhythm and ways of thinking. The increased focus is one of the benefits of pairing, but can also make it quite intense and exhausting. Solution: Taking enough breaks is key. Limit it to a maximum of 6 hours per day. Intense collaboration can be hard Intense collaboration can be hard. Working so closely with another person for long stretches of time is intense. You need to communicate constantly and it requires empathy and interpersonal skills. You might have differences in techniques, knowledge, skills, extraversion, personalities, or approaches to problem-solving. Some combinations of those might not match well and give you a rocky start. In that case, you need to invest some time to improve collaboration, and make it a mutual learning experience instead of a struggle. Solution: Try questions like “How do we want to work together?”, “How do you prefer to pair?”, Is there anything you would like to try next time. Interruptions by meetings When a team practices pair working the effect of too many meetings can get even worse. If each of the persons pairing has meetings at different times, the interruptions are multiplied. Solution: Limit the time slots in which meetings happen or block out no-meeting-time. Power Dynamics There are formal hierarchies, for example between a manager and their report, and informal ones. Solution: What can you actively do to neutralize power imbalance? Pairing with lots of Unknowns When you work on a large topic where both of you don’t have an idea how to solve a problem. Solution: Take on the mindset of pair development, as opposed to pair programming. No time for yourself We’ve talked about how being in a constant conversation with each other can be pretty energy draining. Most people also need some time on their own throughout the day. That is especially true for more introverted folks. When working solo, we quite naturally take time to dig into a topic or learn when we need to. But that can feel like an interruption in pairing. So how can you take that alone and learning time when needed? Solution: Allocate a few hours self learning time. Rotations lead to context switching Too may rotations leat to frequent context switching. Solution: Find a balance between frequency of rotations and the possibility for a new pairing partner to get enough context on the story and contribute properly. Pairing requires vulnerability When you pair, it can be hard to show that you don’t know something, or feel insecure about a decision Solution: Showing vulnerability requires courage and creating an environment where people feel safer to show that their vulnerable. Again, this is all about building teams where people trust each other (regular 1:1s, Feedback, culture where people can ask questions, etc) Convincing managers and co-workers Advocates of pair programming often struggle to convince their managers or their co-workers to make pairing part of a team’s daily routine. Solution: Find a way to try it out.
- Pairing can be exhausting Pairing forces you to keep focus for potentially longer stretches of time, and find common ground with the other person’s rhythm and ways of thinking. The increased focus is one of the benefits of pairing, but can also make it quite intense and exhausting. Solution: Taking enough breaks is key. Limit it to a maximum of 6 hours per day. Intense collaboration can be hard Intense collaboration can be hard. Working so closely with another person for long stretches of time is intense. You need to communicate constantly and it requires empathy and interpersonal skills. You might have differences in techniques, knowledge, skills, extraversion, personalities, or approaches to problem-solving. Some combinations of those might not match well and give you a rocky start. In that case, you need to invest some time to improve collaboration, and make it a mutual learning experience instead of a struggle. Solution: Try questions like “How do we want to work together?”, “How do you prefer to pair?”, Is there anything you would like to try next time. Interruptions by meetings When a team practices pair working the effect of too many meetings can get even worse. If each of the persons pairing has meetings at different times, the interruptions are multiplied. Solution: Limit the time slots in which meetings happen or block out no-meeting-time. Power Dynamics There are formal hierarchies, for example between a manager and their report, and informal ones. Solution: What can you actively do to neutralize power imbalance? Pairing with lots of Unknowns When you work on a large topic where both of you don’t have an idea how to solve a problem. Solution: Take on the mindset of pair development, as opposed to pair programming. No time for yourself We’ve talked about how being in a constant conversation with each other can be pretty energy draining. Most people also need some time on their own throughout the day. That is especially true for more introverted folks. When working solo, we quite naturally take time to dig into a topic or learn when we need to. But that can feel like an interruption in pairing. So how can you take that alone and learning time when needed? Solution: Allocate a few hours self learning time. Rotations lead to context switching Too may rotations leat to frequent context switching. Solution: Find a balance between frequency of rotations and the possibility for a new pairing partner to get enough context on the story and contribute properly. Pairing requires vulnerability When you pair, it can be hard to show that you don’t know something, or feel insecure about a decision Solution: Showing vulnerability requires courage and creating an environment where people feel safer to show that their vulnerable. Again, this is all about building teams where people trust each other (regular 1:1s, Feedback, culture where people can ask questions, etc) Convincing managers and co-workers Advocates of pair programming often struggle to convince their managers or their co-workers to make pairing part of a team’s daily routine. Solution: Find a way to try it out. Skill level stagnation: If the same pair programming partners work together for too long, they may stop learning from each other and become stagnant. To mitigate this, consider rotating partners or scheduling occasional knowledge-sharing sessions.
- Misalignment with goals: If the pair programming partners' goals are not aligned, it can lead to frustration and wasted time. Ensure that both partners are working towards a common goal and communicate regularly to stay aligned. Communication breakdown: If communication between partners breaks down, it can lead to misunderstandings and decreased productivity. Establish clear communication protocols upfront and encourage open and honest communication between partners. Inconsistent participation: If one partner is not consistently participating in pair programming, it can lead to an uneven workload and decreased productivity. Ensure that both partners are committed to the process and hold each other accountable for participation.
- Ping-Pong Programming (aka. Ping-Pong Pair Programming) is a kind of Pair Programming that TDD (Test Driven Development) is included while in practice. In other words, it is a combination of Pair Programming and TDD. The Ping-Pong technique is a type of pair programming where the two developers take turns writing code and testing it. The process goes back and forth between the two partners, much like a game of ping-pong, where one partner writes a test case, and the other writes the implementation code to make the test pass. Then, the other partner writes a new test case that the first partner must implement, and the process continues. The Ping-Pong technique is a useful way to ensure that both partners are engaged in the process and that both are contributing equally. It also helps to reinforce the principles of test-driven development, where tests are written before the implementation code.
- BENEFITS: TDD :) Easier to find the rhythm of the development flow which can be a problem when it comes to switching pairs. A much smaller problem space needs to be managed, so this enables developers to sync with the flow quicker than other styles. Avoids mismatched pair issues -like one developer knows more than the other- as each developer takes turns writing tests and making them pass. The work is gamified, so it puts another kind of motivation for developers. The Ping-Pong pair programming technique can offer several benefits, including: Increased code quality: The technique encourages a test-driven development approach, where tests are written before code, and the code is continually tested, leading to higher-quality code. Improved collaboration: Ping-Pong pair programming requires constant communication and collaboration between partners, leading to better knowledge sharing, more efficient problem-solving, and better alignment on goals and objectives. Better productivity: The constant switching between writing tests and writing code can help reduce distractions and increase productivity, as each partner is focused on their specific task. Enhanced learning: The technique can help developers learn from each other, gain new insights and perspectives, and stay up-to-date on the latest development practices and technologies. Reduced errors and defects: Having two sets of eyes on the code at all times can help catch errors and defects early in the development process, reducing the risk of bugs in the final product. Increased job satisfaction: The constant feedback and collaboration can lead to increased job satisfaction, as developers feel more engaged and fulfilled in their work. Overall, the Ping-Pong pair programming technique can help to improve code quality, productivity, collaboration, and learning, leading to better software development outcomes. Here's an example of how the Ping-Pong technique might work: Developer A writes a test case for a new feature Developer B writes the implementation code to make the test pass Developer B writes a new test case that the implementation code does not pass Developer A writes the implementation code to make the new test case pass The process repeats, with the partners taking turns writing tests and implementation code. The Ping-Pong technique can help ensure that the code is thoroughly tested and that both partners have a chance to contribute to the development process. It can also help to reduce errors and improve code quality by having two sets of eyes on the code at all times.
- How to do Ping-Pong Programming? Let's say there are two developers, developer A and developer B. The development flow goes like the following: A writes a failing test. B makes the test pass writing only enough code to make the test pass. B writes the next test. A writes only enough code to make that test pass. Continue until A and B both agree that there are no more tests for the unit they are currently working on. Either developer can refactor the code only all tests stays "passing". The optimal setup to work in this rhythm is two developers sitting side by side, a single computer with two input devices: That’s two monitors, two keyboards, and two mice. However, developers may do pairs remotely if they work in a remote environment via tools like Live Share etc. Ping-Pong programming can also be done in a group which is a form of Mob Programming. So it can be called Ping-Pong Mob Programming: A developer writes a failing unit test. Another developer -maybe the one next to her/him- writes as little code as possible to make the test pass. Another developer -maybe the one next to her/him- writes a failing unit test. And it continues like this... Any developer can refactor any code when needed but only when the tests pass. When the driver asks for help, the rest of the group politely helps out without any other interruption. Here's an example of how the Ping-Pong technique might work: Developer A writes a test case for a new feature Developer B writes the implementation code to make the test pass Developer B writes a new test case that the implementation code does not pass Developer A writes the implementation code to make the new test case pass The process repeats, with the partners taking turns writing tests and implementation code. The Ping-Pong technique can help ensure that the code is thoroughly tested and that both partners have a chance to contribute to the development process. It can also help to reduce errors and improve code quality by having two sets of eyes on the code at all times.
- What is Pomodoro? Pomodoro (Italian for tomato) is a pairing technique that forces developers to split their work time into smaller units. The units of work consist of 25-minute-long sessions with 5-minute breaks in between, and a longer 20-minute break after every 4 sessions. During these sessions, you should be focused on your task and preferably undisturbed (by your other colleagues, Slack, BBC News, etc). After every session, developers switch their driver and navigator positions. Use the short breaks to really take a break and tank energy, get some water or coffee, use the bathroom, get some fresh air. Avoid using these short breaks for other work, like writing emails. The Pomodoro Technique helps the team stay focused, work efficiently, and take regular breaks to prevent burnout. It can also help the team improve communication and collaboration by providing structured opportunities for feedback and support. The Pomodoro Technique is a time-management technique that can be used in pair programming to help manage time effectively and increase productivity. In pair programming, two programmers work together on the same codebase, usually taking turns at the keyboard. With the Pomodoro Technique, the pair sets a timer for a predetermined period, typically 25 minutes, and works together during that time on a specific task or piece of code. This period is called a "pomodoro." After the pomodoro is up, the pair takes a short break, typically 5-10 minutes, to rest and recharge. They can then repeat the process, setting another timer and continuing to work together in short, focused bursts. The Pomodoro Technique can be especially useful in pair programming because it helps ensure that both members of the pair stay engaged and focused during their time at the keyboard. It also allows for regular breaks to prevent burnout and encourages efficient use of time by breaking down larger tasks into smaller, manageable chunks.
- Improved productivity: By breaking work into small, focused intervals, the Pomodoro Technique can help you get more done in less time. By staying focused on one task during each pomodoro, you can avoid distractions and interruptions that can derail your progress. Better time management: The Pomodoro Technique helps you manage your time more effectively by breaking your workday into small, manageable chunks. This can help you prioritize tasks, set realistic goals, and avoid procrastination. Reduced burnout: The Pomodoro Technique encourages regular breaks to help you recharge and avoid burnout. By taking short breaks after each pomodoro, you can give your mind and body the rest they need to stay focused and productive. Improved focus: The Pomodoro Technique helps you stay focused on one task at a time by breaking your work into short, focused intervals. This can help you avoid multitasking, which can be less efficient and more stressful. Better collaboration: The Pomodoro Technique can be used in pair programming or other collaborative work to improve communication and collaboration between team members. By working together in short, focused intervals, team members can provide feedback and support to each other more effectively.
- https://medium.com/ingeniouslysimple/pair-programming-with-tomatoes-fba29ed23be3