Knowledge Flow in Scaled Agile Delivery Model

We know much about how to scale Scrum to the level of a program in terms of teams configuration, flow of requirements and basic practices necessary to keep agile enterprise afloat. In the meantime there is one important dimension that overlaps with almost every concern of agile delivery – group knowledge management. Without accumulating relevant experience and turning it into knowledge shared by program we are talking about a bunch of people that try to work iteratively and incrementally at best, but aren’t really agile. Without proper knowledge management there is no learning organization.

We will think of agile program as a set of Scrum teams that are aligned around same objectives and keep synchronized having same cadence and frequently integrating their software with each other. Good way to think about such a program is as of Agile Release Train (concept introduced by Dean Leffingwell; see Agile Software Requirements book, Ch. 15, 16); also see posts about Agile Release Train and Scaled Agile Delivery Model on Dean’s blog. On the other hand, we will talk about knowledge creation and transformation based on the SECI model introduced by Ikujiro Nonaka and Noboru Konno in their article "The Concept of ‘Ba’: Building a Foundation for Knowledge Creation" published in California Management Review, vol. 40, #3, 1998“.

Nonaka and Konno distinguish two different kinds of knowledge: tacit and explicit. Basically their so called SECI model (Socialization, Externalization, Combination and Internalization) is one loop of a spiral process of knowledge creation that transforms it from tacit to explicit and back undergoing integration process to combine experience and ideas relevant to the organization.

First stage, Socialization is the stage where tacit knowledge is being shared between individuals. The way it happens is natural and very efficient, not expressed with words or documented diagrams and formulas but transmits valuable information as a result of being together, observing each others actions, collaborating, interacting at emotional level.


Figure 1. Tacit knowledge transmits between individuals as part of cultural scenario ("Skoop Team" back in 2007).

This tacit knowledge can only be shared by individuals if they are open enough to make other people’s behaviors, actions, and values part of their own. Let me give an example in software development: two team mates, David and Sergey, create a new screen within a huge portal for which their larger group developed their own metadata-based framework 2 years back “to be able to define a new screen in only few lines of XML code”. Sergey noticed many times, when discussing new user stories with David or just working in pairs that David does a couple of nice hacks when he needs to introduce complex filtering for tables and that he hardcodes a screen every time (working it around the XML engine) when more than two controls on the page interact with each other in a complex scenario. He learned how to do that himself. As well as David subliminally learned simple rule from Sergey: once you designed a new screen in XML, test it against more than one data sets, otherwise it almost surely crashes on some combination of data. This is tacit knowledge, circulating between two individuals as a result of their interactions and openness to observe and accept other approaches and work scenarios.


Figure 2. SECI stages from article by Nonaka and Konno.

Second stage – Externalization, when tacit knowledge is being translated into precise form understood by others. This means expressing it with words, diagrams, models etc. As Nonaka and Konno pointed out, “This may require deductive/inductive reasoning or creative inference…”. In our case the good example could be a conversation during agile retrospection (or its “meet-after”) where Sergey would tell the entire team that “there’s a difficulty each time we want to add a new screen with many dependencies between page controls, so estimate them as just creating a custom java class, not a simple XML metadata file”.

Third phase, Combination, assumes capturing knowledge created by teams, integrating it and making decisions based on this integrated knowledge. In figure 2 we assume that in our case “g” (or group) is individual Scrum team and “o” (organization) is program. In our example we have Scrum of Scrums meeting where Jon, Scrum Master of Red team to which David and Sergey belong, escalates this issue of “hacking” the portal engine in about ¼ number of cases. Supported by Green Team’s SM, this problem gets escalated to the level of Product Manager to approve for architecture epic to enhance the engine in this and next releases.

Internalization, the last step in the process, is backwards translation of integrated explicit knowledge into tacit knowledge that anybody can use if they find it applicable. ...For the time being all teams should use “hacks” and David will have a brief “how-to” presentation to key developers and all interested people throughout the program on how to do it most efficiently as well as how to properly estimate new stories, that involve such screens. Eventually in the next PSI this story will have its natural continuation when someone from the architecture community of practice or some lead developer will present the next step in portal engine enhancement, so they could start using it to designing new complex screens.

A couple of aspects of SECI in context of agile program…

Documented or not. If we carefully look thru our examples, there is no single word about documenting the newly created knowledge. It is big mistake to confuse explicit knowledge with documented knowledge. Obviously, program should approach documenting (or not documenting) it from Lean perspective, trying to optimize the information flow and neither lose information en route when overly relying on face-to-face communication, nor create piles of useless docs that nobody ever reads and thus it never internalizes. But one thing is obvious for sure, that documented knowledge can only be part of explicit knowledge, created by program as part of this natural knowledge lifecycle.

Communities of Practice. CoPs are actually those circuits that efficiently conduct and transform knowledge thru the SECI stages. Moreover, it provides that second dimension that in conjunction with SoS allows to triangulate the relevant knowledge and rapidly disseminate it across the program. In our example “System Architecture and Design CoP” would help to spot the problem maybe earlier than the SoS and, most importantly, approach SoS and then eventually Product Manager already having the idea of how that architecture epic would look like and how big it is, and so on. Usually we can talk about strong correlation between big and relevant areas of knowledge on one hand and CoPs on the other. If automated acceptance tests are never ready by the end of release, half of the program still don’t really understand how to effectively write and run them, POs do not care about acceptance criteria, regression defects re-occur endlessly, and nobody has straight idea of what should be happening to avoid unpredictable output of sprinting, then quite possibly it is time to establish an “Automated Testing CoP”.

Rituals vs. Random Episodes. Knowledge is being created continuously, that’s the fact. Although there is natural tendency for tacit knowledge to be created and shared between individuals constantly within regular episodes of coding or testing or discussing a story with Product Owner, while Externalization and Combination often happen during meetings and pre-planned discussions. We mentioned two examples already: retrospection meeting can be effectively used for Externalization, SoS and regular CoP meetings are good for Combination stages. Another set of examples could be specification-, design-, configuration- and other types of workshops.

Enterprise Practices. Let’s go thru immediate examples. “Intentional Architecture” was just illustrated above, when “Enhancing Portal Engine to Support Complex Screens” epic made its way from bottom to top and then top-to-bottom. “Managing Distributed Development” is extremely important to ensure effective SECI stages. For example, having individual agile team distributed across the ocean horrifically slows down creation and sharing of tacit knowledge. On the higher level, distributed program that doesn’t manage to establish effective SoS, fails at Combination stage. The foundation for “Organizational Change” will remain flawed unless the knowledge that drives the change is being created organically from tacit knowledge up to the level of abstraction where the decisions will be made based on explicit knowledge and then again used by individuals in the form of tacit knowledge to actually convey any changes.

Rhythm
. If we consider agile team practices that scale to the program level, most of them basically build their own “platform” for rapid feedback as a result of a short cycle which is key Lean theme for knowledge management. For instance, “Continuous integration” implies that short cycles of relevant tacit knowledge will be frequently shared between Scrum team members and across teams. “Mastering Agile Iteration” provides a way to do frequent Externalization. “Short Release Cycle” supports Combination and Internalization of knowledge. Finally, the “Define-Build-Test” paradigm makes feedback possible at all as there is a way to Externalize tacit knowledge that corresponds to tangible user value – the end goal of development process.

As a graphical summary let’s outline the model of knowledge flow in the program:


Figure 3. Knowledge creation and distribution stages in agile program.

14 comments:

  1. What do you think about Knowledge flow based on the principles of logistics.

    i.e. the provision of knowledge and skill at a time and place it is most required and most profitable.

    ReplyDelete
  2. Well, good perspective too. It doesn't make it obvious to me though "how" this model is going to work. So if you have a strong idea about the mechanism itself - me and my readers would appreciate if you share.

    Now if we think about it for a second, SECI model is an "instance" of JIT approach in knowledge management: tacit-to-explicit transformation of knowledge (as well as the reverse cycle) only happen if individuals and teams decide so and because of fairly frequent nature of these transformations, knowledge is being created/transformed "if and when" needed.

    ReplyDelete
  3. We are offering web design services & web service in affordable price.....

    ReplyDelete
  4. Really cool post, highly informative and professionally written and I am glad to be a visitor of this perfect blog, thank you for this rare info! , Regards, servicenow training in hyderabad

    ReplyDelete
  5. Great! Thanks for sharing the information. That is very helpful for increasing my knowledge in this fiel
    Red Ball | | duck life | Slitherio
    Red Ball 2 | Red Ball 3 | Red Ball 4

    ReplyDelete
  6. Great article. Very interesting to read. Thanks for sharing.

    web design training in chennai

    ReplyDelete
  7. I have read your blog its very attractive and impressive. I like it your blog.


    JavaEE Training in Chennai JavaEE Training in Chennai

    Java Training in Chennai Core Java Training in Chennai Core Java Training in Chennai

    Java Online Training Java Online Training Core Java 8 Training in Chennai Java 8 Training in Chennai

    ReplyDelete
  8. I have been reading out a lot of your articles and that i ought to say pretty nice stuff.
    I will certainly bookmark your Blog.neha
    Hybris Training

    ReplyDelete
  9. Informative post! I really like and appreciate your work, thank you for sharing such a useful information about knowledge management system strategies, keep updating the information, hear i prefer some more information about jobs for your career hr jobs in hyderabad .

    ReplyDelete