Agile and ASPICE

I'm not very familiar with ASPICE, but I come from a background in developing software in and for regulated industries such as aerospace and the pharmaceutical industry.

Looking at the Automotive SPICE Process Reference Model / Process Assessment Model Version 3.1, there are a lot of references to the V model. But I have never seen any requirements from industry or industry-accepted documents that mandate a particular process model. Just based on a quick reading of that document, the purpose of the V model in this instance is not to define a waterfall, but to define key process areas with outcomes, practices, and outputs that can be isolated and measured. The V model is a convenient mapping between the work and the verification and/or validation of that work to show what process area produces an output and where that output is either verified or validated.

Agile is fully compatible with standards like ISO 9001 (and AS 9100 in aerospace), ISO 13485, and CMMI v1.3 and v2.0, from software requirements through delivery of an integrated software/hardware system and maintenance/revision of that system. I'd be very surprised if the creators of ASPICE were ignoring the benefits of agile methods, especially in safety critical systems, and mandating a mostly waterfall approach to software development (or even to systems development - lean and agile methods can be applied to hardware and systems, too).

My first focus would be on understanding the need for implementing a V model or if it's just a reference model to ease understanding of the concepts provided. I'd also do what one of the papers I've mentioned below (the ICSSP paper) do - map lean and agile practices with the process areas in ASPICE and how you can satisfy all of the criteria without the need for any waterfall in software development.

I'd consider the following resources as a starting point:

• Clarifying Myths with Process Maturity Models vs. Agile by the International Assessor Certification Scheme, which aligns more closely with my understanding of aligning agile-lean methods with process maturity assessments.
• How do agile practices support automotive SPICE compliance? published in the 2017 International Conference on Software and System Process and it's related presentation slide deck.
• Agile Methods for Safety-Critical Systems: A Primer Using Medical Device Examples, a 2018 book by Nancy Van Schooenderwoert and Brian Shoemaker.
• Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement, a 2010 book by Paul E. McMahon

I also come from healthcare industry, and we do "struggle" with a something somehow similar. However, I do not agree with your statement:

"My understanding is that a requirement change puts you back to the top left of the V, which causes a need to replan design, before you can again re-enter the "iterative/incremental/agile" part."

In my experience, maybe because of great people I had a privilege of working with, if, during "the agile red box" a big change was deemed necessary, big enough to justify a change in written design input (requirements - but we always tried to keep them as lean as possible), then we would "simply" start a side process to align the design input with our updated knowledge. Was it a pain in the? Yes, it was, but it would never stop the Development Team from delivering Increment according to the latest stakeholder needs. Therefore, in our case an agile process would NOT trigger "waterfall upfront planning". It just triggered some changes.

You also wrote:

" Isn't any reference to Agile totally inappropriate once (a) both the requirements and design must be planned upfront, and (b) gate development? "

About (a): not if you distill these initial requirements and design into, let's say, vision.

About (b): depends on specifics, imho

Hi Thomas,

I  really appreciate your reply, thank you. When I look up the V model time moves forward along the x-axis, so I see the V model as sequential steps that gate each other, which to me implies waterfall.  If it was just practises, outcomes, and output, without that function of time, I wouldn’t see it as waterfall.  It also looks like waterfall to me because all the design, requirements, and coding are done before all the testing is and gate testing.  Please share your thoughts if you think I am still misunderstanding.

The first article says that “a process maturity model resides at the “what” level were as agile Approaches are at the “how” level.  To me this is a contradiction of Scrum as well since un Scrum The what is the product backlog and based on empiricism as opposed to pre-defined Upfront planning. Perhaps my confusion is Scrum vs Agile in general.  Maybe this contradicts Scrum but somehow not Agile?  I would really like to understand if this was the case.   Unfortunately I can’t see the other three resources but I wonder if through your experience, would you say that separation of this what and how was how agile was included In the regulated project you work on?  To me, the heart of being truly Agile lies in the what not in the how.  

Thank you,

Katherine

I  really appreciate your reply, thank you. When I look up the V model time moves forward along the x-axis, so I see the V model as sequential steps that gate each other, which to me implies waterfall.  If it was just practises, outcomes, and output, without that function of time, I wouldn’t see it as waterfall.  It also looks like waterfall to me because all the design, requirements, and coding are done before all the testing is and gate testing.  Please share your thoughts if you think I am still misunderstanding.

I'm looking at the published Automative SPICE document Version 3.1 now - time is not on the axis. This is true of my experiences with the V model in general - it's a way to visualize the relationship between a process activity that produces work and a process activity that verifies and/or validates the work. It doesn't necessarily imply sequential steps, but relationships between areas. For example, I don't think that you can argue that Software Integration and Integration Test is the area where your architectural design is verified and/or validated, but that doesn't mean that you need to wait until after Software Unit Verification to start designing your integration and integration tests or that you can't incrementally perform integration and integration tests as units are completed.

The first article says that “a process maturity model resides at the “what” level were as agile Approaches are at the “how” level.  To me this is a contradiction of Scrum as well since un Scrum The what is the product backlog and based on empiricism as opposed to pre-defined Upfront planning. Perhaps my confusion is Scrum vs Agile in general.  Maybe this contradicts Scrum but somehow not Agile?  I would really like to understand if this was the case.   Unfortunately I can’t see the other three resources but I wonder if through your experience, would you say that separation of this what and how was how agile was included In the regulated project you work on?  To me, the heart of being truly Agile lies in the what not in the how.  

I do agree that process maturity models talk about "what you do". Practices are at the "how you do it" level. I think a good example is that software requirements analysis is a "what you do". In Scrum, you realize requirements analysis by producing a Product Backlog, having a Product Owner that orders the backlog, and a Development Team that performs backlog refinement to ensure clarity and detect conflicts or points of confusion, resulting in a set of requirements that are clear, consistent, independent, testable, and so on. And there are a set of practices that can be used by the Product Owner to elicit user needs and turn them into Product Backlog Items and a set of practices that can be used by the development team to decompose the work and estimate it. All of these can be measured by your maturity model.

I would argue that the lean-agile methods are closer to the "how" than the "what". They address how you manage requirements and design and incremental building in a way that enables you to respond to a changing environment. However, the agile methods still have the same SDLC whats as any other process. The difference is in how you structure the whats.

Thanks Thomas.  The way the v model was explained to me prior to posting, time was on the x-axis.  It makes more sense to me that this model could work with agile if this is not the case!  It makes sense to me to that this could work with agile if each horizontal level of the v is done iteratively and incrementally.  Is this how you saw it applied in practice?   If so, would you agree with me, then, that the following two sentences describe an approach that is NOT agile?  A company uses a V model but an iterative and incremental approach is *only* applied at the very bottom of the V (red boxes on slide 5), no where else, not at the top horizontal level where market requirements are defined.  Time runs along the x-axis so that all other steps above the bottom of the V are performed as sequential gating steps over time.

I think our what and how definitions are not quite the same (but it sure it’s a big deal).  To me the “what” is the product backlog and the “how” is how the DT works autonomously and self-organizes to fulfill PBIs via the sprint backlog.  So when you say “how you manage requirements” that, by the definition I’ve been referring to, is the what not the how.  I’ll need to reread your posts to see if we’re saying the same things just using different terminology.

Can you please elaborate on “these can be measured by your maturity model”?  I’d really like to better understand what this should look like in practice.

Thanks again Thomas for taking your time to reply to me!

Katherine

I meant to say “not sure it’s a big deal”, hard to type on phone :)

It makes sense to me to that this could work with agile if each horizontal level of the v is done iteratively and incrementally.

Would this allow an increment to be delivered that meets a release-quality Definition of Done, each and every Sprint? If so, why are they referred to on page 9 as "pseudo Sprints"?

It makes sense to me to that this could work with agile if each horizontal level of the v is done iteratively and incrementally.  Is this how you saw it applied in practice?

No. Iterative and incremental development would imply that each iteration includes requirements analysis, architectural design, detailed design and unit construction, unit verification, integration and integration testing, and qualification test. That is the definition of "iterative". The incremental part is that you aren't working on the full set of desired features, but a small sliver of them.

You can apply iterative and incremental development to the system level or just to the software level. 

If so, would you agree with me, then, that the following two sentences describe an approach that is NOT agile?  A company uses a V model but an iterative and incremental approach is *only* applied at the very bottom of the V (red boxes on slide 5), no where else, not at the top horizontal level where market requirements are defined.  Time runs along the x-axis so that all other steps above the bottom of the V are performed as sequential gating steps over time.

I would agree that is not agile, because it is not iterative and incremental.

I think our what and how definitions are not quite the same (but it sure it’s a big deal).  To me the “what” is the product backlog and the “how” is how the DT works autonomously and self-organizes to fulfill PBIs via the sprint backlog.  So when you say “how you manage requirements” that, by the definition I’ve been referring to, is the what not the how.  I’ll need to reread your posts to see if we’re saying the same things just using different terminology.

The product backlog is a definition of what needs to be built, from a product perspective. But it's not the what from the process perspective. From the process perspective, the what is the goals and objectives, the how is how you meet those goals and objects (usually by applying processes, frameworks, methods, practices, tools, etc.), and then you have how the team actually does its work.

ASPICE (and CMMI and ISO 9001) all describe a "what" - what do you need to do or demonstrate that you do. But none of them actually tell you how to go about doing it. A good example from ASPICE is SWE.1 - Software Requirements Analysis. It tells you that the outcomes include allocating requirements to software elements, categorization of requirements, prioritization, establishment of traceability, evaluation for impact (to cost, schedule, and technical), and so on. However, it doesn't actually tell you how to do those things. Scrum has some answers to some of them, and other practices can be used to fill in the gaps in Scrum.

Can you please elaborate on “these can be measured by your maturity model”?  I’d really like to better understand what this should look like in practice.

Maturity models are designed to measure the whats that you do. In other words, how well are you meeting the goals and objectives set out in the maturity model. There are a near infinite number of ways to satisfy the goals and objectives, some better than others given your context. It's a matter of demonstrating that how you work satisfies the goals and objectives in the model.

I missed something important in saying “each horizontal level of the v is done iteratively and incrementally”.  I should have added “in parallel” to the end of that sentence.  ie. not sequentially.  Does anyone disagree with calling this Agile?  (I need to think more about Ian’s question - can it be called Scrum or just Agile.  My first instinct is that yes the outcomes output and practices in the V model could fit with scrum but only if “each horizontal level of the v is done iteratively and incrementally and in parallel across time as opposed to sequentially”.

Filip- thanks for weighing in.  It’s nice to hear how companies have applied it which is thankfully different than I described.  I also agree that if the design and requirements are expressed via vision without too much detail upfront (ie. no huge list of detailed requirements with requirement ids and lengthly design documents needing peer review), the spirit of agility would not be voided in the same way.

Katherine 

Thanks Thomas.  You said "You can apply iterative and incremental development to the system level or just to the software level." - can you confirm that in your experience, agile (iterative and incremental) it was only applied at the software level and not the system level?   Would it be true to say that when you saw this practiced, that the system requirements were all defined upfront, gating SWE? 

Overall, we are on the same page since you agreed that what I described was not Agile.  I'm still curious about some of the details of the process as you saw it implemented,   Could you correct the following to match your experience?  This would help piece things together in a more visual way for me.  These points are based off Slide 5.  I could still be way off base but would really appreciate being corrected :)

1- SYS2 - define system requirements completed followed by SYS5 which is System Qualification Test

2. Start after step 1 complete.  SYS3 - system architectural design completed followed by SYS4 which is System Integration 

3. Start after step 2 complete.  This is where Agile begins.  All three of the SWE levels and not just the bottom red level are contained within a single iterative incremental approach which, as you mention, includes requirements analysis, architectural design, detailed design and unit construction, unit verification, integration and integration testing, and qualification test.

Thanks again. It really helps to talk to someone about this who's been through it and is also a proponent of Scrum.  

Thanks Thomas.  You said "You can apply iterative and incremental development to the system level or just to the software level." - can you confirm that in your experience, agile (iterative and incremental) it was only applied at the software level and not the system level?   Would it be true to say that when you saw this practiced, that the system requirements were all defined upfront, gating SWE? 

I have yet to personally experience systems engineering work done iteratively and incrementally, so yes - my experience is with a waterfall systems development model that gates a highly iterative and incremental software model. However, I have read case studies involving iterative and incremental approaches at all levels.

What you describe is how I've typically seen it done personally. The systems requirements are defined and "locked down". Once the requirements have been allocated to software, that kicked off two things in parallel. One was an iterative and incremental software development process and the other was the creation of systems integration tests and acceptance test procedures. The software development included all of the software steps in a traditional agile approach.

Someday, I'd be interested in seeing the approach applied to an entire system and multiple engineering disciplines. But until then, I'll just have to settle for reading about it, since my current company only produces software.

Thanks Thomas.  I think if all three SWE levels are included, that at least makes a lot more sense than using it only in the red boxes.  I think a Systems Engineer might argue that since the software requirements trace up to the system requirements which trace up to the market requirements, this constrains the software requirements and means that even if we try to apply an agile process at SWE, it’s still not truly agile with respect to requirements.  Thoughts?

Why not start with a known subset of system level requirements, and start implementing software and tests for those in one iteration? Then in next iteration you produce more system level reqs, more software, more tests... All well connected together, all traceable, but all going practically hand-in-hand, without real time-phasing.

Thanks Thomas.  I think if all three SWE levels are included, that at least makes a lot more sense than using it only in the red boxes.  I think a Systems Engineer might argue that since the software requirements trace up to the system requirements which trace up to the market requirements, this constrains the software requirements and means that even if we try to apply an agile process at SWE, it’s still not truly agile with respect to requirements.  Thoughts?

If the concern is that "we don't know all the system requirements, so how can you trace software requirements"? I would argue that if you have a known subset of system requirements allocated to software and then derive additional software requirements from those as necessary, and iterate on those, then the system requirements can be informed by not only the market requirements, but by the software.

Even if there was a 1:1 mapping between software and system requirements (a case where the system only contained software), part of agile is to reduce risk by demonstrating (if not delivering) capabilities and functionality. Yet we don't consider this to be a constraint, but an opportunity for new requirements to be levied or existing requirements to be changed or removed by way of seeing what a software element is capable of.

Philip and Thomas.  Thank you so much for sharing your knowledge and experiences.  Your responses were incredibly helpful and insightful.  This all makes perfect sense to me :)

I just wanted to clarify that in my original post I said that the ASPICE v-model is waterfall, but we don’t think this is the case because we don’t believe time runs along the x-axis ie. horizontally from left to right.

While debating on assuring compliance with ASPICE and following Agile Scrum in our company projects, I want to get practitioners thoughts on the way I realize this fusion of Agile and ASPICE,

how about, as long as the processes are followed as per ASPICE in an Agile project environment, while Software development progresses and the project completes, both Agile Scrum and ASPICE compliance can be achieved hand in hand? (can't we? I do not see any conflict there)

ASPICE does not enforce any number of times a process should be executed (for example SW requirement analysis can be done over and over again until requirements for customers are truly captured). So if there are updates to any of the process's outcomes what's the harm? we are only improving or refining something.

In real-world scenario, if the ASPICE auditor asks for evidence on how SWE.1 SW requirements Analysis was performed for e.g., even if the requirements did change due to iterative and incremental process of Scrum SW development, again, as long as the team followed the ASPICE processes (through best practices and work products creation), how does it matter if requirements or designs changed over the project life cycle. The project team achieved a higher quality of SW development through following best practices (or for higher capability levels through maturing the processes well in the organization). ASPICE gives that assurance to the OEMs that suppliers are following the practices and processes defined in order to create a safe and quality product.

I hope my understanding makes sense, would like to hear conflicting thoughts or practical challenges around this understanding.

I wonder if the hangup here is between Agile and agile?   If you go back to the Manifesto for Agile Software Development it advocates simplifying process, iterating on work based on new information and being able to quickly adapt to changing needs/requirements.  On the other hand Agile is something made up by people trying to commercialize a principal. 

As such I think that an agile mentality and techniques would be very useful and successful in the ASPICE methods. Using empiricism as the basis of the work you are doing will never be harmful and mostly results in better products.

The manifesto also states things that are favored other others.  ASPICE requires some levels of documentation. There is nothing in the manifesto that says documentation is wrong. It just says that it favors "working software over extensive documentation" and that "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.",  But note that the documentation requirements in ASPICE are not so much for the development team as for the entire team and external parties as needed.  Documentation can, and should be, part of any software development effort at the appropriate levels and for specific uses. 

Scrum is a framework that can help organizations and teams to have more agility. Could Scrum be used with ASPICE?  Sure it could but it will require the organization to understand how it benefits them. It also requires that processes be adapted to work within the framework.

I had experience in working with ASPICE and Scrum together.

As ASPICE model is visualized using V-model, its bit misleading.

I feel that ASPICE and Agile complements each other and I agree to the points in below link.

http://www.svenstig.nu/2019/04/29/agile-vs-a-spice/