That growth rides on innovation, and innovation on learning, is an established fact. However, organizations struggle to maintain the learning curve of their software architects and developers. It is not that they lack talent or drive. These smart, talented, and creative people are boxed into their roles and departments, each working on her own ideas and fulfilling the expected roles. The result? Learning becomes a chore while the tide of innovation seldom reaches the tipping point. The cure for this malaise is surprisingly simple: shake up the system!
However, this is easier said than done. Pre-existing targets, deadlines, workflows, the organization’s vision, and commitments to existing clients, together form a gridlock that can disable any organization’s growth. That is why, it is important to inculcate a culture of continuous learning and innovation by exploring new and different modes and methods of collaboration, learning, and team bonding. Here are four of my favorite practices that aren’t just simple to implement, but also tremendously effective when executed correctly.
First: Utilize Pair Programming
Pair programming is a useful practice to help foster collaboration. As the name implies, this is a programming methodology where two developers work together on a task, which can be accomplished either remotely with screen sharing or sitting together at a desk. At first glance this setup might look counter-productive. “Double the resources on a single code!” some might say. However, a joint study conducted by Alistair Cockburn from Humans and Technology, and Laurie Williams from the University of Utah, Computer Science has found that there is just 15% hike in cost instead of 100%. The additional benefits more than compensate for this marginal hike in cost.
When two developers work on a code together, one codes while the other checks the code, provides perspective, and helps when the first gets stuck. The roles are exchanged after a while. This approach ensures a faster pace of work and better-quality code. Mistakes get caught as the code is being created thereby reducing testing nightmares and improving quality assurance. The code length is shorter and has improved design. Developers learn from each other, talk more often with each other, leading to better team dynamics.
While Pair Programming cannot, and should not, be made mandatory in all situations, it does have its uses. For instance, when faced with a tight deadline, two individuals could work side by side by dividing the tasks between them. This setup not only helps cut slack but provides instant support. Partners can question each other, gather perspectives, help each other out – covering plenty of ground in a brief time span.
Pair programming can also fail in certain situations. Tim Groven, an IT specialist with a .NET development team in Ohio, has shared in a post on Agile Connection that the introduction of Pair Programming in their organization wasn’t without any hitches. Senior developers felt slowed down when paired with junior developers. Some developers found it difficult to express themselves vocally. Some developers just didn’t get along with each other.
That is why the key to implementing Pair Programming is to make it people driven. Introduce pair programming to your team. Give them the freedom to explore its variations (Check out Ryan Oglesby’s post on the ThoughtWorks blog). See what works and keep it fluid.
Second: Host a Hackathon
Hackathons have developed a reputation being adrenaline driven coding competitions stretching through sleepless nights. So, let me set the record straight by sharing Joshua Tauberer’s definition instead: “Hacking is creative problem solving. A hackathon is any event of any duration where people come together to solve problems.” Hence sleepless nights, sports drinks, and awards for winning teams are not integral characteristics of a Hackathon. But bringing everyone together to solve a widespread problem is.
Creativity thrives amidst new boundaries. In any organization, individuals work in teams and according to set processes. While this setup is predictable and safe, it stultifies creativity and breeds boredom. A Hackathon breaks through all such organizational barriers. The intent of a Hackathon is not to find a solution, but to find better ways of doing things, learn from each other, feel inspired, and have fun. Theo Priestly, in an article in Forbes states: “The problem with traditional project methods to tackle business issues is that they become too structured over time, mostly due to how transformation is managed into a Waterfall scenario. Even Agile project suffer fatigue. Requirements are sought from the business community and more often than not the ‘blue sky thinking’ ideas are given the lowest priority due to time constraints and budgets. A hackathon can dispel this by inviting diverse groups of people to the table that wouldn’t normally be given the chance to air their voice to impact a problem or innovate a product or service proposition, and locking them in a room until the solution is built.”
The reason why Hackathons have become commonplace in the tech world is because its benefits are numerous:
- Innovation fueled by creative disruption
- Community building by making programmers from different teams, and who otherwise wouldn’t engage with one another, engage in intense coding sessions
- Sprints of learning and knowledge sharing by making experienced developers work alongside rookies
- Making newcomers feel welcome by breaking bureaucratic demarcations.
- Motivating employees to showcase their hidden talents
- Discovering better, more efficient ways of solving problems