New Year’s Resolution — Getting Over The “Developer Block”
Software development is a tricky beast to tame. It requires a tremendous amount of hard honest work combined with good information organization and exchange, open communication, the capability and willingness to solve problems as a team, as well as the absence of pure bad luck; which can sometimes be the achilles heel of any well-managed effort.
Bajra has been in the software development business for over 11 years now, so here are some things we’d like to share based on our experience that might aid others going through the same situation. These tips are meant to help teams get more output but please do take into account any particular nuances that your organization or team might have and make necessary adjustments accordingly.
The Problem
One of the most common pitfalls of an efficient software delivery team is what we like to call the “Developer Block” — the inability to be efficient due to prolonged exposure to the same set of complicated problems or code. We have observed this more with longer-term projects that tend to be product oriented and require constant support and maintenance compared to short-term efforts which generally have a defined end-state. As a company who carries out offshore development for our own as well as our customers’ solutions, we sometimes notice this within our client teams as well, where long-standing solutions or legacy product teams tend to suffer from a general lack of enthusiasm regarding tasks despite a high level of camaraderie. This tends to lead to a noticeable drop in productivity even though it looks like a similar level of effort, and then deadlines start to slip. When this happens, it causes potential issues for customers and product teams who are prepping up for substantial code improvement or feature launches and creates undue pressure for delivery and account management teams.
The Solution
We have been trying out different approaches to tackle this issue over the past few years at Bajra. When coupled with our own internal expansion, we had to adopt a structured approach for tackling the issue; and this is what we have found to work so far, with the understanding that we are all striving for the concept of ‘kaizen’ — continuous improvement:
1. Get Organized
The most important thing to need to do when you encounter the Developer Block is to evaluate current team structure and make necessary adjustments. We have noticed that teams lose their structural integrity and efficiency over time as team focus changes and there are changes to personnel. While this is natural and expected, it is important to restructure the team to put emerging talent in opportune roles and give additional responsibility to those that have been waiting in the wings to prove themselves. Furthermore, it is extremely important to organize the task at hand to utilize tools that facilitate information exchange and track improvement. Bajra uses the Scrum Methodology for most of our development efforts and we even built an in-house task management system to fit our unique software development process and collect meaningful data which will help us monitor and increase efficiency. It is recommended to utilize an appropriate mix out of the many open source, free-to-use and paid solutions to organize, track and share information; and eventually incent and manage performance.
2. Establish Accountability
Lack of accountability from any team will lead to potentially unmitigable results on business relationships. In the service business, customer satisfaction probably acts as the most common measure of accountability, but It is also important to weigh business priorities in the evaluation of project success. We have found that personalities and delivery outcomes can be conflated while evaluating performance — setting up guidelines for efficient performance assessment is also recommended to counter the friend or mentee bias in larger teams where it becomes easier to skip individual output scrutiny. In our experience, having a team leader be accountable for a groups’ performance is a good step, but there is a definite need for individual targets that need to be met in order to establish an overall performance score at the individual as well as group level. Bajra prides itself on open opportunity, so we have often associated performance and team management targets as part of incentive payouts and those also help all team members understand and perform according to their roles. Additionally, there needs to be careful consideration weighing in different elements to establish what happens if and when accountable targets are missed; as a general lack of consequences will throw off positive effects of any meritocratic system.
3. Facilitate Organized Information Exchange
In most software development groups, there will be some method of defining and capturing requirements. There are a number of schools of thought, techniques, processes, and tools that can be used in this regard; and we don’t intend to discuss the merits of any; but it is very important to have a common system, guidelines, process, and a tool to capture and communicate business needs accurately and with appropriate detail. This should include capture of historical changes and associated communication through some common messaging platform, as it will allow future analysis for search of best practices. Bajra uses a mix of tools depending on our customers preferences for our ongoing software development services, but we amalgamate data manually when necessary to assess project efficiency metrics. There are plenty of integrated systems in the market that allow for product-task level integration, allowing the development team to see how things fit into the big picture, as well as allowing product teams to manage release targets. Nevertheless, oftentimes we have seen many teams use a mix of free-to-use tools to arrive at a good-enough situation. However, there are instances where it might be useful or required to migrate to an enterprise-level solution, so it is recommended that teams review different solutions in the market from time to time and evaluate whether a change is preferred to ensure that information is shared all across.
4. Track and Reward Progress
Any process of efficiency improvement requires a minimum level of tracking to assess the overall benefit from that effort. Generally, projects track large milestones with their associated deadlines and as long as they are met, there is harmony at the larger scale. At Bajra, we do tend to lean more towards this level of milestone-based reward cycle for contributing team members through a variety of appreciative gestures and gifts. However, based on our experience, we recommend that teams also track and reward individual achievements or milestones. With the market as it is, any efforts made towards increasing employee control on compensation should yield a slight uptick in overall happiness and retention. We are currently working on an experiment to further this idea for an internal project, and we will be sharing those findings along with insights from some of our other interesting thought experiments in the software development space through a series of posts such as this going forward. Based on our learnings from previously conducted trials, we have found that there is a mix of business goals, team output, individual growth, and ease of task assignment which should be used to assess, and whenever applicable, recognize progress.
5. Discuss, Plan and Adapt
Bajra utilizes a flat organizational structure to facilitate open communication between all levels of the company. Nevertheless, we have noticed a certain hierarchical hindrance amongst some folks to utilize this open channel based on titles and experience. We have realized that this is inevitable as teams grow, because all startups start to lose that “everyone knows and loves everyone extremely well” feeling after a certain amount of growth and we crossed that a while ago. However, we do tend to focus on that same level of conversational dialogue in our meetings, where we have a set agenda for each meeting, take notes, capture action items, and do a round-robin to let everyone have a word in case they have not had the opportunity to speak so far. Open communication is key to managing tricky projects and delivery schedules. Alongside effective meetings, it is also important to carry out retrospective analysis through discussion from time to time. At Bajra, we do Sprint Retros to let everyone share their perspective of how things went and how they could be made better. Once we have new items to consider through the process, we take those to our governing committees, assess merits/demerits and consider them for a pilot. If a pilot is approved by different stakeholders, then it is implemented, measured and rolled out at a larger scale if deemed appropriate. This way, other teams can benefit from internal innovation and internal innovators can add depth to prevailing company culture.
These recommendations are based on our own experiences and there are cultural and situational nuances that might require certain modifications to these outlined approaches. However, doing any one of these really well should also yield significant positive impacts to overall productivity. We hope that those who utilize any of these recommendations also share their experiences with us so that we may learn and grow better together. Any differences in opinion are also welcomed to be shared in the comments section. For any further questions, feedback or just to say hello, please reach out to us at collaborate@bajratechnologies.com. Visit us at www.bajratechnologies.com to learn further about our company and what we do.
Shreyan Poudyal is the Chief Strategy Officer for Bajra Technologies.
