
In this blog post I want to make a strong case for agile development methodology when working with a technology partner on a joint product. Last quarter I worked closely with the development team for Parallels Automation to accomplish integration of BackupAgent in
POA. I had the pleasure to visit their
development center in Moscow, which I enjoyed really well. Aside from the courtesy and
hospitality I received, the project was a clear case for agile development practices. This particularly applied to
pair programming, which is probably one of the most controversial parts of agile and extreme programming.
Pair programming
During my five day visit I was paired with a developer from Parallels. We worked together as a team. The developer would write code in PHP, while I would nail down impediments on-the-fly or craft better specs when needed. Ironically, I don’t even know PHP very well, but I was still able to help him produce code effectively. My main goal was to keep his fingers tapping on the keyboard.
Coding is only a small part of the project
The nice aspect of this project is that the work fitted nicely into a single sprint. It might even have been one
user story sticking as a post-it note on the internal
Kanban board of the team I worked with. Also, the team members had detailed specifications, which were cross-checked with our mutual
customers. Looking back at the project we spent most time on specifications and testing. During my 5 day visit 95% of the code was produced, but we deployed the solution to the first customer at least one month later (in March) due to all required testing and preparation for deployment. Most of the work was executed by the Parallels engineers, so I do not have a clear-cut insight on time spent.
The project and visit inspired me and made me realize how important it is to know the productivity and effectiveness of your coding process. It also demonstrated that effective coding depends on a lot more than putting a smart developer on the job.