Some system engineering purists and some agilista zealots will often argue about whether modern agile principles can be applied in embedded and real time systems contexts. Agile principles apply to all software development where managing uncertainty to achieve a better economic outcome is the main objective.
In the IT world, where most projects live in a cost center, the goal of productivity improvement is usually to reduce cost, or achieve more bang per unit time or per unit dollar. In other words, productivity improvement in the IT context is predominantly targeted at reducing the cost of a business. In the systems world, where most projects live in a profit center, the goal of productivity improvement has two branches: 1) to capture new revenue sources through innovating new features or attracting new markets, and 2) to reduce cost by achieving more per unit time or per unit dollar. So systems teams have the added complexity of improving the revenue of a business along with improving the efficiency and cost of delivering that revenue.
Purity and zealotry might work for those folks that live in a frictionless environment but such purists make for pretty ineffective teammates in our friction-packed world of software delivery. Software leadership, whether it is focused on IT applications, products, systems or services, is more about managing impurity and uncertainty. The discriminating goal of becoming more agile is an improved efficiency of change, especially in the headwinds of high uncertainty in the requirements, designs or plans. Agile principles such as:managing uncertainty, measuring honestly, integrating first, and collaborating more intimately with users, help steer innovation and uncover better paths to improved revenue. These principles also help to optimize scrap and rework so that more resources can be exploited in productive efforts (analysis, design, code and test) and less resources are consumed in scrap, rework and other overhead activities (regression testing, change management, change propagation, metrics collection, progress reporting, meetings, training). Agile practices such as Scrum, work items, user stories, test driven development, XP, demonstration based assessment, and others are mostly effective at improving execution efficiency, quality and cycle time.
There is one agile principle, namely integration first, that may seem difficult at first glance to achieve in some embedded systems domains. Many folks building software for embedded platforms, some whose hardware components may not be available until late in the development cycle, argue that this principle does not apply to them. These same principles should be applied to the software in physical products where software is the dominant component. This is easier in some contexts, harder in others, depending on the availability of the hardware platform, hardware components, simulators, and other infrastructure support. The largest constraint is mostly cultural. Our traditional process biases represent a large source of resistance.
The default implementation of the V model in most software intensive systems such as Operational Flight Programs, real-time control, command centers, simulators, etc., tends to demand that unit/component/service tests be complete before initiating integration/system behavioral and performance testing. This postpones the resolution of the bigger uncertainties and malignant changes uncovered in integration tests, and instead over-invests in completeness and coverage testing in the components are ensuring that they are free of benign changes and defects. The predictable result of this misguided planning priority is that 40% or more of the life-cycle is expended in late scrap and rework.
In a recent jam session on this topic, we had a very lively exchange whose consensus was that agile principles and practices are clearly applicable to complex and embedded systems development. After a few days of exchange, a different question was posed to the participants:
Which agile techniques, practices or principles DON’T make sense in a systems context? ….or must be substantially adjusted to fit into the constraints or challenges of certain domains.
There were a couple posts answering this question, but they mostly dealt with certain extreme contexts. One could probably identify similar rare occurrences in the IT world.