Archive for July, 2013

Ping Pong Programming

Posted: July 11, 2013 in Agile, Coaching, Process Improvement, Product Development, Scrum, Software Development, Team Building, Testing
3

pingHi guys, in my last post I gave a small introduction to pair programming. This post will be short where I would like to present a small technique that can be used during pair programming. I learnt this in Rachel’s and Liz’s book. This technique is called Ping Pong Programming and it ensures that both members of the pair take a turn at the keyboard. Below you can find the steps.

  • The first developer writes a falling test and then passes the keyboard to his pair
  • The second developer writes just enough code to make the test pass
  • They then work together to re-factor the code that has just been written
  • Then the cycle can start again with the second person writing a new failing test and handing the keyboard back to the first person.

    • What do you think about this approach? Do you think that would help your developers? Do you think it would help you guys to design a better code and to spread knowledge within a team?

    Please leave some comments.

    Best Regards,
    Luis

    Small intro to “Pair Programming”

    Posted: July 8, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building, Testing
    3

    pair-programming-stuhl

    Hi guys, some of teams, that I have been helping lately, identified a lack of knowledge as a problem in some parts of our product. To tackle this issue, they decided to start with “Pair Programming”. Previously, they never did it so they asked me for some guidance where and how to start. That´s why I am writing a small intro to a “Pair Programming”.

    As Rachel and Liz said in their book: “Pair programming is two people working together- at the same computer, solving the same problem. Each person plays an active role in creating the software; the person actively typing is known as the driver, and her/his partner is the navigator who looks ahead to consider next steps and potential pitfalls. Pairs swap fluidly between these roles.”

    If your team adopts “Pair Programming”, these are some of the advantages that you will benefit from:

  • Code is higher in quality, because it is constantly being reviewed
  • Good practices are shared more widely among the team
  • Developers are interrupted less, because people tend not to interrupt people working together
  • More than one developer knows each part of the code
  • Team bonding improves, because the team learns from each other and enjoys working together

    • But what should be done during the Pair Programming session?
    First, when you are driving, demonstrate that an important aspect of pair programming is explaining what you are doing and why, so don´t just type code in silence.

    Second, stay open for suggestions from your pair, even if they are novice programmers. Even though you see a very obvious solution, be willing to try the solution that your pair suggests. In any case, both will learn. If the solution of your pair is wrong, he/she will learn why it is wrong with a help of your explanation. If the solution is good, then you will learn new aspects with your novice colleague .

    Third, one person shouldn´t use the keyboard for more than ten minutes at a time. Using ping pong programming can be a good approach. More information about ping pong programming here.

    One big mistake that is common in “Pair programming” is the fact that only one person does all the job. A lot of interaction between pairs should be observed. Interactive pairing forces pairs moving keyboard back and forward several times. In the beginning pair programming can be frustrating. Most of the time it means that developers will slow down to help colleagues but on the long term this is a tremendous help for the team itself.

    This was a brief introduction to the “Pair Programming” . Naturally, this post itself is not enough but at least gives an idea about what “Pair Programming” is. If you want to know more resources about pair programming, just let me know.

    Thanks and best regards to all.
    Luis

    Small intro to “Coding Dojo”

    Posted: July 3, 2013 in Agile, Process Improvement, Product Development, Scrum, Software Development, Team Building, Testing
    4

    Hi guys,at the company, where I currently work, we are ramping up several Communities of Practices and one of the activities we want to introduce is “Coding Dojos”. This is the topic for today´s blog.

    A Coding Dojo is an activity that brings developers together to work in a pre-selected programming challenge. This is a great way for developers to improve their skills and it´s a great activity to encourage learning between developers.

    Everything starts with a pre-selection of a coding challenge which helps the people to prepare better for the activity. The dojo runs with two developers working in a pair in front of a computer solving the coding challenge. This can span different topics. For example, re-factoring some part of the code, implement a new architecture, etc. The PC will be connected into a projector in order to share their work with the rest of the room/office.

    During the development task, developers talk aloud giving an explanation to others about tasks and their solutions. If the room cannot follow what is being said, the developers will explain once again until they understand the approach taken by the pair.

    In every five minutes one half of the pair changes a seat with someone else in the room. This will allow everyone in the room to participate in this activity. Usually this exercise lasts for 1 hour.

    I believe this is a great way to help team members sharing the knowledge among each other.

    What do you think about this activity?

    Cheers,
    Luis

    How to build “agreement” within your team

    Posted: July 1, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
    5

    Hi guys, in this post I want to demonstrate a small exercise that I learned from the book “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner.

    As an agile coach I spend lot of time introducing new ideas to teams but a question is: ” How can I figure out if these ideas will have enough buy-in from teams to be implemented?” The exercise that I´m showing you today will solve this problem; the exercise is called “Gradient of Agreement”.

    The exercise is really easy. Use a flip-chart, draw fiver different levels of agreement: “Endorse”, “Agree with reservations”, “Mixed feelings”, “Disagree but go with the majority” and “Block”. Ask team members to put a check mark on the level they feel comfortable, as presented below in the example.

    Using this kind of tool allows everyone to reveal its own opinion and level of commitment to the proposed approach. Sometimes it is not possible to get buy-in from the team, therefore I propose that you start with small steps, instead of having an ambitious final solution. Why not break the solution in small pieces, for example, instead of proposing to the team that automated tests should run after every check in, split this ambitious goal into smaller ones:

    • Automated tests should run automatically after every checkin
    • Automated tests should run manually after every checkin
    • Automated tests should run automatically every night
    • Automated tests should run manually every night

    And use the same technique for each different goal. After that chose the one that has the right balance between an ambition and agreement from the team.

    This was the exercise that I wanted to bring up today.

    Thanks,
    Luis