Pairing up developers for enhanced learning and better productivity

Just wanted to share what has been working for my current team over the past few months. This is meant for a team with a decent budget and would not make sense for everyone.

Each work station has a Dell laptop (16GB RAM, Windows 7 Enterprise, 64-bit), three 24" monitors. Runs on either our internal wireless or wired network.

Setup; an area (there are two next to each other) that has two workstations, each station was three monitors, two mice, two keyboards. When not paired you have all three monitors to yourself while paired two monitors are mirrored. In the center of the area is another station which allows one computer to dock to this work station so when we are doing things like code reviews or presentations many can look into what we are doing and this station can be paired too. This setup is repeated across from the first area so now my four person team has a great deal of flexibility. On a side note, we are using TFS and Visual Studio online which really helps as half of the team is doing Entity Framework and restful WCF while the other half is doing pure web that uses the solutions my half codes.

So I am curious if anyone else has tried something like this and if so how did it work for you?

We don't have the people for something like that. The best I can do is talk to myself.

One thing that I have always been interested in with such a design is how you find compatible types? I would think that there are lots of pairings that would be disastrously imbalanced. It seems like the skill level of the coders has to be at least roughly similar, and the understanding of the problem has to be quite similar. The latter probably wouldn't be an issue for long, but the former seems like it might prove harder to overcome.

You are absolutely correct in that there needs to be compatible types. We made a choice after the team was put together. At first we worked in a team room not the current setup. We have a good deal in common ranging from drinking way too much coffee to skill levels. All four of us have an average of 15 years experience coding. Myself and two others are about 25 years, the last has 12 years but they are very concentrated years and would say that person is equal to the other three. Oh, forgot to mention we do things outside of the office together ranging from backyard barbecues to blasting rounds off at the shooting range. There are other teams in my unit where I know two or three would not work well in the current mix and were not selected at least because they support legacy desktop solutions.

Yes at my last place we did pairing. At my current place we just aren't big enough. We have too few developers, and too many different applications to support and develop.

To make Pairing work well in my opinion (and by the sound of it your team seems to fit this Kevin) is your developers need good domain and application domain knowledge and to be at least of similar level, otherwise you are essentially using Pairing to train one of your developers.

We did it in 2 teams, in one of the teams the developers had a lot of experience and had been working on the application for some time, and Pairing worked well. In particular we quite quickly had saw some quality improvements with lower percentage of issues coming back from test.

We also implemented it in a fairly new team (we had done a lot of hiring and this team had been together for maybe a year), this worked less well as it actually slowed the team down.

As for getting the right fit of people, i agree sometime you can see straight away who will work well with others and who will not, however we tried out different pairings to see who could work well together and we had a few surprises. I guess sometimes you just need to try things and see what works.

Yes. It has been known for years in association with XP (Extreme programming) which is one of the types of development that fall under the agile software development umbrella.
http://en.wikipedia.org/wiki/Extreme_programming
"Other elements of extreme programming include: programming in pairs ..."
"Code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of Pair programming."
Always seemed like a good idea to me, and often happens informally for short periods of time even in a "normal" programming environment when two programmers are working together to try to solve some issue.
It helps to have more than one person intimately familiar with a piece of code, but as already stated, if the two individuals are largely mismatched so one does all the coding and the other daydreams the day away, then of course a negative benefit (yes an oxymoron).

We used it at one of my previous job. For my current one, we kinda use it, but mostly when bringing someone on-board. It can work, but as everyone has pointed out, it has to be the right mix of personalities and circumstances. It isn't easy to do. It can be fun. It's how I learned Workflow originally. But it can also be detrimental. If one of the pairs isn't as sharp or quick as the other, it can slow things down if it constantly has to be explained.

-tg

I totally agree, we are fortunate to have people on the team are seasoned over many years. Nobody is better than the others, we all compliment each other. I will say it was no mistake how the team was put together, we have a manager who was a software developer with many years of experience working with team dynamics. My feeling is the team could had been three or two people dependent on how we jelled.

Does the amount of time spent together in code review, versus time bashing on the keyboard on ones own, really justify the setup? I guess if you have space and the physical resources, it is great - having to 'setup' for a code review can be logistically time consuming that people feel it's better spent 'writing code', even though there's value in it.

Don't people like to setup their own 'areas' to their liking, though, while working? It seems you are presenting a fairly static layout, but maybe I can't picture it, since I've never worked in such a luxurious area...

Thanks for your thoughts

First off my team is not responsible or any code reviews per-say, official code reviews are done when a story is done which has 1-n task within a sprint within VSO (Visual Studio Online). In regards to bashing out on the keyboard, from my experiencing with the some developers sitting alone tend to be a bad thing overall i.e. when they get stuck they may very well end up with code that gets the job done but not efficiently and if waiting for a code review can very well hold up the project which I have seen happen or worst yet the code is overlooked which can come back later to bite them or another developer when an enhancement is needed or something breaks.

In regards to code review; our team does what any good programmer does, check as you go followed up with a unit test then when the story is finished pass it off to a) a tester b) a code reviewer.

Very good point on "Don't people like to setup their own 'areas'"
For years I worked in isolation of a cubicle until a new manager came along, said other teams he was on worked in an open area. I was reluctant at first but after a few weeks decided it was a good move even thou privacy was out the door but replaced with projects getting done many times ahead of schedule. This was in place for about eight years then we moved to another area and went back to single work areas which felt odd but got use to it. Recently we put together what I like to call a "all-star team" which I have discussed above where we all get along in work and outside of work. We do have one cube for anyone in a group that might need private time but nobody has used it yet.

Example how this setup worked one day last week, one developer writes very complex (and I mean complex) Lambda statements that are one-liners but broken down and indented so they are easy to read. He was having an issue (at least it seemed) where the statement was using Take language extension with a OrderByDecending which was then used to populate some metro tiles but the order was coming out ascending. He simply rotated his chair and asked me for help (history shows me that when in separate cubes this is least likely to happen). So I not only fix the issue which was actually a problem with the second lamdba statement but noticed how the Distinct part of the constructed which was needed in other parts of the project, made a suggestion, explained how using a custom comparer and did this in LINQPad in front of them so they gained more knowledge. It goes both ways, I was having an issue with COR (Cross-Origin Resource Sharing) were one of the developers with 10 plus years of experience in this area pointed me in the right direction.

Any ways this setup works for many and on the other side of the coin does not work for others. To put this together I am guessing it cost a lot of money ranging from each developer in our desktop and web groups having the exact same computer setup and for the most part code image so that discarding open workspaces one can expect to find specific software so they can get work done. We are large enough to have a professional who only does setups and changes to setups so they in our case start out with a design session with out group, get approval, do the work then another dedicated person comes along and reconfigures our LAN wires (not used much as we have internal secure WiFi). My guess is our 80 inch MONPAD was not cheap.

Quote:

---

To put this together I am guessing it cost a lot of money ranging from each developer in our desktop and web groups having the exact same computer setup

---

Its not so much the hardware costs which in the larger scheme of things is not very much, its the staff costs. In a good agile team you need at least;

A Dev Manager / Team Leader
4 experienced developers,
1 tester,
1 product owner
1 Graphic designer

and that is about the minimum you can get away with. If you are creating something that is not UI intensive you may get away with out the Graphic designer, but that is a team of 7 - 8 people and often you need a team like that for each product you are working on.

This kind of rules out agile at smaller businesses simply due to the staff costs of the team.

Quote:

---

Originally Posted by NeedSomeAnswers

Its not so much the hardware costs which in the larger scheme of things is not very much, its the staff costs. In a good agile team you need at least;

A Dev Manager / Team Leader
4 experienced developers,
1 tester,
1 product owner
1 Graphic designer

and that is about the minimum you can get away with. If you are creating something that is not UI intensive you may get away with out the Graphic designer, but that is a team of 7 - 8 people and often you need a team like that for each product you are working on.

This kind of rules out agile at smaller businesses simply due to the staff costs of the team.

---

In regards to a good team, I agree for the most part in the numbers of positions and would add that there should be a DBA involved at some level that works along with the team. Concerning testers, we have three, each one comes to a standup meeting each morning, we rotate thru the testers each week so each of them gets hands on with the project.

I noticed in one of your earlier emails, you mentioned you where still doing sprints. How long are your sprints Kevin? and do you a full scrum agile setup or something else?

Also as you are writing modern web apps have you looked at any NoSql databases yet, like MongoDb or RavenDb?

We are using VSO for managing the solution in stories/task...
Entity Framework is our model for database work with SQL-Server where it use to be IBM-DB2 (had been in use for 30 years until two years ago)

Quote:

---

We are using VSO for managing the solution in stories/task...

---

Ah ok i was more asking what form of Agile do you use? is it Scrum or something else?

Quote:

---

Originally Posted by NeedSomeAnswers

Ah ok i was more asking what form of Agile do you use? is it Scrum or something else?

---

Scrum

Aha i thought you would be when you mentioned Sprints.

With Scrum i found we spent an awful lot of time grooming and sizing the backlog and in long planning meetings. (i was the Scrum Master so this probably affected me the most) and my team while they liked the flexibility of the scrum approach quite a few of them resented all the extra meetings.

We actually moved from Scrum to Lean Agile at my last place which i have to say i preferred as you get to keep the flexibility of approach but seriously reduce the amount of planning and grooming you do ahead of time. If anything Lean Agile displays more agility than SCRUM :)

For a Dev team it has all the advantages of SCRUM but with few of the disadvantages. It's the business that has to make the bigger change in Lean Agile as they don't get the same type of or reporting on progress, and in fact you don't get any sensible data out of a Lean Agile team until they have been working on something for a few months which can be difficult for management to get there heads around.

I read over that link with some interest and some increasing dismay. One of the problems I have with the whole agile development is that it seems to flirt around the edges of being well defined without ever really getting there. I kind of get the impression that none of the techniques is so rigidly defined that it is entirely possible to determine whether or not a team that is claiming to be doing agile is actually agile. To some extent, it seems like a recipe for more meetings, especially scrum, and those meetings may or may not be all that helpful. Furthermore, the ultimate success seems to be due more to the individuals on the team rather than the technique, while the technique is vague enough that it can be given credit for the success of the team, while also being vague enough that any failures can be attributed to not really following the technique. In other words, agile seems to be more about talking points, and those who push it are just scrum wags.


(ok, so the whole post was about not telegraphing those final two words, but I really do doubt whether agile is more fluff or substance.)

Quote:

---

the ultimate success seems to be due more to the individuals on the team rather than the technique

---

+10000!

This is true of all project management aproaches though, they're all only as good as the people running them. None of them is a silver bullet and any given project will only succeed if somebody takes the time to actually run it.

Quote:

---

One of the problems I have with the whole agile development is that it seems to flirt around the edges of being well defined without ever really getting there

---

What people don't always get straight away is that Agile is NOT a methodology its just a framework, and basically you choose a methodology like Scrum / Lean or XP (extreme programming) from within the Agile family so to say.

Methodologies like SCRUM are actually well defined, that link i posted probably wasn't the best to give you a clear definition though.

It is also worth saying these kind of methodologies are not for individuals or small development teams and if you work in one of these environments then Agile can look very strange to you.

If you work in a Software house where you sell software to business customers then Agile can do a great job making you more reactive to your customers, and if done well can definitely improve your software delivery and product quality.

Quote:

---

(ok, so the whole post was about not telegraphing those final two words, but I really do doubt whether agile is more fluff or substance.)

---

Having worked in an Agile environment i can assure you that if done properly it can work well.

It can also work badly as well if badly implemented, if the development manager doesn't understand it very well or if the team is not experienced enough.

At my last place of work we moved completely agile, first to SCRUM and then to LEAN agile, and we did it in 7 separate development teams

So it was a big place, 7 dev teams all with around 6 developers + 2 testers.

Not all the teams implemented Agile well, and the teams that were inexperienced really struggled in particular with SCRUM which due to the developers not knowing the product meant that planning meeting were at times lasting an entire day for one of the teams!!! (i am not kidding)

If you have an experienced development team working on a product they know (as in Kevin's case), then this reduces these meetings considerably and makes SCRUM workable.

LEAN Agile as a methodology removes many of the meetings described in SCRUM, and in fact it uses principles of lean manufacturing. You basically create a backlog BUT you only clearly size and define the stuff you are about to work on, everything else you spend less time on as it is to far away.

As you pick jobs up you do a task breakdown into task developers can pick up, and share them around the team.

Also you have don't have a fixed plan, you decide on what to do next on a day to day basis as the team finish the last job. You do have a plan (or backlog which should define your whole project) BUT only the over all deliverable NOT what is done when.

To be fair it is a bit more complicated than this as you can have architecture tasks, and if you have dependencies then the Development manager will need make sure that this is reflected in the backlog.

It is a bigger subject then this post to fully describe the process :)

Out of the 7 teams at my last place i would say 5 of them in the end implemented Agile well, the other 2 teams should have never been moved to an agile environment in my opinion.

Agile and its flavours can work really well but as with any other methodologies;

- firstly it needs to fit the problem you are trying to solve

- secondly you need to implement it well.

To be honest, I steer clear of such discussions, as I don't have any experience with larger teams, to make any commentary regarding these paradigms.

Since large teams have been around for many decades, now, they do appear to be rehashings by another name of certain standard techniques.

I haven't really studied these techniques and frameworks in great detail, but it seems to me that one missing element is a single driving architect. Further, while teamwork is good - teams aren't teams unless each individual is more than competent at their given task. The techniques described seem to run the risk of dragging things down to a lowest common denominator.

From all I have read, however, the technique isn't the solution; indeed, the techniques (such as Scrum) have a glaring hole - it is completely managerial based, although it doesn't look like it on the face. You need an enforcement of a timeline, and that requires time management. It looks like each technique simply chops up a larger project into smaller manageable chunks, which an individual developer can put a cost/timeline to without a great deal of experience. Rapid reassessment of current development allows management to realign and refocus on task; you basic develop/assess iterative cycle.

I'm with SH on this one, but it probably comes from being completely ignorant of the application. I generally work in an environment where there is rarely a dedicated programmer, let alone a team of more than a couple, so what I say is probably all hogwash.

Quote:

---

Originally Posted by NeedSomeAnswers

Methodologies like SCRUM are actually well defined, that link i posted probably wasn't the best to give you a clear definition though.

---

To be fair, the link wasn't really about SCRUM.

Quote:

---

It is also worth saying these kind of methodologies are not for individuals or small development teams and if you work in one of these environments then Agile can look very strange to you.

---

This is a good point, in my case, as I work with other developers only to the extent that I say hello to them in the halls. We barely even know what each other is working on, so we are very much individual. I have long realized that all of Agile makes no sense to us with our teams of 1 (not even that in some cases), but I'm still interested in it as a way to move projects along. I guess I have the hope that some day the organization will see a project as sufficiently valuable that it deserves more than one person on it. That day hasn't come, yet, but it might, so I think about it.

Quote:

---

If you work in a Software house where you sell software to business customers then Agile can do a great job making you more reactive to your customers, and if done well can definitely improve your software delivery and product quality.

---

That's actually the part of agile that I find appealing. One of the things I have learned with all the projects I have done in this organization over the last 17 years is that we really fall down when it comes to involving the customer (all the apps are internal, but internal customers are customers nonetheless) in the process. Even when we do get feedback from the customer, that's how it is structured: Feedback and JUST feedback. We say, "we're doing this thing for you, and this is how it will work, what do you have to say?" That's not good. So, that customer-centric focus of agile is appealing to me. However.

Quote:

---

Having worked in an Agile environment i can assure you that if done properly it can work well.

---

This is the problem I have. If you decide to use Agile, and everything works out great, then did you do it properly? If you decide to use Agile and the project ends up being a mess, is it because you didn't do Agile properly, or is it just that the people involved....were themselves a mess.

As a case in point, I have been tangentially involved with a project that has been a mess....I mean been in production....for several years now. I don't know the methodology very well, though it appears to consist of replacing the developers every other year, or so. However, I'm VERY familiar with all of the people involved (other than the developers, since they never stick around long enough to bother learning their names, even). On the one side is management, which are all a bunch of researchers who moved up the ladder a bit. These people are all decisive, stong-willed, and highly analytical. Personality testing, like Meyers-Briggs make them out to be analytical types, and they really are. In fact, this particular group is some of the finest examples of that personality type.

On the other side is a group of people who are even more strongly selected to be relationship oriented. They run semi-autonomous fiefdoms where they have to keep a small team of people motivated at work that is often tedious and occasionally very strenuous (though almost never dangerous except to hands and teeth). Those are the toughest conditions to keep people motivated at, and these people have few tools to work with other than their own personalities. Therefore, they are selected for their ability to achieve goals with disparate people by understanding those people and avoiding the types of conflicts that cause breaks. They won't succeed through force, but are great at persuasion.

Put together, these two groups are oil and water. The one group is forceful and decisive, but not knowledgeable, so they look to the other group for the knowledge, but the other group isn't about to correct the mistakes of the first group, so the mistakes of the first group end up being ratified until the fact that they really are mistakes has caused all the mischief possible.

As a team, the two groups are a disaster, and the project is a limping scrod as a result. Saying that they did, or didn't implement Agile all that well seems like little more than a convenient scapegoat from a deeper realization that these two groups simply don't make a good working team, no matter what the methodology.

Firstly just let be say i am not an Agile evangalist, but i can see the value though in Agile implemented well in the right circumstances.

...And just to point out most of the major software companies use agile. Google, Apple, Microsoft, Amazon and Spotify to name a few all use Agile development.

The reason i included Spotify in that list is here is a really good little video which explains Spotify's Agile development here

It also explains the companies evolution of Agile to suit them which i think is key.

Quote:

---

Originally Posted by SJWhiteley

Since large teams have been around for many decades, now, they do appear to be rehashings by another name of certain standard techniques.

---

To some extent this is true, firstly Agile is not that new and secondly it does indeed pick up bits from other older techniques, but then again pretty much all new methodologies seem to.

Quote:

---

I haven't really studied these techniques and frameworks in great detail, but it seems to me that one missing element is a single driving architect.

---

Not really, it neither includes or precludes an architect, that just depends on your need.

I will give a couple of examples;

1, Most often Agile is brought in to teams working on existing projects so the initial architectural work has already been done, and in my opinion it works at its best here, adding values in small chunk's to existing systems in a reactive way. In this situation you don't really need a lead architect.

2, I also worked in a team building a brand new system from scratch using agile. The team had a senior very experienced developer, they were what you would call the architectural lead.

What we actually did was at certain key points in the project the senior dev would propose a way of designing the system and get buy in from the other developers in the team, which also made sure that all the dev's understood the architecture.

Quote:

---

Further, while teamwork is good - teams aren't teams unless each individual is more than competent at their given task. The techniques described seem to run the risk of dragging things down to a lowest common denominator.

---

This is very true, and a mistake some teams make when implementing agile, you need you developers to be experienced and experienced in the product/domain as well. It just doesn't work as well if the team members are at differing levels of ability.

Quote:

---

From all I have read, however, the technique isn't the solution; indeed, the techniques (such as Scrum) have a glaring hole - it is completely managerial based, although it doesn't look like it on the face. You need an enforcement of a timeline, and that requires time management. It looks like each technique simply chops up a larger project into smaller manageable chunks, which an individual developer can put a cost/timeline to without a great deal of experience. Rapid reassessment of current development allows management to realign and refocus on task; you basic develop/assess iterative cycle.

I'm with SH on this one, but it probably comes from being completely ignorant of the application. I generally work in an environment where there is rarely a dedicated programmer, let alone a team of more than a couple, so what I say is probably all hogwash.

---

The technique on its own isn't the solution, and in some cases as i said in an earlier thread i wouldn't use it, Agile is not a cure all.

What it is a development framework that can in some circumstances make you a more productive team.

Finally i just want to counter a a couple of specific thing in your bigger statement above

Quote:

---

techniques (such as Scrum) have a glaring hole - it is completely managerial based,

---

That is to completely misunderstand agile, its the opposite of that. You have a product Owner who is sort of the equivalent of a product manager, BUT in Agile they become more part of the development team.

In my experience Agile actually take quite a bit of power away from senior management as to HOW you are going to do something. Management only gets to say what they want not how to deliver it which is entirely in the hands of the team.

Quote:

---

You need an enforcement of a timeline, and that requires time management

---

SCRUM does, Lean agile on the other hand doesn't, but even with Scrum that time management is done by the Dev manager / Team Leader NOT outside of the team.

Quote:

---

It looks like each technique simply chops up a larger project into smaller manageable chunks, which an individual developer can put a cost/timeline to without a great deal of experience.

---

Yes and No, as in it is that but it is a lot more than that.

Its quite difficult to explain to someone with no experience of an Agile environment because it is quite different to other techniques imho.

Quote:

---

I have long realized that all of Agile makes no sense to us with our teams of 1 (not even that in some cases), but I'm still interested in it as a way to move projects along

---

Quote:

---

That's actually the part of agile that I find appealing. One of the things I have learned with all the projects I have done in this organization over the last 17 years is that we really fall down when it comes to involving the customer (all the apps are internal, but internal customers are customers nonetheless) in the process. Even when we do get feedback from the customer, that's how it is structured: Feedback and JUST feedback.

---

So one of the thing i really like about Agile, is the review process. In SCRUM you have fixed review meetings with stakeholders, where you demo what you have done at stages over the project. With Lean Agile you are less fixed you just review when the team feel you have completed a piece of work that is a worth reviewing.

If you wanted to take one thing away from Agile for your own use, trying to break up your work into demoable chunks and demo them (assuming you can get the people to attend - in Agile the business does not have a choice in this they must be engaged in the process) and get feedback there and then as to what people like and don't like.

Quote:

---

This is the problem I have. If you decide to use Agile, and everything works out great, then did you do it properly? If you decide to use Agile and the project ends up being a mess, is it because you didn't do Agile properly, or is it just that the people involved....were themselves a mess.

---

Well it the old question is it the technique or is it the people at fault. Part of AGILE is getting the people part right. You have to get the team right, and you have to educate the business to what there responsibilities are. Senior management MUST buy into to the whole Agile approach otherwise it wont work anything like as well as it should.

When AGILE is done properly it wouldn't allow the situation you talked about at some length in your messy project.

Quote:

---

As a team, the two groups are a disaster, and the project is a limping scrod as a result. Saying that they did, or didn't implement Agile all that well seems like little more than a convenient scapegoat from a deeper realization that these two groups simply don't make a good working team, no matter what the methodology.

---

It seems to me though there is no-one forcing them to get the job done or to change.

If people dont want to read those long arse posts :) then just watch the video! i will post it here again

https://labs.spotify.com/2014/03/27/...ulture-part-1/

I did read the long arse post, and felt it was well written.

If this was chit chat I'd make some lewd comment about the discomfort engendered by a long arse post.

Personally I like Agile aproaches and find them a bit more "real world" than more traditional "design up front" aproaches like waterfall for most of the projects I work on. I usually find the user doesn't really know their requirement up front and Agile is much better at coping with that and allowing for evolution of design. That said, there are a few safety crititcal systems I've been involved in and those defeinitely benefit from a more rigidly specced aproach. As others have said, pick the right paradigm for the project.

But whichever paradigm you pick, you will still need to manage it. I think that's often the problem with these discussions. People look to paradigms to manage themselves and the evangelists for any given paradigm do tend to hold out that promise. It's a myth though. Project management takes work.

Quote:

---

Originally Posted by FunkyDexter

...

But whichever paradigm you pick, you will still need to manage it. I think that's often the problem with these discussions. People look to paradigms to manage themselves and the evangelists for any given paradigm do tend to hold out that promise. It's a myth though. Project management takes work.

---

Totally agree. It does feel like the management aspect tends to be overlooked, and that makes me more comfortable with such techniques. No matter how skilled a brick layer, he cannot build a house. Even with a team of the most skilled artisans, they still will not be able to make a house.