In agile organizations, team members work together closely, and team members are highly specialized. But there is hardly any overlap of knowledge and skills between team members; it is basically a team of specialists… sound familiar?
In most teams, it is not possible to move work around. Only one or maximum two team members are able to implement the work planned. This often leads to stress in the team and results in not-done work items at the end of the Sprint.
Team members might be interested in learning and expanding their skillsets beyond their areas of specialization; but usually there is no time available.
T-shaped to the rescue
Line management is often interested in increasing the skillsets of their employees. The so-called T-shaped person refers to employees who not only increase their specialization, but also broaden their knowledge and skillsets to become generalizing specialists. There are two benefits to this approach: line management can apply employees’ knowledge and skills in a broader context and dependency on «Single Point of Failures» decreases. For employees, a wider knowledge base and skillset means increased market value and therefore a better market position.
Trying to broaden knowledge and skillsets with trainings can be a good starting point. Thereafter, it is critical that employees have a chance to gain practical experience to put the newly acquired skills to use. At this point, both line management and agile teams struggle to find sufficient time.
Knowledge Transfer is Work
As an Agile Coach, I ran into this problem about a year ago. After discussions with all parties involved, I came to the conclusion that knowledge transfer means «work». In an Agile Team, work is described as Backlog Items and can be planned in e.g., Sprints. So, why not create Backlog Items for knowledge transfer?
In Agile Requirements Engineering, we often make use of so-called «User Stories». A User Story describes a functionality or customer wish in general from the perspective of the user. It describes the goal and the value of a particular requirement and includes Acceptance Criteria. These Acceptance Criteria facilitate the acceptance by e.g., a Product Owner (PO) once the User Story is done.
A Knowledge Transfer User Story
A User Story is the ideal medium to describe exactly what needs to be done in the case of knowledge transfer. A User Story for knowledge transfer has a clear description about the goal and the value of the Item. It also comes with Acceptance Criteria, which makes it easy to check whether the knowledge transfer has been accomplished.
Once planned into a Sprint, the Knowledge Transfer User Story is divided into Tasks, where Tasks are shorter than one working day. In this way, the knowledge transfer can be planned in very small, controllable steps. Two people work on these Tasks: an experienced team member and a «trainee» or newer team member.
As a team member I want to be able to configure file A,so that I can release the module myself without any support from B.Acceptance Criteria– Configuration of file A without support– Releasing the adapted configuration file with the adapted settings
How did this work in reality?
Was it worth it?
- Full transparency about knowledge transfer (internal/external), no hidden work in the team
- Full transparency for line management about who is broadening knowledge and skills
- The goal and value of knowledge transfer are clear
- Acceptance Criteria ensure that knowledge transfer User Stories have a defined scope and completion can be verified
- Knowledge transfer User Stories have an initial estimation and priority
- The importance of knowledge transfer can be compared to the other work items in the Backlog
- The concrete amount and rate of knowledge transfer are now measurable