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