4 ways to run a leaner dev team

Doing more with less has long been the objective of running a lean tech organization, but now comes the age of COVID-19. IDC predicts a 2.7% drop in IT spending in 2020 with business leaders putting tech purchases and new initiatives on hold. Doing less with less is quickly becoming the COVID-19 normal for this year as IT budgets shrink, tech projects slow, and hiring freezes and layoffs squash hopes for new-hire relief. The challenge for the leaders of today’s tech organizations is weighty: continue to drive new value and fuel innovation without adding talent to the roster or dollars to the budget.

For development teams to succeed in this time of scarcity, they will have to learn to work differently. After the Great Recession, many IT organizations got leaner by taking advantage of offshore skills and resources. With the pandemic, the lesson will not be in offshoring, which many businesses already do. Instead, it will be a lesson in learning to emulate the leaner ways many distributed, offshore teams work: sharing resources across projects, leaning on professionals whose skills and experience are multifaceted, and embracing virtual collaboration tools.

If you’re looking to get the most from the development team you have in place, here are four lessons from the world of IT offshoring in how to do all you can with who and what you have.

Rebalance developer to tester ratio

For organizations using a traditional 2 to 1 developers to tester ratio, this is an opportunity to extend in the same way many offshoring teams do to the 3 developers to 1 tester ratio. Agile development, in all its speed and sprints, makes this stretch possible. Well-defined sprint plans embed testers in the team, streamlining and accelerating testing processes throughout development. With the tester working shoulder-to-shoulder with developers in every sprint — rather than waiting to test in the end phases of the lifecycle — the IT organization maintains both rigorous QA coverage and a leaner execution team.

10 is the magic PM number

In more stable times, best practices call for a dedicated project manager (PM) for every seven to 10 team members on substantial development projects. While PMs can often balance 2-3 smaller, less complicated projects, big projects require at least one dedicated PM for every 7-10 professionals. That’s because substantial projects use multiple platforms for input and output, adding development hours and complexity that requires strong, expert oversight.

Under today’s circumstances, 10 will become the standard number of team members most dedicated PMs oversee. This will save on staffing costs, but it requires smart technology in order to work. Ten team members is a higher, but familiar, PM team member count in offshore development. For example, at NashTech, Harvey Nash’s global outsourcing division, our offshore teams in Vietnam use an agile-based process we call ROAD (Real Offshore Agile Development). Adapted to manage larger work teams averaging 10 in size, the methodology leverages remote collaboration tools, such as Microsoft Teams, One Drive, Zoom, Slack, SharePoint, and DropBox. These collaboration enablement tools arm PMs with the ability to stay on top of all team member activities across the development process.

As PMs oversee higher numbers of team members, one key to success will be ensuring there are tools in place and in use that can support agile development. While many organizations may have remote collaboration tools, they may have relied less on them in the past. As PMs manage more people, they will also depend more on tools that can help them easily and digitally connect, communicate, benchmark, motivate and even meet with distributed team members.

Split your architects

While PMs will be managing more people, software architects will need to adapt by either managing more projects or playing dual roles. Managing more projects is just like it sounds. One architect is put across all projects (or many) versus having an architect on a single project. In this scenario, the architect would focus on the highest-level research, evaluation and design work while passing on all coordination, development, coding and testing work to other team members. For example, project managers can take on the job of communication with the business and the clients to free up architect hours.

In the case of taking on dual roles, an architect could save costs for the organization by playing both the senior design and a secondary support role as a developer. This is not a matter of asking one person to do two jobs but rather of having half of the architect’s time focused on strategy and design and the other half on implementation of that design. In offshoring, this is a common split where the architect also implements, and it can be invaluable in not only improving the final project quality but also improving future designs. Why? Because the architect learns firsthand from design flaws and challenges revealed in the iterative process of building and testing the design.

Kill some meetings

Meetings can feel like the enemy of productivity and that’s because sometimes they are. When developers are moving in and out of meetings, there is a lot of context switching. Time is lost as they leave one area of focus for another. To develop technology with speed and efficiency, it’s important to make sure every meeting has value.

Another way to get lean is to look for opportunities to combine meetings, shorten meetings, reduce the number of people in meetings if they all aren’t needed, and cut out meetings that can’t be justified, such as status updates that can be managed by collaboration technology. By cutting back meeting durations and cutting out unnecessary meetings, IT organizations will win back hours of productivity from every team member. That’s time and money saved.