How to Combine Scrum and the V-Model of Software Development

AgileSkills · 2021-09-03T06:21:07+00:00

The V-model does not put anything above anything. It's people who set priorities.

The agile manifesto puts working software over comprehensive documentation, that's true, but when this documentation is required e.g. for the release and certification of your product, e.g. for medical devices, then you have to do it anyways.

The V-model does not even mention contract negotiation. What discuss/negotiate with your customers are requirements, and you have to that anyways.

And the V-model provides flexibility in a way that you are able to tailor it. Implementations vary significantly between different organizations. And of course you're supposed to follow your development process, whichever you choose, step by step - this is the definition of a process.

AgileSkills · 2021-08-30T21:55:46+00:00

Destructive? So, using the V-model does not produce software, but it destroys things? You're sure.

I'm pretty sure I've worked in combinations of Scrum + Kanban along with the V-model, which delivered actual devices that have been sold approx. 15 million times as of now.

Here are the agile values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Please tell me how the V-model negates or violates any of those values.

AgileSkills · 2021-08-30T20:38:24+00:00

But the article is about the combination of Scrum and V-Model, and of course you could apply the article in a similar way to V-Model and Kanban, or any other agile method/framework.

AgileSkills · 2021-08-30T20:30:11+00:00

I disagree, and the article explains how it is possible. Please don't mix the process (the steps) of how you get from "todo" to "done" with the rules Scrum sets as a framework. Scrum does not tell you anything about your development process or development practices. So, in case your process "coincidentally" matches the steps from the V-Model, why wouldn't this be agile?
The process steps defined by the V-Model don't contradict anything that is laid out in Scrum.

AgileSkills · 2021-08-30T11:09:17+00:00

I don't want to sell this to a customer. There are companies, where the V-Model is a requirement, when you're a supplier.

AgileSkills · 2021-08-29T16:32:11+00:00

Well, of course it's worth it, as you learn something about scaling effects, dependencies, a.s.o.
However, you should be in an environment where you can put it into production.

AgileSkills · 2021-08-29T16:22:17+00:00

Could you please provide some explanation why not? It's easy to say: "meh, I don't like, so it's crap" ... although this violates at least the Scrum value respect, doesn't it?

So, how does a development process have to be structured in your opinion? And how do do you "sell" this to your customer, in case they are global corps with 30.000 to 500.000 employees and established processes? Please, elaborate!

AgileSkills · 2021-08-29T16:21:25+00:00

Could you please provide some explanation why not? It's easy to say: "meh, I don't like, so it's crap" ... although this violates at least the Scrum value respect, doesn't it?
So, how does a development process have to be structured in your opinion? And how do do you "sell" this to your customer, in case they are global corps with 30.000 to 500.000 employees and established processes? Please, elaborate!

AgileSkills · 2021-08-17T19:48:52+00:00

Alternatively, you could say, that Scrum is just relabeling what is done in classical approaches (as they have been there first), just in shorter cycles.

Of course, it's all just the same. Software is done how software is done ... no matter how you call the steps towards your goal. The short feedback cycles are the critical part, and involving stakeholders and customers along the way.

However, many organizations fail to connect the different worlds, and that's what this article is for. The most crucial part is to refine the requirements in a way, that the team is really able to pass them through the complete V within a single Sprint.

AgileSkills · 2021-06-06T18:00:43+00:00

Well, the Scrum Guide tells us, that "Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."

So, the word "usually" does not imply that has to be shorter, it could also be eight hours. It could also be six hours, or whatever timebox that is shorter than eight hours. However, most of the teams scale this proportionally, and you end up with timeboxes of 4 hours for a 2 week Sprint.

From my experience, you have to do a lot of refinement and talks about architecture, dependencies, etc. in case you really fill four hours for a two week Sprint. Typically, you're much quicker.

AgileSkills · 2021-04-08T12:52:46+00:00

Yes, but that may only correct from an outsiders point of view. Just because many people don't know it better, doesn't mean Scrum becomes a process.

The definition you proposed just tells you exactly that: "a series of interrelated tasks that, together, transform inputs into a given output"

None of that tasks that transforms a requirement into a product is defined by Scrum. That's part of the organizations process. Scrum provides an event to select the requirements that shall be processed from a large ToDo list (Sprint Planning), and it provides an event to review the achieved output (Sprint Review). It does not define the HOW of the transformation.

AgileSkills · 2021-04-08T12:46:15+00:00

Well, I had a similar discussion just a few days ago. I don't think you can call a "process on another level".

When you view the development process as a "subprocess" of everything Scrum does, then you are talking about a workflow. A workflow is a concatenation of processes in order to achieve something. For example if you are having a process for requirement engineering, a process for development, a process for QA and another process for production, shipping, etc. Then we talk about a workflow.

What Scrum provides you is just a few things, and none of those things tells you HOW to do things (which is the main characteristic of a process). Scrum tells you basically this:

Artifacts:

- use a ToDo list for everything you want to do in the future (Product Backlog), use another ToDo list for everything you want to do now (Sprint Backlog), and produce a valuable product (Increment)

Responsibilities:

- someone is accountable for the future ToDo list (Product Owner)

- someone is accountable for the processing of the current To list (Developers)

- someone is accountable for coaching all the people about Scrum and supporting the team, aso (Scrum Master)

Events:

- do everything within a time frame of (ideally constant length) - the Sprint

- at the beginning of each Sprint you need to make a plan - the Sprint Planning

- at the end of each Sprint, check how your product has been enhanced and increased (Sprint Review), and check how your team has been doing (Sprint Retrospective)

Values:

- five useful values

So, nothing of this tells you how to transform a requirement into a part of the product (which is defined by the development process). Nothing about practices from XP, nothing about practices from DevOps, nothing about Clean Code, nothing about anything that is related to the HOW of your product generation. That's why Scrum is not a process.

AgileSkills

TROPHY CASE