3 mistakes to avoid when you need to deliver a huge feature on time
Every big project requires challenging structural changes from time to time. Changing the design of a SaaS product is one of them, and the issues it brings have the potential to demotivate developers and lose the company money. What did we do wrong, and how can you avoid the same mistakes?
In this article, I’ll take you through the process of implementing one of the biggest tasks of Kontent development teams—the UI redesign. I’ll show you the pitfalls we failed to avoid and reveal what worked for us so you don’t have to learn the hard way.
Mistake #1: Too aggressive deadline
Our first mistake was that we underestimated the scope. The project, including the UI redesign, significant UX improvements, and major refactor of components’ code, was initially planned to take four months. Soon it became clear to everyone on the project that we’d never make it. Therefore we decided to cut corners and focus only on the UI redesign—and while that wasn’t unrealistic, it was still very ambitious. People were under pressure. They knew they couldn’t afford to make any mistakes.
As a result, developers avoided expensive changes and agreed only to small ones. UX designers were reluctant to make more significant cuts as they were worried doing so would result in a bad user experience.
The problem was that:
- The developers didn’t properly explain why they wanted to avoid certain changes
- UX designers had no idea how expensive specific changes were and whether there were cheaper alternatives
- The teams didn’t know each other long enough, which amplified the existing issues
There was no progress, everyone was unhappy, and it was clear that they needed a change. The teams introduced the following improvements:
- They merged the design and implementation phases into one. That allowed developers and UX designers to collaborate, ideate, generate alternatives and come up with solutions quickly, even during their implementation.
- As the team of developers needed to grow, they shifted smaller design decisions onto developers while keeping UX designers in charge of the reviews. That allowed them to increase productivity by limiting communication.
The teams got to know each other better and succeeded in setting up the baseline. However, we’ve had to fine-tune the approach regularly based on the specificity of the processed tasks and changing numbers of developers and designers on the project.
Mistake #2: Miscommunication between the team and stakeholders
The team and stakeholders used to meet once in two weeks. There was a pre-defined agenda for every meeting, and developers felt the need to stick to it. Plus, the meeting was one of many for the stakeholders. As a result, they failed to express their concerns thoroughly, and neither of the parties asked important questions. The stakeholders didn’t understand the actual issues blocking progress, and the whole situation frustrated both sides.
Two things helped improve that:
- Visual roadmap
Roadmap allowed developers to set up clear milestones and report progress in an easily understandable way. It also helped streamline discussions to focus on possible risks related to future milestones. They further prioritized those, so the most important topics were discussed at the beginning of each meeting and adequately summarised in the end with resulting action items.
- Project-wide retrospective
In the second half of the project, we held retrospective meetings with everybody working on the project. Everyone got the chance to share their views and feelings, which helped clear the air. After the retro, the communication between the team and stakeholders intensified, and developers started making sure that stakeholders understood everything.
We found out it’s essential to share information clearly, convey the mood, and be open to each other. The big retro was the turning point. We’d recommend having such an event rather sooner than later and keep having it regularly.
Mistake #3: Lack of developers’ motivation
The project was very demanding. Large amounts of repetitive work, deadlines shifting several times, changing scope, and so on. It was difficult for developers to see the light at the end of the tunnel.
We aimed to implement the new design and refactor the components along the way. It seemed like a bulk deal. However, it proved to be a frustrating experience. The refactoring took a lot of time, and the developers were constantly frustrated by failing UI tests.
One of the helpful early ideas was to split the refactoring from the new design implementation. We created two narrow-focused groups of developers who could see what they were building faster.
We also introduced timebox implementation. Instead of striving for a perfect result, developers learned to finish good-enough solutions and create tasks for the final polishing at the end of their backlog. That immediately increased progress, sped up the feedback loop, and allowed better prioritization and planning.
Redesigning a large app like Kontent needs a huge effort and is a great learning experience for everybody involved. There were many challenges along the way, and thankfully, many ideas to cope with them. Putting people first is probably the single most important thing on any project.
Here are some key takeaways:
- Look for compromises together.
- Adapt to change. Something that works at the beginning doesn’t have to work later.
- Over-communicate and make sure you understand each other.
- Share your mood/feelings with others.
- Visualize your progress.
- If time is of the essence, cut the scope.
- Don’t mind the details first. Focus on the big picture.