Archive for the ‘xp’ tag
Sometimes it’s the seemingly small details of the agile/XP approach to software development that make it so much more effective than the traditional approach.
I was reminded of this last week with regards to having co-located teams with the developers, BAs, QAs and the business people all sitting in close proximity.
I was working on the auto completion function for one of our screens and the QA on the team, who was sitting next to me, asked me if I could look through the acceptance criteria that he was working on.
This conversation was almost perfectly on cue because I was just about at the point where I had covered all the happy path cases and needed to understand the other paths. While looking through the acceptance criteria we needed some clarification with regards to exactly what the business wanted.
We went over to where the BAs were sitting and posed the question. Luckily they had just had the conversation with the business people and were able to explain the intent behind the criteria.
Interestingly writing this has made me realise that there are a couple of points in our process where more communication would make things flow more smoothly but seeing the speed with which we were able to go from confusion over a requirement to complete understanding was a really great reminder for me.
One of the common trends I have noticed in the stand ups of teams which practice pair programming is that very often the first person in the pair describes what they have been working on and what they will be doing today and then when it comes to the other person they say ‘ditto’.
After I dittoed one too many times on a project earlier this year it was pointed out to me that this was not a valuable way of contributing to the weekend and that I should describe my view of our progress as it may differ to my pair.
I had thought I was avoiding repetition by not contributing information which had already been covered, but I went along with this idea and immediately something was mentioned which hadn’t been previously covered. Instant vindication!
More recently I noticed a similar trend on another project I was working on and we came up with the idea of each pair standing together in the standup and effectively speaking as one.
This allowed us to avoid the ‘repetition problem’ and the ‘ditto problem’ as when it was the second person’s turn to speak they could just add in any details that their pair didn’t speak about without having to repeat the whole context again.
I think this worked reasonably well and it seemed to make our standups move along more quickly.
One of the interesting situations that can arise when pair programming is that one person dominates the driving and their pair can hardly get a look in.
This is not necessarily because they are hogging the keyboard – it is often just the case that they are the stronger technically in the pair and the other person isn’t willing to ask for the keyboard.
A big part of the value in pair programming comes from having both people taking turns at driving and navigating from my experience and there are several ideas that I have come across for trying to encourage a more collaborative approach to pair programming.
Ping Pong Pairing
The idea of this approach is to encourage the switching of the keyboard between both people very explicitly.
Based on the assumption that we are adopting a TDD approach, the first person starts out by writing the test, then they switch and the second person writes the code to make the test pass. Then they write the next test and the first person writes the code to make that test pass.
With this approach both people end up with fairly equal keyboard time and will hopefully feel more involved in the development effort.
My colleague Sam Newman previously wrote about ping pong pairing, including an approach to ensure that both members get exactly the same amount of keyboard time per day.
Learning the Art of Navigating
As a general rule I think the majority of people find it much easier to drive than to navigate.
When navigating it often feels that you are not adding value and it sometimes becomes confusing as to exactly what you should be doing.
Having said that I have worked with some phenomenally good navigators during my time pair programming. While I don’t claim to know how to teach someone how to be a good navigator (I’m still working on it myself), there do seem to be some distinct skills that you can apply to carry out this role effectively.
- Keeping an eye on the big picture – are we solving the right problem, has this piece of code become too difficult to test, are we testing it in the correct way etc.
- Tracking the tasks needed to complete a story and being ready to continue with the next one when the driver has finished the current one.
- Sharing tips on how to navigate around the workspace more effectively – keyboard shortcuts, different tools etc.
If we can become equally effective at contributing as both a navigator and a driver then it doesn’t become so imperative to drive all the time.
Two of everything
This was an approach I was introduced to more recently and involves having two keyboards and two mice connected to the workstation.
The benefit of this approach is that the difficulty of prising the keyboard away is removed and we can just grab our own keyboard and start typing when we have some input to make.
Clearly this needs to be done relatively sensibly otherwise otherwise we end up with both people typing or moving the mouse at the same time. From my experience of this technique that actually rarely happens.
There is also an increased spending on equipment but I wouldn’t imagine this would be that significant.
This was a book which had been recommended to me by a colleague a few months ago as one of the best software development books to read, and after hearing Ian Cooper describe how his team was implementing some of the ideas at the Alt.NET conference I decided I’d give it a read.
I have been working in an Agile/XP environment at ThoughtWorks for the last two years so my context coming into the book was around understanding where the overlap with Crystal Clear was, what differences there are and how I can apply these on my projects
What did I learn?
- I thought it was very interesting that Alistair Cockburn came across the agile principles through the need for efficiency rather than the need to handle rapidly changing requirements. It is also interesting that his project background is of the fixed price, fixed scope variety. This is generally considered an area where it is difficult to achieve success with an agile approach although I have worked on projects like this which have successfully delivered as well.
From my experience the key benefit of the agile approach touted is the ability to rapidly respond to changes in requirements but I also believe that the gains in efficiency we gain from the quick feedback cycles is certainly equally important in my book. Tim Bray has an interesting article talking about the potential for agile to thrive in this current financial climate due to the efficiency gains it can provide.
- I found the idea of software projects being a cooperative game to be a very good metaphor for understanding the trade offs that we make on projects. We need to consider the current game and future games that we will need to play. We can make decisions which benefit us in the current game (e.g. taking shortcuts on design) but we must remember that these decisions will have an impact on games that occur in the future (e.g. increased technical debt to pay off).
- The approach I have seen on previous projects has always advocated achieving business value as the number one priority for story selection. The author advocates a slightly different approach whereby we first tackle the highest risk or highest learning tasks first so that the team can gain this knowledge early while also being sure that it is technically possible to do the things they are being asked to do. This is linked to the idea of the walking skeleton – whereby we create an implementation of the system that performs a small end to end function. Clearly when using this approach it is important to still try and show that we are achieving some business value otherwise the project sponsor may become very nervous.
- The book has some interesting suggestions around retrospectives or reflection workshops. One which we are currently trying on my project is the idea of wrapping up the retrospective with two lists – ‘Keep These’ and ‘Try These’, which contain the ideas suggested in the retrospective. We can then prioritise the items on the ‘Try These’ list and go through the most important ones before the next retrospective.
- Another idea which was quite different from what I’ve come across was the idea of systems personalities. The idea here is that the system displays a different ‘personality’ to different end users. For example it might be fast and efficient or warm, friendly and informative. This seems like a good approach to allow us to drive out exactly how important different aspects of the system are and makes the trades off we inevitably have to make more related to our overall goal.
- The idea of having an expert user as well as a business expert working with the team was another interesting idea. From my experience it is very difficult to get a business expert to come and work with the team full time so I’m not sure how we would be able to get another person to come and work with our team, but several colleagues suggested to me that they do have an expert user working on their team so it is possible. I can see this being a useful role though because we often come across situations where there are two ways to do things and it’s not obvious which way the user would prefer. To have someone who actually uses the system available to answer that question would be quite valuable.
- There is an interesting discussion about the documentation that a project should look to supply – this is often something that we neglect so it was interesting to see explicit ideas on what should be provided being stated. It described the normal ideas such as the source code, architecture diagrams and so on, but one thing which I hadn’t considered as documentation was design diagrams showing the way the system has evolved. We often sketch out designs on whiteboards but rarely capture the evolution of them. It’s certainly an idea to keep in mind.
- I liked the case studies at the end of the book which detailed some experiences teams have had using the Crystal Clear approach. The most interesting part for me was looking at the individual experiences that each person on the team had. The ideas expressed weren’t new to me but it was interesting that they were so similar despite the project being described being so different to the ones I have worked on.
The biggest idea I came away with after reading this book was the idea that we should always be looking to continuously improve. At one stage the book refers to Kaizen – a term from the Toyota Production System which means ‘continuous improvement’. As a result of reading this book I became more aware of this term and came across Kaizen Conf which took place in the US last week.
I think it would serve as a good introduction to the Agile world – it’s not quite as strict as something like Extreme Programming but it seems to get across most of the same ideas.
In the comments of my previous post on pairing Vivek made the following comment about when we should pair:
The simplest principle I have is to use “conscious” pairing vs. “unconscious” pairing. A pair should always *know* why they are pairing.
On previous projects I have worked on there have been several tasks where it has been suggested that there is little value in pairing. I decided to try and apply Vivek’s principle of knowing why we might pair on these tasks to see if there is actually any value in doing so.
The value from pairing on the build when its in its infancy shouldn’t be underrated – the build plays a vital role on projects – providing a decisive point of success or failure for the running of our code.
I have worked on teams where the velocity has plummeted due to a fragile build, eventually ending up in development being frozen while we put it back together again.
While I’m not saying these problems would be 100% avoided by having a pair working on the build – certainly having two people working on it (at least initially) helps reduce the possibility of crazy decisions being made.
If it’s not possible to put a pair on this then at least ensure that the approach being taken with the build is well communicated to the rest of the team so that suggestions can be made and then applied.
Verdict: Pair initially to get it setup. Maybe work alone for small fixes later on.
I have noticed that there are two types of ‘spiking’ that we typically end up doing:
- Spiking to work out how to use an API to solve a problem
- Spiking various different options to solve a problem
If the library to investigate is clear then it may be more beneficial to take a pairing approach. I have worked with colleagues before who had a much different approach to working out how an API should be used than I did and our combined approach has led to quicker understanding than working separately may have done.
When we need to investigate a lot of options then this investigation will certainly be completed more quickly if a pair splits up and investigates the options between them before coming back together to discuss their findings. When this initial (brief) investigation has been done then I have noticed it works quite effectively to revert to pairing to drill down into a specific library.
Verdict: Decide based on the spiking situation
If we’re doing our job properly as agile developers bugs should be relatively easy to pin down to a specific area of the code.
For these types of bugs the value of taking a pairing approach is that we’ll probably write a test to prove the existence of the problem and from my experience we get better tests when pairing.
An approach taken on a previous project was to have one pair focused on bugs and just going through them all until we cleared out the highest priority ones. Another interesting part of this for me is that I would normally consider bug fixing to be very boring but when done with a pair I actually quite enjoyed it and it was often fun hunting down problems.
Verdict: Have a bug fixing pair to clear out high priority bugs
Despite working in an agile environment there are times when we need to write some documentation – whether this be writing some information onto the Wiki regarding use of APIs or creating architecture diagrams for discussion.
This is one area where I feel there is actually very little value in pairing. We tried to pair on this on one project I worked on but the navigator often found it to be very boring and we saw more value in one person driving the initial document and then someone else reviewing it afterwards.
Verdict: Don’t pair
Release or Deployment Tasks
This has often ended up being a task taken on by the Tech Lead or a Senior Developer in previous teams I have worked on.
A lot of the work is similar to writing documentation for which I would advocate a non pairing approach but have someone else look over the release document before sending it out.
However, knowing the production environment and how it all fits together is useful information for other members of the team to know so there may be room for some pairing for part of this process.
This way if/when problems arise in production and the Tech Lead isn’t around the team will still be able to address them.
Verdict: Don’t pair for the documents but maybe for other parts of the process
That’s just some of the grey areas of pairing that I could think of from a quick brain storm. I’m sure there are others too.
My former colleague Vivek Vaid has an interesting post about parallel-paired programming where he talks about introducing lean concepts into deciding when we should pair to get maximum productivity.
Midway through the post he mentions that the original reason that we starting pairing was for ‘collaborative design’ which got me thinking whether there are reasons beyond this why we would want to pair.
I have often worked on clients where the value of pair programming has been questioned and it has been suggested that we should only adhere to this practice for tasks where it adds most value.
Clearly collaborative design is one of these, but there are some others too:
The idea here is that someone who has been on the project for a great amount of time (possibly the Tech Lead) can help bring newer members of the team up to speed.
They can help the new team member to get their development environment up and running (although clearly making this as automated as possible is beneficial!) and help walk them through the code covering any questions they may have.
This role may also involve going though the reason that the team is there (i.e. what problem we are trying to solve), an overview of the way the problem is being solved and the technologies being used to do so, patterns being used in the code and any other information that is considered useful to the new team member.
Using pairing in this context makes it much easier to get new team members up to speed, therefore improving their ability to be a productive part of the team.
Increasing Team Level
Pairing up senior and more junior members of a team is a very effective way to increase the level of the junior person.
More senior team members have a lot of knowledge which they can pass onto junior team members – as this knowledge comes from experience in the field it is not necessarily something that could be gained from reading a book.
On several of the projects I have worked on one of the more Senior members of the team has been the one who provided the onboarding for new team members.
Clearly there needs to be a balance with this approach because no matter how patient the senior person is, at some stage they are going to want to have the opportunity to work with someone closer to their level of ability.
Using pairing in this way helps to bring up the level of the less experienced members of the team and allows them to learn things that more senior members of the team probably take for granted.
This one is a harder one to sell because there are no doubt other ways of sharing knowledge on teams beyond just pairing.
However, I have seen it work successfully on projects I have worked on for spreading the knowledge of how different parts of the application work amongst the team. This is generally referred to as increasing the truck factor – no one member of the team should be invaluable.
I saw this as a benefit on a project I once worked on where I had spent the majority of our time pairing both with ThoughtWorks colleagues and client developers.
At the end of the project we had a meeting to discuss what handover needed to be done in order to allow the team to continue when we finished. We really struggled to find anything at all – the knowledge of how to do the vast majority of tasks was completely spread out amongst the team and no one person had knowledge that the rest of the team didn’t have.
This is almost like a side effect of pair programming but it definitely has some gains which should not be discounted.
Pair Programming vs Parallel Pair Programming
I’ve never used parallel pair programming, only pair programming which is used the majority of the time on projects I have worked on.
I would be interested in knowing whether we can still gain some of these other benefits from using parallel pair programming – it seems to me to be quite a streamlined version of pair programming, and I wonder whether we would still get the useful side effects of pairing if we don’t pair all the time?
When it comes to Pair Programming the Junior/Junior pairing is considered the most likely to lead to disaster. The old joke being that if you pair two Junior Developers together then you’d better hope you have a revert function on your repository. But is this fair?
Certainly pairing two Junior Developers together means that you automatically lose the value of the experience and mentoring skills that you would get if there was a Senior Developer as part of the pair.
Assuming that we’re working on an agile project, the biggest area of risk you have when doing this is the possibility that neither of the developers understood exactly what the story that they are implementing required and they end up going way down the wrong track and not managing to complete it in anywhere near the amount of time that was expected. Now clearly if this happens too many times then it could end up being a project risk, but if the project is being run well then I don’t think that this is necessarily a problem.
Pairing two Junior Developers together gives them both the opportunity to gain confidence in their own ability. There is no longer a Senior person for them to defer to when there is a decision to be made so they have to step up and make the decision between them. This is a crucial part of our development as there are always decisions to be taken, trade offs to be made, and the ability to deal with this is crucial in agile teams.
It is also often the case that the Junior Developers who have just finished at ThoughtWorks University have been very well drilled in the art of pair programming and putting two of them together actually results in a very effective pair. They may not have the experience of other team members but their enthusiasm and lack of bad habits means they can be productive.
Having said that it is useful to provide a safety net of sorts for the pair so that they do not end up struggling (and I’m not even saying that that will happen).
Before starting on the story it is even more important that Tiny Tasks are created for the story being implemented. I find this an indispensable tool and if you ever look at my desk it is peppered with yellow stickies of tasks that I need to do to complete whatever I’m doing. The breaking down of tasks is brilliant for a Developer of any experience level, but is particularly useful here as a Junior pair may not have experience of solving a similar problem before and having a task list will help to keep them on track.
It is also useful to ensure that there is a more Senior person in the team (usually the Tech Lead) available to offer coaching/guidance if it is required by the pair. They may not need to intervene very often but the pair should feel that if they do run into problems that there is someone with more experience ready to help them out.
Overall I don’t think this is a pairing combination that should be avoided, much to the contrary. The team should look for ways that they can help support a Junior/Junior pair and help them to develop their abilities so that them pairing together is not even an issue at all.
I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.
First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.
Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.
I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.
I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.
I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.
The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.
Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.
On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.
I will cover some of my other thoughts in future posts.