DSDM
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:01
>> Hello and welcome to lesson 3.4: DSDM,
00:01
the Dynamic System Development Model.
00:01
I'm your instructor Kane and we're going
00:01
to be going over this particular flavor of Agile,
00:01
which actually was also developed in the 1990s,
00:01
but it was more of a response to some of
00:01
the shortcomings at the time
00:01
with rapid application development.
00:01
In essence, once we got into the mid to late '90s,
00:01
we were moving away from green screens and onto
00:01
more of the power builder
00:01
graphical user interface type of thing.
00:01
That was where rapid application development
00:01
began to become more popular,
00:01
and a lot of the blue-chip companies,
00:01
these are the large companies
00:01
that were complaining about the speed of
00:01
the normal traditional waterfall project management
00:01
got together and created
00:01
a DSDM consortium that came up with this DSDM framework.
00:01
Again, this particular flavor of Agile
00:01
can be leveraged with other types of Agile frameworks.
00:01
It's tool independent,
00:01
so it doesn't necessarily subscribe to
00:01
a particular software tool,
00:01
whether it's combined boards or Microsoft
00:01
project or any of those, it is software-independent.
00:01
In addition, it's often sold as one of
00:01
the most viable Agile methodologies for non-IT projects,
00:01
and I think you'll start to see why here
00:01
as we go through today's lesson.
00:01
The big thing about DSDM is,
00:01
of course, it's business need focused,
00:01
it's incremental and it uses
00:01
the same basic Agile premises as the other flavors.
00:01
But this really is the first inclination of what we
00:01
would call a hybrid methodology
00:01
where Agile is sometimes used,
00:01
which is the combination of waterfall and Agile,
00:01
and it uses the idea
00:01
of building incrementally from firm foundation.
00:01
It has a level of governance and
00:01
a level of oversight that makes it
00:01
appealing to your bigger government projects and some of
00:01
those entrenched blue-chip-type companies because we have
00:01
a dedicated planning and
00:01
requirements development process that is
00:01
being progressively elaborated and
00:01
progressively refined but your stakeholders,
00:01
your executives have a lot more governance structure
00:01
on this type of an Agile methodology
00:01
than they do in some others,
00:01
so that tends to make them a little bit more
00:01
comfortable with this particular flavor of Agile.
00:01
We're still doing our continuous improvement.
00:01
We're doing our iterations,
00:01
what they call a time-boxed method,
00:01
which most Agile really is a time box,
00:01
meaning that of your triple constraints,
00:01
the schedule constraint is the driver.
00:01
It's locked down and the other
00:01
two are allowed to fluctuate,
00:01
so your performance and your effort
00:01
throughout the life cycle of the particular project.
00:01
One of the interesting things about
00:01
DSDM that make it easier
00:01
in some cases to visualize is
00:01
they're proponent was called the MoSCoW method.
00:01
When you're developing requirements,
00:01
because remember DSDM has
00:01
a requirements development phase
00:01
that's a little bit more
00:01
formalized and some of the other flavors of Agile,
00:01
the MoSCoW method is used to basically say must-have,
00:01
should-have, could-have,
00:01
and will not have.
00:01
That's what makes the acronym MoSCoW.
00:01
But the idea is as you're building your requirements,
00:01
the business owners and the stakeholders can have
00:01
a say in what is definitely in scope,
00:01
what is out of scope,
00:01
and what those gold plating
00:01
nice-to-have things are and it gives you some essence
00:01
of a priority structure
00:01
that's a little bit more formalized with
00:01
the business community outside
00:01
of just the scrum team getting together
00:01
every two weeks and talking about what
00:01
the system should be doing and what the new features are.
00:01
It's a little bit more of a clearly communicated effort,
00:01
we have this requirements matrix which gives a warm and
00:01
fuzzy to some of those folks that are
00:01
more tied into the waterfall methodology,
00:01
or this may be their first time trying
00:01
something with Agile and it
00:01
allows for the requirements in
00:01
the planning phase to be
00:01
a little bit more water folly and structured,
00:01
which also makes contract management
00:01
a little bit easier for those of you that are
00:01
working for the government or
00:01
large organizations as we've gone through this course.
00:01
Some of you with a lot of contract management experience
00:01
might be shaking your head and basically saying
00:01
that there's no way that
00:01
our organization can do this because we can't get
00:01
a contract written that would be approved by legal with
00:01
some of these other Agile methodologies
00:01
and that is a concern for quite frankly,
00:01
a lot of larger organizations that still want to
00:01
develop and produce production-ready software
00:01
at a faster pace.
00:01
What you start to look at is
00:01
that requirements gathering piece,
00:01
and then we go into prototyping.
00:01
That's what makes it a little bit more
00:01
iterative versus some of the others.
00:01
You'll see a little screenshot here.
00:01
Talks about some different project phases.
00:01
You've gotten your feasibility,
00:01
your foundation, your ROI, your business case,
00:01
all of these things that develop a warm and fuzzy for
00:01
the individual business owners that maybe
00:01
aren't all on board with a full Agile project.
00:01
Then we go into this exploration prototyping.
00:01
We start looking at how we can
00:01
implement the things that we would develop in
00:01
the feasibility study and
00:01
looking at those MoSCoW work items.
00:01
Then you go into your engineering and then you
00:01
start doing your deployments and things like that.
00:01
It gives you a little bit different look.
00:01
There's a waterfall essence
00:01
and then when you get into the iterative development,
00:01
as those MoSCoW work items become more like a feature
00:01
or a product backlog and you've done some of
00:01
those additional pieces of discovery about them,
00:01
then you start getting
00:01
into the Agile methodology and you start
00:01
really focusing on building
00:01
that quality program or that quality feature,
00:01
doing your testing and making sure
00:01
that you are able to deliver on time.
00:01
That, again, makes
00:01
the business community feel a little bit more
00:01
comfortable that this is not a never-ending project,
00:01
which is really one of the negative stereotypes to Agile.
00:01
I don't think it's necessarily true,
00:01
but a lot of companies are
00:01
unable to implement Agile correctly,
00:01
and what you end up with is basically
00:01
a never-ending project that
00:01
we're always throwing money at it.
00:01
There's always things in the backlog,
00:01
and so they don't get the sense of
00:01
completeness that they might
00:01
otherwise have gotten with a waterfall type of project.
00:01
That building on firm foundations is really
00:01
a key element here to DSDM.
00:01
That was popularized in the late '90s,
00:01
came about again because rapid application development at
00:01
the time had a lot of
00:01
the same complaints that Agile now has.
00:01
Again, as the old saying goes,
00:01
what's old is new again,
00:01
there were that phase in Agile.
00:01
That is one of the areas that DSDM is trying to address.
00:01
In today's video, we discussed
00:01
the dynamic system development model
00:01
and talked about some of the ways that
00:01
it might be more appealing to
00:01
implement in
00:01
a structured and more formalized organization.
00:01
Thank you very much and I will see you in the next video.
Up Next
Similar Content
