I think that organizing any process is quite challenging. And even with well-designed processes it sometimes happens that everyone’s busy and nothing is getting done. Our CTO wrote a piece about introducing structure to a development process to deal with such problems. I thought that it may come in handy for someone and wanted to share it with you. Hope you’re gonna like it 🙂

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:

• Have you ever added a ticket/story for something that needed to be done, decided to plan it for later, only to come back to it a few months later and had no idea what the ticket is actually about and whether it’s still relevant?
• Has your team spent an entire week working on “important” things that “just came up” during that week, and completed nothing you actually planned to do? Was it hard to even tell what you worked on during the next meeting?
• Have you ever forgotten about issues reported by users or the internal team, only to have them reported again a few weeks later with even more frustration?
• Have you ever wondered about the ratio of features, bugs and “other stuff” the team is working on, and had no way of checking that?
• Do you feel that more new bugs are reported than fixed?
• Do you feel that the project is becoming too complex and keeping track of everything is more challenging?

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~tags~(~’retrospective))~searchTerm~’~sort~false~sortDirection~’asc~page~1)), 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.

Originally posted on our blog