What do you picture when you think about developing a new software feature? It’s natural to imagine it happening in a vacuum: You put together some requirements, send them off to the developers, and then after weeks or months of silence, get a notification: “Okay, we’re done!”
In the case of building Redbooth’s new Gantt capabilities, however, the development process has been intensely collaborative — and continuously informed by the needs of Redbooth customers throughout. And as a development team that builds productivity software, Redbooth’s developers also built in processes and best practices to their workflow to increase efficiency.
This is the third post in our series tracing the process of creating user-friendly and incredibly useful Gantt chart functionality for all of Redbooth’s users (you can catch up on the first and second posts if you haven’t already).
Read on to discover how Redbooth’s Gantt development team in Barcelona dug into user requirements and focused on communication and iteration.
You’ll also discover 5 best practices that enabled them to collaborate more efficiently — and see how to apply them to projects that you’re working on right now.
Understanding What Redbooth Users Want
The developers working on Gantt had substantial insight into needs and experiences of the customers who would be utilizing Redbooth’s Gantt features. Product lead Irwin Kwan and product designer Sarah Tanner recorded and shared the interviews they conducted so that the development team could see exactly who would be using Gantt and what was important to them.
“Watching customer videos felt like a reminder of what we’re building Gantt for,” said backend developer Pau Pérez. “We’re building a tool that will have a deep impact on our users’ daily work.”
Watching customer videos also provided insight into the unique needs of companies in different industries, Jorge Morante, frontend developer, pointed out.
“For example, for a construction company, the duration of projects is enormous compared to ours — we’re talking about years-long projects here,” he said. “So that’s something we are keeping in mind while developing the new Gantt.”
“Watching the videos helped me better understand the needs of users in Redbooth and why we are building Gantt,” Jorge added. “This kind of global vision of the whole process when developing features enables us to row in the same direction as a team.”
The team also worked to ensure that they could provide the best possible experience for customers. For example, Redbooth full stack developer Ilya Zayats took a clear messages from watching the recorded customer interviews: less is more.
“The main idea that I got from the videos was that most of the current Gantt tools on the market can overwhelm a user with a huge amount of functionality,” said Ilya.
“So from the beginning, I placed myself in a very skeptical position, trying to question every small part of the Gantt functionality and its necessity. In my ideal world, we should deliver a really stable MVP (minimum viable product) and then iterate quickly while getting feedback from our actual users. And that’s how we’re doing it.”
And with Redbooth users eager to start using Gantt chart features as soon as possible, it was important that the team stayed coordinated and worked rapidly. How the development team approached their work together was key.
Coordinating Work and Iterating Quickly
Back when Irwin and Sarah were conducting user interviews in December, the development team was still awaiting the results of that research. In the meantime, they were setting the stage for a technical framework that would support rapid iteration.
“Even at that very early stage, we were able to make enough assumptions to start investigating the technology underneath Gantt,” Jorge said. “So we could say, ‘Okay, we know we want to render colorful sexy boxes, position them according to date — and the drag-and-drop experience needs to be perfect!’”
The process of iterating quickly — and early — was essential.
“The team was developing throwaway prototypes even before the initial mockups were created,” Ilya said. “That was the key for the future parallelization of our work: it meant that we already had all the underlying ideas and foundations in place and the team was speaking ‘one language’ describing Gantt-related concepts.”
Staying connected on a regular basis was also important, both within the development team in Barcelona and with Irwin and Sarah in California. Daily standups were a key ingredient in that process.
“Every morning the first thing the team does is have a quick stand-up meeting where we explain what we did the day before and what we’ve planned for today. In one word: communication,” said frontend developer Andrés Gutiérrez.
And that morning meeting was just the first point of contact in any given day, which was especially important for the iterative process. “Doing these kinds of big projects, it’s important to iterate in small pieces,” Andrés added.
“We were actively syncing many times every day,” Ilya said. “We were communicating in the dedicated Gantt workspace we had in Redbooth with Irwin and Sarah, and with each other in our own team workspace just to be sure that we were staying coordinated.”
As the developers in Barcelona identified new challenges and opportunities, a lively dialogue continued with the Product team in Silicon Valley (using Redbooth’s built-in video conferencing, of course!). Instead of a top-down process, the combination of cross-disciplinary insights brought the best of several worlds to the process of building Gantt within Redbooth.
“The debates landed us in a good place,” said product lead Irwin Kwan. “Because of that back-and-forth exchange of ideas, along with the ability to ‘play’ with early prototypes and get a real sense of the product from the start, we were able to represent what we heard from our customers. This meant that we could ensure that we’re delivering from a technical perspective as well.”
5 Productivity Processes That Made a Difference
The team continues to use a variety of techniques to maximize efficiency and productivity throughout the development process. You don’t have to be building software to be inspired by these takeaways. Even if you’re working on a very different kind of project, there’s likely to be a strategy here that will work for you.
 Don’t Get Distracted By the Details
By streamlining the process of code review, the team could focus on the big picture instead of little details.
“We were actively reading each other’s code, and we have strict internal rules about how pull requests should be described — and an even stricter stack of tools that checks for the most common developer mistakes in a fully automatic way,” said Ilya. “This allows us not to concentrate on pinpointing wrongly placed commas or brackets, but on trying to understand the underlying idea and reasoning behind the code.”
The takeaway: Free up mental energy by automating as much of your process as possible. If you’re getting distracted by trivial details, you’re not able to focus on big decisions.
 Keep Sprints Short and Focused
In a development workflow based on a Scrum approach, “sprints” are periods of time that the team sets aside for dedicated work toward defined outcomes. At the end of each sprint, team members regroup, reflect on their progress, set clear goals for the next one, and incorporate feedback. For the Gantt development team, the duration of the sprints made a big difference.
“Short sprints really helped,” said Ilya. “Every sprint planning session was very short as well: when the team really understands what they are building, then no big discussions are needed.”
The takeaway: Working with a team? Be thoughtful about choosing the amount of time that will elapse before you meet up again to review and debrief. When you’re breaking new ground, it can be helpful to meet up more frequently.
 Hunt Down Issues Early (a.k.a. Spike It!)
Turning a design for a feature into a fully-functioning feature is always going to be a complicated process, and the Gantt developers knew to expect the unexpected. From technology constraints to compatibility issues, it helped to have a process that aggressively seeks to bring those challenges to light so they can be addressed early.
“On our team, we do what we call ‘spikes’ to overcome this,” said Eduardo Lanchares, full stack developer.
“A spike is a proof of concept of the feasibility of a feature. With that investigation we grab insights of the feature, so we can then spot possible limitations of problems. This information is then shared with product and design team, so they can think of an alternative solution to solve it or dedicate more time to finding a better technical solution. It’s a matter of teamwork: we all try to find the balance between what we want and what is possible.”
The takeaway: Before diving into a new idea, check it out and report back. If everyone involved can keep an open mind, serious issues can be identified early with a minimum of sunk cost. The process may even lead to creative solutions that work better than the original concept.
 Divide Up Work Strategically
Dividing up a large project into parts enabled the Gantt team members to get more done — but only because they were careful to do it in a self-directed way that also prevented potential conflicts down the road, “right-sizing” tasks to make sure the workload was manageable.
“Working in parallel is the key to developing things faster,” said Andrés. “The technology you use and how you structure your code matter. If your code is well organized and things can be split into independent components, you can start working on parts of the feature while your team members are working on other parts.”
Choosing technology that supports this approach makes it much easier to implement effectively.
“We’re using a framework called React.js, which embraces the idea of isolated components that you can compose together,” said Ilya. “Because of this, we’re not solving a maze — it’s more like working with a tree: everyone is touching different branches, but there’s one central trunk.”
The takeaway: Approach the division of work thoughtfully. Many teams divide up projects spontaneously in meetings — “Okay, you do this and I’ll do that.” Make time to ensure that the way work is being allocated makes sense and stays coordinated.
 Explain the “Why,” Not Just the “What”
The team made sure to keep a clear view of why they were building Gantt. They knew that purpose wasn’t trivial when it comes to keeping a development team engaged and moving forward. Understanding the impact of a project changes everything.
“It’s incredible what a big part motivation plays in the development — and success — of a new feature,” said Pau. “It makes it possible to overcome challenges like using totally new technology and building complex UX interactions, and still reach planning milestones on schedule.”
The takeaway: Especially if you have purpose-driven team members, present the “why” in a clear and compelling way. For some people, it helps to be able to personalize what you’re doing; for others, understanding the technical “why” is valuable. It can be tempting to skip this step and just jump in — but it’s an incredible opportunity to increase buy-in from the beginning.
So When Can You Try Gantt?
The behind-the-scenes functionality that makes the feature intuitive for users is surprisingly complex, and extends far beyond Gantt itself to the platform that powers all four of Redbooth’s main applications (browser, desktop, iOS, and Android). The Redbooth developers are hard at work, ensuring that that everything functions smoothly and intuitively.
Currently we’re planning a closed beta within the next few weeks to continue to test and gather feedback. When will Redbooth’s Gantt charts launch for all customers? We’re planning on a Spring release, with more specific timing details available as we get closer to the actual date. Stay tuned to the blog for future posts that keep you in the loop on Gantt’s progress!
Update: Instant Gantt charts have launched! Find out more »
Illustrations by Sarah Tanner