Modelling software development process has been evolving for decades. In this process of evolution, many models have become obsolete, while few served as stepping stones to models we use even today. If you have an idea of Agile, this article will make sense to you.
XP(Extreme Programming), FDD(Feature Driven Development), Scrum, AM(Agile Modelling) all these are some applications of Agile methodology that are widely accepted for software development.
Agile or simply ready for change
There are certain required properties on which success of Agile development depends. Lets take a look.
Self Organised
All teams are encouraged to be self organised and react in an organised way, whenever there is a change of requirements.
Ready to Reconsider
At any point of time, a customer can decide what is going right or wrong for their product, eventually they will come up with a change. Now we must be all ready to reconsider everything right from requirement, planning and execution. However, this is only possible for a team that understands what working in harmony is.
A team that understands each other, communicates and articulates well. A team where each one knows the strength of individual members and adapts accordingly while there is no place for individualism.
Now we see, if the team is ready to take any kind of hit and each one of them complements the team there is no place for animosity and competition, all are working towards the same goal. They all complement each other – the product synced with devs, devs synced with testers. Given any change, they will be able to react in an organised way. Similarly developers are always ready to refactor and redesign. Considering all of these things in mind let’s see how pair programming can help. From some of my experience, I will take you through it very informally.
Pair programming
Agile is all about keeping what is working for team and dropping what doesn’t. For some teams, pair programming is a blessing and companies like these integrate it in their processes. While many are hesitant, there are enough valid reasons also for not considering it at all.
I will not say that pair programming is a must but there are certain projects or features that will benefit from it. So if their team thinks they can adapt to pair programming for certain project and then shift to their traditional approach for the next project. This is totally appreciated in Agile.
Some benefits for pair programming are..
Strengths
Every developer has his own strength. One can be good at writing quick code while the other knows the best practices. In some case some developers have a good hands-on understanding of user interface and others could have more product knowledge. Hence contributing in a rock solid way.
Taking Pilot Seat
During development there will be situations where expertise of certain kind is required, when one with the best hand can take a pilot seat and progress. While this happens, others can simply observe and learn as a byproduct. This simply minimises any hiccups, as paired for a considerable period results in knowledge sharing and mutual learning.
Resting
Working for long hours is exhausting for developers,but this doesn’t mean it will yield more output. They will need some rest periodically for thought process. But in case of pairing when one is working, the other will be able to relax. While one rests, development continues and while both rest they will be discussing problems.
In the middle of no where
Many client requirements need a prototype. This might require some research and development. Like suppose being a Java developer you are expected to crack a prototype in Dart. Of course, any body can learn and develop that prototype but when paired together the radius of learning expands drastically. Imagine your partner is stuck and trying hard to achieve a solution, while you are already doing some random searches and come up with the solution. So it totally make sense when paired, to research as you develop!
Conflict is good
When paired, a developer often argues over an approach and thus has conflicts in thought process. This will lead to identifying trade-offs with each others’ approach. They try to identify what will happen when we take this approach in xyz cases. Finally the one that is most suitable is selected. But this is only possible if they are good listeners and don’t brag about their approach to be right. And it’s never about right or wrong, it is always about what is appropriate and healthy. And when situations change they must gracefully accept that.
Distribute it when necessary
There will always be some checklist with a project. Some projects have a core business logic and then integrating code at several places. While central logic can be done in a pair, other tasks can always be distributed and achieved in parallel.
Un-pair sometimes
Above were some nice facts that I learned but there is one more thing that’s very important. After a couple of projects together it is very healthy to either shuffle pairs or just switch back to traditional approach. This enables developers to get some space and not to be too dependent on each other. The next time they will be excited to know when they are paired again, and they will have added some more skill sets too.
Conclusion
Through my own, experience I have some beautiful memories and shared some great laughs when I realised something stupid has been done. I realised understanding requirement is easier as there is someone to re-verify. In any difficult situation there are more chances to find a workaround as this other person is going through similar challenges, and moreover ready to rewrite almost anything. While developers are getting an upgrade, ultimately team is going to benefit from it.
This article is also published at Medium
