Model Based System Engineering (MBSE): Relating Systems to Value

As part of the product analysis methods, I was discussing with my project management training class when these discussions really made me feel that there is a lack of fundamental understanding on model- based system engineering (MBSE) and its relationship to value. Much of the value decomposition was conceived by the professionals in my training class relating to the product backlog breakdown splitting a product epic into separate components and subdividing them into features and user stories for MVP and MBI/MMF. The focus was of requirements analysis splitting stories into smaller chunks for estimation and delivery lost the connections to the model-based system engineering (MBSE) concepts, such as the system engineering, systems analysis, value engineering, and value analysis, and their tight coupling to technical subsystem interfaces for a simple, secure, safe, stable, and sustainable product. 

Some of the familiar concepts of model-based system engineering also pave their connections with the processes for procurement and agreement management, project enablement and related outcome management, technical management, and the technology related management itself. Such concepts can be found in the ISO 15288 on how system related processes are mapped not only in designing the system but also in designing the processes around the system (Hall, 2018), which is not the product alone but the processes around operations (which is a portfolio component), programs (which focuses on benefits management) and projects (which focuses on outcome management). 

The concepts of managing these processes within a software context can be seen in the capability maturity model integration (CMMI) and the processes of continuous quality management (both QC and QA) can be seen in 6-sigma concepts. Even ISO 9000 umbrella of the ISO 9001 series to total quality management espouse these processes related to both technology and management of technology to ensure quality in numerous standards and regulations (Rajagopalan, 2023). This is what is emphasized by the agile principle, "Business and Technical stakeholders must work together daily!" While each industry may create different models depending on the specific products and their impact on clients and customers, a few generic MBSE concepts apply in all the industries. 

The MBSE concept is analogous to the fable that I heard in India about six blind children touching an elephant and describing the elephant. If elephant is the system and the blind children are the various stakeholders, we are describing the system from what we think we see/feel. Security, for instance, has a different meaning for the technical team members compared to the end users.

For simplicity, let us define the model as a feature-box (functional requirements and non-functional specifications) that adequately represents the set of inputs that can interface requiring the model to prioritize and the set of outputs it will generate. The model's behavior is controlled by a set of complex rules that are manageable. This model now represents the system that must be viewed closely and from far! This requires the system architect not only to see the auditability of the system for diagnosis (such as behavior, but paths also taken and the trails left, considerations for gracious shutdown, etc.). So, how do the system analysis and system engineering differ? 

The system analyst will use a combination of techniques (e.g.: data modeling, interface analysis, data flow diagram, and alerts & event triggers) to refine the model! This is reviewing the model at a close distance. So, the system analyst frequently will consider using class diagram, functional decomposition, sequence diagram, network diagram, entity-relationship model, and deployment diagram as well as the total-quality-management (TQM) foundations like the flowchart, scatter diagram, checklist, root cause analysis, and histogram. But the system engineering discipline observes the model from a long distance. 

Therefore the system engineer focuses on interference defining the boundary of the system (where the system can no longer sustain itself to be valuable), behaviors that exposes the system's vulnerabilities (model is no longer safe or secure without subjecting itself for damage or causing harm to others). The system engineer then uses market analysis, business rules analysis, concept modeling, scenario analysis, risk analysis, state modeling, interface analysis, decision-modeling, Gemba Walks, workshops, focus interviewing, SWOT/TOWS analysis, benchmarking, and brainstorming further supplemented by TQM techniques like control chart and pareto charts. Please note that these are additional techniques beyond the techniques used in the system analysis.

Now, both the system analysis and system engineering concepts can be extended to the extent of benefit (value) derived by the users and the performing organization.  These values can be looked at from multiple angles. One approach is the approach that I normally recommend as custom value, business value, technical value, and process value (Rajagopalan, 2019).  The goal of these exercises is not only to protect the customers and business but also look at efficiency gains through the combination of both the process and technical value giving a competitive market value! When all these areas are reasonably protected, they also enhance the future value (that can be measured using ROI, NPV, IRR) of the product within the product portfolio. The short-term focus will be value analysis and the long-term focus will be value engineering. 

Another lens, that in my humble opinion, extends from the previous discussions is how the model is sustained and supported. From this lens, we can evaluate model from flow (hence Lean), governance (hence Change Management), behavior (Systems Engineering and Value Engineering concepts mentioned earlier) and decision-making (hence Risk Management discipline, Costing Principles, and Costs of Quality considerations). A few refinements are required here.

• Flow is often thought of as work progressing across various statuses. This is horizontal flow. Flow also should be looked at vertically between projects, programs, and portfolios and multiple systems or projects that must work together. 
• Change Management concepts extend in such vertical value flow in terms of risk management, decision-making, funding, and resource planning that happens in program management, PI planning in scaling agile approaches, etc. 
• Governance can be supported at a lower level with workflows that enable faster decision-making and system traceability & auditability. 
• Behavior can vary very widely depending on the organizational processes as well as the maturity/direction required by the team. Hence, it could range from as simple as time tracking, waiting time evaluation, burn rate as well as evaluating negotiation considerations, team health, conflict resolution, etc. 
• The decision-making can be supported by some of the governance considerations, but it could also transcend other work authorization systems based on extensive funding considerations (e.g.: Efficient Frontier, portfolio balancing, resource optimization, etc.). 

What else I may be missing in MBSE definition? Please expand.

References

Hall, D. (2018). Systems Engineering Guidebook. Toney, Alabama: Hall Associates. https://www.incose.org/docs/default-source/default-document-library/systems-engineering-guidebook---isbn-9780692091807bb88028572db67488e78ff000036190a.pdf?sfvrsn=365365c7_0

Rajagopalan, S. (2023). Risk Management: Birds' Eye View of some Standards and Regulations. https://agilesriram.blogspot.com/2023/08/risk-management-birds-eye-view-of-some.html

Rajagopalan, S. (2019). Requirements Management: A value mapping exercise. https://agilesriram.blogspot.com/2019/02/requirements-management-value-mapping.html

Differences between Kanban and Scrum

Recently when attending the 5-day Agile 2014 conference in Orlando, Florida, I had an opportunity to discuss various agile implementations. Some of the discussions centered on selecting the right type of agile methodology to consider for software implementations from extremely regulated medical devices industry and government projects where Scrum was considered prevalent. Then, when I found in my network of work and friends, there were questions that revolved around using Kanban because Scrum wasn’t working.

Having used Kanban and Scrum, I wondered why there is still confusion among the early adopters of Agile and why Kanban would be considered as a substitute for Scrum. Unclear understanding of agile concepts may lead to failure just like how people created a non-existent theory of waterfall based on inaccurate practices (Rajagopalan, 2014). So, I focus below on a comparative study of the basic premises between Kanban and Scrum. I hope this article captures the essence of these approaches demystifying the confusion and helping in the selection of the right approach for the challenge at hand.

One of the primary differences is that Kanban is a method that can be used independently or along with other approaches like Scrum. This is why we even have derivative approaches like the Scrumban.

Concept	Kanban	Scrum
Management focus	Maximize resource usage avoiding delay and enhancing accountability to support flow.	Consistent delivery in the cadence of execution, as the features in the product backlog is delivered.
Operating rhythm	No time-boxed iterative development exists.	Time-boxed iterative development – usually two to four weeks.
Granularity of work	Focus is at the task level for which the scope of work is generally known.	Focus is at the user story level for which the scope may not always be known, requiring it to be estimated before tasks can be identified and taken up by the team.
Agile Estimation & Planning	Estimation is generally not done. There is little to no ambiguity on the task that any member of that team should be able to take on the next available task and execute it.	User stories are estimated. Then, they are prioritized, and risk adjusted so that these are included in the release and iteration planning.
Value Delivery	Every task completion may not necessarily add minimally marketable value to the customer. Task identification and dependency require careful coordination.	The cadence of release and iteration planning focuses on adding minimally marketable feature through the scrum cycle. The self-organized team determines the task identification and dependency.
Progress Tracking	Flow of items throughout the lifecycle limiting delay. This is why the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat Yourself (DRY)” focuses on maximizing work not done	Focus is on tracking the velocity measuring the user stories done and delivered to customer in an iteration
Utility value	Better for managing workload and resource management. E.g.: How many projects of different combinations can be taken up by a project?	Better for managing products, programs, and projects.
Thoughts to consider in software development	Use of Kanban for software development may impede flow if all the units don’t consume the work produced at the same speed. Therefore, additional processes must be in place to support Kanban. E.g.: QA not having capacity to test code developed by engineering team. If QA’s capacity comes from the fact that more defects are found in the build, then, more granularity in tasks to ensure proper code review, unit testing, and documentation are processes that the organizations must have in place.	Implementing Scrum doesn’t mean the ability to write user stories and avoiding documentation completely! This requires a management shift to ensure critical thinking on the product, program, and projects. If iterative delivery is not understood by the management and client, then, Scrum is not an option to consider.

In summary, Kanban and Scrum are both light-weight approaches, but the operating philosophy is different. Scrum focuses on the work being delivered to customers through multiple iterative deliveries of minimally marketable value by assembling a cross-functional, skilled, and self-organizing team or team of teams. Kanban, on the other hand, is a pull-based system and focuses on the visualized workflow where flow is maximized by limiting what gets worked on by the team. Although both approaches require prioritization in the items represented in the backlog, Scrum team can’t pull an item outside of the Sprint backlog when they have capacity. Kanban team can pull the next priority item from the backlog. So, depending on what product, service, or result the team is delivering, or the benefit being sustained in operations, Scrum, Kanban or Scrumban may work. Select the right tool for the right job!

Thoughts?