A project's development team is the engine that drives it toward production. But without effective communication to lubricate progress, misfires can slow it to a crawl. A year or so ago, our design team worked with a client on a data visualization project. They began by wireframing the visualizer to create a mock-up, while our developers started creating some basic parts of the application.
But once developers began building the visualizations, productivity tanked. It became clear that, although the visualizations looked great and were valuable to the end user, they were causing development headaches. Because developers didn't give input on them, they were struggling to implement certain design decisions that should've been made cooperatively.
With development spinning its wheels, we put the project in park until we could assess the situation. At that point, we realized the teams were moving in different directions, so we joined them together in decision-making. Together, they successfully made changes to the existing visualizations and co-created new ones. With productivity back into high gear, our development team cruised through the remainder of the project.
Fortunately, we spotted and corrected the workflow problem within a single project. Quite often, ineffective collaboration goes unnoticed for much longer, wasting company resources and sapping progress. How do you know if progress isn't what it should be? If you adhere to sprints, you can monitor your team's velocity by tracking points completed every one-or-two-week stint. To do this, assign points to each user story within a sprint according to its perceived complexity. Then, at the end of the sprint, tally up those points to determine your team's velocity. Compare this figure from sprint to sprint to determine whether productivity is increasing or not.
A less direct — but also valuable — way to monitor productivity is through code coverage. This metric describes how much of your product's code has been tested. A high percentage of code coverage demonstrates that your team is confident about pushing new code. But if code coverage dips, your developers are likely losing productivity one way or another. Bug count, too, can be a reliable marker of productivity. If developers are continuously pushing features but errors in the code base are increasing, you're ultimately taking one step forward and two steps back. While code coverage and bug defect rate aren't directly comparable between teams, they can give insight into developers' productivity over time. And only by monitoring productivity regularly can you help them work more efficiently.
No matter the source — mismanaged expectations, changing requirements, an unclear decision-maker, or waterfall methodologies — 10 steps can help you bring development back up to speed:
More often than not, inefficient communication is to blame for slow development. At Yeti, we use Slack internally for all of our projects and initiatives. Slack automatically stores our conversations, and we create custom channels for specific projects to keep everyone in the loop. Communication counts, especially for highly collaborative work.
Developers make all sorts of micro-decisions about the project's code, but they often need to involve others as well. When it's not clear who's responsible for each element of a project, productivity suffers. Create a central document that lists every team member's responsibilities on each initiative. At Yeti, we conduct an internal and an external meeting at each project's kickoff, ensuring everyone knows — clients included — who is responsible for what.
In order to work efficiently, developers need to understand the process for committing code into each project. Set up a global contribution guidelines document, or create one for each project, if they maintain a variety of code bases. Senior developers don't have time to debate processes or explain contribution rules each time a new developer joins the project. To avoid this, Yeti's developers operate with unified contribution guidelines and automated code tests. For example, on a back-end project, we have an automated test that ensures pushed code complies with our contribution guidelines.
Plain and simply, waterfall methods kill developer productivity. Even when companies seem to be using agile methods, they're often conducting a series of small waterfalls. To truly be agile, design and development teams must sprint together. Sync teams so that design is working on wire frames to be built by development no further than a week or two in the future. When developers review designs, Yeti has found, they build more effectively and more knowledgeably.
Entrust an engineer with setting up an appropriate continuous integration (CI) and continuous deployment (CD) pipeline for your project. Have him or her document the process so others can use it in the future. This prevents the development team from becoming mired in a cumbersome process to check, quality assurance, and deploy their work. At Yeti, we use Codeship, CircleCI, or Travis to run automatic checks throughout the coding process. This redirects developers' focus from ops work back to their specialty — development.
When a developer finishes a user story, the last thing they want to find out from a project manager is that it's implemented "improperly." To avoid these frustrating feedback loops, ask a project manager to create detailed acceptance criteria so every developer knows when they're finished with a user story. Your project management tool should have a spot for you to record this information, or you can make a custom field for it.
If you haven't already, bring a project manager (PM) aboard. A strong PM amplifies a development team's productivity by removing administrative burden from the team and ensuring nothing slips through the cracks. For Yeti's projects, we assign a dedicated PM to coordinate various aspects of the campaign. Assess your organization's projects, and assign or a hire a project manager for projects that have grown large enough.
Never change stories within a sprint unless absolutely necessary. Developers lose progress and passion when requirements are changed out from under them. It's important to be flexible with agile methods, of course, but once a sprint has been committed to, its content shouldn't change. When Yeti conducts sprints with clients, we ensure everyone agrees on the user stories before kicking off a sprint. Once it's started, the chance to shuffle, change, or remove stories has passed.
No matter who you are, you're maximally productive when you're invested. The same goes for developers. If they're excited about the work they're doing — whether it's cleaning up a code base, trying a new technology, or helping the end user — they'll be more effective. Invite each developer to join a user testing or interview session to give them a reason to work hard. At Yeti, we conduct an informational session at the start of each initiative to share project details. We discuss the reasons behind it, get to know the end user, and give opportunities to meet the client's team.
It's easy to prioritize new features that help a product earn more users or increase revenue, but over time, your project will accumulate technical debt. Left unaddressed, this debt eats away at developers' productivity and slows the project down. When introducing what might be technical debt, we allocate time to pay it down. Decide your ideal ratio of time spent fixing technical debt to time spent building new features, and then create tasks to fix debt at regular intervals. Whatever your technology project, there's no substitute for a communicative, well-oiled development team. So no matter what's slowing product development at your company, give Yeti a call. With a quick tune-up, we'll have it firing on all cylinders again in no time.