Iterative Thinking

Core Platform

Iterative Thinking is a simple but powerful method to work through a complex problem to a usable result.

Get started! Create a tangible artifact representing the problem to be addressed, at whatever may be your current level of understanding. Start with a description of the problem as you understand it. The form of the initial representation can be at any level of abstraction that you can use to understand the problem and its technology. A concept doc, a plan, a spreadsheet, a model, a prototype.

A tangible work artifact beats just thinking about it. This will give you a tangible way to incorporate and test iterations of thought and detail toward handling the problem. When you work on a problem with a tangible tool, the problem will teach you about itself. You will see where expansions are needed, and characteristics of solution will become clearer.

Once you have an initial representation of the problem, layer improvements and function to it in a series of iterations, each expanding capabilities of the Core. Each iteration extends the working solution to include more capability. Functionality of the working solution may not be complete, but it remains functional to the same or greater capability as the prior iteration.

The process itself is straightforward. But be aware that there are differing ramifications of use depending on the technology of the problem you are addressing, as I will describe in some examples.

Plan: As a rule, plan the iterations to the extent known. Backlog items at least, a full plan where possible. Keep the plan updated as you proceed. Develop a "Best-Known Path From Here" at an understandable level: not so detailed as to be brittle or constraining; not so general as to be useless. Planning Integration Sequences containing Integration Points has proven to be useful if the Program involves numerous people. Such a plan can be used to analyze and tangibly coordinate inevitable change. If the plan can be quantified with time, then keeping it up-to-date with actuals will lead to increasing accuracy and ability to plan long-lead items, to coordinate dependencies, and to predict availability of deliverables.

---

Iteration and Coordination

Iteration: Addition of structure or function

It's a good idea to enumerate iterations you know will be needed. As you add function, it is often worthwhile to plan in capability to handle extensions you know are to come.

Each iteration should take care to neither regress existing functionality of the existing work, nor to regress methods of use by the existing work. An iterated version should be call-able or build-able from existing modules that use it. This makes any dependency "soft"; the using module can use a prior version until the next iterated version is available, and can use a newer version with extended functionality without regression when that becomes available. Each iteration adds functionality, features, accuracy, detail to capability of a prior version.

Coodination: Time-box coordination of time among multiple program elements

Some problems may be split to multiple system elements each iterating in parallel. This can be driven by technology specializations, remote work, organizational differences. Such efforts can be coordinated among multiple system elements.

Work on complex problems, such as System development, often embeds work at several technologies, at levels such as Module, Component, Element, Assembly, System, Build. If coordinated availability is required or a significant advantage within or across such levels, that can be managed by coordinating time of availability of overlapped iterations. Time is generally managed using time-boxing: identifying blocks of work within a commensurate block of time. Time-boxes among such work levels are often mutually overlapped, interleaved, or embedded.

---

Applicability

Iterative thinking can apply across many dimensions: Large programs, small projects, paper analysis. Technologies including software development and hardware development. Iterative thinking can be applied to any problem where you do not know the solution up front.

Iterative thinking may have differing implications depending on the technology context in which it is used. With some imagination, those implications can often be used to advantage although in differing ways, to match technology constraints and opportunities. Several examples of applied iterative thinking follow, with discussion of implications and how each example can use them to advantage.

• A numerical analysis project of limited scope within a single complex structure.
• A software program based on sprints.
• A system development program including hardware and software elements, organized as hierarchical integration steps at system level with coordinated time-boxing.

Complex Analysis: Core Platform

Ability to predict usage of Natural Gas billing in upcoming billing period, based on earlier meter readings.

Expectation: meter can be read several times establishing current/seasonal usage pattern and likely daily usage rate in billing period. That usage rate could be used to predict usage for the full period. Usage measurement and billing calculation are determined by the Utility, and by the PUC. These have significant history and regulation, with resulting complex and obscure calculation method. This complexity adds significant complexity to capability for prediction.

Starting assumptions: Read usage meter periodically to determine usage rate, multiply by billing period days to determine period usage. Transform to billing. This was initially modeled in an active spreadsheet.

---

Complex Analysis: Iteration

Numerous complexities were discovered in measurement, usage calculation and prediction, and transformation to billing prediction. Each step resulted in an iteration to measurement method, or to calculation of usage, prediction, or cost. These are intended as illustration of complexities of solving a problem, that may not be visible at the start of a project and that require layers of research to resolve, whose need becomes clear as context is established within the developing solution.

• Meter dials alternate spin direction. Meter measures CuFt, in 100 CuFt increments; a meter reading of 1234 is 123,400 CuFt. At close to 100 CuFt per Therm, the meter reading 1234 closely approximates 1234 Therms, the unit billed by the Utility.
• Utility provides website with documents on billing; but documents overlap and there are gaps and sorting/aggregation disconnects. Similar to billing information on websites of Cellphone companies for those who have dealt with that: reports that sort and aggregate data to differing criteria, with either non-existent explanation or explanation on separate documents some of which are outdated.
• Monthly billing period: 17th of prior month to 16th of billing month.
• Billing period spans two partial months so created date arithmetic LAMBDA functions, available at LAMBDA.
• Determined programmatically the earliest measurement date in current period, basis for calculating elapsed days and billing period days across the period two partial months.
• For billing, each month can be a different Season as defined by the Utility, which affects billing. Each partial month billing is determined separately; Utility bill always shows the two periods separately.
• The Season containing each month adjusts days to be billed at Base rate, and days to be billed at Excess rate. However, cost rate for Base and Excess are fixed on annual basis. (Note that utility nevertheless appears to vary Base and Excess rates; documentation has not yet been found.)
• Base and Excess rates depend on location Usage Zone defined by Utility.
• Billing needs conversion of CuFt measured, into Therms. Seems there is a standard for this conversion, but Utility uses utility-specific conversion rate instead.
• Billing adds additional transport Surcharge for each half-month in billing period.

---

Complex Analysis: Result

Current solution incorporates resolution of each listed complexity. Most data was found on the Utility website, although it was somewhat obscured and most needed interpretation and trial ad-hoc coordination with Utility reporting. Now able to predict usage to close result, early in reporting period. Periodic measurement also shows any usage aberrations so that they can be addressed.

Software Program: Core Platform

You will recognize that iterative thinking is the basis for Agile Scrum/Sprint methodology. Most people reading this will be very familiar with sprints, so they won't be detailed here. But several observations will be made that I have not seen in discussion of sprint pedagogy.

In common use, Sprints are time-boxed to repetitive fixed periods, and work is sized to fit within the Sprint period. Specific dates are seldom assessed. Dependencies are soft, or may be ignored in planning. Coaches may recommend elimination of dependencies through single-team inclusion, although that may be difficult for large or complex projects with multiple locations, technology or application specializations.

SAFe methodology adds complexity, but adds Program Increment planning to predict integration sequences. Timing is not formally predicted. Timing may not be necessary, however, based on business models common among many development efforts. See Program Roadmap business models.

Initial problem description is often documented as a Business Plan Requirement, represented by a Product Management organization and perhaps including an initial Backlog, and may be accompanied by architectural description and an initial Product Development plan estimate from Program Management. Such a problem description often makes use of available prior product, or commercially-available elements, as targets for integration and use in the product to be developed, and therefore provide capability for initial platform prototyping.

Design for core platform software elements usually is done at the beginning part of the program. This task is described in Initial Design Sequence and includes partitioning, package integration, platform firmware, interconnect, data-flow, messaging, and drivers.

Software development effort subsequent to platform design usually iteratively adds function using the platform, and includes SQA and DevOps management testing function, negative behavior, performance, scalability, robustness etc. Bugs are added to backlog, and bugfixes addressed in iteration cycles.

---

Software Program: Iteration

In this Figure, several Program elements run Sprints in parallel on private Development Branches. These dev branches are integrated into a Program or Master branch for SQA at system level and ultimately to a Production Release branch. This illustrates use of fixed sequential Sprints iterating addition of function, separated for work specific to technically-specialized element development organizations, and periodically integrated as common Builds for system-level SQA and propagation. Several of the functional adds illustrated take several Sprints before they are ready for System integration, SQA and use at System level.

This overall sketch seems to be fairly common methodology used to initiate a development effort, and to iterate function as it is developed and tested, to take the development effort toward production use by customers.

Elimination of dependencies. Of interest here is how the incremental development process is used in software and Sprint-organized projects, to eliminate dependencies.

Once a functional element is incorporated into the product branch for SQA and propagation, that functional element remains available at its released level of functionality for subsequent builds. Each integration can already use the current iteration of an Element development. If the newest iteration is not yet available with new function, the most recent available iteration can still be used. Software is essentially free to manufacture and deploy; a new iteration can be deployed for essentially no incremental cost. So use of an earlier version, even if it will ultimately be replaced, does not incur incremental cost. Current infrastructure for code management, integration, test, distribution and installation support the earlier version and also later-updated versions, so material cost and labor cost are at most, minimal. The integrated product will not have the function of the latest in-development iteration, but does contain available function and can be conveniently upgraded when iterated function is available. Accomplishing this also requires that interface to each Element should handle unexpected requests in a safe manner. The net of these is a "Soft" dependency with few disadvantages, and is commonly how Dependencies are eliminated.

It is possible that a hard functional or build dependency will occur – functionality in a service provider Element, that is required by a connecting Element. In that case, the service provider Element may have choices. It may provide a functional workaround (some examples follow below) released in an iteration required to support the connecting Element. It may have provided that in a previous iteration. Note that a workaround implementation essentially adds to technical debt, probably keeping a backlog item open. The other choice would be to implement the required releasable functionality in the service provider Element. Ideally, this is predicted far enough in advance that the program is not delayed by this dependency.

Furthermore, this allows a more general statement of a task completion in a Sprint. Certain task-types may need to span multiple sprint time-boxes with limited penalty. This violates "done-done" of Agile methodology but is necessary for some long-running tasks that cannot be segmented. Examples: Customer evaluation step; foreign government certification steps; etc. These may simply require elapsed time and distribution volume, necessarily crossing multiple sprints.

The continuous integration methodology just described enables dependency elimination, but additional actions can be taken to even more fully eliminate them. Safe handling of as-yet un-implemented requests, modular design, and Element abstraction are among them. A further discussion of dependency elimination can be found at Program Roadmap.

Examples of feature functional development through several Releases:

User interface to a product Element

• Initial prototype for small local development uses Command-Line Interface (CLI).
• For distributed development, App-based Graphical User Interface (GUI).
• For broad web deployment, Web-based Browser User Interface (BUI).

Connection between a Program Elements. Connecting element can specify interface, or accept latest-level interface offered by service Element.

• Initial prototype for local use: connecting Element hard-codes IP address/URL of service Element.
• For broader development, connecting Element reads IP address/URL for service Element, from text file that can be updated locally.
• For production, implementation of Service Discovery Protocol (e.g., SSDP or similar) to locate and select service Element.

---

Software Program: Coordination

Function Development Sequencing Iteration in Software Development is used to divide the overall function development task into manageable blocks.

Managing Dependencies Iteration in Software development has the effect of controlling (eliminating) dependencies.

Managing Program Risk Long-duration tasks can be spread across several sprints. Note that cross-sprint tasks should be limited to specific types planned for this, not a go-to for taking on more work in a Sprint than advisable by Velocity or other sizing methodology. It's important to focus on timely work completion at all times. The exception allows for specific and authorized task types that don't break into sprint-size pieces.

Managing Production Risk Iterated work can be used to deliver function to the customer base quickly. But note that delivering quicky-iterated code to customers should be well-considered. When function development within an Element is complete, there is still time and effort needed for full integration and corresponding bugfix, time for SQA and bugfix, for limited exposure to representative configurations, and for Certification required for customer production use. You don't want to ship code prematurely to customers that will crash their environment, crash multiple customers, disrupt critical function, or violate their business standards. Iteration is a powerful way to get function developed in short time-frames but carries risk also, that must be mitigated.

System HW/SW Program: Core Platform

Hardware development efforts (that inevitably include at least some software development), and System development efforts that include hardware development are different than pure-software efforts.

These efforts include the iterative methods described above for software. Hardware development efforts included in these programs also use iterative methods, but with very different motivations and ramifications.

Unlike software development, hardware development efforts are very sensitive to time and cost. Each instantiation of a hardware element must be physically created, assembled, tested, and integrated and installed in systems-of-use. This requires material and labor cost, and time for fabrication, transport, assembly, and test. Hardware is never free, whether prior-rev or newest-rev and can rarely be reworked for fix or update due to signal integrity and on-site integration requirement.

Initial problem description, just as for Software programs described above, is often documented as a Business Plan Requirement, represented by a Program Management organization perhaps including an initial Backlog, and may be accompanied by an architectural description and an initial product Development plan estimate from Program Management. Such a problem description often makes use of available prior product, or commercially-available elements, as targets for integration and use in the product to be developed, and therefore provide capability for initial platform prototyping.

Design for core platform hardware elements usually is done at the beginning part of the program, prior to physical prototypes build integration cycles. Add-on function after platform design is typically implemented as bus plug-ins etc.

Hardware development effort subsequent to platform design is as much for developing production capability of the product and of the Manufacturing process as it is for product design: Correction of functional problems, Process-Voltage-Temperature corner margin, signal integrity, operating environment, EMI, fab tolerances, material and fab sourcing, production tooling, manufacturing yield, product and production cost. These later increments usually result in component changes with few changes to platform architecture.

The top line of the following image shows a Design task, beginning at the very start of the program. This is development of the Core Platform, the design of which will be iterated. This task is described in Initial Design Sequence and includes hardware architecture, partitioning, logic and mechanical design, board layout and other tasks. Its processes are design-heavy, similarly to software design tasks, and could be managed using Sprint methodology as described above although that is rarely the case. But see Quantified Agile for Hardware.

Build and test Integration Sequences are shown below that. Subsequent design tasks associated with each Integration Sequence cover design updates handling test and productization issues.

---

System HW/SW Program: Iteration

Integration Iterations: The bulk of the diagram shows a sequence of five Integration Sequence iterations each consisting of Material Acquisition, Element and Assembly Build, and Test. Each integration sequence is shown as a horizontal multi-color line from left to right.

Productization Iterations: Progressing roughly vertically is another dimension, Tracks iterating through development of several manufacture-ability processes, and element, assembly and system Build, Integration, Test, and Certification processes.

Prototype distribution is costly. The Integrations Sequence phases differentiate risk and control cost of production.

• Early builds are highest-risk, high-cost due to low volume parts, low-volume manufacture, manual processes; resulting in lower volume build. Distribution usually small, expensed items, limited to local/core developers.
• Later builds are lowest-risk, lowest cost per unit due to higher volume material, automated processes; resulting higher volume build. Distribution to distributed developers, then in-house and customer Alpha test, customer Beta, marketing Demo, Certification units, and larger capitalized systems for SQA, load-test and so forth.

So iteration manages functional dependencies, partly as a means to control build size, cost and time.

Prior-rev elements can satisfy build-dependencies if functional dependency is not available and not required in particular cases. Some number of these units will need to be replaced later with functionally complete elements to complete functional development, formal tests etc. Replacement units must be physically instantiated (materials, build, assembly, test and transport) involving cost and time to acquire, build, test, distribute and install. This can be expensive and error-prone, so hardware usually manages dependencies tightly, reserving this path only to resolve failure of timely delivery of a dependency.

Time can also be controlled by schedule management: As much as possible, the schedule critical path is allowed to contain only tasks whose duration are most likely fixed (transport, fab, build). Tasks preceding those are started such that they complete in time for the critical tasks. Tasks dependent on the critical path are made to be independent of each other.

Note how this differs from software Elements: each instance of each hardware elements must be physically created, requiring schedule and expense for material and labor, and time for material lead, fabrication, assembly, and test. So hardware dependencies commonly remain "hard" and are managed via time scheduled ahead to accommodate all of those. Prior versions of an Element may instead be used, but they must be created with the same costs, and some will need to be replaced which adds to cost and time factors. Iteration among hardware elements is instead usually used to control cost of expanding process development, element proving, and use over the course of a Program.

Iterations as above are used to control time; hardware delivery to customers generally drives the business model revenue path: see Program Roadmap for business models.

---

System HW/SW Program: Coordination

Function Development Sequencing Iteration in Hardware and System Development is used to divide the overall function development effort into manageable blocks.

Program Time and Cost Control Iteration is used for Hardware development to control build cost, to control time, and to manage manufacturing process development across sites and suppliers.

Advice for Program Managers: The Blog Series

1-Program Management Opportunity
Introduces a vision and framework for development of Program Managers and PMO, for Program Management specialization to its environment, and for improved effectiveness and integration of PM with organization operational management.

2-Program Management Career Path
Describes career path thinking for Program Managers including sourcing, progression, advancement, and connection with organizational management.

3-Program Management Career Skills
Career path thinking for Program Managers including skills and behaviors that develop Program Manager capabilities and leadership and pave the way toward advancement.

4-Program Management Specialization: System Programs Phased Methodology
PM Best Practices and Core Program Structure for Hybrid integrated system programs using Phased HW – Agile SW, mixed-technologies. Full-Program agility via automated plan tools with continuous plan update.

The Series also solicits contributions to this Blog site, to extend coverage of PM Best Practices and Core Program Structure to a broadening set of Specializations.

5-PMO Role
PMO behavior to achieve Program Management effectiveness specialized to its environment managing PM practices in the organization, including PM development and advancement and connection with organizational management.

6-Quantified Agile for Hardware
Program Quantification applied to Phased and Agile methodologies to deal with organizational quantitative requirements.

---

More Articles by this Author

Three Levels of Program Management
Guiding Principles for Program Management Action, Program Quantification, and Leverage Through Tooling.

Organizing Program Communication
Program Management depends on effective communication. Design Program communication paths for everyone throughout the Program.

Database Platforms for Program Management Logistics
Logistics Tool extended, using SQL Server and MS Access with MS Excel and PowerQuery.

PowerQuery Tool
Logistics Tool using MS Excel Power Query.

Quantitative Management
Tool methodology for agility with continuous plan update: Program BOM, Tie to Dates, Builds, Element data.

Complex Programs: Structure
Structure Program with Parallel Phasing. Describes coordination of EE/ME, FW, Test, Supply/CM, Driver/Kernel, Transport, Management. Scheduling, Integration points, scaffolding, and starting work. Hybrid Program Cross-Domain Coordination of development frameworks, including Phased and Agile/Scrum where appropriate, via integration points and scaffolding. Software Integration Sequence and Dependency Planning.

Managing Complex Projects
Problem Statement. PM responsibility for Program Management drive throughout an organization, also includes schedule, budget, integration, critical path, logistics.

Program Roadmap
Planning work structure for a Program, and using the plan effectively.

Lifestyle AI
Planning work structure for a Program, and using the plan effectively.

Iterative Thinking
Using Iterative Thinking to solve big problems and complex logistics.

---

Link To Free Tools To Manage Schedule, Logistics, And Finance

Author’s www.softtoyssoftware.com website with articles on Program Management and Program quantification tooling using Excel, MS Project, and MS Visio with SQL databases PowerQuery, SQL Server, and MS Access. Articles describe how you can use tools available from the website, or develop these capabilities yourself using commonly available tools.

Tools available from this website are free. They can handle small to large programs, limited only by your imagination. Using the included Program Template to envision, organize, plan, and run a large program puts me in mind of unleashing a Roman Legion to a sure outcome. Veni, Vidi, Vici! – Julius Caesar.

• https://www.softtoyssoftware.com/dbnet/programmingprojects/powerquerytool.htm
• Details on design of Structured Tables, JOINs, Reports/Pivots in Tools.
• Schedule, Visualization, Reporting.
• Hybrid program agility with continuous plan update.
• Microsoft 365 Desktop – based.