To be agile and keep being agile there is one important aspect you should be conscious about: sharing knowledge.
One thing is that your team should be cross-functional. This of course does not mean every individual on the team should be able to perform each other’s tasks. Cross-functional teams are composed such that they have all competencies needed to accomplish the work without depending on anyone not part of the team.
However, it does not mean that none of the team members have overlapping skills either. In fact, we often refer to the T-shaped person as the ideal team member–having both a broad and in-depth skillset.
In addition, things other than just technical or tool specific skills are involved. Domain knowledge, knowledge about the architecture, coding standards, testing conventions and anything that touches how the team works every day come into play.
To be as effective as possible, I believe it is important that every team member have a base level of understanding of all these things. With a common architecture and domain understanding, every discussion about how to implement new features or how to makes changes to existing parts of the system will be a lot more effective and the outcome will be of higher quality.
Below I have listed some of my favorite practices, feel free to share yours, too!Pair Programming
The ultimate way of sharing understanding and knowledge about the thing your team is working on is getting people together to work on it. Pair team members, let them sit together and struggle with the problems together by looking at the same code at the same time. Have your team rotate pairs every so often to widen the impact. You are not only getting instant feedback, but also cooperating on sharing knowledge about the code and the domain and architecture of the code. Pair programming is a great way to share knowledge and get a new team member up to speed as well.
The last few years, mob programming has come up as a popular alternative to pair programming. This involves getting the entire team together looking at the same code and solving the same problem at the same time. Looking at the effectiveness/efficiency diagram from “Agile Software Development” by Alistair Cockburn, the more closely people work the more effective the communication.
With respect to this, mob programming ideally should work even better than pair programming. How pair programming and mob programming match up regarding cost-effectiveness is, however, uncertain. Nevertheless, working closely enhances knowledge sharing. You should at least be doing pair programming, but make it possible to experiment with something like mob programming as well.Code Reviews
Another great way to share understanding about what is being implemented is getting changesets reviewed by your peers. Discussing changesets through pull requests is a great opportunity to see which new features are being added to the system. It’s also perfect for looking at coding standards or whether or not the changes adhere to your architecture principles.
If you do pair programming you should let another pair review your changes so that you get a fresh pair of eyes on the code. Doing both pair and mob programming one could argue that code reviews are done continuously, but having a separate discussion when merging changes fosters a slightly different focus. Code reviews could of course be done on other blocks of code or parts of the system, but I find it easier to utilize something like pull requests to trigger code reviews on a continual basis.
Again, this follows the diagram given by Cockburn above. The closer you work, the richer and more effective the communication will get.Lunch and Learns
As part of your normal pulse you should have regular demos and reviews of the things your team is implementing. While these demos and reviews are a great arena for sharing knowledge they should be part of your normal practice already. Lunch and learns, however, are a great arena for informal knowledge sharing. They are perfect for your team members to share new ideas, something specific about a recent implementation or going through concerns team members have about some areas of the system your team is implementing.How Are You Sharing Knowledge On Your Team?
The practices mentioned above are far from an exhaustive list of things you can do to enable knowledge sharing on your team. They are, however, my favorite ones–and practices that I have seen work first-hand. By spreading knowledge in your teams, you will enable a base level of understanding of the code, domain, architecture, etc. Without this common understanding, it will be a lot more difficult to get the team to move in the same direction once the direction needs to be changed.
Do you have other good ways of sharing knowledge? Please let us know by using the comments below.