Ebdeb6de770c069ff6f2b37780d2a340

The right time to introduce structure to a development process

Have you ever worked on a project where everything just flowed smoothly, work was getting done fast, and your team was killing it? And have you ever worked on one that was complete chaos, where everyone was busy and nothing seemed to be getting done?

We would all love to be part of projects that feel just right, where meaningful work gets done at a sustainable pace. One of the keys to achieving that is having an appropriate project management structure that matches the stage of the project.

When we start a new project, the possibilities are endless, but we narrow the scope down to just a few achievable areas. At this point, there's hardly any complexity and the team is small. Everyone can keep track of everything that's going on easily. It all "fits in your mind".

Then, as the project grows, so does its complexity and the team size. We're no longer working on exciting new things, we also have to deal with fixing bugs introduced before, and customer requests and support. As the project grows further, even more non-feature tasks come in: infrastructure, scaling, compliance, requests from the sales team, etc.

First, you need to notice the problem

Those transitions don't happen overnight. They are slow processes. If you don't pay attention, you might not even notice them happening. Here are a few questions that might help with that:

If those questions resonate with you, it might be the right time to update your project workflow.

Reflect on your process

At this point, you’re probably hoping that I’ll give you a golden solution that solves all those problems.

I wish there was an easy answer like "when you have more than five developers" or "when the backlog is this long", then you should move from tool Y to tool X, and have exactly three meetings per week.

Instead, the best thing I can offer is to plan for regular pauses where you get the team together, look back at the past few weeks, and discuss the process. In the Scrum world, this is called a Retrospective, but you don't need to stick to any specific process. The main goal is to figure out what went well, what could be improved, and find some ideas for how to do it. Then try them during the next iteration.

Strike the right balance

People have a tendency to overreact. The questions above might prompt you to attempt resolving the problem "once and for all". After all, we don't want to spend more time than necessary on administrative issues.

It's easy to add way too much structure than necessary in reaction to a frustrating lack of structure. You don't want the paperwork to drag your team down. When you notice the first symptoms, don’t move straight to a full Scrum process with daily standups and a dedicated Scrum Master.

The rule we're using is: add more structure only if it hurts, and only enough so that it stops.

Try to fine-tune smaller things first. Focus on describing the problem better in each ticket. Show to stakeholders why doing that is important. Improve your estimations - measure the time actually spent and compare it to what you expected on a regular basis. Set aside some time each week for the “unknown unknowns” - embrace the thought that something will always come up, and don’t let it break your schedule.

At Ragnarson we help companies deliver great products. We take care of development and deployment so that they can focus on growing the product and working with customers.

Work with us