Why Enterprise Agile Matters

I was trained up in the way of large and very large corporations, particularly in software management pedagogy.

  • Document hierarchies
  • Design hierarchies
  • Architectural hierarchies
  • Process and procedure hierarchies
  • Steering committees
  • Change Control Boards
  • Change and Configuration Management standards
  • People hierarchies
  • Audits
  • Traceability
  • Certification
  • Compliance
  • Standards Boards
  • Design, Development and Test standards
  • Inspection standards
  • Project Management expectations
  • Product Management expectations
  • Matrixed organizational expectations
  • Things my mom expected and so on

The real problem had everything to do with the problem of scale and nothing to do with the processes or people themselves.

If we assume that people are generally good and want to do the right thing, and that processes are usually by-products of good people trying to do good things, then how do good people produce well-intentioned process and procedure paradigms that make people hate the journey so badly they want to die?

With scale comes complexity. With complexity comes complex management behaviors. Complex management behaviors beget overhead. Eventually the overhead becomes the project.

Historical solutions for managing scale have required sometimes extreme process and procedure declaration, as well as, micro-management. The bigger the project, the more moving parts. The more moving parts on a project, the more people in leadership are inclined to screw down on the moving parts in the interest of control and information gathering. Screwing down does not increase quality, control costs or guarantee time-based deliverables. In many cases, it precludes it.

People, leaders and team members alike, continue to look for new and better ways to deliver very large, very complex software projects. Understandably so. Agile communicates itself the solution. Is it?

Enterprise Agile matters because the currently published Agile cloud behaviors do not scale. Otherwise stated, today's published materials on Agile, with the current exception of Dean Leffingwell's book Agile Software Requirements, do not adequately answer the questions of, nor scale to existing levels of enterprise organizations accustomed to high-assurance process frameworks. Most of today's published books in the Agile space do indeed teach very important, very critical behavioural concepts, but they do not show us how they all come together into a synthesized set of behaviours that fit into the larger 1000+ person enterprise. One agile team, project or department does not an Agile company make. Until the enterprise itself (including executive management, sales, marketing, support, product and project management) takes on system-level contiguous behaviors centred on continually prioritized objectives and uninterrupted iterative deliverable flow, micro-implementations of agile, though important, will struggle to change the culture of a corporation and may kill itself trying.

If Agilic behaviors are any good at all, it is because of the people. Success happens because of people. And as teams, project, programs and companies scale, so too must our delivery behaviors. Agile behaviors work and there is ample industry data to support it. However, out of the box, it doesn't work at scale no matter how many good people you have in a closet. There is a need for Agile implementations scaled up to large and very-large enterprises addressing, not only the software engineering needs of a large organization, but the operational deliverable culture itself.

How many of your large or very large corporation's project problems are actually technical? More likely, they are sociological, political, culture and operational. How much of your large project budget is attributable to deliverables versus behavioural constructs and associative staff put in place to aid in delivery?

There is a better way. Good people in good enterprises are looking for it. In order for Agile to meet the need, it must scale to meet the demands of good people who will solve their problems one way or another.

Adaptive Learning

Seagulls are known to drop oysters against hard pavement for cars to drive over or rocks at height in order to crack them open. Octopus are known to use one or more discarded ocean floor items to create more secure housing. Various monkey and ape species are known to use sticks for various purposes including judging water height and retrieving ants or termites. Sea otters are known to use rocks to break apart abalone. And humans? Well, we have quite a few tricks up our sleeve as well. All of us mentioned have problems to which we seek and find solutions. Particularly, hunger motivates food access solutions as does safety.

But what happens when the rock the sea otter was using to break apart the abalone itself breaks? What if the size of the abalone changes to be larger than sea otter grip or the shell is thicker than before requiring more successive hits or longer commitment than previous? Surely the sea otter will figure out the need for adaptation wouldn't it? That is the crux of the evolution and adaptation debates. Those species that recognize the need for change survive. Those that don't, don't.

To debate the most efficient programming language, best test coverage approach, easiest to use CI tool, a particular format for user stories or predictable, repeatable forecasting math is well and good, but these items are not the central challenge to humans delivering working software systems. To use OO, TDD, version control, marker boards and CI lights is simply not the conversation. The conversation is learning and evolving. Learning and evolving require a framework of reference. Hence the choice of methods and tools.

Methods and tools server no greater purpose than enabling a framework in, upon and around which people learn. The merit is not the methods or tools themselves, but rather the point of reference from which the methods or tools facilitate learning in order to achieve the desired goal. In order for the sea otter to learn and evolve, there must exist a point of reference. Past failures required noting the situational characteristics leading to failure. Absent these observations, failure will be repeated. The same may be stated about successes.

What if the seagull had success yesterday dropping oysters on a paved road for cars to drive over and he went to bed with a full belly; however, today no cars came by. How many attempts will the seagull make before deciding it is time to try something new? Or will he notice this at all? What if the road is now permanently closed? Will this foster experimentation? Will the seagull observe that he is not getting the same results and be stimulated to change? Or will the bird eventually fall from the sky with malnutrition and die?

To rebel against principles and practices is rebelling against a launchpad for learning. The argument is never about the method or tool. Argument must be made for mechanisms that enable the desired result. Through time, particular methods and tools stand out as more productive investments than others based upon historical context, effort and result. It is these characteristics that we tend to repeat and from which we evolve.

To evolve requires adaptation.

To adapt, requires comparative knowledge.

To gain comparative knowledge, there must exist some form of method and tool based framework enabling observation and comparison.

Of course the framework composed of methods and tools itself must evolve, else it is victim to irony. However, to reject a framework for gaining comparative knowledge in order to adapt or evolve is a sign of those who will not adapt or evolve.

Can you imagine a species unable to adapt to context? Wouldn't it suggest impending death of the species? So to it is with our teams, projects and companies. We can all see the proverbial dead-man walking. Just look for the person, team, project or company who has no framework or worships the framework over the learning.

When Centres of Excellence Matter

Historically I've been opposed to Centres of Excellence (COEs) because I believe after a standard is created, people grow to meet the expectation, not exceed it. Assuming the standard itself is any good at all, then there exists the challenge of measuring against the standard fairly, objectively and completely. Because people are complex, so too become our standards definitions, methods of measure and penalty and reward systems. How pretty this picture is at the end, if there is an end, is dependent upon the maturity of the standards definers, auditors, reporters and so forth. Ironically, the people who compose our organization are often the subject of experiment. My experience has been that COEs are often used for domestic and international certification attainment, audit and re-certification purposes more than actually moving people to endless greatness. A sort of mass production approach, if you will. Of course, until three years ago, my experience was grounded in 1st-world US and UK based technology companies who already had a standard performance expectation, method of measure, modification and evolution. I now see two different contexts. Because I see two contexts it then stands to reason there could be more and the conversation 'to COE or not to COE' becomes of course more complicated. Another point scored for the complexity of human existence.

Consider countries, companies, products, projects and teams who have no existing baseline of acceptability? What about cultures where it is time for the standard of excellence to evolve from non-existence, local, regional or domestic into internationally accepted paradigms? What about countries newly formed, newly war-torn and recovering, newly split or abused by historically poor leadership? Countries in transition. What about the same for multi-national corporations (MNCs)? Non-Governmental Organizations (NGOs)? In each case, regardless the apparent contrast in organizational or entity type, they all have the same fundamental building blocks called people.

In a situation where there exists no standard, there must come to be one if there is to be any form of predictable, repeatable results from efforts. In a situation where the existing standard is no longer acceptable, it must be evolved in order to improve environment, effort and result quality. In a situation where results are unpredictable or unacceptable, it again must be evolved to realize efficiencies and growth/revenue gains. In these types of situations it makes good, practical sense to construct a COE which enables an organization or entity toward a focused direction and goal or set of goals.

COEs by definition create a baseline of acceptable behaviour, output and result. If you, your organization, government entity or government itself are in a place where a baseline of acceptability needs to evolve from where you are to where you need to go, a COE is an industry tried and proven method of evolving. After you have the COE in place and are able to measure planned versus actual results against standard, you may then be ready to move to a more expert level of operation enabling self-evolving teams, projects, programs and organizations or entities.

Standards enable prosperity through predictability. And in many cases, 'how' said standards are implemented and evolved is a better conversation for entity health than questioning 'if' they should be implemented at all. We need only review the fruit of labour to discover whether we should or should not. Keep in mind that a COE is only a vehicle for standards management and relevant only when chosen. The more important conversation is the standard itself. Without standard, humanity and society themselves are not even capable of purposefully evolving towards a common goal.

Imagine a country (or other entity) without standards.

Imagine a country (or other entity) with expansive, industry-agnostic, industry-specific and self-evolving standards fostering predictable, forecasted prosperity.

Choose.

Of course not choosing a standards based situation is choosing the inverse. The next question may then be, is this on purpose or accidental?

Making a Plan, Making a Decision

There is a chasm between making a plan to do something and actually doing it. I've been in Zimbabwe for eighteen months and have heard the same (and sometimes different) people discussing the same ideas over and over and over and over. I have some favorite requests that I receive and thought I'd pass them along. They include, always in document format, the following:

  • Please provide a five year business plan;
  • Please provide an architectural design plan;
  • Please provide an implementation and roll-out plan;
  • Please provide an organizational change management plan; and
  • Please provide a plan.

There is nothing wrong with a plan. However the plan is not the item of worship. In fact, the moment the plan is constructed it is rubbish anyway -- stale, out-of-date, yesterday's news with yesterday's context. The item of interest is the execution. The action.

Any ten-year old kid is capable of constructing a plan. If you want deeper levels of consideration including risk, issue, mitigation, dependency, estimation and the like, you'll need to go with someone who has more experience in life and project efforts. However, even after having a very thorough, very well-thought out plan full of pages and pages of diagrams, bullet lists and impressive fonts, the plan is only a plan. It doesn't get up and implement itself. The plan can't put together a team, build a product or deliver it to market. The plan only talks about what people are to do. And the older a plan becomes before someone attempts implementation of any sort, the more rubbish the plan contains. Circumstances change, people, budget, needs, risks, dependencies, etc. The older the plan, the more rubbish it contains.

I'm not impressed by your car, suit, ring, watch, glasses, haircut or university degree. I'm impressed by your ability to actually do something or otherwise get something done. None of us are getting any younger or better looking (despite what the media tells you), so we either need to actually do something or get out of the way for those who can and will.

As for me, I'm moving on. I'm tired of talking. I want action and result. See it. Plan it. Do it. The focus is on do it. Talk is compost. Even then, compost actually benefits the soil promoting growth. So maybe talk is not equal to compost. Interesting.

Living in a Bubble

Living abroad, I often hear people talk to me about Americans who don't know there is anything going on in the world except from within the American border. Baseball isn't really a 'World Series'. Football is soccer in Brazil (Brasil, Brasilia) and Rugby is considered to be a real man's hard-hitting sport when compared to American Football with all the padding, helmets and so forth. Field hockey, Cricket and Polo are considered international sports by anyone who talks to me. One person told me that he enjoys watching American television because we are masters at creating false realities and 'what-if' scenarios. I've had people mention their love of our innovative spirit, the fact that infrastructure simply works and the unique fact that 50 individual states are joined together to construct one country, as opposed to, 54 countries co-existing on one continent, yet unable to work together. There is a lot to admire, love, respect and learn from when thinking about the US. There are also important lessons to be learned when studying the US or any other particular country, region or continent.

The fact remains that at the end of the conversations with so many internationals, I'm continually challenged by others to see if, for all the other great aspects of America, I'm capable of seeing things from another perspective than purely the United States of America. One person even told me they believed most Americans had no chance of knowing about the world because we learn about everything through the Discovery channel, CNN and Fox News which are all conglomerate owned and orchestrated. "So", as I was told by an associate just days ago, "unless you guys leave your borders and go see the world for yourselves, all you really seem to know is what you're told by your government and by your media institutions." I've heard it before. There is truth in the statement. And when an American friend of mind rebutted with, "We have everything we need inside the borders, why go out?" the idea of a bubble was validated.

The larger issue for all of us, any of us, is that we have to choose to see outside the bubble in which we live. Personally and professionally, our ability to understand what we see, hear and experience on a daily basis is all mapped into the library that is our minds. A library full of personal experiences, experiences communicated via friends and families and even experiences we glean from television, music or movies. The size of our mind-library is moldable. We are able to continue putting things into the library, in which case the library expands. As we group experiences into like categories our perspective on what "Africa" is, or what "foreign policy" means, or even what it means to be an oil-based economy often makes more sense as we gain data. In fact, after we have more and more data (and we've assumedly verified the source of the data) we may even begin to realize that what we considered a 'truth' or 'reality' is a gradient or more different from our original definitions. What if more data helped us realize that we had it wrong?

"The size of our mind-library is moldable." Unfortunately, for as many people there are continuing to put more and more data into their mind-library to evolve constructs, theories, paradigms, definitions and world-views, there are also people out there that don't. Simply characterized, there are many people floating through the ecosphere we call Earth who don't have access to additional data, don't desire additional data, or believe that someone else is going to learn it, think through it, synthesize it and go fix or change it if necessary. Some people may not even know they need to challenge information provided by governments, corporations, religious and political leaders, trusted friends, media outlets and the like. Some may not know the bubble could be bigger. Some people may accept, swallow and digest whatever is fed them. Regardless the situation, each person tends to define their reality by what they choose to see and what they do not choose to see. This reality is their bubble.

The next time you're trying to figure out why the person you're having trouble working with is so inexplicably stupid, consider an additional theory. Perhaps it has something to do with the bubble. The next question may then be, is it their bubble or yours that requires expansion?

Writing, Craft and Journey

Freshly back from a course discussing how to build flourishing companies based upon the Theory of Constraints (TOC) by the Goldratt Institute itself, I wrote a new book discussing how to create a strategic and tactical operational structure for software and technology companies blending TOC, General Systems Thinking and Agile. The book material is being peer-reviewed by colleagues on three continents and I've noticed I'm receiving starkly different feedback from each setting. All of the received feedback is constructive. And particularly interesting to me is the fact that the feedback is very different. All of the feedback is valued and is not the point of conversation. However, the difference in feedback polarizes a conundrum for me. Am I writing to sell? Or am I writing to organize my thoughts and use the material professionally in my consulting work? Ideally, are they the same?

While I've been in my profession for just past sixteen years, I've really only been writing purposefully for a little over a decade doing articles here and there, blog-posts, research papers, one published book, one soon-to-be published book, have been working on a dissertation thesis proposal for about six months, as well as, a movie script for three years. Upon reviewing the different types of writing I've involved myself in through the years I realize I've written with different tact depending upon the purpose of the material. However, at no time have I purposefully structured something to sell. Why? I wonder.

Articles that I've written have always been on request of someone else, have a fixed thesis, word count, audience and well-defined purpose. I know why I'm writing, what I'm writing and am able to craft the material to accomplish the goal as specified to me. On matters in which I have experience, education and am inspired, I do not struggle for words or points and the material flows through my fingers quite quickly. By experience I've found that I do not enjoy writing about subjects in which I have no personal interest, whether educated and experienced or not and I'll politely decline the opportunity to submit a writing associatively. If I'm not inspired, I cannot produce something that even I am interested in reading.

Blog posts are usually instructive, often temporal soap-boxes stimulated by a current reading, situation or experience. Sometimes I may start a blog article and soak on it for days, weeks, months and in a couple of cases, years. However, in the end the blog articles I publish are usually about something of which I have a current, direct interest. And as I've said before, if I'm interested in it, I have no problem researching, thinking through or constructing an argument. In this case, however, I have no defined audience or word count even though there is a thesis and a series of points. I'm temporally passionate about the material and therefore able to construct it without much effort and publish it thereafter.

As for research papers, they are just that. Particularly for graduate work, we were ordinarily challenged to take a thesis, pick one side of the argument and construct or deconstruct the argument in a defensible manner. On subjects that were of no interest to me, I often struggled to pick an argument, perform the research and write a paper that even I was willing to read. Who would seriously want to read material on this matter? Of course, there are people interesting in the subject I would find, hence the significant research materials available to me. Nonetheless, when I was intrigued by the subject, research, analysis, construction, delivery and defense were no effort for me. I loved it. When I was not intrigued, I scraped and crawled through the experience because I ultimately needed the grade. I can read my own material now, years later, and tell you by the sentence structure which subjects I wrote out of passionate interest and which ones were to get a grade.

My first published book (2006) was constructed based upon a passion. That passion was built upon the idea that not enough American programmers, IMO, were globally competitive enough to prevent or mitigate their jobs being outsourced to India at the time. I came to believe that were a programmer more business-literate about all the people, purposes and results around him or her, he may not only still have the job, but be leading the outsourced, insourced or otherwise non-changed domestic team delivering products and services to customers. So, I titled the book, "Becoming Globally Competitive in Software" believing that my target audience was the American technologist who would lose his job unless his eyes opened wider to understand whole company value, not just code level value. I wrote the book in very casual, even loose, conversational manners with each chapter covering a subject in a company that all technologist should be aware of and know. Because I wrote it in a very casual, non-pomp and circumstance manner, I added the sub-title, "The Fundamentals for Regular People" to let people know that this book wasn't a boring academic book, but rather something in layman's terms that anyone could understand. Incidentally, I was later ripped by a college compsci department chair who said the book was too casual for academia. At the end of the chapter there existed a "Top 10" list of items you should know no matter what. If you were familiar with purpose, context and content on this list, then you'd be more cognizant of whole company value and not just believing compilable code is your gift to mankind.

Really the book, as I've soaked on the material now for years, is only written for Americans. In order for this material to be a globally accessible book, I need to remove all the purely American connotations and illustrations for the material to transcend culture and context. I didn't realize this fully until living outside the US for an extended period of time. I'm rewriting the material now with the intent of re-publishing, though I've noticed my passion for re-writing old material is not present. And to change the dimensions of the book I have to resubmit to the Library of Congress and get a new ISBN. All of this because I had a temporal passionate argument that now haunts me. A published book is so finite. Yet the material and people are ubiquitous. I learned much from this first book. I learned that there are different kinds of audiences and particularly that some in the audience are critics of a particularly bristly kind.

The second book, constructed in May 2011 and soon to be published, is built according to feedback I received on the first book and how I learned to research and write differently during my masters program using the American Psychological Association writing style. The material I am passionate about. The construct of the material is written in such a way that it is immediately applicable in most any organization as a pattern, though not just in the field of technology. I've received some interesting feedback, grammar and typos assumed. One type of feedback surrounds the material being too formal. The other, taking too long to get to the point. In fact, one well-seasoned PhD professional (not an academic) told me he was falling asleep and struggled to stay with the material...as if he were reading university materials again or something from a government financial institution. Another peer told me to get to the point and stop explaining things in such detail. Another said he just wanted a bullet list and to move on. What I've noticed is that the well-seasoned tech-heads are asking for two things: a) get to the point now, and b) make it conversational. While they may already know some or most of this material, they may not have seen this material synthesized and presented in this manner. However, they are highly educated, experienced and knowledgeable enough to see it, eat it and use it immediately. In fact one of these guys could have been shown on a napkin at lunch and written the book himself. Detailed explanation to this group of people is a waste of their lives. They are swift enough to drive-by, see it once, use it this afternoon and evolve it in their sleep. I noticed these people are all either trained in or living and working in the UK or US and are in their late 30s, 40s and 50s as career, hands-on technologists.

The feedback I've received from some middle-European colleagues has pretty much said that, other than some stylistic considerations and needs for clarity here and there, it rocks right now and to get it published already. Same age group. Career hands-on technologists. And to throw it off a bit, some feedback I've received from some African colleagues suggests the detailed explanation of the material is necessary and that after reading the book they want to know more. In a couple of cases they suggested the material is new enough to them that they don't have the background to see it, eat it and use it and would need a consultant to come in or a second book with detailed implementation mechanisms.

All this feedback, so far, seems to suggest that unless I'm writing about humanitarian universals such as food, sex, exercise or hair loss, the demographic response for this material differs by age group, years of hands-on-experience, education and continent. This then suggests that to publish to Africa is a different behavior than publishing for the US and UK. And to publish to middle-Europe, the material seems to be somewhere around 'useful' as is. I am intrigued. Of course more data points would yield a better developed trend, but the journey itself is teaching me about writing in an unanticipated manner.

And as for the movie script. Well, I figured being from the career technology industry myself, having a master degree in diplomacy and the common themes of information security, cutting-edge technology, espionage and nation-state building, protection and deconstruction I could summon up some ridiculous creativity and write something that seems so far-fetched it had to be true. I started writing it while in the US and believe that the insight I've gained while living abroad will enrich the material's details. I know I'm not going to use APA, academia or other R&D rubbish I've learned through the years, but rather simply write as I write letting the material flow. Of course, as I've learned with all the other writing experiences, there is audience, critic and so forth. However, my passion lay in constructing the scenario themes, infrastructure and primary activities and experiences. However, I find that character development is hideously tedious. I like understanding a character. And I've thought through the characters multiple times, but the characters more often reveal themselves to me during the writing. I'm enjoying the thought games. Makes me laugh. Stumps me. Forces me into clouds of structured thought all alone while sitting in crowds of people. Makes me half-grin with what I believe is cleverness to later realize it was a stupid thought.

At the end of this writing about writing I've decided that I'm more interested in the intellectual journey of thinking and developing thought which can be applied than I am in constructing a book purely to sell a million copies. In fact, the movie script is really about me enjoying the thought journey. Whether it ever goes anywhere past my laptop we'll see. I've recognized that I like to write in order to think. Writing organizes some of my thinking. After I've thought through it I'm better equipped to do it. However, I've also noticed that after I think through it and document it, I'm not interested in revisiting it (rewriting the material). Forward progression is what I constantly seek. Loitering on an old subject is uninteresting to me. So writing is about thinking. This article is about the journey of writing. Many seem to define success by the number of copies sold, which is monetary and I suppose perceived as an end-state by some. I've decided that I'm more interested in the thought journey than the money. Bummer for my wife I suppose.

A parallel interest to me is that laying down code into a file which constructs a user-interface or lower level behavior requires similar creativity and stylistic discipline. Not just creativity, which is stylistic and subjective. Not just discipline, which can be unimaginative and structurally correct while usefully miserable. Both. Laying down code requires both creativity AND discipline. Disciplined subjectivity built on passion, interest, education, experience, structure and intended audience or purpose.

If I consider 'writing' a craft and the journey itself as my educator, it suggests I am constantly seeking knowledge and experience fostering evolution. If there were ten extremely creative, experienced screenplay writing craftsmen in a room responsible for constructing a new super-screenplay, harnessing all of that creativity and energy into a focused direction would require its own experienced, educated and salted leader who loves the craft and the journey as well. With like-minded journeys and experiences, coupled with creativity, focus and discipline, we would have a higher probability of yielding a positive result enjoyed by others as a wonderful by-product. Money may or may not be a by-product of this journey, but could realistically be so. 'Tis interesting to me then that discipline and creativity imbalances within the team would impede output. And a wrong leader (money-chaser) in that role would most likely destroy the team's (craftsmen) ability to produce.

It seems reasonable to then suggest that pursuing money generates a different professional and product than simply enjoying the journey of evolving the craft itself. Sure, the conundrum. So when we look at team construction, leadership style, method and delivery of any product or service, I suppose we really shouldn't be surprised by the differences we see in results or result quality. Some people pursue their craft which yields money as a by-product. They seem to be the few. Others appear to pursue money assuming they can generate a craftsman-like deliverable as a by-product.

Craftsmen are more likely to accidentally generate money than money-chasers are to accidentally generate a good product. Is the conundrum really 'journey' OR 'money'?

I'm tired of thinking through this. I may just take up painting. Of course then we'll have to argue over that too. Is code, art? Sheesh.

Managing Flow

I recently finished some coursework through Goldratt Group in Israel teaching me a myriad of elements regarding consulting behaviors built upon the Theory of Constraint (TOC) implementation while minimizing distortion between the points of a) theoretical application and b) real application in a production environment. Particularly, 'Viable Vision' and how to build ever-flourishing companies through the application of TOC.

Now I've read Goldratt books before and have evolved my own worldviews on TOC through the realities of product to market supply chain work in software. In fact, having read and applied various aspects of multiple books on the subjects of Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Continuous Integration (CInt), Continuous Inspection (CInsp), Continuous Deploy (CD), Continuous Test (CT), Kanban, Crystal, Scrum, and Critical Chain Project Management (CCPM) I have to say that I've not only read about it, but I've synthesized it and applied it in varying production environments with varying teams to varying levels of success. And I have a number of realizations as a result; five of which I cull out for this conversation at this point:

  1. Is it very easy to achieve local optimizations at the expense of end to end flow;
  2. Human Resource organizational structures (people management) impede operational effectivity;
  3. What worked at the last customer (or on the last project) will not work 'as is' next time;
  4. Everyone wants to achieve flow, few people know they want to achieve it or how; and
  5. There are principles and patterns that transcend industry, yes; however there are then industry-specific killer idiosyncrasies that require exclusive knowledge and experience in order to understand and influence said industry.

Of course, there are more. This is a blog.

I've been working on a new blog post regarding this matter for some time. It turned into a book. So, now I'm working on a book regarding TOC application and evolution within software. The point and purpose of the book is to elaborate on a synthesized solution model for software companies, not software groups. We already have rockstar development groups at many companies. It is the flow of the company that is the problem, hence the book.

TOC is not software explicit, but rather a behavioral-thought framework that is intended to be industry agnostic (even though "The Goal" seems to be production focused, it is not envisioned as such). CCPM is project focused, but not software evolved. Viable Vision is designed for a company level goal using TOC and CCPM behaviors therein. There is application to software companies, even companies who don't think they are software-driven, but have large IT/ICT shops.

I've looked through the books available through Amazon. There is but one book by David J Andersen in 2003 discussing TOC and software. Otherwise, the field is seemingly blank. If I've overlooked what you consider to be pertinent material applying TOC to software, contact me through LinkedIn. Yes, throughput economics counts. Not even the Goldratt Group has produced declarative publishings on the matter of software TOC applications yet. So, it appears we've an under-developed space. Of course this assumes you know about TOC, what it is and understand it isn't another "consulting template", but rather a framework for increasing flow. Perhaps it is the fact that 'The Goal' seems manufacturing-centric coupled with an absence of TOC understanding by anyone outside manufacturing that speaks to this.

What are your thoughts? More later.