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.