Already several times, communicating with colleagues at conferences and lectures, I got this question:
It seems it's time to fix somewhere the answer to it and refer on occasion :)
So, do you need knowledge management at Agile, where information is transferred from person to person? In fact, this is the case when the answer is contained in the question itself. Information is transmitted from person to person, that is, there is an exchange of knowledge . The oral tradition is one of the tools of knowledge management. Very unreliable, but certainly the most popular. The task of the person in charge of knowledge management is to create an environment that is convenient for sharing knowledge. Of course, in agile teams, the environment will be different from classic organizational structures. But basically the answer, of course, is “yes, it is necessary.” Let's understand in more detail.
Let's start with the Agile manifest itself. Its authors directly say that
“That is, without denying the importance of what's on the right, we still value more on what's on the left”The Agile Manifesto doesn’t tell us to “document nothing”! He says that the customer pays money for a working product. If he received it, then in the absence of beautiful documentation he can close his eyes, but not vice versa. The manifest helps to prioritize, but does not put bans. And even if you don’t have time for big docks, in the process of work a huge number of knowledge management artifacts are created, which you can then operate on when making new decisions: tickets, changelogs, etc.
“People and interaction are more important than processes and tools.”In one study conducted among IT workers, it is clear that people in the IT industry put knowledge sharing (i.e. interaction ) in second place among existing challenges in software development.
By and large, the results of this study confirm the first thesis of the manifesto. It seems to me that the legs of the question are growing from the fact that the management of knowledge by many in development is understood as documentation, and not the interaction between people in the transfer of experience.
Yes, by the way, in one of the previous posts I already said that knowledge is not documentation, but the experience gained in the implementation of a specific project by a specific employee . Even if you have not created product documentation, you definitely gained some experience during the project. Moreover, Agile tools indirectly contribute to the fact that this experience is constantly rummaged.
For example, retrospectives . What is this if not a knowledge-sharing process? The team gathers, shares the existing problems (in the field of KM this is called “lessons learned” ) and develops a change plan in order to solve these problems. That is, people rummaged through their experience with each other, discussed it, developed a strategy to overcome inconveniences for the near future, and recorded somewhere this same plan of changes (knowledge management artifact). Usually the results of such meetings are stored somewhere. I’m not sure that there are effective commands that, after completing the iteration, delete data about all past retro.
Or pair programming . Even Wikipedia tells us the following about this tool:
Benefits:
***
Mentoring
Everyone, even a novice programmer, knows something that others do not know. Pair programming is a painless way to spread this knowledge.
***
Training
Programmers constantly exchange knowledge.
Two experienced programmers pump each other, using their own experience. The lord pumps the juna, acting as a mentor. Team mentoring is generally one of the most popular incarnations of knowledge management in software development. The same Yandex even began to teach this art outwardly.
Or take the situation when using kanban. Suppose testers test 10 functions per month, and developers manage to implement 20. This leads to the accumulation of work at QA, and therefore, risks to the quality of their work. In this case, you can, for example, redistribute resources and connect developers to the creation of autotests. Based on the results of the iteration, the team gained negative planning experience and, based on it, can draw up a new plan in such a way as to ensure maximum throughput of the pipeline with the same resources. That is, in the development process, knowledge was gained (= experience), after analyzing which, the team came to the optimization of the process.
Well, there’s a very surface question: will the team not use the experience gained while working on the project when working on other projects? That is, experimentally for the current project, they found out that they can implement with tests an average of 15 functions per month. Won't they again be initially laid at 20 in the new project?
Knowledge is all that happened around the project. The development process does not take place in a vacuum. Coordination, useful links, interaction with other teams, onboarding of beginners, etc. Any team goes through this. With a set of experience, various artifacts appear, such as adaptation checklists for beginners or a database of useful links. This is fixed knowledge or the result of comprehension of the gained experience.
We all participate in knowledge-sharing processes every day (well, really, we constantly communicate with each other!), And work on the Agile methodology does not exclude us from this process. Moreover, it already includes very effective knowledge management tools. It remains only to organize the work of the team so that these tools give maximum exhaust.
In a post I gave just a few examples. Let's discuss in the comments what other Agile tools are at the same time knowledge management tools. Well, or discuss why I'm wrong :)