Feature Injection Chris Matts Agile 2008

Knowledge Transfer

Know that you Know When you know that you know some information, you understand the information and realize its relevance and importance to the problem you are trying to solve. When you are in this state, you are able to plan your further actions for attacking the problem and transfer that knowledge to the rest of the team. Let’s say you are working on an application to automate the decision making process for a mortgage. Anyone who has ever borrowed money to purchase a house knows that the borrowers are asked to provide information about their income so that the lender can determine their capacity to pay back the loan. You understand the importance of information such as the borrower’s employment income, whether that income is from salary, hourly wage, or commission, the borrower’s employer, and the length of their employment. Know That you Don’t Know There are several cases during the early stages of a project where you are aware of specific pieces of information about the problem space that are extremely relevant and important to know, but that you have not had the opportunity to learn or experienced yet. The way you manage your knowledge, or lack thereof, in this state is through risk management. You can move to the Know that you Know state by finding the answer, or issue resolution. Considering the mortgage lending example again, you know that there are rules surrounding how income is treated in the loan decision process, but you do not know what those rules are. In order to get to the point where you are able to transfer that knowledge to the other team members who have to translate those rules, you have to find the answer to the question “what are the rules for dealing with income?” Don’t Know that you Don’t Know All problems have a certain amount of information that the people trying to solve those problems do not know and do not know the information exists (ie realize that there is information that is relevant to their problem domain). The key here is for teams to realize there are things that they do not know that they do not know and manage for that uncertainty. They can also attempt to move out of that space through a process we call structured learning. In this approach you aren’t answering questions, rather you are trying to ask the right questions before the project team stumbles on the question in a more costly manner. Giving an example for this particular state is challenging, because the minute you acknowledge the existence and relevance of a certain piece of information, you are already in the Know that you Don’t Know state, but let’s suspend disbelief for a second. In a mortgage lending decision project, there can be credit policy rules established by the credit risk department which are critical for a proper decision but are not widely communicated. Until you actually find out about the existence of these rules, let alone their relevance to the application, you will not be able to do anything about them, nor would you be inclined to. You have to actively seek out this information before it becomes apparent in a bad decision after it is too late. You need to ask the right questions. Don’t Know that you Know Initially this state sounds a little like amnesia (which would actually be don’t know that you knew something or somebody.) Remember that we defined Awareness as the realization that information exists and that it is relevant and important to the project at hand. The key in this situation is that the information is relevant and important. This is the state that you find yourself in when you are an absolute storehouse of what initially seems like useless information, but never connect the importance of that information to the project on which you are working. The key here is for teams to determine if they have gaps in their knowledge and then determine the relevance of information they do have in order to fill those gaps. Taking another look at our mortgage lending example, we know the general difference between a salary and a bonus is that the salary is a consistent amount that you earn every two weeks or month, while a bonus is something that is not necessarily guaranteed and is received on a very irregular schedule. You probably didn’t however realize the relevance of that particular piece of information to mortgage lending until you connect the fact that you are using past earning experience to determine future earning potential and the ability for a borrower to pay back their loan. Its common knowledge that you wouldn’t initially apply to your project until you determined its relevance.

An Average Project Member

The Dream

The Reality

The Fear

The Truth

Know that you Know When you know that you know some information, you understand the information and realize its relevance and importance to the problem you are trying to solve. When you are in this state, you are able to plan your further actions for attacking the problem and transfer that knowledge to the rest of the team. Let’s say you are working on an application to automate the decision making process for a mortgage. Anyone who has ever borrowed money to purchase a house knows that the borrowers are asked to provide information about their income so that the lender can determine their capacity to pay back the loan. You understand the importance of information such as the borrower’s employment income, whether that income is from salary, hourly wage, or commission, the borrower’s employer, and the length of their employment. Know That you Don’t Know There are several cases during the early stages of a project where you are aware of specific pieces of information about the problem space that are extremely relevant and important to know, but that you have not had the opportunity to learn or experienced yet. The way you manage your knowledge, or lack thereof, in this state is through risk management. You can move to the Know that you Know state by finding the answer, or issue resolution. Considering the mortgage lending example again, you know that there are rules surrounding how income is treated in the loan decision process, but you do not know what those rules are. In order to get to the point where you are able to transfer that knowledge to the other team members who have to translate those rules, you have to find the answer to the question “what are the rules for dealing with income?” Don’t Know that you Don’t Know All problems have a certain amount of information that the people trying to solve those problems do not know and do not know the information exists (ie realize that there is information that is relevant to their problem domain). The key here is for teams to realize there are things that they do not know that they do not know and manage for that uncertainty. They can also attempt to move out of that space through a process we call structured learning. In this approach you aren’t answering questions, rather you are trying to ask the right questions before the project team stumbles on the question in a more costly manner. Giving an example for this particular state is challenging, because the minute you acknowledge the existence and relevance of a certain piece of information, you are already in the Know that you Don’t Know state, but let’s suspend disbelief for a second. In a mortgage lending decision project, there can be credit policy rules established by the credit risk department which are critical for a proper decision but are not widely communicated. Until you actually find out about the existence of these rules, let alone their relevance to the application, you will not be able to do anything about them, nor would you be inclined to. You have to actively seek out this information before it becomes apparent in a bad decision after it is too late. You need to ask the right questions. Don’t Know that you Know Initially this state sounds a little like amnesia (which would actually be don’t know that you knew something or somebody.) Remember that we defined Awareness as the realization that information exists and that it is relevant and important to the project at hand. The key in this situation is that the information is relevant and important. This is the state that you find yourself in when you are an absolute storehouse of what initially seems like useless information, but never connect the importance of that information to the project on which you are working. The key here is for teams to determine if they have gaps in their knowledge and then determine the relevance of information they do have in order to fill those gaps. Taking another look at our mortgage lending example, we know the general difference between a salary and a bonus is that the salary is a consistent amount that you earn every two weeks or month, while a bonus is something that is not necessarily guaranteed and is received on a very irregular schedule. You probably didn’t however realize the relevance of that particular piece of information to mortgage lending until you connect the fact that you are using past earning experience to determine future earning potential and the ability for a borrower to pay back their loan. Its common knowledge that you wouldn’t initially apply to your project until you determined its relevance. STOP DOCUMENTING REQUIREMENTS

Help Others Learn

Issue Resolution

Traditional Issue Resolution

“Real Option” Issue Resolution “So how do we stop this thing?”

Structured Learning

The Questions are out there!

If Only we had the tools to find them

A Familiar Process? AnalysisDevelopment Test Plan Test

Look at the Information flows I(a) I(tp) I(d) I(t) AnalysisDevelopment Test Plan Test

Oops I(a) I(tp) I(d) I(t) AnalysisDevelopment Test Plan Test

I(a) I(tp) I(d) I(t) The Same Process….. But in a different order. AnalysisDevelopment Test Plan Test

Feature Injection

As we pull value from a system, we inject features.

WHY?

Business Value

Where is the value?

Input? Output?

Input? Output?

VALUE INPUTS PROCESS DEVELOPMENT OUTPUTS

VALUE INPUTS PROCESS ANALYSIS OUTPUTS

DEVELOPMENT Spot Example Model Reflect Test

Model DEVELOPMENT ACTUALLY Spot Example Reflect Test

Model ANALYSIS Spot Example Reflect Test

Tim works for IT Karen works for IT Anne works for IT Neil works for IT Neil transferred from Operations in February Stephane works for IT Melanie was on maternity leave last year. Billy Bob works part time for Middle Office and Operations Tim is in Cost Centre Lynn left in 2003 and came back last year. Exercise – Payroll Costs per Department

I(a) I(tp) I(d) I(t) Familiar? AnalysisDevelopment Test Plan Test

I(a) I(tp) I(d) I(t) The Missing Link! Development Test Model Spot Example Reflect Test

Feature Injection Business Analysis feeding Examples into a BDD/TDD Process

Thank you to all the Flickr contributors who made this slide show possible. Abacus : Leaf : Money 1 : Money 2 : Money 3 : Money : Business Value : Oil Refinery : Oil Storage Tank : Camera Man : Eating Food : Harvesting Wheat : Growing Wheat : Waterfall : Sunset : Odd one out : Model : Eye test : Audience : Sowing Seeds :