If you are non technical person and you are managing team of developers (or maybe you are Scrum Master) you probably sometimes ask developers about their feedback about project situation and processes (maybe during the Retrospective meeting)… or maybe not… in both cases this article will be beneficial for you ;)
Yes, the Slack, it can help you to make you developers efficient and give you (and your customers) more insight into the project.
When you are building small feature on which 3 developers will work it is extremely efficient to create for it channel/group chat.
Keeping all technical discussion in one place help them to remember what decisions were made (of course it is a good practice to later document somewhere those decisions in more structured way, or at least part of them), onboard new developer in the micro-project quicker and possibility for you to quickly clarify the questions.
You may also add to it some of the customers (depending on your relation with customers). Developers can announce there key milestones of the project, share test environments or inform about deployment of a new version of the feature.
Those channels are for your project customers and people from your team that needs to be informed about the release of i.e. your backend. You can announce there new features, alert about the planning release (which could i.e. be breaking current version of the frontend) or show some statistics related to releases processes and performance.
Scrum or not to scrum… it is always good idea to sync one time per day with all your developers and key team members. Let developer say about their problems, findings and/or just current work and cut the discussion when they want to talk about it for too long… they like to talk about it… if something needs longer discussion it should not be part of the daily meeting and only involve needed people. It is also good place to announce some major changes in the project (i.e. use of new language or library), introduction of best practises or that someone key for feature under active development is going for 3 weeks vacations ;)
Keep your project features description in one place/document. Have source of truth for your project specification and when you are attempting to create a new feature (or improve current one) firstly update this file and link the change for it in the ticket for the developer. If you have many features at some point you can forget about some small details… and you really do not want this to happen.
When you create ticket with the description for the developer try to use IF THEN descriptions, like:
IF user clicked red button THEN modal showed up.
IF user swiped left THEN he/she was forwarded to the previous screen.
It is easier for developer to translate such a specification into unit tests or QA engineer to e2e tests.
Yes, your project needs them. If you have small team and not that much time start from introducing snapshots tests for your feature components or screenshots tests, they require less time for maintenance after being setup.
If you developers have more time (and/or you have QA Engineer in the team) add e2e tests to your project to better simulate user interaction with your app.
Depending on your project scope and developers number/seniority you can add of course unit tests.. unit test are fast to execute, but it take time to create them and they are less customer focused comparing to e2e tests.
If you have good developers on your team they will try to introduce some new cool libraries to your project… obviously not everything should be introduced, but try not to kill their spirit of learning and trying new things.
Developers wants to stay in the teams with good tech stack and among other developers who try and easily pick up new tech. Maybe you should gave them some time to build custom project for the company, open source something or organise hackathon.
I hope this article will add some value to your project management best practices! Good luck!