The right time to introduce structure to a development process

Have you ever worked on a project where everything just flowed, work was getting done and your team was killing it? Have you worked on one where it was complete chaos, everyone was busy and nothing was getting done? How about one where you spent more time filling out forms and requests for change than doing actual coding?

We would all love to be part of those that feel just right, with meaningful work getting done at a sustainable pace.

One of the keys to achieving that is to have an appropriate project management structure to the stage the project is in.

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 the team size and complexity. We're no longer working on exciting new things only, we also have to deal with fixing bugs that we introduced before and customer requests and support.

As the project grows further, there are even more non-feature tasks coming in: infrastructure, scaling, compliance, requests from the sales team, etc.

First, you need to notice the problem

Those transitions don't happen overnight. It's a slow process. If you don't pay attention, you might not even notice that it happened. Here are a few questions that might help with that:

If those questions resonated 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 a golden solution that will solve 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.

The only reasonable solution is to take regular pauses and reflect on the development process in your projects. The rule we're using is: add more structure only if it hurts, and only enough so that it stops.

Strike the right balance

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

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

Try to tune smaller things first. Focus on describing the problem better in each ticket. Show why it’s important for the stakeholders. Improve your estimations - measure the time actually spent and regularly compare to what you expected. Set aside some time each week for the “unknown unknowns” - embrace 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