Return to site

Mobile dev notes: experience with pair programming

Transition of Pivotal culture to our team

In summer I wrote about our new client http://www.coderbunker.com/blog/coderbunker-a-new-client. I finish with contract and here is a few notes on issues with pair programming I faced with to learn from it and know what to do in the future when you face with it.

 

Pair programming goal.
Goal behind pair programming is increase quality of software and minimise risks to fail project by eliminating critical fail factors. With increasing codebase quality and minimising risk to fail you pay by speed of delivery and increased cost.

 

Challenges:

  •  Clash in personalities. You and your pair have different views, different speed of development, different backgrounds and communication habits. You communicate all the time and it might bring positive or negative results. It takes time for mutual adjustment or you can ended up you both not a good fit for each other. Proposal: develop self learning plan and track progress how you both work with each other, does your velocity and communication become better or worse from week to week; time box it in one - two months
     
  • Velocity. It is difficult to talk about velocity here as in short term it drops as you and your pair have to constantly seek for consensus. I have to rely on management feedback and monthly renew contract to receive signal I do a good job.  Proposal: have access to all business communication to understand progress and the plan, personally for me is difficult to rely solely on opinion from manager as it might be ambiguous.
     
  • Learning new skills. For engineers it is natural to learn tech stacks on the job. Technology moving forward and you have to update your skills as in your free time and on the job. In pair it is difficult to do as you and your pair have different ways obtaining new skills and do it together is wasting your or your pair time. Proposal: either don't go into process if you don't match on all skills or agreed on fixed time per day to obtain new skill if you and your pair don't have this knowledge.
     
  • Diverse signals. Pair programming requires time to learn. The process should be properly established and constantly improved during time. However it is easy to compromise on process to get a quick gains. Sometimes I simply don't know what I should do - learning how to work in this process and incrementally improve efficiency or compromise on it to deliver results, I received different signals and have a feeling I do good job when follow management expectations, not when I deliver value. Proposal: strictly agreed on we either time box time to establish process and learn to work within it efficiently or experiment with it by taking what we found useful.
     
  • Two way communication. People react on feedback. Make feedback loop shorter is a corner stone of pair programming -- that's how team adopt faster to do right things for this project: constant feedback during work in pair, weekly retrospective and feedback on work for each pair. If communication is not open or people complain they don't want to hear your thoughts it demotivates and put process under risk. Proposal: encourage transparency and free information exchange, build a culture of radical honesty.
     
  • Support of the process from all team members. I personally wasn't happy how we do things, one team member was not happy with it as well, but didn't share his concerns with management openly (how many team members didn't share them at all?). My attempt to fit it failed, change in process lead to frictions with management and ended up to stop contract, eventually management adjust the process and it is good as it helped to find support among team members as process already was compromised, but it means we failed to establish pair programming. Proposal: I see the corruption in process was due lack of time (pressure from stakeholders) to properly manage transition from Pivotal culture to a new team. I see the best way to overcome it is start with small team (no more than 2 pairs), develop right velocity (at least one closed ticket per day, tickets intentionally are made small) and build culture of incremental learning&improvement -  scale afterwords step by step without drop in performance and culture compromise.
     
  • Lack of accountability on the project. You don't own your task, you don't have a scope -- you share it with team. There is no way to measure your personal contribution. Personally it makes me uncomfortable as you can not spot and fix flaws in process, your or your partner skills and work habits. It is difficult to understand when you have t work on the problem at your own or ask your pair about contribution, sometimes it might look not polite, but from different pairs I received different (opposite) feedback what to do to improve our work. Proposal: find a way to keep person accountable for what he or she doing, one of the options I offered above is to establish norms for velocity - how quick in general the ticket can be closed.

 

I believe in the process. When we work with pivotal labs in Singapore it was great. Sadly something didn't go right when we finish transfer and team experiments to do it better. Above is my thoughts on this what I would be done better next time. Personally I would use this process for projects with length more than year and a fixed team (not a consulting or service companies)

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly