Tag: culture

Last updated on June 2nd, 2018 at 09:50 pm

In the context of today’s prevalence of global teams, the word culture evokes consideration of the differences between different national cultures. We think of the difference between Singapore and Latvia. Or we might also consider regional differences between Massachusetts and Texas. Or between San Francisco and Los Angeles. These differences are real. They do affect the way the inhabitants of these places deal with technical debt. But these cultural differences are topics for another time.

For now, let’s consider how a particular cultural attribute of teams or groups in organizations affects how they manage technical debt. Specifically, how we regard time correlates closely with our preferences, biases, and even the way we think about approaching technical debt.

Anthropologist Edward Twitchell Hall, Jr. (1914-2009) developed fundamental concepts for thinking about how we experience space and time. In The Silent Language [Hall 1973], he introduced the concepts of polychronic time and monochronic time. They represent two different ways human cultures relate to time.

People and cultures with a monochronic orientation (M-People) regard time as linear. M-People are most comfortable when they undertake only one task at a time. They tend to sequence tasks one after the other. Their motto is “Work on one and get it done.” When M-People must tackle more than one task in an hour, they divide the hour into blocks. They dedicate each block to one task. But time division isn’t always possible. When M-People work in groups, and when they must do more than one thing simultaneously, they divide their groups. Then each subgroup can focus on one task at a time. This is more or less how conventional (pre-Agile) project teams work.

People and cultures with a polychronic orientation (P-People) regard time differently. They define time more in terms of completed tasks than in terms specified by the hands of a clock. For example, a farmer might define time by what’s happening: it’s time for planting, for harvest, for haying, for canning, or for calving. Finer increments are also defined by what’s happening: it’s time for milking, time for breakfast, or it’s sundown or sunset. More than one thing can be happening at any given time.

In organizational cultures, the differences between monochronic and polychronic orientations are evident at every level of activity. For example, in a meeting of M-People, only one person has the floor at any one time. M-People schedule their agenda items, and after they move to the next agenda item, they don’t return. (Well, they do sometimes return, but they aren’t comfortable when they do) A meeting of P-People might have several people talking at once. They bounce from topic to topic as the discussion calls for it. M-People are very uncomfortable in P-style meetings; P-People are just as uncomfortable in M-style meetings [Brenner 2018].

M-approaches can work just fine when we know in advance what the tasks entail. We can carve up our total work into pieces and address them one at a time, because they either don’t interact much, or because we can control their interactions. And we can partition the work across the available people and groups, each working on one piece of the effort.

And that has worked well for much of the work involved in producing and maintaining today’s complex technological assets.

But M-approaches can get into trouble when we work on something that’s complex or unfamiliar. When we don’t have (and can’t devise) a detailed plan of the work, dividing the work either by time or by task can be difficult to get right. To do this kind of work, we must depend more on interpersonal relationships and close teamwork than on scheduling and task partitioning. M-style approaches can flounder. And that’s where P-style approaches have big advantages.

In polychronic work styles, we’re more focused on accomplishments than schedule, because we don’t really know enough about the work to make a detailed schedule. In some instances, estimating how much work something might take is essentially impossible because we don’t understand the task in enough detail. We must then let events guide us, in the way the seasons guide the farmer. The people doing the work must adapt as they go, which requires strong relationships, tight collaboration, and trust.

And that brings us to technical debt management. We can address some kinds of technical debt with M-style approaches. We understand those debts and we know how working on their retirement will affect other work. But many forms of technical debt are so entangled with the rest of the organization’s efforts that P-style approaches are more likely to be successful.

For example, consider a project that’s aimed at retiring some kinds of technical debt. That might require access to assets that are critical to certain revenue streams. And suppose that ongoing work unrelated to retiring that technical debt might also affect these same assets. Coordinating all these efforts is complicated, even when we’re planning for only the next few weeks. But coordinating these efforts six months or twelve months in advance is probably impossible, because we can’t create schedules reliable enough to support such planning. The schedules of the various interlocking activities aren’t well enough controlled for that, any more than a dairy farmer controls the calving schedule. The cows control the calving schedule.

• How much will it cost—total—to retire the technical debt of that kind?
• How long will it take?
• Will that debt retirement interfere with our plans for the rollout of the Marigold products next September?

Conventional project management might not work well for technical debt retirement efforts. Regarding them as “projects,” with defined schedules, defined budgets, and defined staff assignments might be a serious error. Agile approaches, which are inherently more P-style, might work better.

References

[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

• Technical debt: monochronic and polychronic cultures

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

• Technical debt in software engineering
• Team composition volatility
• How performance management systems can contribute to technical debt
• Unrealistic definition of done
• Spontaneous generation
• Legacy debt incurred intentionally
• Controlling incremental technical debt
• Refactoring for policymakers

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

• Unrealistic definition of done

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

• Technical debt: monochronic and polychronic cultures

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

• Team composition volatility

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

• Zero tolerance and work-to-rule deliveries create an adversarial culture

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

• Unrealistic definition of done

Other posts in this thread

• Organizational culture and technical debt
• On assigning responsibility for creating technical debt
• With all deliberate urgency
• Cultural debt can be the primary driver of technical debt
• Using SMART goals for technical debt reduction
• Technical debt smell
• Technical debt use disorder