Building Complex Hardware and Software Systems with SAFe

Building Complex Hardware and Software Systems with SAFe

SAFe Updates

For those of you who have been following (or contributing to) the SAFe for Lean Systems Engineering development, you know that our learnings have now been consolidated into SAFe 4.0. But you also know that there are many more steps in a journey to better understand and apply the Principles of Lean-Agile development to systems that include both hardware and software.

Our next step down this path is a new article by Alex and 321 Gang’s Harry Koehnemann (who was instrumental in the development of SAFe LSE), entitled Building Complex Systems with SAFe, which has just now been posted on Version One’s blog.

Alex and Harry are committed to evolving this work further, and we can expect some solid, enhanced content to appear in the SAFe Guidance section in the next few months. In the meantime, check out this article, and see if you think the u-curve optimization figure for thinking through the economics of complex system integration is as cool a thought as I do.

Of course, comments are welcome, right here.

Stay SAFe!

—Dean, Alex, Richard, Inbar

Author Info

Dean Leffingwell

Recognized as the one of the world’s foremost authorities on Lean-Agile best practices, Dean Leffingwell is an author, entrepreneur, and software development methodologist.

comment (7)

  1. AlexYakyma

    25 Apr 2016 - 9:49 am

    @Frank:

    You right, it’s never an easy journey. Don’t know if it necessarily always gets worse with the size of the organization. We see also smaller organizations having unbelievable challenges in moving towards Lean and Agile at scale. In both cases, mindset more often than not becomes the #1 thing that needs to be addressed. And you right, tooling and current ways of working make it even harder as they reinforce the existing mindset. But this is also good news because it gives us a clue of how to help organizations shift core beliefs into the right direction. As John Kotter clearly suggests in step 8: “Anchor new approaches in the culture” and that is always easier to do once you start operating as an Agile Release Train and go thru multiple PDCA cycles. And like with every complex matter, systemic progress is what matters, not perfection. Now, you right, it takes time. Building sustainable practices takes time by definition. And I think the message here to every change agent and enterprise leader is that as an organization we always have to stay teachable, stay hungry for empirical evidence for all our assumptions and accept the fact that current mindset is never perfect; some dogmas may (and sometimes must) be questioned.

    The latter equally pertains to us as a community…

  2. Frank Schophuizen

    18 Apr 2016 - 3:16 am

    Indeed, as Armond states we are just scratching the surface and as Alex states complex systems hardly ever start from scratch. I would like to add some other complicating factors. (1) Complex system development often involves multiple release trains (teams-of-teams) that need to align and sync somehow to contribute to a business epic (also called initiative, theme, proposition, portfolio epic). (2) Release trains may be contributing to multiple business epics, e.g. products being deployed in multiple product lines or systems. (3) Some release trains may be too “small” to be organized as release trains (e.g. 2 app development teams of 10 people, one for Android and one for iOS) but should – or should not – be organized as release trains for better alignment with other release trains. And (4) combining Agile and non-Agile (stage-gating) teams, including external partners.

    And let’s not forget, not only complex systems hardly ever start from scratch, complex organizations never start from scratch. Deploying a new paradigm in a complex organization, with existing people familiar with current traditions, with tooling infrastructure aligned with current processes cannot be turned over overnight. It takes many years during which people, organization and infrastructure is in a hybrid transition and learning state.

    Growing from small to large by scaling up Scrum to SAFe may seem simple compared to growing from one large and complex universe (traditional, stage-gating) to the next (agile, SAFe).

  3. AlexYakyma

    25 Mar 2016 - 10:44 am

    @Armond:

    In case of a greenfield system everything is a stub in the very beginning simply because you don’t have anything, by and large. Now, most of the systems builders don’t build new systems completely from scratch. There’re always subsystems and components that exist but may require certain change. That BTW provides a venue for another set of practices that are sometimes referred to as “canary build” – an integration based on older existing subsystem(s). So, for instance, you would run a new network OS on your old router model, possibly scaffolded, to validate a broad set of “commonalities” that those two models have. In this case, it’s the “variability” part that will largely constitute the Cost of Innacurate Feedback, as the figure suggests. Now, “older version of the system” is simply an example of a proxy, so it lands itself somewhere on the spectrum.

    As for the gradual evolution of the subsystems, there are two different cases to be considered: 1) when the subsystem evolves from nothing to something and that doesn’t really mean that we are moving right-to-left on the spectrum, it rather means that the spectrum is expanding and 2) the subsystem is already in development but the cost of integration is too high and we are starting with something simpler but immediately pave the path towards higher fidelity in the future. As for case 2, the way the system is designed may well determine our options. Well segregated interfaces (ex: Hardware abstraction layers, or HAL) allow us to move relatively easily from a simple stub to Software-in-the-loop, to Hardware-in-the-loop option.

    Thank you Armond for digging deeper into this. This is just an example of a very critical set of trade-offs and our mission is to help the industry embrace a different way of thinking, moving from binary (“if you can’t integrate on a daily basis like in SW, you should waterfall it”) to more balanced view of looking at this as an optimization problem at that’s what Lean thinking is all about!

  4. AlexYakyma

    25 Mar 2016 - 10:40 am

    @Andrew: thanks for your comment.

    Yes, it is one of the pressing issues. Overall, Harry and I briefly touched on the question of how SAFe addresses compliance and regulations issues in our yesterday’s webinar with 321 Gang. The link to a recorded version will come out soon and I will post it here.

    In the near future we intend to address the topic of regulation and compliance further and even though it’s just a plan of intent and not exactly a promise, I think it is in a sense inevitable.

    Now, part of the answer to addressing concerns like IA where it comes with an array of specific NFRs, some of which have to be build up, others continually assured, this is where the mechanism of Enablers in SAFe becomes handy. Every PI begins to include some enablers that contribute to those NFRs. If you think about for a second, RMF is an example of a PDCA cycle, so the question, as usually, boils down to the choice of how long we want that PDCA cycle to be, a full project length or just one PI? Yes, you’re right, RMF does not necessarily overconstrain the matter, it’s the typical interpretation of each every regulation in the form of a phase-gate approach that actually represents the problem. So, the next tier of work for us is to “double click” on this broader topic of compliance and regulation in SAFe enterprises and especially address the questions around associated NFRs, incremental build-up of compliance requirements, impact on decentralized decision-making and product development economics. We will be blogging and tweeting about it as we go.

    Thanks for raising this critical topic, Andrew.

  5. Armond Mehrabian

    24 Mar 2016 - 11:57 am

    Dean,

    Alex and Harry’s webinar on “Building Complex Systems with SAFe 4.0” was fabulous. They applied the principles of SAFe 4 to all kinds of cross domain industries with practical examples. They courageously addressed the thorny subjects of cross-domain integration, fixed bid contracts and the like. As you can tell, I’m very excited about this work.

  6. Armond Mehrabian

    22 Mar 2016 - 2:27 pm

    Great topic. I feel like we’re just scraping the surface of this huge topic. I currently have three clients that are wrestling with these very issues.

    What are your thoughts on adopting the integration strategy (graph in section 3) at the right side of horizontal axis (stub) at the beginning of a green-field project and progressively replacing it with mechanisms to the left until we have the real-time subsystem? This way we are able to have objective milestones right from the start and move progressively towards the real (higher fidelity) solution.

    However, if we’re building on top of an existing subsystem (i.e. it’s part of the solution context), is this graph still accurate? Wouldn’t it cost the same whether we’re building on top of a stub or an existing subsystem?

  7. Andrew Long

    17 Mar 2016 - 9:03 am

    Dean, this crosses the realm of complex systems and how SAFe addresses NFRs, but I submit to you that the topic of information assurance (IA) deserves more in-depth attention from the Agile community. Similar to how we are realizing the OpEx/CapEx and accounting issues associated with scaled agile development, most large organizations also encounter the challenge of addressing enterprise risk (e.g. legal/regulatory, financial, security, and audit) in an Agile environment (particularly at scale for large systems). There seems to be a relative paucity of resources on this, and despite e.g. the relative flexibility of NIST publications on the topic (I happen to think RMF is wholly executable in an Agile manner), most source material for how to address IA takes a very plan-centric, waterfall, sequential approach to information (see for example the CISSP CBK). I am curious what are SAI’s thoughts on this?

Leave a Reply