Hey there. Welcome to the Better Business Analysis podcast. While Ben's gearing up for the show, I've got an exciting offer just for you right now. When you enroll in our Certified Better Business Analysis Level One course, use the Code Podcast at checkout to score a whopping 50% off. Don't miss out on this fantastic opportunity to elevate your skills and advance your career. Head over to our website and enroll today. The Better Business Analysis Institute presence.
The Better Business Analysis Podcast with Benjamin Walsh. Hi everybody, it's Benjamin Walsh from the Better Business Analysis Institute. Check out our website at BBA dot Institute. Now this week we are going to be delving into a topic that I kind of found by accident and I'm going to give you back story as I always do before we get dive into the topic. So I was working at an
organization, a consultancy. We had a large intake of graduate testers, and one of my responsibilities was to give these testers an idea about what business analysis was all about and explain the benefits to testers when it came to business analysis. Now, one of the traditional models of testing, if you're not from that world, one of the fundamental models back in the day is something called the V model. Now, these testers were new.
They were being trained in testing, They didn't really know what the V model was, but a lot of BAS don't know what AV model is, and a lot of testers will look at the terminology V model and maybe go, Oh yeah, that's really old. How? How's that applicable in an agile world? Now we just pause there for a second and just rewind and say look, if you're a tester, what
is your job? So your job is to test that the product is working effectively, that the process can be completed, and ideally, if you're, you know, doing proper functional testing, you're looking at can the job to be done be completed successfully? You raise defects and bugs and whatnot, and some of the artifacts or outputs that you are trying to produce actually align very nicely with some of the artifacts that we produce in the wood of BA and also in the
architecture space. So if you like the specifications that we write, the high level requirements, detail requirements, then the architects or devs might put together a solution design and then you know write code if you like, which go into a product map, two different testing artifacts that need to be done throughout testing and there's something called shift left and testing. It's really around getting testing up done up front.
And so things like a test plan done by maybe a test manager or a test lead should be done quite early. And so the idea of the V model is that you say, well, when the high level requirements are put together, you know you should start on your test plan. And when the detail requirements are done, you should start to go into more detail. And when the specification's done, you could start getting into your test cases and and and so forth.
So there's a map between kind of things like unit tests which connect to packets of code, and there's different levels of abstraction and testing, much like there is in the world of business analysis and also solution design, architecture and development being subcategories of that. So the V model is about mapping those two, right? And it and it and it existed to say we should start these things early as testers. And this is actually the input. So you can take two things away from that.
One is that testing should start early, as I've just said, but also that testers aren't making up test cases or test plans from nothing. They are using the artifacts created by the BA for the first half and then the solution designer, the reply to the requirements and then the developer, if you like to create their materials, right. So you know and if we just look at the middle segment there, you know test cases come from the requirements.
They should the user stories have acceptance criteria which link to test cases. So I think it's important in this episode to understand who's using your requirements. And I would say a large audience was there's there's two audiences. If we take a kind of a parallel path here, one is the tester is using your user stories to correct test cases. Because ultimately they're testing whether or not the user story is acceptable and it has the acceptance criteria being completed.
And at the same time and generally, first, the program is writing code, producing the product, adding to the product, you know, improving the product based on the user story. So the user story is critical to both the developer knowing what to do and also the tester to know what to test. And then the words come together when you go through the testing process. So this is, this is true.
You know, this is really true proper development and regardless of methodology, regardless of waterfall or agile if you like. And I'm just going to use those two examples. There are many others. They're the most, you know, the ones that we talked about. They're the most. This is true regardless of of of what kind of methodology you're using. This is what happens. This is the whole point, OK.
So it doesn't matter if you do it rapidly and slices like Agile or you're doing it as a Big Bang. This is, you know, you're testing everything at the same time, you're, you know, writing requirements and you're delivering well at the same time. Which is more waterful approach, approach, which is one end of the spectrum. This is true. So anywhere on that spectrum, this model is true.
OK, so the V model is true. It is not something that is old and may have been developed a while ago, but it is true. It is a fact that this happens regardless of methodology, OK? And it's really important to know that this exists for testers and us, but also it shows who's using our requirement. We are writing our requirements for the developer. We are writing it for the tester, right? They need it to complete their
process. So by understanding this world, you as ABA can write better user stories, OK? You can provide more clarity, you can be more concise, you can be more accurate and transparent and help these two audiences which are your prime audience of your output to to really understand what your customer wants.
And of course your first job is to make sure that the requirement reflects, you know, adds to the epic if you like or the and then the themes, the objective of the project and that your product owner and whatever shape or form they exist in either the end customer business owner or a proper true product owner that you have captured.
You know what they want in true detail after you've translated that, which is the process of business analysis, elicitation and analysis and then translation into your user stories, right? So if you like, that first half is the input and the process you go through and then the output is testers and developers okay and probably designers as well.
So during the design phase you may have designers who have to read your requirements and to be honest, I find them the most tricky because they can be the most creative and move quite far away from some of the functions you're just trying to get in there. So you need to, you know, use this process to to also map to them. OK, so this is who uses your requirements. It's really important. I think that's the number one lesson from this whole topic today.
But so if you've taken that away, then this all the rest of this is going to be bonus. And the true purpose of this episode today is to talk about something called Agile V Model. OK, And this was something I actually stumbled across.
Obviously, conceptually it existed in my head, but I hadn't found a body of knowledge or really one institution or Wikipedia article or whatever it was that fully captured exactly my view of the world, which was just if the VML exists, if the VML is true, if that's the premise we're going with here, if requirements you know map to test cases, if you know it feeds into development and there's a relationship there, and it should happen ideally all at the same time, what would Agile look
like? And for me, if you're following this process, so imagine AV, imagine driving down a hill and then right up a hill again. So this is it's AV and have you there's maps going down the V at the same time the testers doing their work as we head down the bottom of the V to the product. So the products down the bottom, what is it that what what would that look like in an agile world.
So conceptually, I knew that if simply if as we start our V journey, so the test plan's done, maybe we're in a bit more of a structured approach once we get down to the design and kind of doing the release of product increments, which is agile, aren't we just doing the V model again and again and again and again, again rapidly? Aren't we just saying, well, OK, well then the requirement's done, It's released in the product, but the test and then test it.
So with a with a waterfall project, all the requirements would be done into the product, the tester would test all the do all the tests, right? So that's the traditional V model. So in an agile model, wouldn't we just be going, well, one requirement's added to the
product to the bucket. The tester then just takes that thing and tests that thing and then we know that that they might do other things called integration testing or regression testing to make sure that the product that that new feature of that it hasn't broken anything. So there's a little bit more to it, but in effect, isn't Agile just doing that again and again and again every, every Sprint? Aren't we just doing lots and lots of these? And So what I did is I searched it up.
Agile remodel, there's got to be something like that. And I found a great place where this is articulated in in a fantastic manner and it's not actually from the world of all all projects. It is actually being talked about in the Internet of Things project. OK, so when if you don't know what Internet of Things are, they're all the devices, small devices, smart devices that exist everywhere. So it is probably was the really quiet revolution just before AI, but it was taken off massively.
So these are the little smart devices that might be a sensor somewhere, little tiny things. You can buy them on the Internet, Internet, if you've got a smart home, all those things that connect to your phone, like the robot or the air conditioning unit or a sensor for the door. Or I've got a for example, we've taken out our our lock and we have a smart lock on our front door. That's an Internet of Things. So all those things, they're
usually small devices. They usually last for a long time as in they don't draw much power. They only use power when they when they need to. The these things are all around us now. The sensors, the and they're built into things like drones and all the rest of it. So all these tiny devices now, not PCs, tiny devices are connected, OK, need to connect to wireless or the Internet and they're a piece of hardware
generally. So all the things that were true of hardware programming, So what we would what we used to call kind of assembly code or lower level programming needs to be true. They need to have rapid release, they need to work when you release, you need to release full and complete, they need to work or otherwise that device
goes offline. So, so I guess one of the things that is true or a better way of articulating what I've just said is that these devices will update and need to be updatable quite rapidly, right, for the software and those things need to continue working, as in you can't do a huge massive bunk
release. So in order for Internet of Things to work effectively, there had to be some thought about continuous releasing, continuous testing, and all these things that if you're involved in a programming firm
you understand about. We talk about continuous testing, continuous integration and all these things are great for large pieces of software, but they have to be true in the world of Internet of Things because if they don't then those those devices go offline and then you know they stop working, those sensors stop working. So some of the so that this area was forced to think about about what methodology would work if we naturally needed to continuously improve the
workings of these devices. OK And what is the method that we use to continually improve these devices? It's agile, right? We need to release rapidly. We need to release iterations. We need to do changes rapidly on the fly. So we knew that was true, but how do we do that? So we am sure, we are sure that the release we've got out there is true and proper and not just like cowboy programming. So we need Rigger and what brings us Rigger, the V model having a map through.
So they've combined and they've combined those two methodologies in a kind of an academic way, but in a conceptual way and now a real way. And they call it the Agile V model. So I've actually most of what I'm going to talk about next, I've stolen from the what's called the Digital Playbook. It is available if you look it up Digital Playbook and it's talking about what is the difference between Agile and kind of the Agile incident of things and what is the Agile V model.
We know the benefits of Agile. We know the fact that it has some massive shortcomings when it comes to certain types of projects which are generally mission critical projects or complex projects. They it's really easy to think of when you've got your startup hat on and you're releasing a
web app, that's fine. But if you're say dealing like I said with these mission critical devices that are out there that could be sensors on nuclear power stations, you know, these are things that more aligned with what I would call, yeah, more critical kind of pieces of infrastructure.
It's the same kind of mindset, it's more hardware related with things can't go wrong, OK. If your web app has a bug, you you might accept that and go live with it because you're getting customer feedback and it's it's not going to kill anyone, whereas this other side could literally result in harm. So we need to have some structure and that involves complexity. So how do you do that rapidly without going fully, you know, waterfall and just baking in.
Too much process and too much governance. And this is the answer. So when we talked about the V model earlier, some of the disadvantages of the V model was that it was inherently waterfall based. As in it didn't think about there was just one V, right? It didn't have the VVVVVV on forever, It was rigid and it was inflexible. It didn't support iteration or implemental development. It didn't really talk about MVP or prototypes or continuous improvement.
And ideally because it was just one V, it wasn't possible to adapt to changes midway through development. You had already committed upfront which was you know I guess some of the disadvantages of waterfall and so therefore you know you can make small changes if you needed to and do it like a hybrid waterfall model. But it was kind of seen as having a bit of a bad reputation. A lot of people didn't actually look to the V model and it and and they literally will turn
their heads. Have you. I had people turn my heads when I started talking about it and I was like, I don't, I don't understand why you got the bad thing. Some of the advantages though it was suited for stability when it came to complex requirements which was required really when you had multi company development projects. So that's the other lens when you look at here is that actually if you've working with lots and lots of teams you need rigger in terms of making sure
they all come together. It's not a mess. So with incentive things there might be people looking after the hardware, the software, the you know, the location, the logistics of these things. And so it it could be it can be quite difficult in that environment, which is why the again why this methodologies probably come from their
environment and their landscape. There was the built in with the V model originally there was the built in verification and validation and that was really, really important for what I said before, highly regulated mission critical applications where you have to have that like that was that's critical.
If there was a, if there's a bug, you know in the unit testing or integration testing which is the verification tests or there was even validation testing in terms of user acceptance or usability tests, if those things went wrong, there was a bug, it could result in harm. So we needed to kind of they needed to this company which is called the, you know the Digital Playbook and it's there's a company behind it. I'll let you Google that yourself. They were looking at these
problems. OK, so the so the and this is they, They've again only applied this to the Agile Internet of Things framework. But for me, I think we just we can apply it to any project that's in this kind of landscape of mission critical. And I strongly believe that any project still goes through this general method. If you go to the the Agile Internet of Things playbook.org, you can Google it. You'll see visual pictures which will help outline what I'm saying here.
So it'd probably be useful to load that up and have a look, even pause the podcast, look at it and then come back to it. But what we can so but I'm going to give the outline in words since you've got it in your head and then you can see the pictures. So the idea of the Agile framework and I'll quote here and it it aims to strike a good balance between agile software world and the least agile world of often safety critical, complex and large scale projects. OK with hardware and
manufacturing elements. So the idea of the Agile V model is to combine agile development with the V model, right? You can do this. And so like I said, it's kind of a series of these that just keep going. But on the left hand side, you've kind of got the more structured system design, decomposition and the requirements which they don't talk about here. So I'm saying that BA fits into this.
You've got the increment planning and that happens for your like your Sprint and then of course you're doing your validation, verification, continuous integration, continuous test and continuous delivery. So as you release, you're doing that again and then that's for one Sprint. And then you do it again and again for every other Sprint. So each Sprint becomes a complete V that includes the development and the integration
and test. The edge off schedule introduced the concepts of dedicated integration sprints. So we've talked about this before. Not all sprints have to end in a functional change per SE. It could be Sprint to do requirements upfront, It could be a Sprint to do some design only tasks.
So in this methodology, we introduced the concept of dedicated integration Sprint. And what we're actually doing is that you're benefiting both the agile way of working and also of course the more rigid way of working.
So it allows us to skid do a kind of like if it's Sprint in, it allows us to do Sprint in plus one and so forth again and again and again until we have released in a true proper way the way we want to do it. So if you look at the BA world, the starting point before you even start getting into this kind of idea and they do talk about Sprint 0, which I don't particularly like, which is a preparation Sprint. But look, you can do this in an agile while or not.
I would suggest as I talk about quite a lot is that there's work to be done before you even get into the development phase and that's the whole framework of the Better Business analysis delivery journey. So if you think there's some upfront strategic product planning that needs to happen.
So that's the kind of first cut, what I would call the high level business requirements phase and all the work before that you would already start, you wouldn't start this process, OK, the development process until you've already got a story map and the definition of done complete. You've already got the component architecture. So you know basically what the architecture is going to be.
You've got the team, you've got the environment and then once that's set up, you could call that Sprint zero. I would call it kind of the upfront analysis, strategic and enterprise analysis phases in the VA world. You do all that, and once that's set up, you then kick into these VS OK? And of course, if you're using the story maps, you've got your high level. I don't know in this method, don't. There's something I don't like about it.
They group their story maps into functions, whereas we would group those into epics and then of course all the different posts under that. They are your user stories. So the story maps should outline the epics required to get the job done. OK, So what I again, I'm taking the best bits of this methodology and trying to make
it generic to business analysis. So if you like, I'm taking the edge of the model developed for the incident of things and I'm saying that you can apply this to your work regardless of whether or not you're working on Internet things or any type of project because it's still true. And I'll talk about how the testing element comes in here. You've got your user story, you've got your acceptance criteria right, which are which are ideally you know the detail behind what you've got on your
stereo board. You've got your definition of done from the agile world which is kind of cross use case criteria which need to be true. And then you've got your generic criteria that come off it. So it's kind of your unit test, your code review, your non functional requirements and that forms the basis for the testing world.
So you're using not just you know if you like just the requirements, you're actually able to check that we are our Sprint goal and the definition of done at the front of our Sprint is done as well. So you're combining the both traditional V model aspects of just requirements to making sure that you're actual definition of done for your Sprint is is true and of annual definition of done.
You would outline things like all tests need to have been passed, the code need to have been reviewed and that these non functional requirements were met. OK, so there's a lot that you can take in by reading that. There's a whole lot of visual pictures that will be helpful for you to kind of understand this a little bit more. But I want to talk about the kind of high level phases for the V model making the connection and then talking about really some real real world examples here.
So the phases really of the Agile V model in summary are planning. So you're emphasizing upfront planning of with flexibility and adaptation. So that's doing the strategic planning, doing your storyboard. So that's kind of from product management leading into agile there. So that's all pretty modern day techniques, that's not old school, that's not little for then in the development phase you're using the iteration sprints, you've got integrated kind of V on V activities.
So as the VS dip and go into the next V, there are integration activities at the end of that which are happening, which is more of the continuous integration and testing. And I'm not going to go into that, but that's the new way of DevOps world. That's what DevOps is all about. Then you've got the verification, which is highlighted through testing within each Sprint, within each Sprint, not at the end which is the old way validation.
So you're on, I guess that's ensuring that the solution meets the overall goals. So you know it's not just the product is fit for what you have just developed in that Sprint. But overall the product as a whole is still meeting the user requirements. That's what we talked about by validation. The job to be done is still working. We haven't broken anything and the user is able to complete their complete journey end to
end. We call regression testing as the testing team that helps with that. There's around deployment, so there's carefully planned and monitored deployment at the end of these structured these which is really important as we said because you deploy once ideally to these Internet thing devices or mission critical. I would say that if you are applying this to a project like a web project which isn't mission critical, the deployment side is probably you still need to do it.
Probably it's good best practice to do it this way, but less important in terms of the disruption that would happen if you release something that had a bug in it. It talks about the fact that we we're incorporating in here feedback as well. So the importance of continuous improvement and adapting what we know. So because you're doing these, these, these these releasing these features, functions, requirements and testing straight away, you're getting feedback straight away from each
test, right? So you can feed that back into the process, not just the what we get from developing a feature or requirement and getting feedback, We can also get testing, validation and feedback and incorporate that into our agile kind of retrospectives. And we know, OK, well, you know, maybe we could do a better way of testing this.
And I'm not just right now, I'm talking about technical tests because I'm reading what how the V model has been applied to Internet of Things. But these can be, these can be usability tests, right? These can be customer tests. So it could be the fact that you're getting rapid test feedback from a customer directly through customer insights. So you've just released something that's mission critical or let's let's say we've applied this to a non mission critical environment.
So a website you've gone live with a website, maybe it's an ecommerce website, you're using the Edge LV model because you it's got you. The reason why you're using this approach is because you it's you cannot afford for there to be a bug on this website because you may be a big brand. So maybe Coca-Cola or McDonald's for example, where a bug would damage your reputation and may cost you if you had a bug.
In terms of the fact there's so many users who use go to McDonald's or or purchase Coke that if there was a bug and it involved, I don't know, people getting a discount, it could be financially crippling And just the fact that you've got you need this whole lot of non functional requirements because so many people are going to be using this app. So I would say that for McDonald's releasing the new McDonald's app, this would be a really good approach to use.
OK, so we've got our, let's say app, let's say it's a web app, but it runs on your phone. So an app, and you've released it on your phone. It's a new McDonald's app, and you get feedback straight away that maybe it's through someone like a hot jar or something that people just can't. You've just released a new feature around coupons, using coupons, and you're finding that people just can't figure out what their coupon code is and add it to check out
appropriately, right? And you're like, this is a disaster, starting to get social media feedback that it sucks, the new app release sucks. That no one can use the coupons. Is it a scam? And so you're getting that feedback. So next iteration you're like OK, well we released the feature like functionally everything was done like job to be done, tick like everything passed. Everything passed from a functional point of view or even
a non functional point of view. If you look at it in a pure software way, coupons were added.
I could add coupons. I didn't find it hard because I tested it. But if you actually incorporate end user testing, and I'm not talking about like the people at McDonald's who said, yeah, that's fine because I've used the app again and again, I'm talking about we've now had you know, the 1st 1000 users or a test group hopefully released this just to a test group of all app users, which is how things happen these days generally. So you have like AB testing.
So most people are using the old version of the app, but you know maybe the people in New Zealand are using the newer version of the app or Auckland, you can do that kind of stuff. So they're using it. So our test group is using it and then they can't use the coupon feature, it's just ineffective and they're starting to get some social media feedback. That's called customer insights.
We can take that in and go hey the functionally this tip we we didn't have a test case about, we didn't have the customer insights because we didn't release to the to our customers. So there was no way we knew this. We've just released that feature. We've now had feedback far out. We need to make some changes to the design to make it easier to use these this coupon feature. OK, so that's perfect, right. That's perfect. We've it's it's kind of a critical lab.
People can't use it. It's causing us reputational damage. It gets added to the next Sprint as a high priority item and we work along the way. And now then, maybe in our testing, testing, feedback, continuous improvement is OK. We're going to release this to a much smaller community to get feedback before releasing it to a larger group and before releasing it ideally to everyone, which could have happened. So do you see how this method, just having a bit of rigor in
there can actually help? So you're again getting testing involved earlier and those requirements are tested, but we're not just talking about testing for technology changes, we're also checking for customer insights.
Now I guess some of the comparisons that we talked about before is that you know you are getting this kind of certainty planning, validation structure and predictability that you got from the traditional V model and I guess you're addressing some regulation, regulatory compliance needs. So sometimes it's it's you actually have to test in this
way. So the signing off the test before you go to the next V, if you like, might actually require some governance and important governance, independent testing, all the rest of it. So this works in that manner as well, allows for that, but it enables this. So it allows that to cover that complexity and the compliance needs, but allows us to still work in an agile team and
environment. Now if you go to the kind of Agile Incident of things project and framework, you'll see some examples on which they have applied this to instant things. Examples which will help you understand what what I mean by this. But I do think that I want you to take this at a very high level. I want you to not get too obsessed with the method, that they have the detail of the method and take it away as more of a framework you hopefully you you have you.
By listening to me today, you know that there is a good way of incorporating structure into a project delivery framework that allows for agile to do things which you know are adaptable, responsive and change. But you're able to integrate the V model which allows us to catch early issues in the development process and allows us to get feedback in a really structured
way. And so therefore instead of just going fully waterfall which will be the alternative and do things very structurally and signed off, you can actually do both using the V model and allow the Agile V model and allows us to incorporate agile and the V model which will allow us to you know really have a collaborative way of detecting early defects,
customer satisfaction. You know, increasing collaboration, still allowing us to have adaptability and I guess release in increments, but also allow us to have some structure which allows us to make sure that projects are released right the first time and especially in mission critical situations like in the world of Internets of Things. I hope you have learned something today.
If you don't know the V model, your action is to look up the V model so you understand what I'm talking about and you understand how requirements are used. It's true it it exists in some form and you look up the Agile V model and understand both how Agile and the V model can be used in those environments I talked about. Cool. I'll see you next week.