In Studentpulse we really believe that customers have the biggest impact on developer success.
One of the values we really care about is that our developers feel that their work impacts customers.
We know how important it is to work closely with the customers, while also not becoming a feature factory. We believe that having customer feedback on the product motivates developers to proactively improve the product. We do that by allowing close collaboration between project manager and developers. Every week you will be a part of knowledge/feedback sharing session where PM will report you everything there is to know in relation to customers, be it feedback, appraisal, feature request.
However, we do not take every customer feature request and add that blindly to the product. We do not want to become Feature factory*.*** We experienced that this leads to accumulation of technical debt, developers not being able to polish current features and overall Code smells and biased product*.* To avoid that we have prioritisation sessions where team will rank features to work on current release.
Another thing we strongly believe in that developers should see the outcome of the work that they did.
To achieve that we reduced handoffs to minimum, shortened feedback loops and reduced the number of active projects that developer is working on.
Usually (98%) of the time you will be working closely with Project manager when defining a feature spec that you will have to work on. If the feature requires UI design, designer will come into play and present you a final **Figma** design file. This way you are working very closely with the team and all will be involved in thought process when designing a feature. In our experience this allows for better developer productivity because it reduces number of clarification meetings/Slack messages.
To shorten feedback loops we use the strategy of small releases and/or gradual release when possible. This means that we release weekly. This allows to get feedback from clients faster, have a smaller testing/developing scope and easier to digest Release notes.
To keep release velocity high we automate the annoying bits. We have automated release process with CI tools.
To increase focus time and reduce context switching we try to reduce the number of active projects number to minimum. In practice that means that you will be working on one project at a time. The only exception to this is the time when we are working on bugs & enhancements round. That usually consists of small tasks all over the product.