Medium size in-house desktop application, not a commercial product.
Has about 100 internal users.
Dev team is 8 people, only 4 full time, and 2 QA engineers who are also part time, since they also test other applications. In addition there's a large support/integration team of around 30 people who occasionally contribute new code and bug fixes.
The essential roles are team lead, technical lead, and a slightly less essential PM.
I'm the technical lead, which is a sort of role that was tailored for me. I don't make roadmap decisions, but I'm usually consulted before each decision is made.
I also help everyone on the team with tough debugging problem, and I also design each new big feature, or at least influence its design, and I also participate in all code reviews. I'm also an IC (individual contributor) myself, implementing new features and fixing bugs, and sending weekly status reports.
Everyone on the team does support. Sometimes we just assist the bigger support/integration team, sometimes we work directly with the users. There's a rotating roster of support in the core team, which officially doesn't include me, but I'm always on hand to help with any tricky issues. Roughly 50%-70% of my time I either support my team or the users.
The team lead is similar but less technical (although she's very good). She decides who does what, fills up Gantt charts for upper management, manages our tasks, and does one on ones with the team and deals with crises and complaining customers. She is also an IC, and working on her own allotted features, albeit slowly.
Both me and the team lead are former users / support/integration engineers of this product who transitioned into the team. The team has changed twice around us since we came on board. This helps a lot since we know what our users are going through and we speak their language.
I can't stress that enough – it helps that both me and the team lead were essentially former support staff / users of this product, and we have stayed with the organization and with this product even though we have many bad things to say about both of them.
We also spent many years in the company but had slightly different roles. Between us we know many people who started with us, many of whom are now in upper management. We both command some internal respect (sometimes it doesn't help though).
Our PM … doesn't do what usually is done in other companies. He does his job once in a week (he also has many other hats, in one of his other hats he's also our direct manager), mostly protects us well from upper management shenanigans, and when necessary acts as a judge when we can't reach a decision on our own.
The development team is split to small groups, we work on different features / bugs, in teams of one or two at most. Each of us has ownership of a specific part of the application, me and the team lead together are familiar with all the parts.
A release takes about a year, although we aspire to bring it down to 6 months (so far unsuccessfully) and typically includes 2 big features and 2 small ones. We release alpha and beta versions to users. Our PM goes through a process of finding internal users who are early adopters and are willing to put up with a (mohre than usual) buggy software. It takes so long since like I said we aren't dedicated to greenfield development, we also do a lot of support, bug fixes, documentation and presentations. We do the greenfield development in tandem with this.
Working on a new feature involves me and/or the team lead sitting with the users and talking with them, then I go over the existing code, and flesh out a design, do a quick prototype, show it to the team. After an internal discussion we also show it to potential users, and for some visual changes we request feedback through an internal website. Then we open a new item in our work-tracking system with the details, name of the users who requested it, and for a big feature also document it in a document.
Backwards compatibility is huge for me personally, we try to never ever break anything, and deprecate things very slowly, if at all. Some of our users are non-technical and require hand-holding, and yell at us if we move things around without a good reason.
Regressions are a big problem, since historically the team was even smaller, and the team lead didn't believe in QA at the time (unfortunately) so when I came aboard there were hardly any tests for the application. Over the last 8 years we've added many unit tests, integration tests, and our QA team has added a lot of automated GUI tests, but they are not enough since there are many small features and they often interact with each other.
Most serious bugs appear while interacting with the GUI and several things start running in the background, and these are very hard to isolate and test.
Testing: Our QA team has a very detailed manual testing document for the application's GUI which they run through before each major release. This catches some regressions each time. Some parts of it are automated, but by no means all. Currently the automated part is slowly being migrated to Ranorex.
I personally dogfood a lot when developing the application, while developing I pay attention to each small deviation from what I know, stop what I'm doing, document it, and either fix it or open a bug that will be triaged later. I'm a former QA myself so I find that natural, but other people in the team find it difficult.
A combination of these things (unit test, manual testing, dogfooding) prevent many regressions, but definitely not all.
Knowledge sharing – we share through code reviews, and informal chats. Usually when someone calls on me to help them with some tricky bug or design problem I also take the opportunity to teach them a bit more about that area of the code. So does the team lead.
We don't use any special tools to design. Most design happens in Word documents.