The use of Agile Processes in many software domains is straight forward. Start with some notion of what Done looks like in units of measure meaningful to the decision-makers, start developing Features, get feedback from the Users, iterate on the needs until the User says we're good to go.
There is another set of software systems associated with safety and safeguards and their real-time control systems. You're likely a recipient of the outcomes of these systems every day, from the electric power grid (IEEE 1547 and IEEE 2030) to your car (ISO 26262, IEC 61508), to the aircraft you travel in (DO-178C), to the medical equipment used by your medical provider.
The global market of this class of software in 2020 is estimated to be $214,390,000,000 (yes 214 Billion Dollars). The Mobile applications market is $98 Billion in 2021. The global business software market in 2018 was $322.91 Billion which includes Finance, Sales & Marketing, Human Resources, Supply Chain, and Others.
So when we hear about agile processes like:
- Deadlines aren't needed
- All requirements evolve
- Story Points measure progress
- Plans we don't need no stick'in plans
- We don't need to estimate we just deliver as fast as we can
- Our agile development method is better than anyone else's
- All agile operates best in flat organizations
- Those doing the work should decide how the work is done
and similar phrase uttered by agile pundits, always ask first what domain do you work in where what you suggesting is standard practice?
A Reality Check
Without a domain and context, it's difficult to have a conversation about the principles of anything.
- Is the domain and context guided by regulations?
- Do the users of the product you develop have deadlines of their own?
- Are there not to exceed budgets for the customer or the supplier?
In our DO-178C there is an Agile Application Life Cycle Management (ALM) process. Customers expect rapid releases of software meeting the DO-178C (Software Considerations in Airborne Systems and Equipment Certification) and its companion DO-278 (Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems), NQA-1 (Nuclear Quality Assurance), OSHA 1910.119 (Process Safety Management) or ISO 26262 (Road Vehicles - Functional Safety) and ASIL (Automotive Safety Integrity Level) quality certification.
At the same time, all the benefits of agile development are still in place
- Iterative and incremental development
- Delivering quality releases quickly
- High levels of collaboration across teams and customers
- Prioritization of customer needs
So next time you hear any advice or opinion on how agile software should be or not be developed, start with these questions:
- What domain do you work in?
- Does your customer have a deadline for the Features you are developing?
- Is there a not to exceed budget for this development in order to stay in business?
- Are there external constraints on the software you're developing?
- Regulatory constraints
- Business process constraints - interfaces with external systems
- Is the person making suggestions or conjecture actually accountable for showing up on-time, on-budget, with the needed Capabilities to accomplish the mission or fulfill a business strategy?
- Or is that person selling a solution without defining what the problem is?
