Agile and ASPICE

Last post 07:59 am June 30, 2019
by Katherine Brown
15 replies
Author
Messages
04:12 am June 26, 2019

Hi Fellow Scrummers,

I was wondering if I could ask your opinion on the slideshow at the link below.

https://www.slideshare.net/RuchikaSachdevaITIL6/autospice-agile-hand-in-hand-71671833

In a nutshell, ASPICE is a method of development for automotive projects based on the waterfall v-model.  It dictates that your market requirements (problem domain) and design/technology (solution domain) are both defined upfront.  Some companies are applying "agile processes and events" to (only) the red boxes on slide 5 and calling it "Agile ASPICE".  The idea is that during the implementation and testing of code at the bottom of the V, you do two week sprints and get user feedback and then if changes are needed, you need to go through a formal "change management" process to implement those changes.  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. 

My questions are:

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

2- Am I the only one who thinks it's very wrong for an agile process to repeatedly trigger "waterfall upfront planning"?  :(

I am trying to make sense of this so I appreciate anyone sharing their thoughts.  Thank you,

Katherine 

 

 

09:39 am June 26, 2019

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:

12:27 pm June 26, 2019

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

12:40 pm June 26, 2019

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

01:12 pm June 26, 2019

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.

02:14 pm June 26, 2019

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

 

 

02:15 pm June 26, 2019

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

03:08 pm June 26, 2019

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"?

04:04 pm June 26, 2019

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.

04:13 pm June 26, 2019

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 

05:00 pm June 26, 2019

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.  

06:35 pm June 26, 2019

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.

04:35 am June 27, 2019

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?

08:42 am June 27, 2019

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.

09:36 am June 27, 2019

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.

07:59 am June 30, 2019

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.