Tag Archives: Agile

Pair-programming game: Farsight Navigator

Farsight Navigator

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Make experienced navigators become better
  • Focus on long-term design decisions
  • Create design incrementally
  • Teach others how short-time design decisions can affect the design on the long term

Concept

Both the driver and the navigator need to know very clear which is the purpose, the destination, of their current code writing process. This concept works extremely well if you are doing Test Driven Development and you want to produce design incrementally.

The roles of the development are very well separated:

  • the driver is not allowed to think too much ahead
  • the navigator is not allowed to say anything about the implementation details unless some decisions would drive them out of their course.
  • in the case of conflict they need to stop and decide together which is the best approach

The driver

  • needs to focus only on the small implementation details.
  • will write code in small batches of maximum 5 minutes and will make sure the code is functioning well

The navigator

  • needs to see how the code will develop on the long run
  • if the driver tries to think too much ahead, the navigator needs to ask him questions until the driver understands why that decision is a bad one.
  • needs to be a very experienced person in programming and in software design
  • needs to keep their calm and explain always the objections to some path
Farsight Navigator

Farsight Navigator

Option
If you want to have an easier far-sight navigator session think to do a session of behavior slicing, value sampling and then order the resulting behaviors from simple to complicated. This activity will give you a first list of tests you need to implement. This list is just a temporary list, as some tests might be split, some new ones might appear or some of them might need to be discarded.

Outcomes

In the case of a problem where we cannot really know how to proceed we can apply this technique in production. If done well, we will have the simplest design possible, custom created for the problem we want to solve. We will write the minimum amount of code, but further we will minimize our possible design mistakes by focusing more on the design than usually.

This technique prevents us from doing mistakes that are hard to repair afterwards. You might say that you are doing TDD with special focus on long-term design decisions.

Whenever I used this technique, the efficiency of reaching a solution was astonishing from both the time spent and the quality of the solution point of views.

Remarks

This is the hardest pair-programming game I know. The purpose of this game is to make experienced navigators become better. I would recommend this only after at least 6 months to one year of continuous pairing from both of the pairs.

Have you read Dune by Frank Herbert? If you did not please read it because I guess you will like it. If you did read it, then you might remember the Spacing Guild and how they could guide the space ships by their special skills and protect them from danger. In the case of this game our navigator is like a Guild Navigator from Dune.

The navigator needs to  have special skills of pairing, programming, is extremely experienced in software design and is a very good communicator.

When will become a navigator with a far-sight?

Image credit: http://dictionaryproject.files.wordpress.com/2010/08/compass.jpg

Pair-programming game: Yes, and…

Yes, and…

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Make the team members that always disagree try to build up on top of the ideas already presented.
  • Some members of your team are very stubborn and you want to show them that there could be other solutions than their own.
  • You want to improve solutions immediately when you see a smaller or larger improvement option.
  • You want beginners to feel they add value when pairing with more experienced people.

Concept

When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.

Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…

So the rules are:

  • none of the pairs can delete the code of the other.
  • at each step when switching from driver to navigator one needs to improve the existing solution and tests.
  • whenever one of the pairs tries to delete the code, the other needs to say “You should improve the existing one. Please go back and say Yes, and… I will do…“.
  • none of the pairs are not allowed to be angry on this request of not deleting code.
  • only unused code can be deleted, like for example after refactoring the code is not used any more. Both of the pairs must agree that the code can be deleted.

Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.

Yes, and

Yes, and

Read More →

Pair-programming game: Beginner’s Mind

Beginner’s Mind

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • You have very stubborn programmers in your team and you want to make his views softer.
  • To any problem, your team says there is only one solution, and that is their solution. You want to let them see there are always alternate solutions, which sometimes are better.
  • You had issues in the past with architectural or design decisions, just because the problem was not understood sufficiently.

Concept

A very experienced and neutral person, ideally an external technical coach, will pair with the team members one by one.
The rules are that:

  • the team member will be the driver
  • the technical coach will be the navigator
  • the technical coach is allowed to always ask beginner, even basic and stupid questions like “what are you doing”, “why are you doing this”, “tell me what is happening in this code”
  • the driver is not allowed to be angry by the beginner questions of the technical coach; the driver needs to always explain what is their current idea, how they can implement it and why they chose this path.

These sessions should have a specific, very clear topic. The technical coach needs to make sure that each member of the team understood the purpose.
The pair-programming session should not last more than 30-60 minutes as it is very tiring for both of the performers.

Beginner's mind

Beginner’s mind

Read More →

Pair-programming game: Silent Programming

Silent Programming

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes:

  • Useful when you have talkative people in your team that do not agree or agree but do not write enough code for one task.
  • The code is not easy to read

Concept

The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.

Silent Programming

Silent Programming

Read More →

What is pair programming?

Pair Programming

Blog post series

This blog post is part of a series about pair programming games. To read about more please click see more sessions on pair programming games.

About

Pair programming is a technique in which two programmers work together to solve a task. They work on one computer, ideally each having their own keyboard in front of them.
There are two roles: driver and navigator.

The driver writes the code and takes the short time decisions. The driver should trust the navigator totally for the long term decisions.

The navigator reads the code of the driver and gives meaningful suggestions on how the code could be better. Also the navigator focuses on the long term decisions and thinks the strategic direction the code moves to.

Both the driver and the navigator need to verbalize their actions and concerns and to speak on the code.

cat-pair-programming

Read More →

Pair-programming game: ping-pong

Ping Pong Pair Programming

Blog post series

This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.

Purposes

  • Learn pair-programming easier
  • Force the “know-it-all” programmer to see other ways of writing code
  • Force the “know-it-all” programmer to collaborate more
  • Push for collective code ownership

Concept

The roles driver and navigator change often inside the pair.
This activity is like a game of ping-pong of the roles between the two members of the pair. They both can take short time decisions while being a driver and can spot strategic design decisions while being a navigator.
Refactoring can be made by any of the programmers on their turn, but only when the code and the tests are stable.

ping-pong

Read More →

Open Agile Cluj, the 6th edition

Open Agile, the 6th edition in Cluj

17 November 2012. It was a great day for the Romanian developer community and for all passionate people in and around Cluj. This was the day when Agile Works and Mosaic Works organized the 6th edition of the OpenAgile conference. As always, its purpose was to popularize both gold old concepts and brand new ideas in Agile, Lean and Software Craftsmanship. Additionally, we often talk about Gamestorming, Change Management, Psychology and other interesting fields. Like the other editions, the event was balanced between information and practitioners’ experiences while mixing organizational and technical topics. OpenAgile was thought from the beginning as a non-profit event that helps knowledge exchange between the members of the Agile Works community. And what better way of sharing ideas and experiences than having three Open Space time slots!

I have to remark the great job done by my colleagues Alexandra and Nicoleta to remotely organize the event. For example, they did not have the chance to see the venue in advance. This works because of the trusted network of conference partners and suppliers that help organizing everything smoothly. But what a work that is! As an attendee, you often don’t see all the aspects of a conference (especially when it all goes well), so here’s a short list: the speakers know where to arrive and how to get to the venue, the volunteers are doing their part of the work, the sponsors are happy with the packages offered, the venue is set-up right, there’s enough coffee and thousands others. There are always small complaints and unexpected events, sometimes conflicting: it’s too warm *and* too cold, the coffee machine broke down etc. Everything was very well in the end, so I’d like to thank Alexandra and Nicoleta for the awesome job they did making it look easy!

Read More →

Open Agile Cluj 2012 – Our Fabulous Volunteers

Open Agile Cluj 2012 – Our Fabulous Volunteers

Since a couple of Open Agile editions we had the idea to ask volunteers to help us with some parts of the conference. It seems that for the Cluj edition we had this idea well-baked in our heads. Alexandra and I took the responsibility to ask who would want to be a volunteer and then to explain our concepts and how the conference would be.

We decided to have a remote call with all the volunteers, a couple of weeks before the conference. It seemed like a very useful ideas as it was also underlined by our volunteers retrospective, made after the conference. We explained during the call what were the areas where we would like help and each volunteer chose at least one responsibility. This was a kind of kick-of of the conference.

Read More →

Open Agile Cluj 2012 – The Crazy Erik Talboom and Jurgen De Smet

Open Agile Cluj 2012

The Cluj edition of Open Agile was special for more reasons: it was the first Open Agile in Cluj, for the first time we engaged volunteers who were fabulous, the first touch with Open Space for most of the attendees at the conference.

At this edition we had invited Andrea Provaglio to have the opening keynote, but because his flight was cancelled in the last minute he could not arrive. In return, he made a short ten minute overview about his presentation on Skype.

And because of this happening we had to convince Jurgen De Smet to give another talk, since he was already present at the venue after the Management 3.0 course he had taught. He was crazy enough to create a new talk in less than an hour. After we told him about our idea of him replacing Andrea, in a couple of minutes post-its started to fill-up the coffee table in the lounge of the venue. His idea was a bit alien to the Agile world, this giving it even more value: Financial Improvement. You can find his video here and his slides here.

We then stole the idea from this year’s ALE Conference: all the speakers of the day will have a Talk Show where they will say briefly what they will talk about in their presentations. Since everyone found it really useful during ALE, we thought, why not use it for Open Agile too. So thank you ALE 2012 organizers for inventing this concept!

One of the highlights of the talk show was Erik Talboom dragging Jurgen De Smet on the stage and slapping him hard, just because Jurgen was sloppy with his Agile Transformation. You can see this outrageous event here.

Read More →

TDD as if you meant it, Turku, Finland

TDD as if you meant it Turku, Finland

Because of my plane connection from Bucharest to Turku which was not so great, the trip lasts around 12 hours all in all, I needed to stay from Friday to Tuesday next week in Turku. So why not trying to organize an event shorter than the coderetreat, for two hours in the evening like I did a lot of times in Bucharest. Aki was really receptive to my idea and in a matter of hours he found a host, and announced the event to the local community.

TDD as if you meant it, Turku, Finland

Read More →