I feel like my team is stuck in a rut, but unable to come up with good ideas for improvement

There's a german word for the inability to see where your processes' problems are: "Betriebsblindheit" ("operational blindness").

It may help to first collect the issues that team members already know but think cannot be solved due to whatever restrictions (financial, regulatory, business decisions, etc.). If you can establish a connection between these issues and the perceived productivity reductions, you may have leverage to work on the restrictions or find workable alternatives.

If introspection does not give you new insights, then you should consider bringing in an outside expert who can look at your established procedures (and how you actually practice them) and may have experience that allows them to propose ways out of the situation.

Your ideas about re-building parts that you're unhappy with is a typical developer approach, and from what I've heard and experienced, it rarely works well (even though it's sometimes inevitable). You will feel productive for a while (implementing all the new design ideas, working on real bugs, etc.) but the net effect on product quality and maintainability may be low.

You're very abstract about what the root of the problem actually is in your view.

If a team of up to 10 people (which I'd say is larg-ish, not small-ish) have been beavering away for a few years on an application, you'd very well expect there to be a lot of rigidity accumulated.

After 20 or 30 man-years of design, there's also considerable scope for circumstances to change or for earlier solutions to reach breaking point, and things often have to be redone to a much higher level of complexity.

There also has to be some point at which an application - even a well-made and fit-for-purpose one - has grown to around the maximum level of complexity that a given team can handle, and further changes become increasingly slow and tiresome to integrate.

I'd think carefully about whether you are simply at the stage of dealing with a mature application.

When a problem seems so big/complex that no-one has ideas on how to solve it, you either need to break it down into smaller problems or start measuring/gathering data. As technical lead, I've found coming to the team with a dumb idea is a sure-fire way to knock loose some better ideas if they feel free to voice their opinions :) Propose a small incremental improvement or some way to try to measure which part of your process is slowing you down the most.

I find just taking any action, even something very small, with the understanding that it can be rolled back if it doesn't work will help the team engage with the problem. One thing we do at our retros is Loved, Loathed, Longed-for, Learned. The team spends some time writing sticky notes for each category and we put the up on the wall. Then we go over all the notes. It makes it easy to know which things about the process to keep, which things are missing and which annoyances to tackle first.

A system (software or not) can be deemed as good or bad by looking at different factors. The reaction time perceived by the final user, time between visible bugs, time to implement new features, time to fix bugs, and so on, and so forth. So, when you already made the system fast, it does not mean that is does not have visible bugs.

And here is the first conclusion: the quality measured by one factor, any factor, grows asymptotically. It means that, after some time, even a lot of effort will achieve very little benefit. Is it bad? Does it mean that the system needs to be dumped and re-created from scratch? I do not think so.

I remember a complaint on the internet several years ago, where some user was trying to find an e-mail client to replace Thunderbird. Why? Because he noticed that there were no modifications to Thunderbird for a very long time, and he considered the project dead. The fact, explained by someone, was that Thunderbird was (is) a very mature application, full of features, and its long life helped fix most bugs. So the project was not dead, it was just that there was realistically no more work to be done.

The second conclusion: A system can the "measured" by many factors, all of them important. So go ahead and brainstorm a good and relevant list of important factors for your system. Consider requirements and other documents (help files, user manuals...), implementation, testing, deployment, debugging, customer support, technical, financial, time related, marketing-related...

Then go ahead and prioritize those factors, and group them as you see fit. For each of them, define objective ways of measurement. Seconds, hours, lines of code, amount of money (globally, and per unit of time), number of bugs found internally vs bugs reported by the customers, lawsuits against your company due to faulty products etc.

Define in a S.M.A.R.T. way what you want to achieve. Make a roadmap and agree on it. Then make a detailed plan for implementing the roadmap, and start implementing the plan.

Keep in mind that while you improve matters regarding one factor, you can easily damage other factors. You might increase the speed of development at the cost of more bugs reported by the customers.

Additionally (which can actually be done in parallel with the previous ideas), hire external specialists to have your system assessed, by all the factors. They might help you find factors that you might have missed.

Rinse... Repeat...

Once you find out that there is nothing left to be improved anymore (ha ha!), just sit down and relax. Or sit down and start creating another system.

1. Have a break from navel-gazing. The end user doesn't care in the slightest what patterns or frameworks you use. It makes no difference to them. What they care about is:-

• Does the product do what they need?


• Is the product acceptably fast?


• Is the product bug-free?

2. Is the real problem that the product is complete, and anything more is just creeping featurism? If you want something useful to do, find out if there is anything that the users actually need. And I guarantee it won't be a new pattern or framework.

It is the technical team leader's responsibility to look over the software development procedure you are using. And the only way to improve it successfully is to have some consensus within the team, in terms of tools, languages, coding standards, testing and so on. Ideally, ideas and improvement suggestions can come from everyone in the team.

If there is no leader pushing for improvement, or if the leader is not responsive towards suggested improvements, or in case they are unenthusiastic in general, then stagnation will happen. The general mindset will become "if the boss doesn't care, then why should I care" and then everyone will just do the bare minimum of what's expected of them. This is probably a very common situation.

Bad leaders will think the solution lies in using some particular project management model or in doing various team building activities, but such things have very peripheral impact. What matters is how fun the actual daily work is - if there's an atmosphere where everyone thinks their effort an opinion matters. Creating such an atmosphere is hard and there's no easy fix. And perhaps especially in tech where people tend to get promoted to managers because of their technical skills rather than their people skills. If you are stuck with a passive, unenthusiastic manager then there isn't much you can do.

If you are the manager and uncertain how to pick up the pace once more, one thing that could work is to bring in some new blood: hire a few enthusiastic junior programmers, who are eager to learn and eager to work. Their attitude might rub off on the rest of the team. They will want to know why you do things in a certain way, so while teaching them you also get a fresh outsider's look on things, to easier see where there is room for improvement.

Sounds like you need a fresh look on your processes

I would suggest hiring a consultant, familiar with your environment elements