Archive for April, 2009

Cultures in Our Markets

April 27, 2009

A comment on my last blog post, woke me up to the difference between developing within a culture, and developing from outside a culture. It took email exchanges and tweets to further develop that idea. I’ll show you what I mean in this article. And, thanks to Greg Yankelovich, who tweets as piplzchoice, for that comment.

To make sense of the within and outsider notions of culture, we need a way to visualize a culture. I’m focused on culture as containers of meaning, and hence practice, the stuff of software use.

Philosophers conceived of meaning as “The Ontology,” as if there were only one central structure of meaning. AI researchers have taken on ontologies as agent communications vocabularies. Information architects differentiate ontologies from taxonomies as well. Ontologies are about concepts. Taxonomies are about things. A thing’s place in a taxonomy is based on the decisions used to classify the thing, the taxons. Similarly, A concept’s place in an ontology are based on its definitional differences that philosophers called sortables, and that I’ve come to call ontons. You end up with decision trees. I call the leaves of these decision trees infons. I will say that this vocabulary is not mine. I found it on some Perot Systems or EDS website eons ago.

So to visualize an ontology, we will use a decision tree.

Visualizing Culture

Visualizing Culture

In the figure we start with (1) the usual decision tree, a binary tree. (2) Shows a more abstract representation of the usual decision tree. (3) Moves the binary tree to a multiple branched decision tree, which leaves us with a cone. (4) Shows how a culture contains subcultures that contains subcultures.

The rightmost diagram (4) encodes a cultural terrain. This is the key visualization we need to begin mapping out the cultures within a corporation.

You have the corporate culture, the priority culture among the functional cultures that compete for the “market leading” cultural position. You might find yourself working in an engineering culture, a sales culture, an accounting culture–I hope not, or a marketing culture. That will depend on tradition and the CEO. The corporate culture would provide the shell in any representation. The corporate culture would contain the management culture, and the numerous functional cultures.

The functional cultures may contain specialist subcultures. IT would be a functional culture. Engineering might be a separate functional culture even if it is staffed with IT people. The goals and reporting structure would separate IT from Dev. Your technical writers would have their own functional subculture, since as a population they share meanings, goals, tools, practices, and processes. Their distribution into development teams wouldn’t alter their functional culture. The same goes for the developers, QA people, marketers, and whoever else may be on your team or report to you. Such is culture in a matrix. Consider the culture of your team to be your responsibility, yes, a human, soft-side management responsibility is yours.

Then, you have your boss and his boss and his boss–the line management structure organized within the management culture of your company.

But, let’s skip from where we work to where we sell, to our customer’s organizations. They look similar to your organization in terms of their cultural terrain. Your product has stakeholders all over their cultural terrain. Marketing and sales deals with all of them, and in the late market, where offer expansion is key to success against the fast following, price competitors, you will deal with all of them as well.

My prior post and last week’s discussion on the #aopmtweet chat was about how requirement elicitatin could be improved by focusing our market populations on the cultures that we usually ignore and crosscut. The above visualization provides some hints to the boundaries that statistical aggreation ignores.

Moore’s technology adoption lifecycle also hints at functional culture as a segmentation mechanism. It shows up in how one would bring a discontinuous technology to market. Moore tells us to start with a custom application. Adding stage gatting to Moore’s model, we can use the client’s vertical as our statistically aggregated population and verify the number of seats and the number of dollars available in that market. An important distinction in these custom applications is that they are products. We should already have our technology.

Our technology is the realization of our idea. We coded to our own specification. Software engineering emerged from engineers and computer scientists who coded for themselves, so they coded within the specifying culture, which enabled them to get away with ignoring culture. They didn’t have executive stakeholders or requirements volatitlity to deal with, and neither do technology developing companies. Culture intrudes when you go to market. That’s when you find yourself and your team coding from its culture for those in another culture. They are coding products.

Now, when we start a custom application gig, we might not yet have our technology platform, so we will have to develop it, as we develop the custom application. If you can, separate the technology platform from the custom application. Separate the container from the contained, the automation from the automated, the channel from the message. Deal with the bifurcated development processes: one based on engineering for engineers, another based on engineering for functional practitioners. You’ll need two teams and two different elicitation processes. One will focus on the technology platform. The other will focus on the customer application riding on top of the technology platform. Build the custom application to the last release of the technology platform, to the last API, rather than the latest API.

So we have started down the Moore’s technology adoption lifecycle (TALC), which consists of sequentially organized, risk orientation-based markets. The TALC is shown in the next figure.

TALC with each market's culture count annotated

TALC with each market's culture count annotated

Starting at the left, you release your technology platform to your technical enthusiasts, or geeks. You provide free betas, because they will not pay for code. They will debug it for you. They will figure out what it can be used for. They will advocate it to their IT bosses and corporate management in terms of interesting applications that solve real problems in their workplace. They help you find the early adopters that will pay for custom application development. You code for people in the same culture as yourself, when you code for the technical enthusiasts.

To make money, you need to find a paying client. You do this in the next market, the early adopter market. These people are business executives that run an organization that will be functionally oriented, or possibly line oriented. Here you will code for people unlike yourselves. You will code from your culture for use in other cultures.

In the diagram, the custom application market is divided into eight different sections that represent the eight custom apps you will need in the bowling ally, or vertical markets.

Once your client’s period of exclusion expires, you can sell that custom application to other companies in the client’s vertical. The market would actually be a particular spot in the vertical, but it would be the same one occupied by the client’s company. The programming situation is still coding in one culture for use in another. The meaning problem persists here.

Once you leave the bowling ally or vertical markets, you once again sell to the IT market, a horizontal market. You move back to programming from one culture for use by the same culture.

Then, you move into the post-tornado, price-based, fast follower competition, or red ocean, situation. This may occur before your entry into the late market. From here on, until you consume the late market, you will code for both IT and functional users, so you will need the culture facing capabilities you might have abandoned as you exited the verticals. One red ocean strategy is mass customization, which has you focusing on functional unit meaning in the various industries that comprised your vertical markets, as well as moving up and down the industry stack or tree that constituted the vertical market. Lots of cultural boundaries need to be observed here.

We need an eliciation process that is sensitive to the functional cultures that comprise our markets. We need to understand and acknowledge the cultural boundaries in our development and marketing processes. We need to move away from aggregated populations that scramble meaning and lead to increased use costs by our customers. The survival of our industry depends on the latter.

Even where we code for our own engineering culture, we do not code for people like ourselves, otherwise, they would code the application themselves, rather than download and compile, or pursue funding by their management. They use an API when it is easier to learn that roll themselves. So even within the engineering or development culture there are subcultures. We need to be aware of these as well.

Let me know what you think. Comments help a lot. Leave a comment! And, for those of you using a feedreader, email your comments to Dave44000@yahoo.com, and I’ll post them here. Thanks!

The Waterfall Infrastructure Behind Agile

April 25, 2009

During last Thursday’s Twitter #aopm, Anthropology of Product Management, chat, we discussed how functional cultures would provide better requirements than statistical aggregation. Later that night, it came to me that requirements elicitation and basing it on statistically aggregated populations was so waterfall!

So I wrote down the following list  of waterfall vs. Agile enabling notions:

Waterfall/Agile
Requirements/User Stories
Releases/Iterations
Delayed Value Delivery/Frequent, Incremental Value Delivery
Statistical Aggregation/Functional Cultures
Mass Population/Niche Populations
Nash Games/Poisson Games
Complete Information/Adoption
Fixed Population/Population Uncertainty
Normal Distribution/Poisson Distribution
Bayesian Processes/Markov Processes
Gaussian Processes/Hidden Markov Nodes
Closed/Open

The items to the left represent the waterfall way. Those on the right a potential agile way.

We talk about user stories, but at the same time we talk about requirements. Well, which is it going to be: waterfall or agile? Clearly, requirements came from software engineering and exist to support the waterfall.

Releases, sure, don’t get me wrong. Agile still delivers a release, but iterations matter. In Feature Driven Design (FDD), an Agile method, you ask how many iterations it will take to release a single unit of minimal marketable functionality. This means that Agile delivers more often. When we move from the waterfall to Agile, we release more often.

A release is where we ship value to the customer. This regardless of whether we are doing the waterfall or agile, but with agile we ship value to the customer more often. Agile reduces our client’s problems with paying for the incremental value delivered. They pay in smaller chunks of money for small chunks of code. They also learn less after the install, so they get more use out of the code. They become productive sooner. We get feedback sooner. The waterfall delays value delivery.

We code for a client or more likely a customer, assumed to represent, the entire customer base. Coding for clients is a necessity for radical/discontinuous innovation. Most of us code sustaining/continuous applicaitons. The customer for the waterfall is someone we’ve never seen. The customer for agile is physical in the sense that it may be the product manager, but its still imaginary, because the product manager has a constructed an aggregate user in their minds. In both cases, the waterfall and agile, the customer is an aggregate of many users going so far as to create the mythical integration app user who negotiated away their meaning. These aggregates are meaningless. Software applications augment thought, or that’s that theory. As such, software applications should be meaningful, which implies that the application respects the meanings of its various users. Meaning is orgranized and defined by a culture. Users are practitioners in a particular functional domain, hence a functional culture. These cultures segment populations into smaller chunks. Functionality for such chunks would be more meaningful, more stable, less risky, unaggregated, and more addressible in the marketing sense. Functional culture is the natural target for Agile.

The statistical aggregation underlying the waterfall addresses a massed population. We use statistics to tell us about that population, but in some self fulfilling way we defined and created the population first, and only afterwards analyzed that population. Sure the regression fits. The error is small. But, the population is still mytical. Agile and functional culture would naturally address a niche population well defined by others, rather than by us. Statistical analysis of a niche population will provide better insight, than the same analysis on a massed waterfall population. Niche populations also define Moore’s custom application engagements and subsequent verticals in the bowling ally with Moore being focused on radical/discontinuous innovation.

For the waterfall to work, you need stable requirements, and a stable population from which to derive those requirements. The division between economic buyer, represented by the executive sponsor, and the users from various functional units further enhanced the myth of a mass population and the existence of a single integration vocabulary. The mythic nature of the mass population and integration vocabulary was clearly demonstrated by requirements volatility. Requirements volatility does not arise from the users changing what they do. It originates in the politics of the executive sponsor’s decision in the face of the political maneuvering of the functional units, who are motivated to protect their meanings and practices.

Agile doesn’t work better in regards to requirements volatility until it addresses a real user from a culturally determined niche population. Agile belongs to the real user, the real population, and their meanings.

In game theory, we learn the Nash game and its equalibriums. Somewhere in there the notion of complete information is mentioned, and quickly forgotten. We do x, they do y, our outcome is s, their outcome is t. But, is it true that we know what their strategic response is going to be? No. So the Nash game is mythic, instructional, but unreal and unreliable. A Poisson game, a game of population uncertainty is a better fit if you consider a population of strategies, or markets subject to adoption of their underlying category. A Nash game has a fixed population of strategies. A Nash game is built on a normal/Bayesian/Gaussian distribution. A Poisson game is built on a collection of successive Poisson distributions, which is a natural representation of Moore’s technology adoption lifecycle. Markets are Poisson.

In parametric statistics, a Normal distribution can be transformed into a Poisson distribution, and vice versa. A warning however is needed here, statistical inferences made on the transformed variates are error prone.

Processes can also be categorized by the same classification scheme I used on the distributions on games. Bayesian/Gaussian processes use all prior probabilities to determine the next state in the process. Markov process use only the information in the current state to determine the next state. Markov processes are bassed on Poisson distributions. So the waterfall is Bayesian/Gaussian, and Agile is Poisson. Again, Moore’s technology adoption lifecycle is a Markov/Poisson process, which fits Agile.

Taking a machine learning perspective, early research into artificial neurons led to hidden Markov nodes as a means of creating a fusion network of switches and weights that could learn. Hidden Markov nodes also discover things that they found on their own without regards of the intentions of the researchers. These days Gaussian processes are used rather than Hidden Markov nodes because the Gaussian approach is easeir. But, for this ease, you have to trade off discovery. Gaussian learning does not discover new aspects. Hidden Markov nodes reflect Agile; Gaussian, the Waterfall.

The Waterfall is closed to the new. Agile is open to the new. Yes, we can do change control on the waterfall and get to the new, but is it the natural outcomes of quicker releases, an interation focus, real users, less aggregation, and meaning rather than math?

We are still being dragged down by the infrastructure that supported Agile. Think about it.

Leave a comment. Thanks.