Scrum, a well-established framework in the world of IT, based on lean agile principles the goal is to help people, teams and organizations generate value for complex problems.
A classic scrum team consists of a small set of people with key roles dedicated to their specific area of expertise.
In short, the Scrum Master is accountable for the team’s effectiveness, the product owner is accountable for maximizing the value of the product the team is working on and the developers are accountable for creating the actual product.https://www.scrum.org/resources/what-scrum-module
In an ideal workplace, we have a team that work in sync with each other and the surrounding environment. However, the reality is not always like that ideal.
During my time as Scrum Master and developer at a large workplace with a complex environment, I've made some interesting observations.
With all these highly competent experts, we unknowingly create knowledge silos that creates a bottleneck effect in many of the projects. Even though the goal of Scrum is that developers, testers and requirements analysts work together with one project in an agile manner with short feedback loops, that is not always the case.
When there is a bunch of different projects that are squeezed in to a Program Increment and those projects is distributed among the developers within a team. After a few Program Increments it is only natural that for example developer X gets assigned project A since developer X have worked with similar projects or domains in the past. After a while, knowledge silos have formed within a team. This is not the goal in the lean agile scrum world, but it is quite common.
Let us look at a small example when this creates a problem:
This is not only bad planning; this is a common side effect of knowledge silos.
One solution to knowledge silos is T-shaped competence.
So what is characteristic of T-shaped competence?
It is a combination of depth and width; let's take a software developer as an example. The developers in a classic Scrum team have a clearly defined role, to develop the product. It is common that the requirements come from above or a specific requirements manager within the team. The developer interprets these requirements and the developing process takes place, during development there is need for testing so an additional tester steps in, tests the software against the requirements and gives feedback. This continues until the software meets all the requirements and the stakeholders are content with the result.
Each of the individuals in this project have a deep knowledge within their fields, they all work together in an agile manner but they do not share each other’s knowledge. This works out just fine until something interrupts the structure of the team.
If one instead takes a T-shaped approach to knowledge, the teams can become even more effective and agile. The depth in knowledge will not change for the different roles, but cross-discipline expertise applies to each role. The result of this kind of approach is the elimination of the knowledge silos within the team and reduces the risk of the bottleneck effect in the projects.
The step towards T-shaped individuals may be difficult and there is some resistance as we are creatures of habits, but the journey is well worth it in the end as the efficacy increases.
A workplace example
My team consisted of a Product Owner, a Scrum Master that also had the role of Tester, a Requirements Manager and four Developers with different levels of seniority. We had many of the problems mentioned above, with knowledge silos and the bottleneck effect when someone got sick or went on vacation but overall we managed. Until our Requirements Manager and our Tester/Scrum Master quit around the same time, and there were no plan to replace them.
After discussions about us merging with another team or borrowing competence from other teams when needed, we took things in our own hands. I was one of the developers and we decided that I would also take the role as Scrum Master, and the requirement- and test competence should spread among the developers.
One of the first tasks we set up for ourselves was a workshop lead by an independent facilitator to set the expectations of each classic Scrum role. First individually followed by a group discussion and a written summary in order to set the role descriptions. In order to identify knowledge gaps within our team we had another workshop with group discussions and set an action plan to go forward. The biggest gaps were in Test and Requirements Management as expected, but smaller gaps as the result of knowledge silos were also identified in the process. The actions we decided on were to seek up individuals within the organization that were willing to share their knowledge with us and set up both presentations and practical workshops.
With all these new tools and knowledge, we began to implement this in our daily tasks. As expected, there were a few bumps in the road and our approach was not always well received by others in the organization. As a new Scrum Master in our team, I had to sit down with several individuals to ensure them that this is not a threat to the traditional Scrum roles and we are not interested to eliminate the roles such as a designated Tester or Requirements Manager. We simply had to make adjustments in order to survive as a team and to continue our deliveries. I gave examples from previous workplaces where I had implemented this type of work mentality as a success, even though Scrum was not a factor in those cases. A year went by and our way of working with T-shaped knowledge was truly a success, our team continued to deliver value and often in a faster pace hence the bottleneck effect were almost none existing.
Now I have been helping other teams within the organization to see the benefits of T-shaped knowledge and to view it as a complement to traditional Scrum teams, not a threat to tradition. We will continue our knowledge journey and spread our success story wider in order to help struggling teams.
