Tag: transformation

Posted on

Outsourcing Technical Debt Retirement Projects

From time to time, people ask me about the wisdom of outsourcing technical debt retirement projects. Because the answer depends so strongly on the particulars of the situation, there’s no general answer. But there are general guidelines—factors to consider when making the decision. Let’s refine the question first, in the form of a case:

Our organization uses an array of software and hardware assets to execute our mission. We developed some of these systems so long ago that the original developers have departed. They left here for other companies, or they left in spinoffs, or they moved on to other parts of our company. Some of these moves were due to reorganizations, some to promotions, and some to personal career decisions.

Most of the people who are now maintaining these assets have learned by doing.  This has been necessary because we haven’t kept the documentation current enough to be a reliable reference. We know that the systems harbor significant levels of technical debt, and the documentation itself carries debt. So we want to retire all that debt, but it’s a big job. Should we hire contractors? Or a vendor who specializes in large scale technical debt retirement projects?

This is a typical situation, but many variables are unspecified. And typically, even more variables are unknown. Those unspecified or unknown variables make the decision tricky. To illustrate, I’ve listed below seven issues that would affect decisions about outsourcing technical debt retirement projects.

In-house staff probably has useful knowledge
Deciding about outsourcing technical debt retirement?
The dilemma: outsource technical debt retirement, or do the work in-house?

If the in-house staff has much undocumented information about the current configuration of the assets, they have an enormous advantage over contractors or an outside vendor trying to do the same work. And even though the in-house staff wasn’t involved in initial development, they probably have valuable knowledge of the asset if they’ve been engaged in maintenance or enhancement to any significant degree. And they probably know more about the assets than any outsider would. So if the ultimate decision is to outsource the work, try to devise an arrangement in which the most knowledgeable in-house staff are acting in a reference role.

Debt retirement effectiveness depends on knowledge of enterprise strategy

Knowledge of enterprise strategy is useful in technical debt retirement projects. For example, suppose we know that a future project will be rendering some or all of a given asset irrelevant. We can use that knowledge to focus the debt retirement effort.

However, in some cases, revealing strategy to outside vendors is risky, even with ironclad NDAs in place. So some asset owners avoid revealing strategy information. They accept that the outside vendor might perform otherwise-wasteful tasks. This approach can be a low-cost way to manage the risks that arise from revealing strategy. Others choose to perform the work in-house. Working in-house enables them to use their knowledge of strategic direction when allocating effort in debt retirement or when deciding what the transformed asset should look like.

Detailed knowledge of the debt retirement effort is itself valuable

Knowledge of the what and why of the actual debt retirement work can be helpful in resolving any difficulties that surface after completion. That knowledge is also helpful in future work on similar assets.

With outsourcing, after the work is done, any unreported information about what the vendor did and why they did it departs with them. If in-house staff perform the work, that information remains in-house. This can be very helpful if the asset is a critical asset, or if you expect further future enhancement work or debt retirement work on that asset or similar assets.

Debt retirement work almost inevitably generates new knowledge

When people work on debt retirement, they usually have specific objectives. Even so, as they work, they generally uncover issues they hadn’t anticipated. Both in-house staff and contractors experience these aha’s. The difference between them is what happens after the work is done.

If in-house staff does the work, they can use this newfound knowledge in other projects, including new development. Not necessarily so with the outside vendor. If the same vendor is employed again for another effort, they can apply that knowledge if doing so is in scope for the next contract. But if that vendor doesn’t return, or the scope of subsequent efforts doesn’t permit it, then they can’t apply that knowledge. Moreover, the vendor might not even report what they found, though most would because they hope it will lead to more work. If they do report it, the in-house contract monitor should be sophisticated enough to recognize how valuable that kind of information is. Sadly, many are not.

Asset service disruptions can be problematic

Another difficulty with outsourcing technical debt retirement projects relates to asset service disruptions. In some debt retirement efforts, some assets must be taken out of service for periods that are moderately disruptive or worse. In-house staff likely have relationships of long standing that make cooperation, negotiation, and consideration relatively easy.

If negotiation difficulties arise, the lowest level executive or manager who’s responsible for all parties can facilitate resolution. And over time, with practice, all parties learn to work out these issues more effectively. With outside vendors, this process can be more difficult, because of the absence of existing relationships, the termination of relationships when vendors exit the scene, and the lack of formal authority of some specific executive or manager.

If in-house staff can’t do the work, consider hiring

If the in-house staff is overloaded, or if they lack the skills necessary to take on the technical debt retirement effort, outsourcing can seem like the only workable approach. Not so fast though. If a stream of debt retirement projects is in your future, consider the advantages of building a debt retirement function with a long-term agenda. Examine again the factors cited above to determine the scale of the advantages of building such a team.

Outsourcing probably works well for refactoring

The one activity for which outsourcing can be a big win is refactoring. Refactoring doesn’t usually require much knowledge of company strategy. And it doesn’t require much “non-localizable” knowledge. That is, the requirement that the refactoring not cause changes in asset behavior enables the asset owner to write a very tight contract with the debt retirement team. They can then perform their work with confidence because they can test the asset’s behavior incrementally. Also, with refactoring, asset service disruptions are usually minimal.

One last suggestion. With outsourcing, the vendor might have significantly more experience with technical debt retirement efforts than does the client. This asymmetry gives the vendor an advantage at every stage. For technical debt retirement efforts, they know more about contracting, devising statements of work, defining acceptance criteria, and managing risk. Most important, they have experience dealing with the many speed bumps that can occur in these projects. To manage the risks of that advantage, consider retaining a consultant experienced in these situations. This person’s role is to monitor communications between enterprise and vendor to ensure fairness. The mere presence of such an individual can deter the vendor from some of the abuses that can be so tempting in these asymmetric situations when trouble arises.

Other posts in this thread

Posted on

Managing technical debt

Last updated on August 24th, 2019 at 05:57 pm

Managing technical debt is something few organizations now do, and fewer do well. Several issues make managing technical debt difficult and they’re discussed elsewhere in this blog. This thread explores tactics for dealing with those issues from a variety of initial conditions. For example, tactics that work well for an organization that already has control of its technical debt, and which wants to keep it under control, might not work at all for an organization that’s just beginning to address a vast portfolio of runaway technical debt. The needs of these two organizations differ. The approaches they must take might then also differ.

A jumble of jigsaw puzzle pieces. Managing technical debt can be like solving a puzzle.
A jumble of jigsaw puzzle pieces. Where do we begin? With these puzzles, we usually begin with two assumptions: (a) we have all the pieces, and (b) they fit together to make coherent whole. These assumptions might not be valid for the puzzle of technical debt in any given organization.

The first three posts in this thread illustrate the differences among organization in different stages of developing technical debt management practices. In “Leverage points for technical debt management,” I begin to address the needs of strategists working in an organization just beginning to manage its technical debt, and asking the question, “Where do we begin?” In “Undercounting nonexistent debt items,” I offer an observation about a risk that accompanies most attempts to assess the volume of outstanding technical debt. Such assessments are frequently undertaken in organizations at early stages of the technical debt management effort. In “Crowdsourcing debt identification,” I discuss a method for maintaining the contents of a database of technical debt items. Data maintenance is something that might be undertaken in the context of a more advance technical debt management program.

Whatever approach is adopted, it must address factors that include technology, business objectives, politics, culture, psychology, and organizational behavior. So what you’ll find in this thread are insights, observations, and recommendations that address one or more of the issues related to these fields. “Demodularization can help control technical debt” considers mostly technical strategies. “Undercounting nonexistent debt items” is an exploration of a psychological phenomenon.  “Leverage points for technical debt management” considers the organization as a system and discusses tactics for altering it. And “Legacy debt incurred intentionally” explores how existing technical debt can grow as long as it remains outstanding.

Accounting issues also play a role. “Metrics for technical debt management: the basics” is a basic discussion of measurement issues. “Accounting for technical debt” looks into the matter of accounting for technical debt financially. And “Three cognitive biases” is a study of how technical debt is affected by the way we think about it.

Posts in this thread:
Posted on

Leverage points for technical debt management

Last updated on December 11th, 2018 at 10:40 am

Adopting a program of technical debt management entails significant change to the system we call the enterprise. The problem can seem so daunting that we don’t know where to begin. The places to begin are the places where the change agents have greatest leverage—what systems analysts call leverage points. Consider this scenario.

You’re sitting in the kickoff meeting of the new Technical Debt Management Task Force. The CEO is talking about how she realized that the company had a technical debt problem. It was when the Marigold project went through delay after delay, and was finally declared done, with multiple objectives waived. She’s saying something about, “we were trying to do backflips with millstones around our necks. So I want this task force to show us how to get rid of the millstones, and then get rid of them.”

McMurdo Station, Antarctica, as seen from nearby Observation Hill
McMurdo Station, Antarctica, as seen from nearby Observation Hill. The United States Antarctic Program, a unit of the National Science Foundation, operates the station. It can house as many as 1258 people in Summer. Photo (cc) Gaelen Marsden courtesy .

OK, you think. But how? We’re a global enterprise with thousands of engineers and operations on every continent. Except maybe Antarctica. No wait, we’re there, too. McMurdo I think. We have software we don’t even know much about, acquired long ago along with the companies that built it. And we’re building new systems or modifying old ones all the time, trying to move everything to the cloud while enhancing data security. Where do we begin to look for the millstones of technical debt?

Have you been in that meeting? If not, can you imagine being in that meeting? Meetings like that are happening around the globe. We’re all in the same soup.

It turns out that the answers to the millstone questions are available, but the pioneers and deep thinkers who have shown the way aren’t working on technical debt. Their field is called systems analysis. They work on problems like the collapse of the North Atlantic fishery, urban deterioration, unemployment, poverty, climate change, and the causes of the Great Recession of 2008—really difficult problems. Although the technical debt problem isn’t quite that challenging, it’s challenging enough to justify taking a look at the methods of systems analysis.

And when we do that, we immediately encounter a concept many call leverage points.

What are leverage points?

Leverage points are places in complex systems where a small change in one thing can produce big changes in system behavior. In a brilliant 1997 article, Donella Meadows describes what she calls “places to intervene in a system.” [Meadows 1997] She followed this article, making improvements each time, in 1999 [Meadows 1999] and 2008 [Meadows 2008]. Let me summarize Meadows’ work here.

To alter the behavior of a complex system, intervene at one or more of 12 categories of leverage points. For example, one category is called “Rules.” It consists of the incentives, punishments, and constraints that govern the behavior of the people and institutions that comprise the system. By adjusting the system’s rules, we can alter overall system behavior.

One more thing: the leverage points form an ordered hierarchy, ordered by effectiveness. Acting at a higher-level leverage point is more effective than acting at a lower-level leverage point. And more difficult, too. The ordering of the categories is a bit fuzzy, because every situation has its own quirks, but generally, the order is as given in the list below.

In a moment I’ll give an example of using leverage point #9, Delays, to bring about change in the way the enterprise deals with technical debt. But first, here’s a brief summary of the leverage points in increasing order of leverage; not enough to truly understand what they are, but probably enough to pique your interest. As I write posts that illustrate interventions at these leverage points, I’ll link to them from here.

  1. Numbers: Constants and parameters such as subsidies, taxes, and standards
  2. Buffers: The sizes of stabilizing stocks relative to their flows
  3. Stock-and-Flow Structures: Physical systems and their nodes of intersection
  4. Delays in feedback loops
  5. Balancing Feedback Loops: The strength of the feedbacks relative to the impacts they are trying to correct
  6. Reinforcing Feedback Loops: The strength of the gain of driving loops
  7. Information Flows:  The structure of who does and does not have access to information
  8. Rules: Incentives, punishments, and constraints
  9. Self-Organization: The power to add, change, or evolve system structure
  10. Goals: The purpose or function of the system
  11. Paradigms: The mind-set out of which the system—its goals, structure, rules, delays, parameters—arises
  12. Transcending Paradigms

Changing systems that have delays in feedback loops

When we use feedback to control systems, and there are delays in the feedback, we can potentially create destructive system behavior. And that can happen when we try to control technical debt.

Whenever we try to control a quantity in an enterprise process, we must (a) set a target value for that quantity; then (b) measure its current value; and then (c) take action as appropriate to move the current value toward the target value. Systems analysts (and control theorists) call that arrangement a feedback loop. The action taken to move the current value to the target value is sometimes called the control signal. Under certain conditions, the feedback works as expected.

For example, to control the profitability of the enterprise, we can examine its net income, say, quarterly. And at the end of each quarter we can make adjustments if net income isn’t in the target range.

Feedback loops generally work pretty well, but under some conditions, oscillations can develop. One of those troublesome situations occurs when there’s a delay in the loop that’s of the same order as (or longer than) the time the system takes to respond to adjustments. Meadows uses the example of adjusting the water temperature of a shower when there’s a long delay between making the adjustment and feeling its effects. Overcorrection is almost inevitable, and that’s what causes system oscillation.

So let’s suppose that we’re trying to control the rate of accumulation of technical debt. One approach is to set a target for TDnew, the new technical debt generated in a project. To be fair to all projects, we decide to normalize this quantity according to the project budget B. So we set targets for each project’s N = TDnew/B, and we require that projects estimate N, on an ongoing basis, with a goal of having N in some target range when the project is complete.

One problem with this approach is that we rarely identify accurately all the technical debt we’ve incurred until some time has passed after project delivery. With time, as the newly produced assets go into production and learning accumulates, we acquire the wisdom needed to identify more of the technical debt we created. This is one source of delay in this feedback loop.

So let’s assume that this happens for several projects, and management decides that delayed recognition of incurred technical debt is a common occurrence. To account for this, management lowers the target ranges for N for future projects. This causes project managers and project sponsors to include in their project plans additional effort directed at retiring more of their incremental technical debt before their projects complete, to enable them to project lower values of N. They must therefore identify as much of the incremental technical debt as they can, and retire it, to meet the lower targets for N.

But recall that technical debt identification sometimes requires time and experience using the newly produced asset. And the reverse process also occurs. Technical artifacts that we thought were technical debt prove to be useful in unexpected ways, and actually turn out not to be debt items after all. As a result, some of the incremental technical debt that got retired before the project was completed actually should not have been retired. Eventually, people realize that this happens with uncomfortable frequency, and so the targets for N are raised once more.

Oscillations thus set in. Long delays inevitably cause them. To prevent oscillations, shorten the delays.

How to shorten delays in feedback controlling technical debt

With technical debt, we can shorten delays in several ways.

  • If the asset is meant for human use, involve representatives of the user population in the development and design process as soon as practical. Have them exercise the asset, or prototypes, early. Listen to their suggestions. Observe how they use the asset.
  • If the asset must interact with non-human assets, exercise it early and often. Don’t think of this as testing, though it might look very much like testing. What you’re actually doing is searching for shortcomings in how the asset interacts with non-human assets, in design and implementation in an asset that already works.
  • Subject the asset to multiple reviews all along the development trajectory. Don’t wait for final release to review it.

These practices expose technical debt items early—potentially, during initial design—thereby reducing delays in identifying what is and what is not technical debt. They help to advance the date at which we uncover missing capabilities or capabilities designed or implemented in awkward ways. No surprise, I’m sure, but these practices are consistent with Agile approaches to technological development.

Indirect effects can add to delayed recognition of technical debt

Most of the argument above assumed that the incremental technical debt associated with the project was incurred within the asset undergoing development or maintenance. But technical debt can occur in other assets as well. When the development team is unaware of such “remote” or “indirect” incremental technical debt, recognition of that new incremental technical debt can be significantly delayed. The project’s N will appear to be smaller that it actually is, until that remote incremental technical debt is recognized.

This form of delay is likely to occur when the debt incurred is asset-exogenous. Recall the example of line extension of mobile phones. In that example, the enterprise incurs technical debt in one set of products as a result of the introduction of a different product. In some cases, the newly incurred technical debt is immediately evident. When it is not, delays can be substantial.

This effect is by no means rare. Any organizational change can potentially add to the technical debt portfolio—reorganizations, acquisitions, expansions, wholly new products, and much more.

Conclusions

Interventions at the leverage points of an organization can produce the changes we want with a minimum of effort. Some subtlety is involved, because Meadows’ leverage points are expressed at a high level of abstraction.  But applying them to the problem of technical debt management is a promising approach.

Bookmark this post. I’ll be linking to more examples of using leverage points to manage technical debt. So far:

References

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

Other posts in this thread

Posted on

Unrealistic definition of done

Last updated on February 1st, 2018 at 07:27 am

Many an enterprise culture includes, perhaps tacitly, an unrealistic definition of done. When an enterprise culture assumes a definition of done for projects that excludes — or fails to adequately acknowledge — attributes related to sustainability of deliverables, technical debt expands inexorably. In most organizations, the definition of done for projects includes meeting the attributes that most internal customers understand and care about. These attributes might not include sustainability [Guo 2011]. Indeed, even among technologists, the definition of done might not enjoy precise consensus [Wake 2002].

The 2009 Ford Focus SES coupe (North America) engine bay
The 2009 Ford Focus SES coupe (North America) engine bay. Gone are the days when typical owners could learn how to maintain their own vehicles. Engines have become so complex that even experienced mechanics must be trained to maintain engines with which they’re unfamiliar. Since these vehicles are being offered for sale to consumers, clearly their manufacturers regard their designs as “done.” But is technical debt a factor in the growing complexity of modern motor vehicle engines? It’s probably present in their software, and it would be most surprising if we found no technical debt in the mechanical design. Photo (cc) Porsche997SBS courtesy Wikimedia.

Because attributes related to sustainability of deliverables are less well understood by internal customers — indeed, by nearly everyone — it is perhaps unsurprising that sustainability might not receive the attention it needs. Applying scarce resources to enhance attributes the customer doesn’t understand, and cares about less, will always be difficult.

To gain control of technical debt, we must redefine done to include addressing sustainability of deliverables. Although there may be many ways to accomplish this, none will be easy. Resolution will involve, inevitably, educating internal customers so that they understand enough about sustainability to enable them to justify paying for it.

The typical definition of done for most projects ensures only that the deliverables meet the requirements. Because requirements usually omit reference to retiring newly incurred non-strategic technical debt, projects are often declared complete with incremental technical debt still in place. A similar problem prevails with respect to legacy technical debt.

A more insidious form of this problem is intentional shifting of the definition of done. This happens when the organization has adopted a reasonable definition of done that allows for addressing sustainability, but under severe time pressure, the definition is “temporarily” amended to allow the team to declare the effort complete, even though sustainability issues remain unaddressed.

For most projects, three conditions conspire to create steadily increasing levels of non-strategic technical debt. First, for most tasks, the definition of done is that the deliverables meet the project objectives, or at least, they meet them well enough. Second, typical project objectives don’t restrict levels of newly incurred non-strategic technical debt, nor do they demand retirement of incidentally discovered legacy technical debt. Third, budget authority usually terminates upon acceptance of delivery. These three conditions, taken together, restrain engineering teams from immediately retiring any debt they incur and from retiring — or documenting or reporting — any legacy technical debt they encounter while fulfilling other requirements.

For example, for one kind of incremental technical debt — what Fowler calls [Fowler 2009] Inadvertent/Prudent (“Now we know how we should have done it”) — the realization that debt has been incurred often occurs after the task is “done.” If budget authority has terminated, there are no resources available — financial or human — to retire that form of technical debt.

Unless team members document the technical debt they create or encounter, after they move on to their next assignments, the enterprise is likely to lose track of the location and nature of that debt. A more realistic definition of done would enable the team to continue working post-delivery to retire, or at least document, any newly incurred non-strategic technical debt or incidentally encountered legacy technical debt. Moreover, strategic technical debt — technical debt incurred intentionally for strategic reasons — is also often left in place. Although it, too, must be addressed eventually, the widespread definition of done doesn’t address it.

Policymakers are well positioned to advocate for the culture transformation needed to redefine done.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[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.

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

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

Available: here

Cited in:

Other posts in this thread

Posted on

Failure to communicate the technical debt concept

Last updated on May 25th, 2018 at 09:46 am

The behavior of internal customers and users of enterprise technological assets can contribute to technical debt formation and persistence. Because of these contributions, introducing effective technical debt management practices requires widespread behavioral changes on the part of those internal customers and users. Accepting these changes, and the initiative and creativity they require, is possible only if people understand the technical debt concept. When they do, they can appreciate the benefits of controlling technical debt, and the consequences of failing to control it. Similarly, when they do not understand or accept the technical debt concept, progress toward effective technical debt management is unlikely. Policymakers can contribute to the planning and execution of the required organizational transformation.

Even when the engineering teams are aware of the technical debt concept, and when they do try to manage technical debt, they cannot make much progress unless they have the support and understanding of their own management, their internal customers, and their customers’ managements. Everyone must understand that controlling technical debt — and retiring it — is a necessary engineering activity that has a business purpose. Everyone must understand that technical debt arises as a result of everyone’s behavior — not just the behavior of technologists.

A tensegrity 3-prism
A tensegrity three-prism. . Read about tensegrity structures.
Image (cc) Bob Burkhardt courtesy Wikimedia.
Part of the job of Management is to see that engineers have what they need to avoid incurring technical debt unnecessarily, and that they have what they need to retire elements of legacy technical debt on a regular basis. Internal customers must understand that communicating their long-term business strategies to Engineering is essential for limiting unnecessary creation of artifacts that become non-strategic technical debt. Only by understanding the technical debt concept can internal customers learn to avoid the behaviors that lead to non-strategic technical debt, and adopt behaviors that limit new technical debt.

Tensegrity structures provide a metaphor for organizations that have mastered the technical debt concept. Tensegrity structures use isolated rigid components in compression, held by a network of strings or cables in tension. The rigid components are usually struts or masts, and they aren’t in contact with each other.

The struts correspond to the users or customers of technological assets. The cables correspond to the engineering activities required to support the customers. The organization is stable relative to technical debt only when the two kinds of elements (struts and cables) work together, each playing its own role, but each appreciating the role of the other.

Advocating for cultural transformation

Advocates of any change to organizational culture are often seen as acting in their own self-interest. That’s a common risk associated with cultural transformation. It’s a risk that can lead to failure when inserting practices related to technical debt management into the culture. The risk is greatest when advocates for change are drawn exclusively from the technical elements of the enterprise. The ideal advocates for these ideas and practices are the internal customers of the technical organizations, and senior management.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[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.

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

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

Available: here

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons