Long-game Strategy

Most people have the will to win, few have the will to prepare to win. ~Bobby Knight

I've always liked this quote from Bobby Knight and have always been intrigued with his mind. His career as a basketball coach and leader spanned forty-six years with 902 wins and 371 losses second only to someone who was trained by Mr. Knight, Mike Krzyzewski. People often characterize Mr. Knight as "strict, disciplined and devoted". Some even suggest "maniacal". Regardless interpretation, the fact remains that he knew how to win.

One of the most important things I remember about Mr. Knight was the focus on fundamentals, fundamentals and more fundamentals. His reputation even existed in gyms he'd likely never been. My own basketball coaches in the 80s were influenced by Mr. Knight's practice regime and had us focusing on ball-handling, physical fitness, man-to-man defense, motion offense and more ball-handling and physical fitness. While we wanted to be selfishly running, gunning and getting glory as the star player, coaches had us doing line-touches, dribbling, passing and defending while preaching selflessness at every moment.

Even though I've never met the man, what I learned from Mr. Knight was that winning takes about three hours per game. Preparing to win takes every moment, between every game. Said preparation requires unfaltering discipline. Predictable, repeatable, bet your whole career on it, discipline. Discipline in the fundamentals leads to the wins.

Particularly what I believe I learned from Mr. Knight is that the wins were only by-products of the journey of discipline.

You'd think this post was about sports. It is about life philosophy. It is about work ethic. It is about behaving every moment the way you want to behave when it matters most.

There are fundamentals in software systems and teams as well. Defining the problem you need to solve before defining the solution. Decomposing the solution path into iterative, digestible elements that are predictably and repeatably delivered in timely, quality-defined and driven manners. Continuous integration, testing, inspection and delivery. Having a behavioral framework in place which helps you understand planned versus actual results and how you can evolve for the next game. Patterns, precepts and practices. Fundamentals. Daily practiced. Daily improved. So that when it matters most, it's just another day.

Many, many, many people want to stand up on a stage or out in the middle of a floor to receive attention, reward and adulation. But only a handful are willing to apply the long-term, daily, tedious, fundamental discipline to get there.

Another of my other favorite quotes from an interesting mind originates with Ralph Waldo Emerson.

Life is a journey, not a destination.

I think this is what Bobby Knight was talking about.

Seasonal Polyphenism

One of the interesting hives of thought that has always consumed me is failover, redundancy and scalability. In other words, NINES availability. The interesting irony is that a conversation on NINES is dust in the wind absent a list of pre-requisite decisions and behaviors.

These choices,centered around building team, company, product and service, are outstanding intellectual challenges I enjoy. Doing well at these elements is to head in an important and correct direction. Building usefulness. To believe that having these in place rocks the earth like nothing else is shortsighted. These elements, while critically important to our birth, existence and evolution, are merely foundational steps prior to moving to the next step in our morphology: unconditional availability.

{
IF we have a system that people want to use
   THEN it must be available for consumption
ELSE we will have no customers or revenue
   AND we will have no need for team, company or product;
}

Sure, we can slice up the conversation multiple ways just like our technical stack. Pre-caching, load-balancing, web-servers, UI/UX, logging, languages and libraries, databases, cores, storage, physical v logical server farming, distributed topology and so forth. Choice flavours? Combinations? Conditions? What comes first? When to proactively versus reactively evolve? Religion? Science? It isn't a technical conversation alone.

We can additionally argue there is no need for system without product. No need for product without the key feature. No conversation of company without team, nor team without transparency as Lencioni rightly articulates. Decisions without numbers. Numbers without traps, hooks, filters, loggers and sniffers. And so forth. Rabbit holes not necessary to traverse unnecessarily. Perhaps the conversation might not be facts, figures, features and behaviors alone either.

Determining product, service, company, culture, market, approach, definitions of done and success are nothing less than a sojourner's paradise. Individually, each composes a metaphorically self-encapsulated ecosystem. Together, they become something more. A system. Dependent. To evolve, each must remain adaptable. To be adaptable, one must be available. Autonomy is therefore dependency. Dependency on sub-system polyphenism.

My current work further validates what I already believed and continue to enjoy as a life principle. Polyphenism. Context-driven adaptation or seasonal polyphenism. To become what is required of you contextual to the time and situation requires adaptation. Polyphenic behaviour assumes recognition of seasonal system attributes.

I could easily belabour the point. For example, can the evolution of a sub-component kill the sub-component itself? The system? Can evolution of the system make a sub-component irrelevant? Can lack of evolution devalue and kill a sub-component which kills a system? An excellent conversation.

To discuss my favorite systems engineering subject, availability, assumes system, component and element-level polyphenism.

To be a part of such a an adaptable, evolution-capable system, assumes sub-system polyphenic abilities. And sub-systems are composed of individual sub-assemblies and finally, elements. An element in such a context includes you and me. Absent polyphenistic attributes, we're nothing but a bunch of Dodo birds.

Just for fun, was the Dodo an element, sub-component or itself a system?

How about this for an answer: no matter the size of the ecosystem, to be a healthy system, you never get to be just an element and only an element. And to have useful conversation and action regarding NINES, you need to know the answer to the question.

So I'll ask the question again, differently. Was the Dodo an element, sub-component or itself a system? And did the Dodo exhibit polyphenic characteristics? I'll help you a little bit, the Dodo is extinct.

Solving Unstated Problems

Always interested in the big picture, through the years of my career I've tended to focus on system level observations by default. Listening to a customer discuss a component level problem within a company, team, project or product, I no longer consciously look for system implications. It just happens. Ishikawa diagrams self-generate, IF-THEN conditions line themselves up, risk-reward lists and COO/COA/ROI math begins to reveal itself and I may even begin considering possible feature sets, priorities and the like dependent upon my previous night's sleep and morning caffeine intake.

So while the customer is telling me about the problem of employees stealing information using memory sticks I'm naturally thinking about IP, Infosec, physical security, authorization and authentication, system activity logging, net traffic logging, employee contracts, local law and the social implications of getting caught in this environment. The customer? The customer is thinking about employees with memory sticks.

Consulting is sometimes hard. In my experience, cross-cultural consulting, particularly in unlike cultures, is harder.

If in one culture, we are paid to be assertive, be capable of justifiable confrontation, think about the system, mitigate risk, eliminate waste, argue solutioning options and choices, as well as, sell why we are the most fiscally responsible and viable solution provider for a problem, we obviously tend to behave in this manner and even amplify it through the years. Uninhibited, direct, complete, accurate, now.

If in another culture where questions are valued more than direct statements, near submissive-humility is valued more than direct frontal assaults, pronoun choices make or break the conversations, listening is valued over talking and solving a component level problem is the only thing that matters irrelevant of system implications all set in a community-relational setting, it is something we must then learn through preparatory study or risk blowing up the opportunity and relationship in the time it takes to consume one cup of tea (or less).

Understanding the socio-cultural differences between the consultant and customer may turn out to be more important than anything else and we need to know this before the meeting, not during.

According to Sun Tzu, understanding the enemy better than one understands self is critical mass and the key to success. In international relations, understanding the potential partner or customer better than one understands self has a critical place in long-term, viable, sustainable success. To defensibly understand the details of one's industry, company, product, service and team and be capable of direct frontal face-off leading to a win is excellent if that is the characteristic of the culture and people group in question. However, it is your finality if the people group in question values extended relational conversation and community over individualistic, bullet-list drive-bys composed of succinct, fact-based presentations.

For years we've discussed that the customer doesn't know what they want until they see what they don't want. It remains true over and over again. I've recently learned the statement is assumptive.

The assumption lay in the belief that if true, then we'll experientially understand the solution path journey that lay in front of us including COA, COO, ROI, scope shift, defect density potential and % rework from multiple paths. This intelligent, experienced understanding that we have is culturally context-sensitive. It doesn't transcend socio-cultural variation.

Useful for cross-cultural consulting, the customer not always knowing what they want until they see what they don't want may continue to be a true statement and may continue to transcend unlike cultures. However, understanding the follow-on solution path potentials, risk and financial implications thereafter does not transcend and has critical socio-cultural implications. The fact that there may exist multiple solution paths, there will be risks, rewards and rework does transcend. Anticipating how to effect the solution is culturally contextual. One size does not fit all regardless what our efficiency math suggests. Even franchise models have cultural variability.

The best example I have of this right now is an executive, in a culture strikingly different from my own native home, asking for help with a memory stick problem in his corporation. Over a meal that discussed life more than work and took three hours, his desired solution was to mitigate risk by putting virus scanners on all memory sticks as policy. The problem statement that I thought I originally heard was a form of corporate espionage, particularly IP leakage which required immediate responsiveness. The problem the customer ended up articulating was virus infusion through poorly managed memory sticks. So, we agreed on the problem of poorly managed memory sticks. However we were oceans apart regarding the implication of poorly managed memory sticks. His real concern for now was the introduction of malware, viruses and the like.

Why were we so far apart? It went like this:

The customer told me he was having problems with employees bringing in personal memory sticks, sharing personal data from home to work computers and then sharing between themselves and other employees. As he talked, my mind shifted into action. I thought about company property use policies, IP protection, systems management, network management, logging, sniffing, illegal distribution of data, elimination of memory sticks and so on.

Do you know which problem bothered him most? Inoperable computers. The introduction of viruses and malware into his house had made many computers inoperable. His communicated problem statement: preventing inoperable machines by mitigating virus and malware introduction. His desired solution was the installation of virus software on all memory sticks.

I disagreed that this was the greatest problem statement. I further disagreed that the posed solution statement was the correct path. I believed memory stick utilization leading to IP leakage, espionage and foreign controlled machines was of greater importance.

In the end, a contract could be had if the problem and solution statement verbiage, as well as, follow-on action, matched that of the customer's desire for virus and malware software on memory sticks. In the end, a contract would not be had if it were to discuss and deliver IP protective measures. All of this over an extended relationship journey requiring food, drink, conversation and relationship.

Customers communicate what is bothering them. And customers then understandably want that which is bothering them to go away. Anything less is failure.

To the customer, this component level or even elemental level problem is currently their systems view. We can challenge it. However, until this particular plank is removed from their eye in the form of delivering that which they asked, they often won't be interested in seeing what we believe is the true forest.

Now, add to the complexity of the relationship by discovering the customer wanted a relational, community based interaction with you that required food, drink and laughter. It is only then, after you additionally failed to recognized the customer's component view is their system view, that you recognize you've only brought armor, a shield and a sword covered in dried blood in your kit when they wanted tea, biscuits and a meal.

We can win or lose a contract based upon our ability to hear the customer well enough to solve their problem according to how they want it solved. However, unless we explore and seek to understand the socio-cultural idiosyncrasies of the customer if different from our own, we won't make it past a cup of tea.

Incidentally, the entire relationship hinged on my use of the word "we" and never the use of "I". In an individualistic society, "I" is expected. In a community-based society, there is only "we". The use of "I" facilitates social expulsion.

One pronoun separated me from contract and it had nothing to do with my career, education, experience or skill-set. I hadn't done my research. I didn't get the contract.

Big Iron Software, Part 5

Iterative, autonomous software evolutionary behaviors. What are they and why do you give a rip?

Very simple. Without them, you're practising old-school, big-bang, very expensive methods of command and control deliveries characterized by high administrative overhead, long-tail deliveries, miserable response to change-request time tables, missed market opportunities, high-defect densities and completely bogus status reports detailing effort to return rations with allegedly quality metrics. Sure. Sounds like subjectively exaggerative descriptors?

The next great game is not hardware. It is software. It is artificial intelligence. It is autonomous decisioning systems.

  • Blood re-circulates the body 60-70 times/hour in a healthy person at rest.
  • DVD player disc revolutions are anywhere from 37,800 to 91,800 revolutions per hour.
  • Hummingbirds flap their wings about 200,000 times per hour.
  • The Ford St. Thomas plant asserts 62 completed passenger cars delivered per hour.

Question: How long does it take you to move production-class software to market?

Don't give me all the reasons, regulations, complexities and enormities of why it takes as long as it takes. I don't care. I'm not working at your company. Since you are, be honest with yourself. Why does it take as long as it takes?

Next Question: How much does it cost? (If you're moving software/hardware integrative systems, how much just for the software piece?)

There are a number of things you can do to implement a continuously evolving software system in your company. How frequently the software is evolved internally versus moved to public production are two completely different conversations we can and will comfortably decouple.

Continuous Integration

Implementing a system that continuously looks for new code, continuously builds the new code into the existing code base and tells everyone when the latest received code breaks the previously known-to-be-good source bundle is one of the easiest methods of moving from a command-and-control manual system to an autonomous one. Set it up once, run it forever. This assumes your teams are *all* using version control.

Continuous Test and Test-Driven Development

Automated test-driven development is another facet of this continuously evolving structure. Tests are written first based upon specifications. Code is written to prove the test fails. After the test agreeably fails, code is written only until the test passes and you are done. No need to over-engineer the solution for a myriad of reasons including defect insertions, feature and function specification creep and unwanted monies spent with no ROI potential. As the code is checked-in as 'completed', the automated test(s) are checked in as a single unit. When the build routine looks for new code, it finds code+tests and kicks a compile. If no tests, no compile and new code rejected. If code compiles, test. If tests pass. Keep going.

Continuous Inspection

Implementing another facet of this system includes continuously inspecting the code against a set of previously defined standards. For example, naming standards, cut and paste (duplicity), complexity, uncalled code, traceability to change requests, information security alignment and anything else important to your team deliverables. Every time new code is checked in, it is sniffed out against the pre-set standards. New code, compile. Clean compile, test. Clean tests, inspect. Clean inspection, notify the house. Failure on any one of these elements, notify the house and reject the newest code submissions.

Continuous Deployment

And what about the ability to deploy on-demand, specifically, continuously? Yet another facet of this mechanism. Deploying to downstream test systems, customer acceptance test systems, sales and customer support test systems, production beta sites and/or live production systems is at-hand. The same routines that check for new code to compile all the way through testing, inspection and notifying teams about new package readiness is also capable of moving the package into a testable or production usable environment and state, continuously.

If new code, then compile.
If clean compile, then run tests.
If clean tests, then inspect.
If clean inspection, then deploy.

And how fast does this all happen? Well, the answer is relative to the size of the compile, number of tests, number of inspection checks and deployment terminating points. However, it is very reasonable to see all of this happen measured in minutes, multiple times per hour. In other words, while we may not yet be as fast as hummingbirds, we today have the capability to move new software to production in a measurably tested and validated state multiple times per hour without people. In other words, we could reasonably perform over-the-air software updates to navigation, integration and operating systems in cars, tractors and other assembly-line deliverables in hours.

Question: Why aren't you?

Sure, there are some operational, organizational dependencies that you need to solve to get here. For example, if I can generate a new, working software feature in less time than you can generate a document talking about it, why are you generating the document?

Furthermore, why could a team not already be delivering working, tested, inspected software modules every thirty-days as production-ready candidates while I'm still spec'ng out new feature requests? Why do I need a full list of feature requests prior to starting anything? Doesn't this seem like an assembly line behaviour to you? Smaller batches, higher throughput.

The ability to deliver a software system in a matter of minutes and hours, exists. Compiled, inspected to standards, tested to specifications and deployed. All autonomously. If you're still spending months eliciting requirements, designing possibilities, manually inspecting, verifying and validating then you're competitors are not only going to beat you to market and take more market share by exploiting your absence, their margins will be superior as well. We can religiously debate process all day. It is the money math we're really discussing.

Either you can move software to production as quickly as a completely functional car, tractor, grader or drill or you can't. Simply looking at your software request backlog and budget to actual financials coupled with production support reports will tell you the whole story.

Now, when do we decouple software from hardware delivery velocities/methods and when do we recouple them? Let's keep going with this conversation.

1 | 2 | 3 | 4 | 5

Big Iron Software, Part 4

Managers and Project Managers expert in standard project management bodies of knowledge and management theory are absolutely capable of making a shift to flow-based iterative software engineering behaviors. The required organizational cultural shifts, behavioral shifts and daily operational practices will be different from predictable, repeatable manufacturing bodies of knowledge and different from text-book PMI and Prince2. The limiting factor, while expectedly challenged by cultural, political and bureaucratic complexities, will actually be two personal limiting factors:

  • The type of experienced manager or project manager who is old enough to believe they've already learned what they need to know for success and therefore already understand something insignificant like software; and/or
  • The type of person who is unable to admit inexperience, uses an opaque interpersonal management approach, and believes command and control leadership structures were the only chapter in the management theory books of use.

A person with previous experience, education and developed skills who doesn't know anything about software is capable of learning and evolving. The limiter will always be themselves and their ability to adapt.

Were I to have an enterprise software program in a legacy hard-line manufacturing company that over-spent, under-delivered, underwhelmed or consistently delivered something less than my competitors, the first place I'd look every single time is the leadership. Obviously we'd assess the teams and behaviors, specification behaviors, organizational prioritization and commitment history and practices, marketing and sales impacts to the delivery chain and more. However, Step 1: Leadership. Why?

Leadership defines goals, aligns enterprise portfolios to said goals, defines operational behaviour paradigms to meet those goals, and generally makes or breaks an organization's ability to deliver through their leadership style and the other leaders with which they surround themselves in the name of, ironically, leadership.

At the project and program level, it makes sense to understand risks and have plans/theories to mitigate them. Issues? Remove them. Dependencies? Accept them where necessary, change them where possible. Task-based effort estimates and roll-ups to larger deliverable units of work? No problem. Reporting, status reporting and the like? Sure. So what's the problem?

The problem lay in the employed mechanics of controlling the delivery versus the deliverables and throughput flow. It is a classic paradox. The mechanics employed to control the delivery actually break the deliverable.

Theory of constraints, lean manufacturing, kaizen, kanban, just in time and any other flavour of manufacturing efficiency you'd like to throw in there are built on the premises of:

  1. maintain system level flow; and
  2. eliminate anything that inhibits or otherwise precludes system level flow.

Were leadership to, through frequent iterative practice, constantly evaluate the system flow looking for process and procedural waste, the system itself would identify those things within itself precluding, inhibiting or otherwise subverting flow. The only reasons this won't be apparent is:

  • The evaluators are looking at components of the system, not the system itself;
  • The evaluators are protectionistic believing the system problems are with other people's components.

Take the principles of flow already achieved in successful assembly line environments and apply the idea of flow to software. Look to Henry Ford, Taiichi Ohno and Eli Goldratt to understand assembly line flow. Only then are you prepared to abstract these concepts into the software realm. Prepare yourself, they look the same. They aren't. And the leaders, managers and project managers who can't see this will contribute, in the terms of successful manufacturers, waste.

Let's talk about iterative, autonomous software evolutionary behaviors for a moment.

1 | 2 | 3 | 4 | 5

Big Iron Software, Part 3

Before we go on, let's qualify what we're discussing a bit further.

In terms of manufacturing company types adopting software, we're discussing successful legacy mobility manufacturing companies that produce cars, trucks, bulldozers, tractors and directional drills upon what most of the world currently relies.

In terms of types of software, we're discussing user-facing software, as well as, control and embedded package types.

The reason for this explicit focus is built upon a single premise: though historically successful in assembly line manufacturing, these legacy companies will not successfully implement a software:hardware integrative process. The reason? Coming off decades of successful hard-line products and assembly line efficiencies known the world around and believing that few things on earth could be as difficult as hard-line assembly, these companies will be inclined to under-value the complexity of software production, delivery and support. Resultantly, software will be over-engineered in terms of features, under-engineered in terms of quality as defined by the software industry, software deliverable costs as a percentage of total production costs will sky-rocket and customer satisfaction for once-heralded products and companies will inevitably decrease. It doesn't have to be that way.

Let's look at the first of six aforementioned steps: Decouple software from hardware.

There are multiples areas where software must be decoupled from hardware:

  • The process and procedure for designing, developing, testing and delivery
  • The process for embedded versus control versus user-facing software
  • The process for Day 02 production support
  • Management
  • Project Management

Design, Develop, Test and Delivery

Typical mechanical design today lives on visual design. CAD, 3D printers and holography as an example. The logic is that a defect in a soft-design is cheaper than a defect in a hard-line prototype. Software agrees with this. A defect found in requirements is cheaper than a defect found in production.

Where design, develop, test and delivery are different is that hard-line production typically is built upon process frameworks known as quality gating systems, based upon Deming's Plan-Do-Check-Act cycle of quality, designed to prohibit product evolution (investment) until it passes at each duly defined checkpoint. Expensive, though it works for hardware. It doesn't work like this for software and in fact is an inhibitor.

In software, waiting until you 'Do' is already too late and expensive to 'Check'. This cycle of quality (Plan-Do-Check-Act) is practised linearly. Software is not linear. In fact, it is concurrent in terms of multiple team members, multiple distributed geographies, multiple code packages and purposes, multiple specifications, integrations, tests and deliveries per hour or less. In software, it is cheaper to mock and stub multiple instances of potential software solutions than it is to build out models in documents and visual design tools talking about working software. Though younger than tool and die hardware assembly behaviors, software engineering has successfully evolved to the point that software is specified, designed, tested, coded, refactored, delivered and generating revenue faster than hardware will make it through prototype, assembly, quality assurance checks and production distribution. The differences are necessary.

Day 01 production delivery. Regardless the cycle-time for software delivery, such solutions are useless without their hardware counterparts. It is true that the software specify, test, code, refactor and delivery loop may be decoupled from the hardware production process giving leadership and teams more freedom to R&D without hardware boundaries. However, production delivery requires pre-production integration and test at the sub-assembly, assembly and system-levels for systems analysis and validation. No argument. Lives of people are often at stake dependent upon end-state system quality. By design, architecture, process and procedure are decoupled from the beginning and later coupled only for Day 01 production release quality control. This means Day 01 deliverables are gated as it is typically practised in legacy hard-line manufacturing systems.

This is where the merging of all deliverable and support behaviors stop in terms of binding them into one deliverable mechanism. Day 01, merge them into a single, iterative release management behaviour. Day 02, decouple. It is at this point in the process that old-thinking will bog down, befuddle or otherwise kill new thinking.

Day 02 production support and delivery. To be delivered to production will require a hardware vehicle. However, were user-facing software systems successfully decoupled from control systems, and control systems decoupled from embedded software systems such as sensors, they need have nothing to do with each other in terms of 'when' delivery to production occurs. Day 01? Sure. Sensor package 1, version 900 is coupled with Control unit 12, version 374 is coupled with end-user software package 13, version 4325. On Day 02? As long as software solutions respect the boundaries and limitations of the physical hardware specifications in production, it doesn't matter. We should be able to update any software package, at anytime, for any reason. However, if we combine them and push them through historical hardware driven quality gates, our operations costs will inevitably increase, customer responsiveness will slowed, and satisfaction? Guess.

In the world of hardware and software integration, the physical boundaries of hardware are the TOC identifiable system constraints. Sure, after a working hardware solution is finally in production, up to 100 units per hour will be manufactured per a static set of specs or static set of fixed-variable specs. Software is not comparable and has even more flexibility than imaginable. And in regards to user-facing software, real-time production change-set responsiveness will be required. Are we really going to send a car or tractor to the garage every time we need to make a software change? Seriously? Software, with a battery of automated tests, inspections and other quality checks based upon evolving specifications, can be coded, tested, validated and delivered in minutes 7x24x365 at far lower COA and COO than anything hardware can currently touch. Not understanding these differences is detrimental to continuing success.

Think about this. Cell phones are activated over the air at the push of a button. Software updates, over the air on-demand or as scheduled. Cars, tractors and the like? Send'em to the shop.

User-facing software changes in near-real-time as defects are discovered, new features are required and as system user requirements demand it. Software system not bearing load? Modify it per collected field data, subsequent analysis then using the spec-test-code-refactor-deliver loop. Get it done in minutes or hours per the same quality standards used for initial production delivery. Cars, tractors and the like? Send-em to the shop or send out thumb-drives. Either guys in the garage are going to need to be senior technical consultants or there will need to be amazingly constructed intermediary software analysis devices or we can eliminate the man-in-the-middle syndrome altogether.

Decouple production delivery and support of software from hardware constraints or be beaten by the teams who figure it out.

Now, let's talk about old project management behaviors and how a manufacturing PM and Manager will not successfully transition to software unless they overhaul their understanding of flow.

1 | 2 | 3 | 4 | 5

Big Iron Software, Part 2

The Goals of Manufacturing:

  • Shareholders: To cast the vision for market share gains
  • CEO: To lead the corporation to the desired market share and revenue
  • COO: To operationally design, deliver, support and evolve the portfolio
  • CFO: To forecast and guide investment and return ratios
  • CMO: To market and sell the portfolio to existing and new customers
  • CIO: To manage corporate information assets internally and externally
  • CSO: To protect the operations and intellectual property of the corporation

Question: Who above should know that delivering software is completely different from delivering a car, truck, tractor, grader or directional drill?

Answer: Everyone. From the topmost Executives to the janitor and back up again.

Reason: The economic, organizational and software delivery models necessary for cadenced, iterative unbroken-flow software delivery requires something new of a manufacturing organization than has previously been experienced with big iron assembly lines. How the teams interact, what they deliver, how and when they deliver, inclusive of moving from cost accounting to throughput accounting will warp some people's minds. The organization, as a whole, needs to understand how corporate culture must change to include software. It is no small feat and will be underestimated by leadership, scorned by existing project management, calculated incorrectly by financiers and resultantly micro-managed thereby making things worse.

If the goal of manufacturing is to produce product that takes market share from competitors and increasingly generates more revenue, there must exist a method to the madness. The typical methods of lean manufacturing processes will not work with software.

People who have grown up, lived and breathed manufacturing success, and are the now current leadership must beware: you must wake up to the fact that achieving flow-managed software delivery is different than typical e-design hard-lines behaviors or you will watch your historical success disappear in direct proportion to your organization's ignorance.

Ironic in this situation is that manufacturers are outstandingly equipped and ready to blend flow-managed software deliverables with cadenced assembly line behaviors. Already accustomed to tooling, retooling, robotic automation, iterative behaviors and burstable delivery batches, the manufacturing industry is experienced enough to get it. Will they choose it?

So we're left with the question of how do manufacturers adopt software delivery behaviours with the same success they've achieved in manufacturing? The default behaviour will be to treat software like hardware. This approach will increase costs, create scope drift, increase waste and ultimately fail with the end-user.

The answer lay in six steps:

  1. Decouple software from hardware
  2. Eliminate old project management behaviours
  3. Implement an iterative software management method
  4. Implement autonomous design/development/test methods and procedures
  5. Recouple software and hardware deliverables for first-time iterative production releases
  6. Keep software releases decoupled from hardware releases, production through sunsetting

Sounds easy. It actually isn't that complicated, though does require an experienced team on the software side of the company, as well as, a willing team on the hardware side of the company. Unless top-down leadership chooses and commits to this organizational change, it won't happen.

Now that we've discussed what, we'll review how to implement the aforementioned five steps in the next post. Our goal is to recognize that combining iterative managed flow software deliverables inside historically successful big iron assembly line enterprises is possible. However, in order to achieve success that end-users care about, the organizational shift must occur from the top to the bottom and back up again.

1 | 2 | 3 | 4 | 5

Big Iron Software, Part 1

The title likely leads you to believe I'm going to discuss large enterprises, large processes and heavy bureaucracies that either don't deliver at all or they deliver poorly from every perspective except the Project Manager's metric sheet. You're right. However, the conversation is perhaps from a perspective unanticipated. What I'm discussing below is the fragile, clunky, fractured world-view evolution of historical assembly line companies into the realm of software. Any person who believes because they understand assembly line flow, they therefore understand software is a fool. Do I have your attention?

While in Israel for some classwork in 2011 I had the privilege of talking with Eli Goldratt one month before he passed away. During that meeting he candidly told me that Theory Of Constraints (TOC) was never intended to be just for manufacturing, though because of his book "The Goal", it was characterized as manufacturing from the published birth of the material. In fact, he originally envisioned it to apply to anything that requires delivery flow. Business, software, hardware and manufacturing are only conversation points. They are all the same in terms of:

  1. they are intended to deliver something according to specification;
  2. delivering according to specification then allegedly elucidates planned revenue; and
  3. delivering with managed flow decreases waste thereby increasing profitability.

We can thank Henry Ford for his ground-breaking work in linear assembly line construction and flow. We can further thank Taiichi Ohno for taking the Henry Ford assembly line model and evolving it into a non-linear pull-by system now known as Kanban. And Eli Goldratt then took both Henry Ford and Taiichi Ohno's materials and evolved them yet further in terms of how to increase system-level flow by eliminating both system and component-level waste. Managing flow looks something like this:

IF managed system-level flow,
THEN planned revenue;
ELSE revenue loss through operational waste.

I discussed this in another blog post titled, Managing Flow and later in a book titled Fundamentals of Software Company Operations in more detail. Some manufacturing theory can and does apply to software. However, it isn't understood well enough to do it correctly or successfully as it forces manufacturers to adapt to a new form of systems thinking.

Assembly line companies like Ford and Toyota have excellent histories of hard-product assembly line evolution. Entire enterprise cultures and academic bodies of knowledge have borne up around their successes. Now these companies, including others like Caterpillar, Vermeer, John Deere and more, have a new challenge. Higher and higher percentages of these historically big iron and aluminum (aluminium for some of my non-American English speaking friends) assembly line companies are now composed of software. Much of it embedded for fixed sensors. However, more and more of it represents a very-large ubiquitous software ecosystem. The internet and everything that goes along with it.

At some point very near today, the cost of building, delivering and supporting software will represent more of the delivery and operational cost of a car, truck, tractor, grader or directional drill than the hardware and hardware assembly line combined. And software moves at a far quicker change velocity than anything the big iron hardware world has ever had to solve. However, because of the historical success of the manufacturing industry such as at Ford and Toyota, leadership in these companies will believe they are giants. And software to them will (does) look no more complicated than another physical feature they can simply design in CAD, manufacture to specification and deliver without environmental variability.

These companies, who have typically and historically led and evolved the manufacturing world with total-earth domination, will fail because they choose to short-sightedly treat software as a factory behaviour.

Q: How do you take the success of assembly line production and translate it into software production?

A: Decouple

In the follow-on post, we'll explore the idea of why decoupling software evolutionary behaviors from historical hard-line assembly line behaviours is necessary and what steps are necessary to get there.

1 | 2 | 3 | 4 | 5