Having an efficient way to work together in teams is crucial to the team’s productivity and growth. Many teams are struggling to find the right balance between having no knowledge sharing and meetings/events to having too much, causing the team to be tired of it and eventually will stop doing knowledge sharing activities altogether.
This post is about how software teams can effectively work together, make decisions and share knowledge without it is being too tiring for the team.
Let me first start with a principle that applies to anything in life
Start small and then scale up as you get positive feedback from what you are doing.Christian Lüdemann
So that means -that the following activities I am going to explain should be introduced on small scale at first and then the frequency should be increased as it proves its worth. If you can promise me to do that, we are ready to dive right in, shall we?
Effective decision making
Ah, people agreeing on stuff, how hard can it be. Well it becomes harder as the amount of people affected and implications of the decisions are growing. Then you can’t just have a quick chat at your desk. Also, you want the decision outcome and reason to be documented, so future developers joining the team will understand why the decision is made.
How is this done?
What I would recommend is to do chapter meetings where these decisions are discussed and made. For a front end developer, this will be the web chapter including all of the other front end developers in your team/department. Whenever a developer wants to propose a new decision he can add it to a decision log and put it on the agenda for the next web chapter meeting.
As said before, start small and then scale up. A good place to start could be a one-hour meeting 2 times a month and if you feel that is not enough you can start doing this every week.
The team should have a place that describes the front end architectures at the higher levels, making it easy for new people to get an overview. This includes documentation of the delivery pipeline, communication with other units and overview of apps. You should not need to document the very code specifically, but if there are some key parts of the apps that you should be aware of without looking at the code you can add it to the documentation site on a higher level. High level is the key for documentation because low-level documentation will not be maintained manually and should not. The code should explain “the how” and comments are used to explain “the why”. You can use tools like Compodoc to generate a static page for documenting an Angular app.
The team should have activities that promote knowledge sharing. The tempting thing I have often seen is to just call people into a meeting with no agenda called “knowledge sharing” or we are “going to find something to talk about” and then knowledge sharing magically happens. A meeting should always have a clear agenda or it will most likely be a waste of time. When people go to the “knowledge sharing” meeting without a clear agenda and get nothing out of it they stop coming and knowledge sharing is dead.
What I propose instead is to start with a knowledge sharing session once a month and for each meeting have someone do a 30 minutes in-depth presentation of a relevant topic and then have 30 minutes for open discussion. This works because the in-depth presentation will bring enough value for people to come to the meeting and the presentation will set a theme for the remaining 30 minutes of the meeting.
This post touched upon three things you can do today to make you dev team more effective and better: effective knowledge sharing, documentation, and knowledge.
Effective decisionmaking by having chapter meetings discussing decision log items set up prior to the meeting and also serves to document why the decision is made. The team should document the architecture on a higher level to provide an overview. This includes diagrams of apps, architecture, list of app URLs and the development process. Lastly, knowledge sharing activities should ensure that the team gets better by having a meeting with a team member doing an in-depth presentation on a topic followed by a discussed around that topic.
Remember to start out small with these activities and do the necessary adjustments for you organization and this should give you a better workplace as well as better team members.
Do you need help with this stuff? Check out my FREE case study.
Did you like this post? New posts every week. Subscribe so you don’t miss any.