Tag Archives: Agile

Pair Programming in Retrospect

I’ve been doing pair programming for two years now. During this period I gained a lot of experience, so it is time to do a little retrospective and organize these experiences. I hope that you find something useful here, or even better, you may start to do pair programming.

Basics

Pair programming is one of the 12 core practices of eXtreme Programming in which two participants sit together and do programming using one computer. One of them owns the keyboard, while the other one assists. They are continuously discussing how and what to do.

What Worked for Me

After trying out several different pair programming styles, I’ve come up with a list of things which worked out quite well for me:

  • Use the same development environment as the others
  • Close all applications except the development environment
  • Pick a pair for the whole day and do not switch pairs during the day
  • Do pair programming only the agreed amount of time
  • Work with different people during the week if possible
  • Change roles (keyboard owner and associate) frequently, at least once in every 30 minutes, but never in the middle of the TDD cycle
  • Be honest, communicate a lot and be cooperative and patient

Read more »

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)

Weekly – CW14

Without further ado, here is the collection for calendar week 14, 2011:

  • Lean Software Management BBC Worldwide Case Study is out! It contains evidence which shows that over the 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24% (quote from the source website) by using Lean ideas. Impressive!
  • Simon Sinek made an insightful TED talk about a model for inspirational leadership. If you are a team leader or you are working with people, you must watch his talk.
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Farewell Gift

I’ve got a very nice farewell gift (on the left) from my old colleagues at Ericsson Hungary Ltd:

Thank you guys very much, it was my pleasure to work with you! Take care, and good luck with your new assignments and projects!

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Agile Seating Layout

A couple of weeks ago my team started to do things differently than before, and I promised I’d write about the effects of certain changes and new improvements. Effective and fluent communication is essential for an agile workspace, but unfortunately our former seating layout didn’t support either of that, so we changed it, inspired by an idea from Martin Fowler.

Have a look at the following seating layout (I modified the layout a bit due to privacy reasons):

At first sight, this is a regular seating layout, everybody can do their work in it, so far so good. Let’s have a look at it from the communication perspective. Communication is effective when there are no barriers, but unfortunately this specific layout is full of physical (the worst kind) barriers:

There are two borders (the red lines on the picture), which cut the team area into three separated isles (1, 2 and 3). A border can be a small wall or even a larger monitor. Sometimes the wall isn’t something physical; when someone has to stand up regularly in order to see something which somebody else is showing to her, then eventually she will stop standing up and communication between them will cease, because it is not convenient for her (for example in case of ‘H‘ and ‘C‘).

Read more »

VN:F [1.9.13_1145]
Rating: 10.0/10 (4 votes cast)

Pimp my Team

Abstract

From the middle of January 2011, our organization has been working in a new structure. There were different outcomes of this change, one of them was that my former firefighting team has been dismissed, and so has the team introduced in my Kanban Nightmares article. This post is not about ther organizational change and its effects, but about the start-up of a new team in the agile world. I’m going to launch my first series of posts in which I’m going share – because sharing is good – the life of my new team in an agile perspective.

The title of the article is influenced by MTV’s Pimp My Ride series, in which talented and creative engineers are customizing cars. The team members and I are the engineers, and our way of working is the car. While watching the show, I got the impression that not every customization is necessary for having a well-functioning vehicle, but if I take away the fancy, unnecessary extras, the engineers are doing a damn well job. This is what we are going to do: customize our car, maybe a little bit too much, and after driving it a little, we are going to add new or remove existing extras in order to have a very good car. The show has the following chapters:

  • Introduction of the car owner, and her situation
  • Meeting, where the engineers discuss the customization – similar to a planning meeting
  • Assembling the car - short session about how the engineers are building the car
  • The showdown – the engineers present the car to the owner - explain what they have built and for what purpose
  • Test drive

Before starting the actual post, I would like to thank Daniel H. Pink and Olaf Lewitz for their insights on demo cancellation and rewarding systems, which topics will be presented shortly.

Read more »

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)