Better Scaled Agile for Hardware
Hardware development organizations have begun to embrace the Agile practices that have been so successful in software organizations. However, making Agile effective in hardware organizations requires more than just Scaling...
This page will explain the differences between hardware and software development that impact Scaled Agile, and will show how set-based decision-making is needed to make it work well.
Key Differences that impact Scaled Agile
Courtesy NASA/JPL-Caltech.
Software Development...
Hardware Development...
Software can do essentially anything.
Physics. Hardware must obey the laws of physics, chemistry, etc.
Software development works directly on the product that gets delivered to customers.
Manufacturing is separate from development. Hardware development doesn't deliver "product" to the customer, manufacturing does.
Most experienced software engineers can do at least lightweight work in most any area, whether database, logic, user interfaces, etc.
Due to the many different physics areas of expertise, there is need for a lot more engineer specialization in hardware.
It is practical to have engineers dedicated to specific teams over extended periods such that they can learn their team velocity and independently schedule their team's backlog.
Because of those specializations, it is typically necessary for teams to share key experts (which breaks several Agile techniques, like independently measuring team velocity).
The product is software such that there is rarely need for a separate model of the product. It is reasonable to develop the product itself for testing (the minimum viable product).
There is a fundamental difference between "the model" (software for simulating the hardware for early testing) and "the product" (the actual hardware).
Agile's Backlogs of Stories
A key mechanism in Scaled Agile is the "Backlog" of "Stories" that get prioritized and planned into each "Sprint".
Those are "stories" rather than traditional "tasks" because we want the engineers to remain focused on the customer's needs in a coherent way.
In hardware, because development targets manufacturing directly and the end user indirectly, and because models are used for learning more often than prototypes or final product, there is need for four different kinds of "stories":
-
knowledge gap identification stories
-
knowledge gap closure stories
-
decision convergence stories
-
manufacturing deliverable stories
And below you can see how those four different kinds of stories fit in the hardware development process:
The Critical Role of the Causal Map
The Causal Map makes those first three kinds of story concrete. And making stories concrete is key to being able to apply the Agile practices effectively. Hence, we assert that the Causal Map (or something similar) is key to the effective application of Agile to hardware teams.
To make things concrete such that they can be reliably prioritized and planned, as Backlog items must be, we generally need some sort of visual models. However, any sort of drawing or structural definition will tend to result in people jumping to solutions or inadvertently making decisions earlier than desired.
The Causal Map avoids that by making explicit the decisions that have not yet been decided.
Contact Us
If you have questions, would like a demo, or would like to schedule us to visit you, please email us at Answers@TargetedConvergence.Com. Alternatively, you may call us at 1-888-LRN-FRST (1-888-576-3778). Either way, we'll route you to the right person.
Or if you prefer, you can send email direct to:
-
Our Sales Team at Sales@TargetedConvergence.Com.
-
Our On-the-Job Coaching Team at Mentors@TargetedConvergence.Com.
-
Our Software Support Team at Support@TargetedConvergence.Com.
-
Our Website Team at Webmaster@TargetedConvergence.Com.
-
Our Accounting Team at Accounting@TargetedConvergence.Com.
-
Our Human Resources Team at HR@TargetedConvergence.Com.
After 10 years in Carrollton, we have moved a few miles south to the prestigious Las Colinas region of Irving, TX:
Targeted Convergence Corporation
320 Decker Dr #254-03
Irving, TX 75062-3999
You can visit (and Like! or Follow) us at our official pages on LinkedIn and Google Maps.
In order to successfully deliver the product to the customer, Development needs to deliver deliverables to Production.
In order to do that successfully, optimized design decisions need to be made. 75% of those key decisions are made in Concept Design; 85% are made before the start of Detailed Design.
To optimize those decisions, the required knowledge must be learned.
To learn the right knowledge, you need to identify the knowledge gaps based on the Targets, Ideas, and Capability Limits you are faced with.
Scaling Across Team Lines
With Hardware Development teams needing to be split and/or needing to share experts with specialized areas of expertise, there is often need to supplement traditional Agile practices with some ability to manage across team lines.
The Causal Map can come to the rescue by being a visual model of the stories in the Backlog.
The decisions shared across teams will be explicitly modeled in both Causal Maps. So, it is trivial to connect those teams' Maps in a clear visual way.
Integrating Events (the purple diamonds in the picture to the right) can be used to plan the coordination of shared decisions between the teams.
The addition of Integrating Events into the scheduling effort helps transition the team from what we call "Schedule-Based Decision-Making" where decisions are often made prematurely to "Decision-Based Scheduling".
This is the "Set-Based Design" (or truly the "Set-Based Concurrent Engineering") that is called for by some of the premier Scaled Agile methodologies to facilitate the coordination of their "program increments", "agile release trains", or similar mechanisms.
They all rely on some form of intelligently-coordinated decision-making; we can enable that!
