Simple ain't Easy: Myths and Misunderstandings about Simplicity

Obviously not all of us have the same idea of what Simple or Simplicity actually mean, specifically in the context of system design (including software, and processes). Here are some common misunderstandings that I frequently encounter about the meaning of "simple design":

"Simple" is not the same thing as "easy to do/understand."

Sometimes something that is "simple" is easy to do or easy to understand. Whether or not it is easy, is often more closely related to how familiar or intuitive it is. Eventually, it may be quite simple to do or understand. But initial attempts to do or understand it may be anything but easy!

The simpler solution may require us to learn something new, and think about something in a way that hasn't occurred to us before. Closed-minds will often close-doors on new ideas (simple or otherwise) because they simply don't want to entertain changing their current views and beliefs.

"Simple design" is not the same thing as "simple to develop/deploy."

If it's simple from the get-go, then it may perhaps be simple to develop/deploy. If the solution is already in place, then making it simpler may involve changing a lot of minds/behaviors as well as a lot of the system, and both of those may be anything but easy to do (especially changing minds/behaviors).

"Simple" is not the same thing as "good enough!"

Put another way, Simplicity != Sufficiency. "Good enough" has more to do with whether something is sufficiently workable "for now" while still fostering subsequent improvement or refinement for later. That doesn't mean the deployed result is simple/simpler; it just means we may be better served by getting to that point in an incremental and evolutionary (emergent) fashion.

In order for that to be true however, it means that the partial/incremental solution must be easy to subsequently change in order to refine and improve!!!

If I install something that is incomplete with the intent of making it more complete, and if it is very hard/painful to change, then I may end-up with the current-state-of-affairs for a number of IT solutions and business-processes: short-sighted, insufficient solutions that the organization defends, and chooses to suffer and impose on others because they don't want to suffer the impact of the change that could bring about relief from the suffering they have become accustomed to living with.

"Simple" is not the same thing as "simplistic!"

A simplistic solution often does not work! One definition of "simplistic" might be the false appearance of simplicity. It's not enough to seem/appear simple. It also has to work (successfully) in order to actually be simple!

Many times someone will discard or exclude a suggestion because it introduces something additional or new into the current design, and they don't want to add anything more/new in the name of simplicity, but they may be being simplistic instead. If the new/added thing is a rightful part of the problem that needs to be solved, then its introduction is correcting an act of omission in the solution design that neglected something essential in the problem-domain.

Sometimes we exclude things that we don't want to see (in the name of simplicity) which are nonetheless a real-world element of the problem we need to solve. Dismissing them in the case where ignoring them has failed to solve the problem, is not simplicity; it is ignorance. It is okay to want something that is "stupidly simple," but not at the expense of being simply stupid!

If the result doesn't do what it's supposed to do when it's supposed to do it, it may seem simple, but, as Gerry Weinberg points out, it's likely that something crucial to the problem statement was omitted or misunderstood either in the design, or in the problem statement itself.

What is "simple" for one request may not be "simple" for the whole!

When faced with a single, seemingly simple request to enhance a system, the requestor may want the specific solution to be simple for their particular situation and perspective (this is sometimes called "point-based thinking"). But what usually needs to be simple is the resulting overall system. Making it simple from one view or situation may just compromise other parts (and stakeholders) of the system. That's not eliminating complexity; it's not even "sweeping it under the rug"; it's just sweeping it onto someone else's doorstep.

Note how a lot of these myths/misunderstandings are more about resistance to changing our thinking/behavior than about being simple.

The Agile Manifesto defines simplicity as "maximizing the amount of work not done." But I think that's a more accurate characterization of Lean than of simplicity.

Recently, I looked though a number of sources of information about what is the meaning of "simplicity" and what are its principles, and I came across a number of interesting resources:

• A Forrester report on The Power Of Simplicity In Application Development
• The MIT Media Lab's SIMPLICITY Project and
  Maeda's Thoughts on Simplicity Blog
• Principles of Design from the W3C
• Principles of Landscape design, including Simplicity, Variety, Balance, Emphasis, Sequence and Scale.
• KISS Principles for Object/Relational DB Mapping
• An essay on Elegance and Simplicity & Scale
• Wikipedia entry on Occam's Razor
• The entry on "Simplicity" from the Stanford Encyclopedia of Philosophy
• University of Wisconson's webpage on Simplicity, Unification, Parsimony, and Occam's Razor in Science
• An essay entitled The New Science of Simplicity
• Edward DeBono's principles of achieving simplicity
• a DM Direct special report entitled A Simple Plan: Embracing Simplicity Can Reap Huge Business Intelligence Benefits
• a paper on the Simplicity Principle in Human Concept Learning
• Some Design Principles for Simplification from the SAP Design Guild (and a corresponding webpage of resources on simplification)
• Various sources of quotations about simple/simplicity, such as ThinkExist, QuoteGarden, Quotes of the Heart, Brainy Quote, Albert Einstein quotes, quotations on simplicity of design and quotations about software design

After mulling-over all of those, I think it's fair to say that while "Simplicity" may be, well, "simple", truly understanding "simplicity" is in fact quite hard!

• Simplicity involves being able to see the whole from a systems thinking perspective while at the same time being able to focus in on what is relevant and essential and how it impacts the rest of the system.
• Sustainable simplicity often has to evolve or emerge on it's own from a set of simple guiding rules.
• The opposite of simplicity is complexity (as opposed to "hard" or "difficult" or "time-consuming" or "labor-intensive")
• In mathematics, simplicity is often "elegance" and is more than just the intersection of "what is necessary" and "what is sufficient"
• In architecture, "simplicity" is often synonymous with "beauty"
• Hiding complexity isn't the same as removing complexity.
• Many of the tools we use to manage complexity in systems design may in fact add more/new objects to hide complexity or separate concerns
• Minimizing dependencies throughout a system is more critical to simplicity than minimizing the number/types of objects
• Occam's Razor does not in fact say that the "simpler explanation is better" ... it says that the explanation that makes the fewest assumptions and poses the fewest hypotheticals (i.e., minimizes the number of "given" and "unproven" conditions) is the most preferable because it is easier to comprehensively test in order to prove/disprove.

I think that true simplicity is about minimizing and managing overall complexity. Complexity in software design and development comes from the sheer size and complexity of the problem we are being asked to solve, and the richness and vastness of the interconnected maze of interactions within the system and between the system and its environment.

• The overall complexity of the system is dominated far more by the interactions between the parts that makeup the whole than it is by the parts alone.
• For any non-trivial system, simplicity often has less to do with the number and kind of different things involved and more to do with the number and kind of interdependencies between them.

So achieving simplicity is less about managing "parts" of "things" or individual point-solutions, and is more about managing rules and relationships between the parts and things and solution-sets.

When dealing with large or complex systems (like most software, and software processes) the number of things (scale) and different types of things (diversity) that need to be managed is overwhelming. If we can come up with a modicum of modest, simple rules & principles to govern our design decisions in ways that help us minimize and manage interdependencies, eliminate constraints, and remove waste, then we are on the path to solving the real problem and meeting stakeholder needs in a way that is both simple and sustainable.

I'll close with my collection of favorite quotes on simplicity and simple design from the sources I culled above.

Everything should be made as simple as possible, but not simpler. -- Albert Einstein

Three Rules of Work: Out of clutter find simplicity; From discord find harmony; In the middle of difficulty lies opportunity. -- Albert Einstein

For every problem there is a solution which is simple, clean and wrong. -- Henry Louis Mencken

Think simple as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles. -- Frank Lloyd Wright

Beauty of style and harmony and grace and good rhythm depend on simplicity. -- Plato

The ability to simplify means to eliminate the unnecessary so that the necessary may speak. -- Hans Hofmann

Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity. -- Charles Mingus

Everything is both simpler than we can imagine, and more complicated that we can conceive. -- Goethe

The whole is simpler than the sum of its parts. -- Willard Gibbs

The pure and simple truth is rarely pure, and never simple. -- Oscar Wilde

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius--and a lot of courage--to move in the opposite direction. -- E. F. Schumacker

Besides the noble art of getting things done, there is the noble art of leaving things undone. The wisdom of life consists in the elimination of nonessentials. -- Lin Yu Tang

Very often, people confuse simple with simplistic. The nuance is lost on most.-- Clement Mok

You can't force simplicity; but you can invite it in by finding as much richness as possible in the few things at hand. Simplicity doesn't mean meagerness but rather a certain kind of richness, the fullness that appears when we stop stuffing the world with things. -- Thomas Moore

The point of philosophy is to start with something so simple as not to seem worth stating, and to end with something so paradoxical that no one will believe it. -- Bertrand Russell

The aspects of things that are most important to us are hidden because of their simplicity and familiarity. -- Ludwig Wittgenstein

Manifest plainness, Embrace simplicity, Reduce selfishness, Have few desires. -- Lao-Tzu, Tao Te Ching

Simple things should be simple and complex things should be possible. -- Alan Kay

The key to performance is elegance, not battalions of special cases. The terrible temptation to tweak should be resisted unless the payoff is really noticeable. -- Jon Bentley and Doug McIlroy

... the purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. -- Edsger W. Dijkstra

Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated. -- Edsger W. Dijkstra

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity. -- David Gelernter

Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. -- Alan Perlis

Technical skill is mastery of complexity, while creativity is mastery of simplicity. -- E. Christopher Zeeman

Architect: Someone who knows the difference between that which could be done and that which should be done. -- Larry McVoy

One of the great enemies of design is when systems or objects become more complex than a person - or even a team of people - can keep in their heads. This is why software is generally beneath contempt. -- Bran Ferren

A complex system that works is invariably found to have evolved from a simple system that worked. -- John Gall

The most powerful designs are always the result of a continuous process of simplification and refinement. -- Kevin Mullet

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. -- Antoine de Saint-Exupéry

Simple, clear purpose and principles give rise to complex intelligent behavior. Complex rules and regulations give rise to simple stupid behavior. -- Dee Hock

Six Sigma and Good vs Bad Variation

I briefly touched on Six Sigma (the methdology, not the number/measure) in my previous blog-entry on Cost, Cruft and Constraints, and how Six Sigma methods are about reducing what I called destructive variation:

Six Sigma is about eliminating process variation, but not just any kind of process variation. It's about eliminating "destructive" variation. Destructive variation is value-subtracting variation (rather than value-adding).

Some go too far with Six Sigma and interpret it to mean that ALL process variation is "bad." I don't subscribe to that belief. I think there is intentional variation that adds value, as well as "essential" variation that is either unavoidable, or else emerges naturally (and beneficially) out of the creative & learning processes.

Many have tried for repeatability & reproducibility where it isnt always appropriate. The knowledge creating aspects of software development aren't always appropriate places for procedural repeatability and removing variation. The feedback/validating aspects often are. I think Software CM and testing are appropriate places for this: anything that is appropriate and desirable to automate (like building and testing) would be an appropriate for removing variation and SixSigma techniques.

So just like not all conflict is bad, not all variation is bad! And Six Sigma efforts should (I think) limit their focus to destructive variation for the portions of their processes where it make sense to have both repeatable procedures and reproducible results.

I think I'm actually starting to come up with a combination of Agile, Lean, TOC and Six Sigma that is both cohesive and coherent. I credit David Anderson with starting me down that path. (Look out! CMMI might be next :-)

Business Agility Defined

The last few blog entries on agile definitions, and Agile + Lean + TOC have inspired me to proffer up this aliterative definition of Agility in a Business context.

Business Agility is ...

Rapid Response to Change with Optimal Efficiency in Motion, Economy of Effort, Energy in Execution, and Efficacy of Impact!

Is that too verbose? Is it enough to say simply:

Rapid response with optimal efficiency, economy, energy and efficacy!

Note that I dont say anything above about keen sense of timing & awareness to change in one's Environment. Should it? What about Entrusting and Empowering others?

Cost, Cruft and Constraints

My earlier blog-entry on "Feedback, Flow, and Friction" met with mixed reviews.

Many commented that agile development is ultimately about lowering the cost of change. Others noted feedback is important, but unless you respond to it, and take appropriate action, it's not the be-all and end-all it may seem. A few felt the that "friction" wasnt quite close enough to "contraints."

It seems when it comes right down to it, Agile, Lean and TOC are all about trying to eliminate and/or remove the following:

• Cost-of-change: Agile is about reducing the cost of change by making change easy and catching the need to change much earlier thru continous feedback and close, frequent stakeholder interaction.


• Cruft: It (cruft) is waste! And Lean is all about eliminating waste in order to maximize flow.


• Constraints: TOC is all about eliminating constraints, and using the five focusing steps to do it.

While we're at it - Six Sigma is also about eliminating something: variation (but not just any kind of variation). It's about eliminating "destructive" variation. Destructive variation is value-subtracting variation (rather than value-adding).

The phrase "Cost, Cruft and Constraints" doesnt sound as attractive as "Feedback, Flow and Friction." A large part of that may be due to its nonconstructive focus on what to eliminate rather than on what to create.

For each thing I'm allegedly eliminating, I'm gaining something else:

• Reducing the cost-of-change makes it easier to accommodate change and be adaptive/responsive


• Eliminating waste helps maximize flow of the production pipeline.


• Eliminating constraints help maximize throughput


• Eliminating destructive variation helps maximize quality in terms of correctness, reliability, availability, operability, maintainability, etc.

Pragmatic Multi-Variant Management

I had a rather lengthy post on this subject on the Pragmatic Programming Yahoo group ...

My advice as a CM guy is you do NOT want to use branches or branching to solve this problem. If you have to manage/support multiple "configurations" of functionality for multiple markets/customers, branching is just about the worst way to do it (and this is coming from someone who is an advocate of branching, when done the right way for the right reasons).

The issue is likely to be one of "Binding Time". In your case, you would prefer the binding-time to be either at build-time (such as conditional compilation or linking), or release-engineering time (packaging up the "right" sets of files, including configuration files, for distributing to a customer), install/upgrade-time, or run-time.

One of the prefered ways to do this is with Business-Rules; particularly when it comes to decisions of "variable" policies and/or functionality. With GUI's depending on the kind of variation, you might resort to either conditional compilation or else simply creating separate source-files (instead of branching the same file).

There were some substantial discussions on this topic on CMCrossroads forums that yielded many practical insights and further resources. I recommend them:

• CM for product variations
• Branching or using #ifdef?

fantamango77 wrote:

I can say I tried out different strategies in earlier projects already. But not with such a big project. And none of the ways I took made me happy. It always ended up in a kind of hell: Configuration hell, branching hell, inheritance hell.

Yes - and some of those "circles" of h*ll are far worse than others when you look at the overall costs and effort. The bottom-line is that if you have to support multiple "variants" rather than a single evolving "line", you are adding complexity, and there is no way you are going to be able to sweep it under the rug or make it go away.

So it all comes down to which techniques and strategies in which "dimensions" of the project/product will prove most effective at minimizing and managing dependencies, effort and impact by most effectively allowing you to leverage proven principles such as encapsulation, cohesion, modularity, abstraction, etc. in the most efficient ways.

Think about what aspects or dimensions of your project/product are required to be "variable" in order for you to support multiple variants. Do your "variants" need to differ ...

• in functional/behavioral dimensions
• along organizational boundaries
• along multiple platforms/environments
• along temporal (evolution) dimensions
• along project dimensions

Figure out which one or two of these are the primary "dimensions" of variability you need to support. Then find the set of mechanisms and techniques that apply to it.

For example, if you need to allow variability primarily along functional and environmental "dimensions", then which of those "dimensions" does version branching operate within? Version branching operates primarily within the space of evolution/time (concurrent, parallel, and distributed development).

So temporally-based techniques are not going to be best suited to handling variation in the behavioral or environmental dimensions, as the isolation/insulation they provide does not most effectively minimize, localize or encapsulate the kinds of dependencies in the non-time-based aspects of the system.

Differences in policy and/or mechanism are typically best handled using a business-rules approach to deliver a single codebase with multiple possible configurations of rules and rule-settings.

Differences in platforms are best handled by well known design and architecture patterns like Wrapper-Facade, and numerous patterns from the Gang-of-Four design patterns book.

Differences in behavior may be best handled by functional/feature selection and deselection "design patterns" like Configurator, to enable or disable features and/or services at post-development binding-times.

Inheritance may be useful in some cases, if the type of configuration needed really does fit a single hierarchical model of increasing specialization. In other cases, an aspect-oriented approach might be better.

Also think about the following in terms of what needs to "vary" and what needs to stay the same:

• Interface -vs- Implementation -vs- Integration
• Container -vs- Content -vs- Context

This kind of commonality and variability analysis helps isolate the fundamental dimensions or aspects of variation that need to apply to your project. If something needs to be able to vary while something else doesnt, then "encapsulate the thing that varies" using techniques that separate interface from implementation (or implementation from integration, or etc.) in ways that "keep it [structure] shy, DRY, and tell the other guy."

You might end up using a combination of strategies depending on the different aspects of variation you require and the "dimension" in which each one operates.

Nutshell definitions of Agile development

Over on the Extreme Programming Mailing list, someone asked "Could any one tell me what's exactly Agile Methodology(method) is?", a couple really good responses followed that I rather liked (italics are mine in the excerpts below).

Phlip wrote:

Agile development means using feedback to prevent waste and optimize development.

Software development follows an inner cycle of writing code for new features, and an outer cycle of delivering versions to users.

• The inner cycle risks waste when we debug too much, or write too many lines. Larger teams also cause waste when one person must wait for another to upgrade their modules.
• The outer cycle risks waste simply because when customers wait a long time for new features, the odds increase that they will request changes to existing code.

Feedback" means you set up a cycle so your project can tell you about its current status, early and often.

• The most important feedback for the inner cycle is automated tests. They prevent wasting time debugging, and they help you remove lines of code that are not needed. And they make your code safe for others to change, so they don't need to wait for you.
• The most important feedback for the outer cycle is frequent releases to end users. If you give them the high value features first, then the odds they will request rework are low. (High value features tend to have obvious specifications.) Then, the odds they will request new features are high, so you repeat. Each new release will reinforce and fine-tune the high value features.

Put together, these processes allow teams to move rapidly to new territory, and to not trip or make mistakes getting there. The dictionary's word for such fleet and sure-footed behavior is "agile".

John Roth wrote:

Agile is a style of project management which lets the project respond quickly to changing requirements. It also usually incorporates frequent releases, or at least the possibility of frequent releases without undue extra project management overhead.

Ease of handling changing requirements naturally leads to leaving the definition of detail to the last responsible moment, rather than having to have all details completely specified up front.

Most named agile methodologies don't specify much outside of project management. Scrum, for example, specifies a lot of project management, a small amount of team practice (put the developers in a room and do daily standups) and gives essentially no guidance about how to actually construct the software.

XP is the only one I know of that specifies all three (project management, team practice and software construction practice) in detail.

C. Keith Ray wrote:

Agile methods react well to changing requirements, permit delivery of working, tested, software at frequent intervals, and generally require less "overhead" than older document-driven formal methods. To enable this reduction of overhead, Agile methods rely on "social" tools and practices (such as shared-workspace, "information radiators", and retrospectives) as well as technical tools and practices like automated builds and automated tests.

Someone referred to James Bach's definition of an agile methodology:

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.

Steven Gordon wrote:

What makes this question so vexing to so many is that being agile is contextual rather than definitive.

Being lean and principled is not necessarily sufficient to be agile - one must garner feedback from the context (from customers and management as well as ourselves) and adapt appropriately to that feedback to remain agile. Doing the exact same things could be agile in one context and not particularly agile in another.

Feedback, Flow and Friction

I think those three words may just possibly distill the essence of Agile, Lean, and Theory of Constraints: Feedback, Flow and Friction!

• Feedback is, to a large-extent, what Agile is all about. It is about getting continuous feedback quickly and frequently as possible (at all levels of scale) to promote collaboration and synergy and synthesis of the knowledge we gain thru learning and discovery so we can validate it early and often.
  
  
• Flow is what "Lean" is all about. It is about ensuring smooth continuous flow of the value stream, from creation thru delivery, and eliminating redundancy and waste wherever possible.
  
  
• Friction is what "TOC" is all about: identifying and removing the constraints that impose friction on the flow of value and the feedback cycle of discovery and learning.

What do you think? How far off the mark is this? How badly am I oversimplifying?

Impacts of Extreme Globalization and Extreme Competition

I promised to say something about how I think all this stuff about globalization, innovation and extreme competition will impact CM and Agility. But first, a refresher on the books that I blogged about throughout most of March and April:

• The World is Flat: A Brief History of the 21st Century, by Thomas Friedman
• 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 (also the paper The Coming IT Flip-Flop, Rajesh Jain's "Tech Talk" on Extreme Competition, and Human Interaction Management)
• The Only Sustainable Edge: Why Business Strategy Depends on Productive Friction and Dynamic Specialization, by John Hagel III and John Seely Brown (also see the Edge Perspective's blog)
• Whole New Mind, by Dan Pink (also see Dan Pink's blog)
• The Design of Things to Come : How Ordinary People Create Extraordinary Products, by Craig M. Vogel, Jonathan Cagan and Peter Boatwright (also see Fanning the Creative Spirit and Innovation at the Speed of Laughter)

My blog entries on the subject thus far have been as follows:

• The World is 5-Dimensional: Globalization and Teleportation
• End of the Line: The Rise and Coming Fall of the Global Corporation
• Three Billion New Capitalists: The Great Shift of Wealth and Power to the East
• Extreme Competition: Innovation And the Great 21st Century Business Reformation
• The Coming IT Flip-Flop
• The Only Sustainable Edge
• Whole New Mind: Moving from the Information Age to the Conceptual Age
• The Design of Things to Come : Pragmatic Innovation
• More Extreme Competition: Business Drivers, Realities and Strategies

So here are my jumbled thoughts on what I think it all portends for Agility and CM ...

• Extreme Globalization will continue to drive the need for Extremely Distributed Development teams and team members.
  
  
• Extreme Collaboration will increase the trend for needing human-interaction management over workflow enforcement. Tools will need to be less prescriptive and predictive and more enabling and empowering (particularly of "rich" virtual communication where face-to-face is not possible).
  
  
• The Internet as the new personal computing platform will meld deployment CM with development CM and with ITIL. It will also make managing dynamic dependencies of components and services an absolute nightmare, especially for Service-Oriented Architecture. But it will be a necessary nightmare to face.
  
  
• All of the above, plus regulatory compliance and accounting (such as Sarbanes-Oxley) will combine to make issues of security and fine-grained access control of electronically stored assets and business-intelligence (and processes) an even bigger concern than it already is, which tools will need to do a better job of addressing.
  
  
• The collaboration and innovation process will itself need to be "Agile", and agile practices will need to extend from "delivering software" to "delivering innovation." Applying principles of Agile, Lean, Theory of Constraints (TOC), and even SixSigma to the "innovation supply chain" will become increasingly important. We'll need to struggle to understand what refactoring, test-driven (trust-driven), continuous integration, pairing, and being adaptive/responsive to change mean in this new context.
  
  
• All of the above will also make automating extreme traceability an even bigger concern. But a more agile-style of development that is task-based and event-driven, will help to automate extreme traceability as pragmatically as possible. Extreme "big brother" environments that know and log everything we are doing, in the appropriate context (with the appropriate privacy/security levels) will be an increasing trend in properties of the IDEs and ALM tools we use.
  
  
• All of the above will also make for "extreme configuration identification." We'll have so many things to try to track, it will be almost intractable to try and identify and track them (and their dependencies) in the usual ways. Search engines will help us out here with "tagging and searching" rather than "capturing, filing and sorting", with multiple views and scopes and transparency/trust levels.
  
  
• Extreme time-based competition and focus on the customer-experience will bring "Lean" and TOC (particularly "Lean") methods even more prominently into the limelight. Creating and managing baselines will be more challenging as signficant CM events (such as baselines) blur closer and closer together (what I term the 'collaboration-dilation' effect) and transform discrete events into continuous flow. The logging and tagging+searching capabilities previously mentioned will need to help us with this.
  
  
• Extreme Visualization for how to conceptualize these things in our heads and share those concepts with others, will be another important focus of the next generation of "extreme" ALM tools and services to assist us.
  

What else? I know I'm missing something else that I thought of earlier but am drawing a blank now. There's gotta be more than this!

CMCrossroads articles on FDD and Situational Code Ownership

The following two articles of mine appear in the April 2006 issue of CM Crossroads Journal (the month's theme is "Agile Development Practices"):

• Feature-Driven Development - an Agile Alternative to Extreme Programming


• Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership

If parts of them look familiar it's because these articles evolved out of multiple entries from this blog over the past year :-)

The more I look at FDD, the more I really like it as an agile method suitable for a large projects and companies, especially those striving for CMM/CMMI. I also really like the work David Anderson has done tying FDD together with Lean, TOC, and SixSigma.

I'd be real interested in any work on melding FDD together with many of the project management practices of Scrum, and some of the programming practices of XP (e.g., continuous integration, TDD, collective ownership, and refactoring).

More Extreme Competition: Business Drivers, Realities and Strategies

Another a follow-up to my previous blog-entry about Peter Fingar's book Extreme Competition ...

In the book, Fingar talks about 5 "unstoppable" drivers/transformers, 16 "new realities of business", and 13 "strategy patterns" to consider. Rajesh Jain, who wrote the foreward to the book, has a very well-written series of blog-entries collected together in Tech Talk: Extreme Competition.

I've already blogged quite a bit about this book, so I wont go into detail about each of the items listed below other than to simply list them. For more details, I recommend looking at Rajesh Jain's Tech Talk: Extreme Competition and also the numerous materials available from the homepage for the book Extreme Competition

The Five Unstoppable Drivers Transforming Competition

1. Knowledge as Business Capital
2. The Internet
3. Jumbo Transportation
4. Three Billion New Capitalists
5. The New IT

The Sixteen New Realities of Business

1. Extreme Customers
2. Extreme Innovation
3. Extreme Individuals
4. Extreme Customization
5. Extreme Business Processes
6. Extreme Teams
7. Extreme Supply Chains
8. Extreme Experiences & Self-Service
9. Extreme Industry Blur
10. Extreme Education & Learning
11. Extreme Government
12. Extreme Health Care
13. Extreme Time
14. Extreme Change
15. Extreme Specialization
16. Extreme Branding

Thirteen Strategies for Extreme Competition

1. The Time to Act is Now!
2. Be Slavishly Devoted to Your Customers
3. Think Globally, Act Globally
4. Be a Superspecialist
5. Connect with the Superpsecialists
6. Be a Brand Master, Fight Brand Bullies
7. Embrace Time-Based Competition
8. Grok Process!
9. Embrace The New IT
10. Offer Process-Powered Self-Service
11. Offer Product-Services and Experiences
12. Systematize Innovation
13. Be a Good Citizen

Book Review: Collaboration Explained

My review of Jean Tabaka's Collaboration Explained: Facilitation Skills for Software Project Leaders appear's in this month's issue (April 2006) of The Agile Journal.

I think the book has a lot of useful information, methods and techniques about creating collaborative software teams that are pretty hard to find in other books because most other books on the subject aren't targeted specifically at software development and software project/technical leadership. See the Featured Book section for the review.

Extreme Traceability

I gave the following response in a March 24 posting to the extreme programming list on the subject of XP-style traceability:

dsrkkk wrote:

Whatever process we use, we need to track requirements, user stories to design and test cases. The traceability provides obviously many benefits. Why don't we automate traceability? How can we humanly track these complex relationships? If we do manually, we may miss something.

I responded . . .

The less you work in a waterfallish-way, and the more you work in an agile fashion with very short feedback loops, the less necessary it becomes to make additional efforts to track/trace requirements.

If I first do lots of requirements, then lots of design, then lots of code, etc., I have to "put the pieces together." The task I performed to write requirements was different from the one that did the design which was different from the one that did code, tests, etc.

If I work in very short cycles (particularly using test-driven development), then an individual development task looks something like:

• write a single test
• write the code to pass the test and no more
• refactor the code
• commit my changes (Note I might commit my changes before refactoring too).

If, when I commit my changes to the repository, I associate my "commit" with the name or id of the story the test was for, then I have a single, fine-grained change-task that went thru the complete cycle of specification, implementation/design, verification all in a matter of minutes for a single "commit" and user-story.

Working in such fine-grained full-lifecycled tasks automatically associates all the elements that were created & updated as part of the task, which in turn is associated with a user-story. Ta da!!!! Traceability comes along for the ride almost automatically.

From Extreme Locality, in the Feb 2004 "Agile Times", pp.37-40

In Agile methods, we often hear a lot about the importance of simplicity: simple design; do the simplest thing that could possibly work; simple tools; minimal documentation ... Much of the documentation and artifacts created in larger software development methods is for the sake of capturing historical knowledge: the rhyme and reasons behind why something is there, or is designed a certain way.

The desire for such information is often used to justify the need for formal traceability and additional documentation for the sake of maintainability and comprehension. Some very powerful and sophisticated tools exist to do this sort of thing. And yet, there are basic fundamental principles and simple tactics to apply that can eliminate much of this burden.

WHENCE FORMAL TRACEABILITY?
The mandate for formal traceability originated from the days of Department of Defense (DoD) development with very large systems that included both hardware and software, and encompassed many geographically dispersed teams collaborating together on different pieces of the whole system. The systems were often mission critical in that a typical “bug” might very likely result in catastrophic loss of some kind (loss of life, limb, livelihood, national security, or obscenely large sums of money/funding).

At a high level, the purpose of formal traceability was three-fold:

1. Aid project management by improving change Impact Analysis (to help estimate effort/cost, and assess risk)
   
2. Help ensure Product Conformance to requirements specs (i.e. ensure the design covers every requirement, the implementation realizes every design element and every requirement)
   
3. Help ensure Process Compliance (only the authorized individuals worked on the things [requirements, tasks, etc.] they were supposed to do)

On a typical Agile project, there is a single team of typically less than two-dozen. And that team is likely to be working with less than 10 million lines of code (probably less than 1 million). In such situations, many of the aforementioned needs for formal traceability can be satisfactorily ensured without the additional rigor and overhead of full-fledged formal requirements tracing.

Rigorous traceability isn’t always necessary for the typical Agile project, except for the conformance auditing, which some Agile methods accomplish via test-driven design (TDD). A “coach” would be responsible for process conformance via good practices and good “teaming,” but likely would not need to have any kind of formal audit (unless obligated to do so by contract or by market demand or industry standards).

Agile methodologies turn the knob up to 10 on product conformance by being close to the customer, by working on micro-sized changes/increments to ensure that minimal artifacts are produced (and hence with minimal reconciliation) and that communication feedback loops are small and tight. Fewer artifacts, better communication, pebble-sized change-tasks with frequent iterations tame the tiger of complexity!

For more then you ever wanted to know about the why&wherefore behind traceability, see The Trouble with Tracing: Traceability Dissected

Trends in SCM Predictions for 2006

The January 2006 CMCrossroads Journal came out a few months back. Each January issue of CMCrossroads Journal usually tries to make some predictions about SCM in the coming year (or years).

My predictions on The Future or Agile SCM (from the January 2005 CMCrossroads Journal) actually tried to project thru 2008 (and even 2010 and beyond for one particular prediction). This year we scaled it back to just looking at 2006 (and possibly early 2007).

There were several recurring themes that I noticed among the half-dozen or so articles. No big surprises of course, but the degree of concurrence among the different contributors was very noteworthy (at least I think so):

Globally Distributed development is the new "normal"

Globalization is kicking into high gear in the "flattened world" (see Thomas Friedman's The World is Flat and Barry Lynn's End of the Line : The Rise and Coming Fall of the Global Corporation). The trend of globally distributed development is increasing at a rapid rate and will be a more important focus (and more frequent "buzzword", along with "collaboration").

ALM is the "new" SCM!

Application Lifecycle Management (or ALM) is becoming the new/trendy term for the full-spectrum of Software CM. Vendors have spent the last 6 years or so buying-up individual tools to provide "full-lifecycle" suites to enhance an IDE: modeling tools (that do their own versioning), requirements tools, version control, test management, change-request tracking, and others are all being offered as singly-packaged suites of integrated tools. And the vendors are using the term "ALM" for the result.

TeamSystem, and Eclipse ALF & Corona are the new "Vision"

Microsoft's new Visual Studio Team System (and Team Server) will make a huge splash! Look's like the splash already started, with TeamSystem winning a "Jolt" award (tho not in the SCM category). The fact that it's Microsoft and integrated with VisualStudio is enough, by itself, to warrant other vendors "taking notice." With a single integrated tool-set running off the same server and integrated with the IDE, you can do all sorts of amazing things with automated logging and traceability (especially if it's web-services enabled, or the .NET equivalent).

In order to compete, other vendors are aligning with the Eclipse ALF project, which just recently had its "proof of concept demo." ALF is the Application Lifecycle Framework, an under-development set of web-service and interoperability standards for vendor-independent integration of tools in the ALM space (version control, change/defect tracking, requirements mgmt, test management, project tracking, build/release mgmt, and even IDEs and modeling tools). And at EclipseCon 2006 the Eclipse Corona project was announced as a recent "spinoff" of ALF. According to a March 20 InfoWorld article:

"ALF addresses the issue of integration and communication between developer tools across the lifecycle; Corona enables Eclipse-based tools to integrate with ALF, according to Eclipse. Also known as the Tools Services Framework, Corona provides frameworks for collaboration among Eclipse clients."

Other related Eclipse projects are BIRT (business-intelligence & reporting tools), the Data Tools Platform, the Test & Performance Tools Platform and the SOA Tools Platform.

Integration of CM with ITIL is the new "Enterprise CM"

More and more SCM services departments are having to deal with many of the same issues of IT (and even being lumped together with IT) as they support not just the functions for CM, but also provide deployment, training and support for the corresponding ALM tools, repositories and servers. The integrated CMDB is also useful for both traceabilty and accounting/accountability (think Sarbanes-Oxley).

Also, more and more folks are needing to extend CM into their deployment sites at their customer's operations to help them handle field-issues and upgrades, even monitoring, service-tracking/licensing/monitoring and possibly some CRM functions.

So it makes sense that CM professionals who need to deploy, develop and support "the whole shmeer" are having to learn and understand CM, ALM and ITIL. Word has it that integration of CMMI with ITIL is coming soon.

SOA, BPM and TCO are emerging priorities on the horizon

There wasn't quite as much mention about these, but it seems clear that they will be growing more important this year. Service-Oriented Architecture (SOA) will be important to the extent that TeamSystem and ALF are important, and some vendors are already using SOA-based integration for the tools within their own suites.

As the integrations between ALM tools and with the IDE become more seamless, Business Process Management (BPM) and Workflow will become a bigger concern as folks try to more readily define and automate their processes, particularly for deployment to multiple distributed sites.

And Total Cost of Ownership (TCO) is becoming an increasingly more prevalent factor in selection of CM/ALM tools. The spiffy features and functionality are nice, but just as much weight (if not more) is being given to business issues of global licensing and upgrade/support, administration/maintenance, along with total cost of ownership.

So where does that leave us today? And how does this relate to the subject of last month's blog-entries about globalization and the resulting business imperatives of continuously connecting and collaborating to create, innovate and dominate?

The Design of Things to Come: Pragmatic Innovation

This book, by Craig M. Vogel, Jonathan Cagan, Peter Boatwright, sort of naturally follows from previous blog-entries "connecting the dots" from globalization 3.0, to continuous collaboration + innovation, to the sets of right-brained skills Daniel Pink says will be essential to prepare us to move from the information age to the conceptual age.

The Design of Things to Come : How Ordinary People Create Extraordinary Products, is about "people-focused" innovation and how to use the skills Dan Pink describes to create a new breed of innovation that forges an emotional connection to the customer to provide a thrilling customer experience in the various forms it may manifest itself for business.

Throughout the book, the term Pragmatic Innovation is used, enough so that it hopes to become a new "catch phrase" (time will tell if it succeeds). Much of what it describes, including its focus on people and pragmatism, seem very well aligned with the values described in the Agile Manifesto.

Put this book together with the previously mentioned works from Peter Fingar (Extreme Competition), John Hagel and John Seely Brown (The Only Sustainable Edge) and Dan Pink (A Whole New Mind), and you may very well have a blueprint for both strategy and tactics on how to connect, collaborate and innovate and in what areas (and in what ways) to attempt it [such as focusing on "the customer experience" and Human Interaction Management while companies like Google transform the internet into our ubiquitous personal computing platform].

Add a dash of Fanning the Creative Spirit and Innovation at the Speed of Laughter, and maybe we'll get a solid picture of what the ideal future workplace may look like: agile, lean, connective, distributed, collaborative, pragmatic, people-centered, innovative, and dominating the competition.

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?