Whole New Mind: From The Information Age to the Conceptual Age

Daniel Pink's latest book seems to be out in both paperback and hardcover with slightly different titles. The hardcover version is A Whole New Mind: Moving from the Information Age to the Conceptual Age. The paperback version is a tad more recent and has a more sensationalistic title: A Whole New Mind: Why Right Brainers will Rule the Future. The best place to go to learn more information about the book is Dan Pink's website (and blog).

From what I can tell, much of what Pink concludes is a result of the same sort of things that Thomas Friedman (The World is Flat) and Peter Fingar (Extreme Competition) and John Hagel and John Seely Brown (The Only Sustainable Edge) discuss in their respective books:

In the new "flattened world" of Globalization 3.0 the only way to get ahead and stay ahead is to innovate faster than your competition. And the keys to rapid business innovation are to "connect and collaborate!"

So those who have the skills to see the big picture, connect with others, effect collaborative synergy, foster creativity and innovation (or innovate and be creative) are the skills that will be in highest demand (and commanding the "cushiest" employment arrangements.

Pink claims we are in the process of moving from the Information Age, where we have access to, are driven by, and overloaded with hoards of information vying for our attention, into the Conceptual Age where we put it all together and figure out what it means in the smaller and larger context of our lives and our interconnected personal and professional networks. The essential skills needed to survive and thrive in the Conceptual Age are: Design, Story, Symphony, Empathy, Play and Meaning. The book then describes in more detail what those are and how we can try to develop and hone them for ourselves.

An excerpt from 800ceoread.com summarizes the book:

A Whole New Mind looks at the right brain/left brain differences and shows how those historical issues are radically changing. As I learned during a weekend in Vermont with Tom Peters, Dan Pink also believes that: "The MFA is the new MBA." Pink points out that design and traditional "right brain" thinking will be the course of the future. The first part of the book gives a primer on how the brain works with great stories from Pink on how his brain was scanned and stimulated and how the different parts of his brain responded. He then goes into pages and pages of supporting stories and examples from his extensive research. Excellent reading!

Pink states that we are entering the Conceptual Age and to prepare for it we need to improve six essential abilities. They are: Design, Story, Symphony, Empathy, Play and Meaning. These abilities are the chapter heading for the final six chapters. At the end of each of the chapters, Pink has a Portfolio which is a combination of tools, exercises, and further reading culled from his research and travels that can help you sharpen each sense.

If that piques your mind for more of Pink's "Whole New Mind," here is an excerpt from the Introduction to the book:

The last few decades have belonged to a certain kind of person with a certain kind of mind – computer programmers who could crank code, lawyers who could craft contracts, MBAs who could crunch numbers. But the keys to the kingdom are changing hands. The future belongs to a very different kind of person with a very different kind of mind – creators and empathizers, pattern recognizers and meaning makers. These people – artists, inventors, designers, storytellers, caregivers, consolers, big picture thinkers – will now reap society’s richest rewards and share its greatest joys.

This book describes a seismic – though as yet undetected – shift now underway in much of the advanced world. We are moving from an economy and a society built on the logical, linear, computer-like capabilities of the Information Age to an economy and a society built on the inventive, empathic, big picture capabilities of what’s rising in its place, the Conceptual Age. A Whole New Mind is for anyone who wants to survive and thrive in this emerging world – people uneasy in their careers and dissatisfied with their lives, entrepreneurs and business leaders eager to stay ahead of the next wave, parents who want to equip their children for the future, and the legions of emotionally astute and creatively adroit people whose distinctive abilities the Information Age has often overlooked and undervalued.

In this book, you will learn the six essential aptitudes — what I call “the six senses”—on which professional success and personal satisfaction increasingly will depend. Design. Story. Symphony. Empathy. Play. Meaning. These are fundamentally human aptitudes that everyone can master—and helping you do that is my goal.

****

A change of such magnitude is complex. But the argument at the heart of this book is simple. For nearly a century, western society in general, and American society in particular, has been dominated by a form of thinking and an approach to life that is narrowly reductive and deeply analytical. Ours has been the age of the “knowledge worker,” the well-educated manipulator of information and deployer of expertise. But that is changing. Thanks to an array of forces—material abundance that is deepening our nonmaterial yearnings, globalization that is shipping white-collar work overseas, and powerful technologies that are eliminating certain kinds of work altogether—we are entering a new age. It is an age animated by a different form of thinking and a new approach to life—one that prizes aptitudes that I call “high concept” and “high touch.” High concept involves the capacity to detect patterns and opportunities, to create artistic and emotional beauty, to craft a satisfying narrative, and to combine seemingly unrelated ideas into something new. High touch involves the ability to empathize with others, to understand the subtleties of human interaction, to find joy in one’s self and to elicit it in others, and to stretch beyond the quotidian in pursuit of purpose and meaning.

As it happens, there’s a convenient metaphor that encapsulates the change I’m describing—and it’s right inside your head. Your brain is divided into two hemispheres. The left hemisphere is sequential, textual, and analytical. The right hemisphere is simultaneous, contextual, and synthetic. Of course, we enlist both halves of our brains for even the simplest tasks. And the respective traits of the two hemispheres have often been caricatured well beyond what the science actually reveals. But the legitimate scientific differences between the two hemispheres of the brain do yield a powerful metaphor for interpreting our present and guiding our future. Today, the defining skills of the previous era—the metaphorically “left brain” capabilities that powered the Information Age—are necessary but no longer sufficient. And the capabilities we once disdained or thought frivolous—the metaphorically “right brain” qualities of inventiveness, empathy, joyfulness, and meaning—increasingly will determine who flourishes and who flounders. For individuals, families, and organizations, professional success and personal fulfillment now require a whole new mind.

I wonder if I'm one of those "Right-Brainers" or not. Alas, I am right handed -- tho I swing a baseball bat, tennis racquet, and golf-club with a lefty grip. Of course one can have and/or hone these skills regardless of one's "handedness." My Meyers-Briggs type indicator is INTP. That is allegedly the "innate architect" type: Architects are highly analytical, but also somewhat artistic (i.e. creative) and need to see the bigger picture and how it all connects together; they can also narrow their focus too much on the "worlds of the mind" that they strive to create. If it helps any, I used to be a dancer in a previous life (my Mom was a dance teacher and I was classically trained since the age of 4 in modern, ballet, jazz, and several other forms of dance).

Perhaps there is yet hope for my future! All indications thus far are that my four-year-old daughter and two-year-old son are left-handed. :-)

The Only Sustainable Edge

The Only Sustainable Edge: Why Business Strategy Depend on Productive Friction and Dynamic Specialization, by John Hagel III (former senior advisor at McKinsey & Company) and John Seely Brown (former Chief Scientist at Xerox Corp.) is a book that builds on the conclusion of Peter Fingar's Extreme Competition. Like Fingar, Hagel and Seely Brown draw the same conclusions about the "flattened world" described in books by Thomas Friedman (The World is Flat), Barry Lynn (End of the Line), and Clyde Prestowitz (Three Billion New Capitalists) . . .

The new flattened world means that the only way to get and stay competitive is to continuously innovate at a pace that your competition cannot match, and utilize technology to that end. But where Fingar delves deply into the drivers and forces and forward looking solutions, The Only Sustainable Edge focuses on the process of how to achieve such continuous fast-paced innovation and what is necessary to create and sustain it.

From the book's website at www.edgeperspectives.com, the following areas are covered:

• Developing New Business Strategies: Traditional approaches to strategy are broken and what must be done going forward
• Understanding China and India: Contrary to popular perception, China and India are emerging as global centers of management innovation
• Competing in a Flat World: As Tom Friedman suggests, the world is flattening, but companies can use pragmatic approaches to create powerful new sources of strategic advantage
• Finding Innovation on the Edge: In pursuing innovation, shift attention from the core to the edge - the edges of business processes, the edges of enterprises, the edges of emerging economies and the edges of new generations of tech savvy consumers and workers
• IT Matters More than Ever: New generations of technology are converging to create even more powerful sources of innovation and strategic advantage
• Reassessing Public Policy: Public policy can amplify or undermine business strategies - business leaders must become catalysts for public policy change

The thesis of the book is that effective business strategy "depends on productive friction and dynamic specialization." They write of "the core" versus "the edge":

First, we mean the edge of the enterprise, where one company interfaces or interacts with another economic entity and where it currently generates marginal revenues rather than the core of its profits.

Second, the edge refers to the boundaries of mature markets as well as industries, where they may overlap, collapse, or converge...

[Third], geographic edges, especially those of such emerging economies as China and India, where consumers of all kinds crave Western goods and services that will ease their burdens and improve their lives.

Finally, we refer to the edges between generations, where younger consumers and employees, shaped by pervasive information technology, are learning, consuming, and collaborating with each other and where baby boomers are preparing to retire or switch careers over the next decade.

The authors focus on three strategic imperatives in order to build and sustain this strategic competitive advantage: dynamic specialization, connectivity and coordination, and leveraged capability building. Some key excerpts from reviewer comments at Amazon.com:

Fred G. Sanford:

Hagel and Brown are two well pedigreed authors, and they attempt to explain their view on what is the next frontier in corporate strategy. The answer is that value of the firm lies not inside the firm but at its edge. The edge is a broad metaphor for geography (India, China and Brazil), maturity (old econ and new economy), physical edge (inside the firm as well the partners outside). The key insights from this book are:

• Two types of forces have converged to squeeze margins -Informational technology, and Public policy shifts. Try telling this to the 500,000 people who have lost their jobs in the valley.
  
• Three key elements of the new model for business strategy are:
  
  1. Reconceive sources of strategic advantages by accelerated capability building across boundaries. This implies - Dynamic specialization, Connection and Coordination of 3rd parties and Leveraged capability building. Elaborated using the Li & Fung, Hong Kong retailer example.
     
  2. Master new mechanisms to build advantages - This implies focusing on efficiency as well as effectiveness, process outsourcing and offshoring, loose coupling of extended business processes and production friction
     
  3. Adopt new approaches for developing strategy
• Given this framework, conduct a diagnostic that inventories the key initiatives for the last 12 months, as well as the proposed initiatives for the next 5 years. At the end of this diagnostic, you should be able to identify what activities you can offshore and outsource and therefore you can dynamically specialize.
  
• Process networks are predicated on loose coupling of processes and Productive friction. Productive friction can be decomposed into four factors, Performance Metrics, People, Prototypes, and Pattern Recognition.
  
• Process networks are enabled by performance fabrics and IT is critical in achieving a solid performance fabric. Web services is critical in implementing this new fabric.

Laurence Stybel:

The current fad is to talk about business models organized along industry lines. The authors argue that industry focus is insufficient for a proper conversation about strategy. Within that industry-focused model, there needs to be a second strategic focus. They see this new strategic focus along three dimensions:

1. Infrastructure Management. Financial services, pharmaceuticals, and the computer industry are already structured in significant ways along these lines. State Street Corporation is an example of a company that services the financial services industry but its value clearly revolves around infrastructure management. UPS revolves around infrastructure management of logistics. An infrastructure management theme works well for relatively routine, high volume business activities.
2. Product Innovation. Specialized biotech companies are taking on more of R&D activities so that large pharmaceutical companies can focus on scale intensive manufacturing and distribution. There are specialty design shops that serve the fashion industry. There are specialty semiconductor design shops that serve the electronics industry.
   
3. Customer Relationship. These firms concentrate on identifying target customer segments, getting to know that segment very well, and using its resources to mobilize third party products and services to address the needs of their customers. Physicians who practice general medicine, financial planners, real estate agents, and attorneys all provide this framework. Accenture is a company with this type of framework.

Emily Levine:

Dynamic Specialization:

The pre-globalized world world was divided into what Isaiah Berlin called "hedgehogs" - generalists, who know a little about a lot of things; and "foxes" - specialists, who know a lot about one thing. In a globalized world, the specialist is neither fox nor hedgehog: the specialist must know a lot about one thing...and how it works in many, many different contexts. To grok the specialist as a boundary-crosser, moving laterally across a broad spectrum, is also to understand the shift from a vertical to a horizontal focus (what Thomas Friedman calls "flattening"). Likewise, the transcendence of the fox/hedgehog paradigm suggests that oppositional constructs themselves may be passé. Indeed, throughout the book, the authors look to maintain the tension between opposites rather than resolve the tension either one way or the other. (Thus, unlike the early enthusiasts of chaos theory, who replaced "things" with "flow", Hagel and JSB have a healthy respect for both.)

Performance Fabric:

Pre-globalization, growth was measured size and/or efficiency. In a globalized world, growth is measured by complexity. You grow by deepening and broadening your connections, forming new partnerships, entering into new collaborations, growing one's skills across many more contexts. That tapestry of connections is what Hagel and JSB call "a performance fabric". I'd be tempted to say that the richer the tapestry, the richer the company and its shareholders, but now I'm thinking "tapestry" doesn't do justice to the elasticity of the performance fabric. Perhaps "trampoline" would be better - it gives you that added bounce you need to vault into a higher stratosphere, a higher level of complexity. (Perhaps it could be said that in a globalized world, companies have to grow up.)

Productive Friction:

Pre-globalization, boundaries were thought to be hard and fast, built like moats around a castle to protect one's enterprise against competitors, predators (or pirates) and/or regulatory bodies. In a globalized world, boundaries are points of connections as well as separation. Companies and individuals have to collaborate with competitors. Those working in and with countries that have different ideas of property and the boundaries we create to protect property, need to negotiate boundaries rather than impose them. Rubbing up against each other in this way creates friction, but, as anyone who's ever watched "Survivor" knows, rubbing two sticks together produces fire. Likewise, productive friction sparks new ideas and new solutions.

Next, I will look at a Whole New Mind, by Dan Pink (also see Dan Pink's blog)

The Coming IT Flip-Flop

As a follow-up to my previous blog-entry about Peter Fingar's book Extreme Competition, a related article by Fingar called "The Coming IT Flip-Flop" (also available in a BPM Trends article) builds on the same trend, and talks of the increasing need for Human Interaction Management, and tools that try to facilitate that INSTEAD of trying to do more workflow/process automation (see related book of the same name). Some relevant excerpts:

It won't be just the satellite/fiber networks that drive the continued globalization of highly skilled white-collar workers, it will be the ability to create virtual work spaces where far flung teams can work together in real time. As globalization continues, the demand for a new generation of technology support for work accomplished by geographically dispersed teams becomes clear.
. . .
And the answer isn't workflow... Such capabilities are needed to help a company put it's "house in order" with application integration. But they don't directly support the way people actually accomplish their work.

What's needed is dedicated support for dynamic human-to-human interactions that cannot be preordained or pre-programmed the way system-to-system interactions are. Further, it's the human-driven business processes that are the very heart of business process management and project management. A New Category of Business Technology.
. . .
The Old IT applied automation to information; the New IT applies automation to relationships. The Old IT was about keeping records and transmitting data; the New IT is about "connecting and collaborating" to get work done--now that productivity doesn't require proximity.
. . .
It's not enough to organize human activities around information; it must be organized around the work itself. In the Industrial Age, human activities were organized around the assembly line; and in the Information Age, human activities are organized around information (the raison d'etre for functional management). In the emerging Process Age, where a company's business processes are key to effectiveness, it's now time to organize human activities around the work itself. That means fusing traditional collaboration and information tools and extending them with a complete theory of human work iif we are to build systems that can support the way people actually work, versus treating them as cogs in an information machine.
. . .
Xerox's former Chief Scientist John Seely Brown, is correct: "Processes don't do work, people do."

These are subjects near and dear to agility (supporting "people and interactions over processes and tools").

I'll talk about a recent book from John Seely Brown and John Hagel in my next blog-entry.

Extreme Competition: Innovation And the Great 21st Century Business Reformation

For a "hot off the presses" view of what one of the experts in the BPM and IT communities thinks about how the new "flattened" global economy will impact our industry, take a look at Peter Fingar's recent book "Extreme Competiton: Innovation and the Great 21st Century Business Reformation" (see the provocatively illustrated Executive Summary).

When Peter Fingar spoke at the October 2005 ABPMP meeting (which was hosted at the Galvin Center) he described his new book as trying to be a "wake-up call" for the US. With the new global economy, the US will no longer be at the head of the pack in the new knowledge economy of knowledge workers and the continuing dearth of interest in the US among younger folks to go into the software/knowledge engineering field will quickly put the US economy behind the pack.

This book tries to explain what the effects of Friedman's "flattened global economy" mean for our industry and how that all adds up to extreme competition and innovation engineering, with extreme globalization and extreme mass-supply chains making it possible for even the small shops to compete, and (from Clyde Prestowitz' book) the three billion new capitalists from the emerging markets in China, India and the former Soviet Union ready to take advantage of them.

So, what strikes fear in the hearts of business leaders these days? Globalization and Commoditization. We are not on the brink of a new world economic order, we've already cross that threshhold.

Fingar predicts that even what we today call innovation and "agility" won't be enough -- we'll need the "second derivative" of that, which is being able to quickly respond to change by continuously innovating and reinventing ourselves and our business processes (think of "extreme refactoring" and "continuous integration" but of an entire enterprise's business processes and supporting technology infrastructure).

We will need to focus on extreme collaboration and enabling human interaction in the customer experience as we involve the customer in our efforts. Tools and technologies to both involve/enable our customers and to enable our businesses will need to provide advanced and innovative human interaction management in order to allow us to globally and adaptively collaborate with agile responsiveness. In the era of the "always on, wired world", how can companies compete?

Operational innovation-where you forge new relationships across to globe to form extreme supply chains, pursue extreme innovation and collaborate with extreme specialists-is the next true source of competitive advantage.
. . .
Innovation is the new "holy grail" of business because with the whole world now a source of supply, your company must innovate to avoid becoming a commodity player that cannot make margins.

Fingar uses "connect and collaborate" as the catch phrase for how this new operational innovation will be accomplished. Being innovative isnt enough. To compete and dominate, you have to set the pace of innovation, and and connect and collaborate with such operational efficacy that your competitors simply cannot keep up with the pace of your "continuous innovation."

Then there is that matter of the scarcest resource, the most valuable resource--time. If you want to succeed today, you must become a time-based competitor. ... Being a time-based competitor allows you to earn solid margins be being responsive to your customers. Customers love responsiveness and, in turn, will reward you with loyalty and increased business. Being a time-based competitor allows you to be first-to-market where you earn the greatest premiums, and allows you to set the pace of innovations in your industry.

Fingar also notes that the kinds of innovations needed will be more service-focused rather than product-focused, centered on how you operate, how you deliver services to your customer, to create a "customer experience", and how you empower your customer with information to be "in control" of the whole process to demand what they want when, and at what price.

I'll be blogging more next month on various aspects of this book and some of the strong tie-ins to CM and Agility.

Three Billion New Capitalists: The Great Shift of Wealth and Power to the East

Next up on my continuing theme of globalization and collaboration is Clyde Prestowitz' book Three Billion New Capitalists: The Great Shift of Wealth and Power to the East...

Peter Fingar, in his book Extreme Competition refers to Prestowitz' book quite a bit. I haven't read Prestowitz' book myself, but from reading about from others and seeing the reviews of it on Amazon.com, I think one can get the basic idea. Some quotes there of interest ...

From Publisher's Weekly:

While China and India focus on trade and industrial policies and turn out competent workers who put in long hours at a fraction of American wages, the U.S., Preston argues, struggles with crushing trade and budget deficits, a zero savings rate, failing schools, dwindling investments in scientific training and research, a collapsing dollar and a debt-dependent economy that will face an "economic 9/11" once foreign creditors bail out... and argues cogently that the research and development apparatus and high-tech entrepreneurship that is supposed to save America's economy is likely instead to follow the manufacturing base offshore. It's a lucid and sobering forecast.

From BookList's Mary Whaley:

Prestowitz, economic trend-spotter, reports, "Over the past two decades . . . China, India and the former Soviet Union all decided to leave their respective socialist workers paradise and drive their 3 billion citizens along the once despised capitalist road." These new capitalists symbolize the threats to end 600 years of Western economic domination as America's lead role in invention and technological innovation lessens and the Internet allows jobs to be performed anywhere. The author foresees the possibility of an "economic 9/11," which won't kill but will cause great hardship. To prevent what he sees as an accident waiting to happen, Prestowitz offers a wide range of solutions relating to the dollar's role in today's global marketplace, addressing the reality that Americans consume too much and Asians save too much, and facing energy challenges in the U.S and problems confronting our educational system. The author offers valuable insight into these important topics currently being debated in government and corporate circles.

From Robert D. Steele:

His most important point is made in one line: America does not have a strategy. America does not have a strategy for winning the global war on terror, it does not have an energy strategy, it does not have an education strategy, it does not have an economic or competitiveness strategy. The government is being run on assertion and ideology rather than evidence and thought--a media cartoon has captured the situation perfectly: as the VP tells the President that we are "turning the corner" the two walls behind them are labeled Incompetence and Fantasy. As a moderate Republican and a trained intelligence professional with two books on the latter topic, I have to say that this book by this author, a Reaganite businessman and senior appointee in the Department of Commerce is right on target. We *are* out of touch with reality, and we do not appreciate, at any level from White House to School House, the tsunami that is about to hit us.

The author makes two important points early on in the books: first, that information is the currency of this age, replacing money, labor, and physical resources; and second, that the best innovation comes from the right mix of sound education across the board, heavy investment in research & development, and a co-located manufacturing bases that can tinker with R&D and have a back and forth effect. America lacks all three of the latter, and is not yet serious about investing in global coverage of all languages, 24/7.

The book goes into a lot more depth and detail about the Asian culture and economy, and chapter 12 has the author's list of recommendations for what the US needs to do (Steele says chapter 12 alone worth the price of the book).

This indeed seems to be an interesting book, and an interesting lead-in to the one I'll discuss next, Peter Fingar's Extreme Competition, which is another sort of call to arms for the business and software industries, and gives even more emphasis to collaboration and human interaction management.

End of the Line: The Rise and Coming Fall of the Global Corporation

Continuing the theme of globalization started in the previous blog-entry on Thomas Friedman's The World is Flat and how the internet & wireless technologies + mass accessibility gives us the 5th dimension that transcends time & space to give us the "virtual inverse of teleportation" ...

Barry Lynn's End of the Line : The Rise and Coming Fall of the Global Corporation picks up where Friedman left off and goes into more depth. He takes a somewhat alarmist view. He argues that with all this extra social and technical connectivity comes greater and more thoroughly enmeshed dependencies of businesses and economies upon increasingly more fragile and rigid "weak links" and little or no sufficient security (both in terms of computer security, and financial and economic security).

One example, an 1999 earthquake in Taiwan that registered 7.6 on the Richter scale and had a death toll of 2,400 was barely known to most Americans. But it "took out" two of Xilinx's semiconductor factories, and within days thousands of assembly-line workers located from California to Texas, were temporarily laid off. Wall street responded and shares of computer-makers like Dell, HP and Apple took a downward spike, and by Christmas "American shoppers were scurrying to avoid the shortages of laptop computers, Barbie cash registers and Furby dolls." (quoted from a reviewer at Amazon.com)

Lynn writes: "We must never forget that the germ of our global economy was the desire of the postwar governments to foster peace by forging cooperation."

He talks about transnational partnerships as a way of bolstering national security, and talks about supply chains, single-source risk, and logistics. In many ways it is about risk management (and its associated dependencies) and what that means in the flattened world of such delicate social and technical dependency networks, and how forging partnerships and collaboration helps safeguard against security threats.

The collaboration and trustworthiness themes should ring a familiar tune with many agilists, as should risk management. The dependency network being dealt with here is not the architectural dependencies of a software system design, but the sociotechnical network dependencies and economic risks. And diversity, single-sourced (localized/encapsulated) risks, redundant failover, and other strategies can be used.

I think he's basically saying that the flattened connected world economy is a complex adaptive system that exhibits emergent behavior to create unexpected order out of unanticipated chaos (and vice-versa). It's not as optimistic as Friedman's work and paints a lot of scary scenarios.

I have an even scarier one that's been occurring to me while reading all of these works: Bird Flu Pandemic. It doesn't even have to happen. It just has to be feared enough of being imminent enough soon enough that enough people start eschewing real human contact and interaction within any close physical proximity.

What will we do to stay connected? We'll resort to technology in place of the "human touch" and face-to-face communication. We'll be reclusive, stay within our homes. Wear gloves and masks when we have to go outside, do more online shopping (especially delivery) with extra safety and sanitation precautions on the part of ourselves and delivery persons, well ... you get the picture.

Talk about being able to spread damage instantly across a wide "social" network in a busy, bustling flattened world ... even when/if we do have a vaccine, we cant produce and distribute it fast enough at high-enough volume. Now if it were software or some form of nano-bio-technology, we could distribute it digitally and wirelessly some how. But that's a bit of a pipe-dream.

Or is it? How do you fight a virus that deadly that quickly? Seems to me something that spreads so fast like that ... one would have to "fight fire with fire." I'm no medical professional, so I have no idea if it's possible, but what if we could somehow make a "good virus" that was highly "contagious" and could be transmitted upon contact or close proximity. Maybe it could mutate bird-flu into something harmless, or less harmful (without mutating again). But it seems to me the only hope of being able to produce and distribute something of the scale necessary to combat bird-flu would be something that can be (re)generated and (re)transmitted much the same way as the thing it's trying to combat.

What might be an "agile" approach for something like that, that could rely upon collaboration and cooperative development?

The World is 5-Dimensional: Globalization and Teleportation

This will be the first of several blog posts on the subject of globalization and my thoughts on what it portends for CM and Agility ...

For those of us who haven't read Thomas Friedman's The World is Flat, here are a few resources to familiarize yourself with the basic gist of the material in short-order time:

• Why The World is Flat (with a short+sweet synopsis of the 10 great 'levelers'), by Dan Pink
• Wikipedia's entry on "The World Is Flat'
• It's a Flat World, After All, by the author
• An NPR Interview with author Thomas Friedman

The book is about globalization and how technology (and other "levelers") have "leveled the playing field" for so many others in (formerly) thirld-world countries to compete with "the big boys."

I think the book is, in part, saying that mass availability of technologies like the internet and Wireless connectivity, have provided us with the "inverse" of teleportation. The mass availability and accessibility of the internet and its pervasiveness into the everyday life of businesses and individuals is essentially the virtual inverse of teleportation: instead of being able to send ourselves anywhere, instantly, we have the ability to virtually summon anything from anywhere to wherever we are!

Okay, so we've only be able to do that digitally, with the mass commoditization of the internet and wireless technologies. We can do it with information and data, but not physical objects. But we can still connect with people anywhere instantly!

In terms of business, the world is "flat", but in terms of technology, we're basically saying The World is now 5-Dimensional!

The traditional 4 dimensions are the three spatial dimensions (height/length, width, depth) , and time. Friedman is saying that these "flatteners" have occured. Of course the world isnt really flat (we know it's round), but what I perceive him to be saying is that a new "dimension" has emerged that now allows us to come pretty darn close to bypassing the traditional constraints of time and space.

This 5th dimension is technology plus mass accessibility! Each of the "flatteners" Friedman describes is a form of technology that allows information, communication, and collaboration to transcend the traditonal time-and-space boundaries of the physical world. And the internet (the "virtual world") is a big part of that 5th dimension. But we did't make it to that 5th dimension right away. It wasnt until everyone and their mother in this country, and all the other countries we economically compete and partner with, had access to that technology (and used it!)

Friedman calls this Globalization 3.0. Whereas Globalization 2.0 was centered around business, the increased pervasiveness of the internet into daily lives and gadgets gas created Globalization 3.0, which centers around individuals. I wonder if globalization 4.0 might be achieved when we finally perfect virtual teleportation and have the ability to project our own virtual presence (not just a "holographic image" but many of our our five senses) to interact with that of others. (That sounds a little too much like the Matrix for my taste.)

Here some interesting reviews and commentary on Friedman's book:

• Why Bill Gates beleives the World is Flat
• Wake up and face the flat earth!, an interview with the author by Yale Global Online
• The Great Leveling, a review by Warren Bass of the Washington Post
  
• The Polarised World of Globalisation (A Response to Friedman’s Flat Earth Hypothesis)
• Gloablization is Great, Sort of, a review from BusinessWeek online
• The World is Clustered, a review by Lisa Haneberg, of the Management Craft blog
• A review on IBM DeveloperWorks from an IT-perspective

Over the coming weeks, I'll be musing more on what this might mean for the future of CM and Agility, and I'll be commenting on several related books on the topic:

• End of the Line : The Rise and Coming Fall of the Global Corporation, by Barry C. Lynn
• Three Billion New Capitalists: The Great Shift of Wealth and Power to the East, by Clyde Prestowitz
• Extreme Competition: Innovation And the Great 21st Century Business Reformation, by Peter Fingar
• The Only Sustainable Edge: Why Business Strategy Depends on Productive Friction and Dynamic Specialization, by Hagel and John Seeley Brown (also see the Edge Perspective's blog)
• Whole New Mind, by Dan Pink (also see Dan Pink's blog)

Unchangeable Rules of Software Change - Redux

I put together a couple of my earlier blog-entries on the topic of software change and iterative development and developed them into an article in the February 2006 issue of CMCrossroads Journal. The article is entitled The Unchangeable Rules of Software Change (just like the earlier blog-entry) and updates some of what I had blogged about earlier.

In addition to the first three commonly recurring pitfalls encountered when first faced with the reality of these "unchangeable rules", I identified three additional pitfalls that typically occur when first attempting iterative development. It also has a few more iterative development resources than my previous follow-up blog-entry. Lastly, I expanded the rule-set by one, adding the "quicksilver" rule to the "quicksand" rule as noted below:

The Unchangeable Rules of Software Change

Rule #0: Change is Inevitable!

The Requirements/Plans ARE going to change!

Rule #1: Resistance is Futile!

There isn't a darn thing you can do to prevent Rule #0.

Rule #2: Change is like Quicksand -- Fighting it only makes it worse!

The more you try to deny and defy rule #1 by attempting to prevent rule #0, the worse things will get.

Rule #3: Change is like Quicksilver -- Tightening your grip makes it slip from your grasp!

The more you try to deny and defy rule #2 by attempting to precisely predict, or rigidly control change, the more erratic and onerous the result will be.

Rule #4: Embrace change to control change

The more flexible and adaptive you are at accommodating change, the more control you will have over your outcomes

You can read the whole article here!

More SCM Blogs

In my last blog-entry of 2005, I posted a list Software CM and Version-Control Blogs and asked for others that any of you recommend. I know of a few more now:

Austin Hastings now has a blog! Check it out at Doing Better!

Austin is incredibly knowledgeable about CM and architecture, and I also think he's not only much more concise than I am [I'm (in)famous for being verbose] but he's also a lot more insightful and much more quickly sees the 'whole' system and gets at the crux of the matter. I'm expecting great and inspiring things from this blog, and judging from his entries on Defining Baseline and Table Data Gateway, I won't be disappointed!

Kevin Lee has a forthcoming blog!

Okay - so it's not quite a blog yet. But it supposedly will be very soon. Kevin has a forthcoming book on Continuous Integration using ClearCase, ANT, and CruiseControl that looks to be pretty good. And he has some nice articles and downloads from his "buildmeister" website.

Rob Caron writes that Robert Horvick started a blog about Team System's version control features and API

Agile IT Organization Refactoring?

On the agilenterprise YahooGroup, someone asked for advice about how to structure the whole enterprise/organization, including core competencies for development, support, testing/QA/V&V, business/marketing analysts, systems engineering/architecture, deployment, PMO, CM, IT, etc...

I asked if he was looking for things like the following:

• Configuring the Agile Organization
• How to Build an Agile IT Department
• Design Principles for Highly Adaptive Business Systems (and a companion article)
• Social Network Analysis
• Organizing the Agile Company
• Agile Methods for Large Organizations - Building Communities of Practice
• Show Them How (article from CIO Magazine)
• Dion Hinchcliffe's article.entry on Post-Modern Enterprise Architecture: Service-Oriented, Agile, Decentralized

Mishkin Berteig wrote that he thinks that "this is one of those places where Lean and Agile really start to blur into one-another via queuing theory." I mentioned that I think Theory of Constraints (TOC) also blurs-in with Agile and Lean via queuing theory as well, as evidenced by the work of David J. Anderson.

Mishkin also wrote:

"The answer is that in a lean portfolio management situation this is a mandated constraint for projects. Projects simply are not approved unless they are able to fit inside that timebox. If you have a larger project, you must break it into two.... and you must not make it fit by making a larger team.... which leads to the other side: all teams should be roughly the same size, team composition should change very slowly, and people should be dedicated to a single team at a time."

I replied that, rather than the above, the practice of "pairing" and "refactoring" might actually scale up by refactoring people across projects and teams every 3-6 months. I'm thinking about the case of an IT department that supports several so called "products", and in any 3-6 month period, they of course get requests against those projects, as well as requests for new projects.

Now, not every request and/or project has the exact same priority. So having each project or product prioritize it's backlog and then work on whatever "fits" into the next iteration sort of assumes that each project has the same priority (if all the teams are more-or-less the same size and experience mix).

If, instead of each project/product separately prioritizing it's backlog, they might instead do something like:

• Form a combined backlog list across the entire department
• Have representatives [governance] from each customer organization in the enterprise meet, and prioritize the department-wide backlog list
  
• And whatever shows up as the topmost requests that can be handled in the next financial quarter with the available staffing is what gets worked.

If that means that some projects or products get more of their requests worked on in that time-frame, then so be it. And people might be "refactored" across teams and projects within the department, adding more staff to "feed" the projects that have the "lion's share" of the most highly prioritized requests from the backlog.

Wouldnt that be essentially creating a "pull" system for "allocating resources" to projects?

If pairing were used, it would help the "refactored" folks come up-to-speed more quickly on the new product or project. And after awhile, I'd think most folks in the department would have a reasonably high knowledge level and awareness (and appreciation) about all the "important" projects going on in the department, and understand the overall "business" big-picture a little better (at least for that department).

That would still seem agile to me. It looks similar to some matrixed approaches, but I think its a bit different because it is more fine-grained and incremental. I'm thinking it would help "scale" a single agile project and team into an overall "agile" department servicing an entire portfolio of projects, and making sure that those projects that are most valued for the given quarter get the appropriate amount of resources relative to how the "Customer" prioritized the backlog across the entire portfolio.

Wouldn't it? Or would team-dynamics and other people-issues make it too darn hard to incrementally rotate/refactor people in that manner?

Isn't this also an example of using the Five Focusing Steps of TOC? (Would this be an example of a team/project constraint elevated to the level of the department and using dynamic allocation of the entire department's staff to subordinate to the constraint and place the most staff on the projects with the most valued requests?)

Resources on Color Modeling

As a follow-up to my previous blog-entry about Agility, MDE, and how perhaps FDD and Color Modeling could be the missing link (with the latter being the equivalent of Refactoring to Patterns, only for models instead of code), here are some more resources on Color Modeling:

• Wikipedia page on UML Colors
• A History of Color Modeling
• Peter Coad's descriptions of feature-sets and color modeling patterns including a color modeling overview, and Archetypes, Color, and the Domain-neutral Component
• Color Modeling and The Law of Demeter, by David J. Anderson
• Whole Part Relationships in Color Models, by David J. Anderson
• Arguments about Color, by Daniel J. Vacanti
  
• The Coad Letter: Modeling and Design Edition, Issue 68, a New Beginning
• The Coad Letter: Modeling and Design Edition, Issue 44, Strategies -- Boundary; Colors; Time Line; Status
• Other "Coad Letter" articles related to Color Modeling
• An excerpt from "Object Modeling in Color with UML"
• UML Color Modeling with Archetypes
• UML in Color to UI Design : White Paper : uidesign.net
• the recently created colormodeling YahooGroup

Also see the EpoWiki "Agile" Page for a great page of resources on "Agile" in general.

Agile vs MDE: XP, AMDD, FDD and Color Modeling

The February 2006 issue of IEEE Computer is devoted to Model-Driven Engineering (MDE). MDE is actually a bit broader than MDA/MDD, because MDE (allegedly) covers more of the lifecycle, and corresponding process and analysis. Doug Schmidt's Guest Editor's Introduction to MDE is a pretty good overview of the current theory and practice and the obstacles to overcome.

A co-worker of mine is very interested in combining Agile methods with Model-Driven Engineering. He feels that the benefits of agility and of model-driven code-generation show tremendous promise as a breakhrough combination in productivity and quality and he is stymied that there aren't a lot more folks out there trying to do it.

He attended UML World in June 2005 and had some discussions with Scott Ambler (AgileModeling), Steve Mellor (co-creator of the Schlaer-Mellor OOAD method, and co-author of "Agile MDA", Executable UML and MDA Distilled), and Jon Kern, Agile MDA Evangelist (who helped Peter Coad launch TogetherSoft). He found most of what they had to say supported the possible synergy between Agility and MDA, but was very surprised to see AMDD folks and XP/Scrum folks throwing away their models once they had the code for it.

Upon hearing the above, I noted that Peter Coad is quite possibly the missing link between MDE and Agility:

• Coad created the agile method known as Feature Driven Development (FDD) as well as the field of "Color Modeling" with UML.


• Like MDE and MDA, FDD is very focused on domain-modeling, and using the model (rather than the code) as the primary form of "capture" for communicating knowledge about the system. [See my article "FDD is Football-Driven Development (and XP is Rugby)" for an explanation.]


• The TogetherSoft tool-suite was allegedly tailor-made to be an "Agile IDE" of sorts to facilitate doing FDD and Color Modeling.

The potential mismatch between MDA, with AMDD and XP-like Agile methods, is that:

• Full/pure MDA strives for 100% generation of all code and executables directly from the models.


• Ambler's AMDD, and "domain modeling" espoused by the likes of Robert Martin, Martin Fowler, and others in the XP community strives for "minimal, meaningful models", where they model only as needed, as a means of gaining more understanding, and then embed the knowledge gained into the code and/or tests.

I beleive FDD has the potential to bridge the gap. It strives for a comprehensive domain model, but from that point the code is written by hand (using coding practices that are traditionally non-Agile in nature, including strict-code-ownership, and formal code reviews/inspections). FDD doesn't say anything about using MDA/MDD techniques to auto-generate code, but the method is extremely amenable to doing exactly that.

Furthermore, doing so would remove a lot of the manual parts and practices of FDD that many consider to be the least "Agile". And much of the FDD "Color Modeling" patterns and techniques are very much the equivalent of refactoring and design-patterns that are currently used for code. See the end of this message for some more resources on Color Modeling.

In my own humble opinion, I think the "sweet spot" is somewhere in between 100% code generation and "hand-crafted" code. I realize that 100% is the ideal, but I'm thinking about the 80/20 rule here, and whether trying to eliminate that last 20% is perhaps not always practical.

I think the biggest barrier to doing that today is tools:

• The modeling tools are good at handling the structure, but not as much as the behavior.


• High-level programming languages like Java and C# and their IDEs are more convenient for specifying behavior (which is still largely textual in UML 2 and Action-Syntax Languages).


• It is extremely difficult to maintain the non-interface code for a "class" or "package" unless it is either 100% manually coded or else 100% auto-generated. If it is 50-50, or even 80-20, then the "nirvana" of seamless and reversible round-trip design to code and back just isn't quite there yet.

What would get us there and help close that gap? I think the "melding" of the IDE with the modeling tool is what is needed - and it would have to allow specifying code such as Java or C# as opposed to only allowing ASL "code" (most of which looks pretty darn close to Java and C# anyway :) as well as a means indicating if/how a chunk of code was auto-generated or if it was to be hand-crafted, but "navigable" and editable via the Model.

The Eclipse framework shows a lot of promise in helping us get to that point, and has a lot of the groundwork and building blocks already in place, but still has a lot more work to be done.

I hear some of you saying, "Okay Brad, I see what this has to do with Agility. But what does this have to do with CM?" Well, in my January 2005 Agile SCM column, among other "crystal-ball gazing" predictions, I talked a little about "Model-Driven CM" and how it would resurrect the once popular SCM research-area of Software/System Configuration Modeling:

• MDE/MDA would readily lend itself to allowing the developer to focus on the logical structure of the code, letting the physical structure (files and directories) be dictated by the code-generation tool with some configuration scripting+profiles.


• This in turn would allow models and modeling to be easily used to analyze and design the physical structure of the code, including build & configuration dependencies.

Of course, we have a ways to go until we get there, but I do believe the trend is on the rise and it's only a matter of time.

Some other resources related to Agility and MDE:

• Anyone going to EclipseCon2006 to see Agile Application Development with Eclipse and Pragmatic MDA
• Hans Wegener's Agility in Model-Driven Software Development? Implications for Organization, Process & Architecture
• Andreas Voelter's Patterns for Incremental/Iterative MDD
• Martin Fowler's Language Workbenches and MDA
• IEEE Software Oct 2003 Point/Counterpoint" on MDA -vs- MDD
• Jorn Bettin, on the Practicalities of Implementing CBD and MDA and where Agile fits in the picture
• Dion Hinchcliffe's Domain-Driven Design: MDD Done Right?
• Alan Cameron Wills' Agile Components - Scaling XP
• A 2004 Workshop on Graph rewriting for Model refactoring in MDE/MDA, sponsored in part by:
• Scientific Research Network on Foundations of Software Evolution
• A Formal foundation for Software Refactoring
• Architectural Resources for the Restructuring and Integration of Business Applications (ARRIBA)
• Research Center on Structural Software Improvement
• The Program-Transformation.org Wiki-Web and Homepage
• And lastly, Jeff Sutherland writes of Charles Simonyi's latest effort, Intentional Software:
  

  "Simonyi’s vision, and the reason he started his company, is to take the idea of models and go one step further: to link the model and the programming so tightly that they eventually become the same. Programmers and users will be able to switch between many contrasting views of the model they are creating, and revise programs at will simply by tweaking the models (see “Just-in-Time Programming,” below). It’s something like an architect being able to draw a blueprint that has the magical property of building the structure it depicts—and even, should the blueprint be amended, rebuilding the structure anew."

Book Review: Practical Development Environments

Matthew Doar's Practical Development Environments (PDE) looks to be a pretty AMAZING book. It really does cover the entire lifecycle of development environment tools for version control, build management, test tools, change/defect tracking, and more. My previous favorite work on this topic was the Pragmatic Programmer's Pragmatic Project Automation (PPA), but no more.

The PPA book is still a GREAT book! And it focuses a lot more on programming and automating tasks and good ways to go about doing it. It goes into some of the details of particular tools and setting them up, especially JUnit.

But the PDE book is far more comprehensive in the range of development environment practices and tools that it covers, including not just the automation aspects, but evaluating them, setup and administration, integrating them together (and issues and challenges encountered), and many more aspects of testing, building, project tracking, version controlling, and just generally helping the development team get work done with maximal support and minimal hindrance from the tools they use.

If you want to be a toolsmith, and learn more about scripting and automating tasks and some of the common tools that already exist, then I'd still recommend Mike Clark's Pragmatic Project Automation.

If you're focus is less on how/when/why to automate and more on evaluating, setting-up and maintaining a practical development environment for your team, then Matthew Doar's Practical Development Environments is definitely my top pick nowadays!

Book Review: Perl Best Practices

As far as I'm concerned, Damian Conway's Perl Best Practices book should be required reading for any serious Perl programming, and should be mandatory for any team that does any serious Perl development. These best-practices and conventions are exactly the sort of thing that programming teams need to come to grips with, and establish shared norms for how to make their codebase clear and "clean."

Next time I come across a team of Perl scripters that needs to develop a set of team standards and strategies for how to do thse kinds of things, I'm simply going to tell them to get this book: read it together, discuss it, learn it, understand it, and then do it!

O'Reilly Book Reviews

I received a whole slew of books from O'Reilly to review, so I'll be writing about them in a subsequent review either on this blog or in separate articles. The one's I'll be reading through are:

• Practical Perforce, by Laura Wingerd
  
• Perl Best Practices, by Damian Conway
  
• Perl Testing: A Developer's Notebook, by Ian Langworth, chromatic
• Advanced Perl Programming, 2nd edition (completely revised), by Simon Cozens
  
• SQL Cookbook, by Anthony Molinaro
  
• Practical Development Environments, by Matthew Doar
  
• Applied Software Project Management, by Andrew Stellman and Jennifer Greene
  
• Producing Open Source Software, by Karl Fogel
  
• UML 2.0 in a Nutshell, by Dan Pilone and Neil Pitman
  
• Java in a Nutshell, 5th edition, by David Flanagan
  
• Java Enterprise in a Nutshell, 3rd edition, by Jim Farley and William Crawford
  
• Prefactoring, by Ken Pugh
  
• Essential Business Process Modeling, by Michael Havey
  

Watch this space! I've already been making my way through Perl Best Practices, and it looks quite good. The other one I'll be doing soon is Practical Development Environments, which looks like it might give the Pragmatic Programmer's Practical Project Automation more than a run for it's money.

Iterative Development Resources

As a follow-up to my earlier entry on The Unchangeable Rules of Software Change, one of the things that particular team figured out it needed was to try and use iterative development as a means of managing change and being more responsive to customer feedback while still controlling scope.

Of course, saying "do iterative development" is one thing. Figuring out how to actually do it for a group in an organization that isn't accustomed to it is another thing entirely. So here is a list of resources on the subject of adopting, planning/managing, and doing iterative software development -- particularly for those coming from a background of phased-sequential (waterfall,V) model of planning.

Iterative Development Resources:

• Wikipedia page on Iterative Development


• Iterative vs. waterfall software development: why don't companies get it? , Bill Walton, Computer World, Feb 2004


• Craig Larman and Vic Basili's paper in IEEE Computer, June 2003: Iterative and Incremental Development: A Brief History, and presentation slides for History and Evidence: The Evolution of Agile, Iterative vs Waterfall


• Also from Craig Larman, Iterative and Evolutionary, from Ch 7 of the book Agile and Iterative Development: a Manager's Guide


• Overcoming cultural challenges in adopting iterative development , by Clay Nelson, The Rational Edge, October 2004


• Philippe Kruchten's article From Waterfall to Iterative Development: A tough transition for project managers (Rational Edge, December 2000) and Going Over the Waterfall with the RUP (Rational Edge, April 2004)


• Per Kroll's Transitioning from Waterfall to Iterative Development (Rational Edge, April 2004)


• Joe Marasco's Iterative Development, from the book The Software Development Edge: Essays on Managing Successful Projects


• Brian G. Lyons' Managing Requirements in an Iterative Lifecycle


• Kurt Bittner's What is Iterative Development? Part III: The Management Perspective (also see Part II: the Customer Perspective , and Part I: The Developer Perspective), from the Rational Edge, Mar-May 2005


• Effective Governance practices for iterative software development, Mark Lines (Rational Edge, Feb 2005)


• Iterative Software project planning and tracking , Johanna Rothman


• Heuristics for Iterative Software Development, by Drako Sotirovski, IEEE Software May/June 2001


• Involving Customers Early and Often in a Software Development Project, Laura Rose, Rational Edge, January 2006


• Iterative Software Development - a Practical View, by Morten Korsaa et.al., from DF-16 (Datateknisk Forum), Denmark 2001 (and some very nice accompanying presentation slides)


• A Report of Development Lifecycle Methodologies Compared


• Controlling Iterative Software Development projects - The Challenge of Stakeholder & Technical Integration , by Bendik Bygstad, ICSS2004 proceedings


• Using Iterative and Incremental Development Processes in Global Software Development, from the 3rd International Workshop on Global Software Development , May 2004


• COCOMO-based effort estimation for iterative and incremental software development , Oddur Benediktsson et.al., Software Quality Journal, Nov 2003


• Tool support for iterative, adaptable, and agile software development methodologies, by Scott Henninger, 2002 ICSE Workshop on Iterative, Adaptable and Agile Processes


• Timeboxing - a process model for iterative software development , by Pankoj Jalote, from 2003 Journal on Systems and Software (also see ICICT 2005 paper on Using Defect Analysis Feedback for Improving Quality and Productivity in Iterative Software Development)

Kandt's SCM Best-Practices: Tool Practices

More from the paper Software Configuration Management Principles and Best Practices, by Ronald Kirk Kandt, appearing in the Proceedings of PROFES2002, the 4th International Conference on Product-Focused Software Process Improvement, Rovanieme Finland, December 2002.

In this article, Ronald Kandt describes ten basic principles that support configuration management activities, and then goes on to describe twenty three "fundamental" practices, which are split across the categories of: Management Practices, Quality Practices, Protection Practices, and Tool Practices.

In this entry, I'll enumerate Kandt's Tool Best-Practices for SCM (in priority order, with the most important ones listed first):

Practice 19:

Check code in often

Kandt goes on to explain "This practice should be constrained when checking in code on the primary development branch. That is, developers should only check in working versions of code to a [primary] development branch."

The main reason given is to ensure against loss of change by making sure the code is in the repository. So although initially it might seem this practice is about committing in small talks (which I'm sure Kandt would approve), that doesn't appear to be what he's emphasizing. This really seems to be about frequent use of "Private Versions" and then, before doing a Task-Level Commit, making sure one does a Private Build and runs Unit Tests and Smoke Tests as part of the Codeline Policy.

In other words: "If it ain't checked-in, it don't exist!"

Practice 20:

Configuration management tools should provide patch utilities

The stated benefit here is to support incremental release/deployment and also remotely submitted changes over slow telecommunication connections.

Practice 21:

Do not work outside of managed workspaces

Seems like the "Private Workspace pattern to me

Practice 22:

Do not share workspaces

This is sort of reinforcing that the workspace should be private rather than shared. Having said that, while I agree shared workspaces (not include Pair-Programming) shouldn't usually be the norm, I have seen cases where it can work quite well.

In order for this to work, there must be an explicit "protocol" agreed upon up-front by all the contributors to decide who doing what, when, and to what (not just who is modifying which files when, but who is building what else and when) and/or how to rapidly communicate who is doing what when. See also work by Andre van der Hoek et.al. on Continuous Coordination: A New Paradigm for Collaborative Software Engineering Tools and related work on the "Palantir" project.

Practice 23:

When developing software on a branch other than the primary branch, regularly synchronize development with the development branch

This seems like mainlining (the Mainline pattern) and rebasing (a.k.a. Workspace Update). Only I would say that regularly synchronizing should apply to private workspaces/sandboxes even when they aren't using a private or task branch. The more general rule would seem to be the Continuous Update pattern.

Th-th-th-thats all from Mr. Kandt's list of 10 SCM principles and 23 SCM best-practices!

Kandt's SCM Best-Practices: Protection Practices

More from the paper Software Configuration Management Principles and Best Practices, by Ronald Kirk Kandt, appearing in the Proceedings of PROFES2002, the 4th International Conference on Product-Focused Software Process Improvement, Rovanieme Finland, December 2002.

In this article, Ronald Kandt describes ten basic principles that support configuration management activities, and then goes on to describe twenty three "fundamental" practices, which are split across the categories of: Management Practices, Quality Practices, Protection Practices, and Tool Practices.


In this entry, I'll enumerate Kandt's Protection Best-Practices for SCM (in priority order, with the most important ones listed first):

Practice 15:

Use a software system to perform configuration management functions

Also known as: "Use an SCM tool!"

Practice 16:

Repositories should exist on reliable physical storage elements

Practice 17:

Configuration management repositories should be periodically backed-up to non-volatile storage and purged of redundant or useless information

Practice 18:

Test and confirm the backup process

Is there really anything here to argue with? (I didn't think so :-)

Oh, and that #18 is one that is often overlooked. I can't tell you the number of times I've come across folks that think there stuff is safe "cuz it's backed-up," but their backup process didn't confirm that they were able to successfully read/extract the data that was archived.

Next up, we'll look at what Kandt identifies as Tool practices in his list of 23 SCM best-practices.

Kandt's SCM Best-Practices: Quality Practices

More from the paper Software Configuration Management Principles and Best Practices, by Ronald Kirk Kandt, appearing in the Proceedings of PROFES2002, the 4th International Conference on Product-Focused Software Process Improvement, Rovanieme Finland, December 2002.

In this article, Ronald Kandt describes ten basic principles that support configuration management activities, and then goes on to describe twenty three "fundamental" practices, which are split across the categories of: Management Practices, Quality Practices, Protection Practices, and Tool Practices.


In this entry, I'll enumerate Kandt's Quality Best-Practices for SCM (in priority order, with the most important ones listed first):

Practice 8:

All source artifacts should be under configuration control

Practice 9:

Use a Change-Control Board (CCB)

Practice 10:

Build software on a regular, preferably daily, basis, followed by invocations of regression test suites

Practice 11:

Document identified software defects

Practice 12:

Software artifacts that comprise a release should adhere to defined acceptance criteria

Practice 13:

Each software release should be regression tested before the test organization receives it

Practice 14:

Apply defect repairs to every applicable release or ongoing development effort

Most of folks in the "Agile camp" and in the "CM camp" would probably consider most of these to be "no brainers." The ones that Agilists might pick nits with are 8, 9, 11 and 14.

Control Contrarians and Wooden "Boards"

For 8 and 9, I don't think you'll find any agile folks recommending against the use of a version control system/repository. They would likely take issue with the appropriate meaning of "control." The words "control" and "change control" often set off sirens and red-flags for many agilists. And with good reason - they all too often see control attempted in a way that stifles developers and imposes highly restrictive waiting and redundancy for authorization/permission to do things; and they often see it executed as a means of preventing change instead of embracing it (see The Unchangeable Rules of Software Change).

Agilists also don't like the term CCB. Not only does the word "control" raise hackles (as already mentioned), but the term "Board" doesn't mesh very well with Agile values and perspectives on the whole concept of "team": a "board" conjures images of people isolated from the day-to-day workings and workers of the project. In reality, iteration planning meetings basically fill the CCB function for most agile projects because the iteration is usually small enough that there just isn't time to introduce new requirements within the iteration's timebox, so it's usually deferred to the next iteration.

Bugbases and Human Faces

There are many agilists who will rail against using a change/defect tracking tool. They say things like: there shouldn't be enough defects to warrant a bugbase (as opposed to a spreadsheet); rather than documenting and describing them in a database, we should just go fix 'em instead; index cards are a better for recording the bare essentials and promoting conversational dialogue and two-way face-to-face communication; tracking systems dehumanize communication and are too easily misused to the effect of hindering rather than facilitating dialogue and collaboration.

I understand all of these remarks and concerns. And while they all raise valid points, my own position is different. I consider a basic defect/issue/enhancement tracking (DIET) system to be every bit as essential as a version control tool. I still use index cards as a means of initiating dialogue and eliciting/capturing resulting needs and constraints. But then I put them into the tracking tool. Maybe if my handwriting were more legible the cards would be comprehendible enough to others, but I still think it's much more useful and convenient for tracking, organizing, sorting, searching, status accounting and generating reports (even if they just get posted to a local "information radiator").

I also think information about defects should be captured in order to identify and understand possible trends and root-causes, as well as provide evidence and history to consumers and customers (especially those requiring formal support/service-level agreements).

I do think a lot of change control implementations (and resulting tool customizations) make things harder on developers than needed, for the sake of convenience to other roles. I think that's what leaves the bitter taste in many agilists mouths and why they dislike it so much - because it holds them back and/or diverts them away from what they feel is most important: delivering value to the customer in the form of tangible, tested results. I think that's a shame because I think it doesnt' have to be that way. A few tracking tools are gaining popularity in the Agile arena, like VersionOne, and Jira.

The Monstrosity of Multiple Maintenance

Okay - I don't think that any agilists will say that a defect shouldn't be fixed in all applicable release. What they will say is that they would first do everything in their power to have one and only one mainline of development. Branching a new mainline to support a legacy release or a market/platform/project-specific variant is anathema for most agilists: it creates redundancy among code-streams (fixes have to be applied and integrated more than once) and splits the value-delivery stream into isolated streams/teams of diminished capacity.

Agilists would prefer to see a solution at a later binding time that uses design patterns of software architecture, building/releasing, licensing/distribution, & install/upgrade rather than patterns of version branching. For the most part I agree with them, but I am less wary of branching in the case of parallel development (because I know how to do it really effectively), and I am perhaps more accepting of the case of multiple releases (but I would still fight like heck against multiple variants :-)

Next up, we'll look at what Kandt identifies as Protection practices in his list of 23 SCM best-practices.

Kandt's SCM Best-Practices: Management Practices

More from the paper Software Configuration Management Principles and Best Practices, by Ronald Kirk Kandt, appearing in the Proceedings of PROFES2002, the 4th International Conference on Product-Focused Software Process Improvement, Rovanieme Finland, December 2002.

In this article, Ronald Kandt describes ten basic principles that support configuration management activities, and then goes on to describe twenty three "fundamental" practices, which are split across the categories of: Management Practices, Quality Practices, Protection Practices, and Tool Practices.


In this entry, I'll enumerate Kandt's Management Best-Practices for SCM (in priority order, with the most important ones listed first):

Practice 1:

Maintain a unique, read-only copy of each release

Also known as: create an immutable release label

Practice 2:

Control the creation, modification, and deletion of software artifacts following a defined procedure

Also known as: use version control, and agree on how you'l be doing it -- for example by identifying which SCM patterns you'll be using and their specific implementation in your project's context

Practice 3:

Create a formal approval process for requesting and approving changes

Also known as: manage change/scope, preferably by managing expectations rather than by trying to prevent change

Practice 4:

Use Change Packages

This one is more than just task-level commit, it builds on task-level-commit to provide task-based-development

Practice 5:

Use shared build processes and tools

We wrote about this in our October 2003 CM Journal article on Agile Build Management and it's March 2004 successor article on Continuous Staging

Practice 6:

A version manifest should describe each software release

This is more than just a self-identifying configuration listing of files and versions. Kandt also intends it to mean identifying the set of features, fixes, and enhancements too, as well as all open problems and issues. This is often included in the release notes for a new release. It also relates to the information necessary to satisfy a configuration audit.

Practice 7:

Segregate derived artifacts from source artifacts

Also known as: know your sources from your targets! Often times, the versioning/storage strategies used for the two may differ. (Of course, that's not the only reason to segregate them.)

Next up, we'll look at what Kandt identifies as Quality practices in his list of 23 SCM best-practices.