Engineering the Knowledge

The Constructive Agility Behavioral Model identifies knowledge as a critical component for agility and effectiveness. Agile transformation is mostly a learning journey. We therefore need to be intentional about what knowledge is needed, how people will learn it, and what support systems they need to maintain it and to continue to learn and progress.

The Knowledge Pyramid

Product development is not like riding a bike. To learn to ride a bike, you don’t have to understand how the bike works. You get on the bike and try it, and fall, and next time adjust a little, and eventually the reinforcement learning network in your brain is able to train itself entirely through trial an error. The knowledge is entirely tacit: you don’t really understand what you are doing: you just do it.

Product development involves a great deal of tacit knowledge, but it also requires a lot of explicit knowledge as well that you learned through instruction or reflection. That is knowledge that you apply cognitively, using your frontal lobes.

Cognitive knowledge begins as data which you receive. Memorization enables you to retain information, but not necessarily with understanding. To understand something that has been received, you have to build a semantic model in your mind, consisting of links from the information to concepts, possibly resulting in new concepts being defined within your mind. Once you have a mental model, you can apply it to predict things. For example, your mental model of a bicycle enables you to predict that if someone does not peddle, then they will note start moving.

Over time, through use of your mental models, you observe more obscure connections. Your model becomes more nuanced. It is like a holiday tree with ornaments being added on over time. The model becomes sharper and more accurate in its predictions. That refined model is wisdom.

Organizations obtain people with expertise through three pathways: retention, training, and recruiting. By “training” we are including any form of internal learning program, including coaching, mentorship, classroom training, dojos, and job rotation.

Organizations used to invest a great deal in training people. Then during the 1990s and 2000s they greatly reduced internal training. This was because job turnover had increased, and it was felt that investing in people was not cost-effective: it was easier to just hire people as needed.

Today market share often matters more than profit, and so having the skills to get features out quickly is essential.

Things have changed. Today companies tend to be concerned more with market share than cost: if you lose market share, being efficient no longer matters. And market share growth is very dependent on being able to rapidly introduce product features. But if you do not have the skills you need, then it will take you longer to introduce features. On top of that, today it is getting harder and harder to find the skills that are needed: waiting until you need them is too late. Instead, you need to always be forecasting what you need, and making sure that those skills will be in place.

Make Professional Development Strategic

If you wait until you have a need and then turn to Human Resources to find those people, it will be too late. Things move too quickly today. Products turn over in a year. Today it is necessary to look forward and project skill needs, and have strategies in place to ensure that those skills will be in position when they are needed, without delay.

For that reason, the function that acquires and maintains human skills needs to be strategic. The old approach—the “human resources approach—is obsolete. It has become too focused on legal liability and recruiting. Those are important things, but they are not enough, and they are not viewed as strategic.

A better model is PeopleOps, in which there is a top-level advocate for defining, finding, retaining, and developing the skills that the organization will need over time. Part of that includes helping the organization to define its target culture, which has a large impact on retention.

In a PeopleOps approach, a top-level people advocate (such as a Chief People Officer) has shared accountability for the organization’s capabilities. The people advocate collaborates with the head of operations to,

  1. Identify capabilities that will be needed over the horizon, such as the next twelve months.

  2. Advocate for learning and development, so that the people in place have opportunities to learn and grow in ways that are compatible with the direction of the organization.

  3. Envision and plan for the organizational culture that will support retention goals.

The second element above means that learning is treated as a priority. Suppose for example that someone wants to learn a new skill, and rotating them to a different team would enable them to learn that skills. However, they are very productive on their current team, and their current team would experience lost productivity if that person leaves the team. If learning is a priority, then the long term benefits of learning will be weighted against the short term benefits of the person staying on their current team—instead of short term considerations always winning.

An important aspect of agility is that collaboration is not recurring: it is continuous. Circumstances can change from month to month, requiring plans and efforts to adjust. Thus, any forward view of capability needs must be reconsidered every time the situation changes in a way that challenges the assumptions that went into capability planning. This requires that leaders are always considering the implications of events, and restart discussions as soon as necessary when things change. This is a major behavioral change for which leaders—and in fact all team members—require training and coaching. We call it event-based leadership.

The Role of Enterprise Architecture

During the decade of the 2000s there was a big push within IT to define enterprise level technical architectures. This was generally referred to as “enterprise architecture” even though it tended to focus only on technology.

It did not work, because it put too much focus on written information, and not enough on knowledge or wisdom. It also failed to recognize an important fact: too much information makes the information unusable. Excessive detail destroys the ability of others to learn the information, and in an enterprise that must be agile, rapid learning is far more important than documenting every detail.

What then should the mission of enterprise architecture be, if any? Instead of trying to codify all of the enterprise’s technology into a consistent and complete top-to-bottom design, the mission should be to make sure that,

  1. People can easily find information when they need it.

  2. The information meets their need: it is either for learning or for reference, but not both at the same time.

  3. The information must be easy to update.

Reducing Cognitive Load

Information designed for learning is brief and incomplete: it only focuses on what is needed to enable someone to start using the information. If someone is tasked with adding or changing parts of a system, and the system is unfamiliar to them, they need to find information that is suitable for learning, not for reference. For example, if a programmer finds an “architecture”, that architecture is only suitable for learning if it describes the key strategies of the system and how those work together, and nothing more. In other words, it is important to not impose any unnecessary cognitive load on them just so they can learn how something works.

Complete architecture references are usually not needed, because there are usually design artifacts that, in effect, document the system. For example, if one is designing an engine, there are probably solid models of the engine’s parts and an assembly level model. However, an architecture should make sure that if such things do not exist, then there is sufficient reference documentation.

Let’s consider an example. Suppose the organization has a set of microservices. If those are documented using an OpenAPI spec, then a separate online system for documenting service APIs would be superfluous. But if the microservices are not defined using an API spec, then an online API reference would be very helpful. In general, do not duplicate documentation that is created naturally in the course of work.

What is usually missing is the why. Digital systems usually are built using artifacts that self-document what things exist, but all too often there is no mention of why those things exist of why they are the way they are. The why is what someone needs in order to learn about a system, which is necessary for them to be able to work on that system.

Enterprise architects should therefore make it their business to make sure that developers can discover and learn the “why” about things, without having to look too hard. That might involve setting standards for what kinds of documentation exist, and making its update part of the “definition of done” of any new feature or change. It might involve having design reviews instead of just code reviews. It might involve coaching developers to instill in them the importance of documenting the “why”.

There is more though. Enterprise architecture involves defining technical strategies. But instead of laboriously codifying those strategies in sophisticated documents, it is far more effective to summarize their intent, and evangelize those strategies. Share the information with people, but work directly with them to turn the information into knowledge. To do that, you have to visit with teams, have conversations with tech leads, give talks about the strategies, and help teams to apply them. You have to embed yourself in the actual work at least part of the time, coaching people in how to use the strategies. Otherwise, the strategies will remain only in their documents, and will languish.

Create a Culture of Agile Documentation

[Under development]

Agile approaches for:

  • Maintaining an information model (DDD)

  • Documenting APIs

  • Meta data for test datasets

  • Dashboard culture

Ways to Inject Knowledge Into Teams

Extended Team Member as Coach

  • Provide experts who participate as adjunct team members, usually part time.

  • The experts teach the other team members new techniques, and coach them in using those techniques.

Dojo

  • Provide an expert who embeds in a team and observes the team’s actual work.

  • The expert conducts training sessions as needed to show team members new approaches, and then coaches team members in using those approaches.

Extended Team Member as Specialist

  • An expert is provided to a team to participate as adjunct team members, usually part time; but the expert performs specialized work rather than showing others how to do it.

  • This is appropriate for work that requires deep expertise that cannot easily be transferred.

  • The expert can become a bottleneck.

Elements Of a Learning Program

One of the core concepts of Agile 2 is that everyone who participates in a value delivery stream needs to have a basic understanding of every step of the stream. One does not have to be an expert in everything, but you have to know the basics of how it works—enough to be able to have intelligent and holistic conversations about tradeoffs that affect your step and other steps.

Toward that end, knowledge is key to agility. The chart below lists key knowledge area that are essential for a product development initiative.

In addition, the following areas of expert-level supporting knowledge are needed, for those who help to set up and oversee the initiative.