The Custom Business Software Show – Episode 2: Why “DSDM” Is Ideal For Custom Software Development For Businesses

Brett

In this episode you’ll hear our thoughts on:

Focusing on the full project lifecycle with an Agile method
Providing best practice guidance for on-time and on-budget delivery
Adhering to its 8 principles
Meeting with the client to comprehend project objectives
Conducting a workshop to identify high-level features and screens necessary
Examining business constraints and processes to determine how the solution can enhance the business
Diving deep to uncover any risks or complexity
Calculating the entire project timeline
Breaking down the large time box into smaller “time boxes” for each feature
Progressing with development, testing, and deployment iteratively
Achieving 80% of the value with 20% of the effort
Delaying adding polish until the application is in a workable state
Enabling early delivery of value to the business
Employing a visual tool to show work at various stages of the process
Representing tasks with requirements and time estimates
Encouraging clients and stakeholders to be actively involved in the process
Continuing the process after the “time box” of work is completed
Adding new mini “time boxes” and continuing the process
Moving through the requirements gathering, development, testing, and deployment phases

So, listen here as we discuss these!

TRANSCRIPT:

Everyone may have heard of different software development methodologies such as the Waterfall, Agile, Scrum and Kanban.

But maybe there’s one variation of agile that’s less common or less well-known.

And that’s called DSDM.

DSDM is formally known as the dynamic system development method.

And it’s an agile method that focuses on the full project lifecycle.

It provides the best practice guidance for on-time on-budget delivery of projects with proven scalability to address projects of all sizes for all businesses.

Built into the framework are eight principles.

Focus on the business need, deliver on time, collaborate, never compromise quality, build incrementally from firm foundations, develop iteratively communicate continuously and clearly and demonstrate control.

As we’re focusing across the whole project, the initial kick-off will involve sitting down with the client understand the project objectives, and the high-level requirements expected of the expected to be completed within the timeframe.

This process might be completed as part of a workshop over one day or two days, in which we’ll get some high-level features, different screens that may be required.

Understanding the business constraints and the business processes that are currently in use, and how this solution may improve the business moving forward.

With this information, we can then go away and do a bit of a deep dive and further understand what’s required any risks, any complexity, anything we’ve missed during the initial kick-off.

From here, we can ask the questions to the client and resolve those issues.

And from here develop what we call a time box.

The initial time box can be described as how long do we think the entire project will take to deliver from when we kick off until when it’s in production ready for use.

The advantage of doing this is that we can get some initial feasibility as to whether the project can go ahead or not.

That might be based on the amount of time that the client expects the project to take, it might be the amount of budget that the client has put aside for the project.

And if all things go, well, then we can kick off into the next stage, which would be refining this initial time box.

As with all agile methodologies, one of the key focuses is on the iteration of phases throughout the life of the project.

And DSDM is no exception there.

Once we have a large time box for the entire project at a high level, we can then break that down into features that are of the highest importance and work our way down and build time boxes for each of those will then kick off development, and then testing and deployment.

So, we get a workable working product iteratively throughout the whole project.

It’s important to note that these time boxes are estimated on actual time and not story points as you might find in other agile methodologies.

And this is important for clients in particular who have come up with a set budget that they are willing to invest, and they need things done by a certain time, we can at least then answer the questions:

When is this going to be done by when?

Are there any risks and if there are risks?

What’s the overflow?

As we break each time box down into little mini-time boxes and start development on those features contained within we take the rule of thumb that 80% of the value of the solution can be delivered with 20% of the effort.

This is a pragmatic approach where everything doesn’t need to be perfect from the outset, but good enough that it fulfills the business needs and that they can move forward with the rest of the project and start getting value as early as possible.

This doesn’t mean that we ignore adding the polish the perfection of the gold plating to the application, it just means that we delay it until the application a workable state and delivers value to the business.

This means we don’t end up with a highly polished perfect one feature out of 10 that the business has in that timeframe.

Rather, we have 10 out of 10 features that they can use.

They’re not 100% polished, but we can go back and polish them afterwards.

Now how do we get to this stage within the process?

Breaking down a time box into a little bit more detail and describing the process and how we actually get to a deployable product or feature.

We will start by adding what we call cards to a Kanban board.

Now a Kanban board is a tool that we use to visually depict work at various stages of the process.

And a card is in effect a task that we’re going to complete in that process.

Different stages within that process might include requirements gathering, development testing, and ready for deployment.

All done.

Each card will have all the requirements documented within itself so that they can be referred to at any time.

They will also include any commentary questions, findings from experiments, or investigations contained with them.

So, you’ll see a full history of what’s happened with that task over the course of time.

It will also have the estimated time for completion, whether that’s one day five days one week, as collaboration is a big part of DSDM.

As the cards move through the Kanban board, the client or the stakeholder is encouraged to be highly engaged and participate with the prep within the progress of those cards.

So that might be there to answer questions and discuss the requirements.

Once the card reaches a certain level of completion to be involved with the testing, and even be involved with the creation of any documentation and how it relates to the business and any existing business processes.

Once this time box of work has been completed, then the process will restart.

A new mini-time box from the larger initial time box will be created.

New cards will be placed on the Kanban board and there’ll be moved across as they’re moving across.

The focus is always on those cards that are closest to completion to be worked on.

So that we’re not always starting on new work and not completing work but making sure that whatever work is started is actually completed and delivered.

How does this differ from something like Scrum.

Now, this might be a little bit contentious.

The development team won’t be looking at the project in its entirety from the outset.

But they will have multiple sprint planning sessions throughout the project.

Each sprint planning session will involve the entire team.

And they will go through different requirements features that need to be implemented and estimate and prioritize that work.

Without using any time measurements or metrics, they will use what we call story points to estimate the tasks.

And these stories point typically correlate to the amount of effort required to complete that task.

You can use different methods of assigning story points, or they could be a Fibonacci sequence, they could be a doubling of numbers, it’s up to you as long as each value is relative to the previous and next value.

So, if you had a task that was estimated to be worth five story points, and another was worth 10 story points, then you would expect the second one worth 10 to be double the amount of effort of the first.

Now, this shouldn’t carry us on to time, because a five-story point if it could take three hours to implement or it could take six hours to implement.

It’s the important part is it’s related to effort.

You then work out how much storage how many story points can be completed within a sprint, sprint could be a two-week block, or it could be a three-week block.

And the number of story points that you can play is your velocity.

Using that velocity, you can then look back and say well, of those 20 story points that we create.

Completed the next Sprint will aim to allocate 20 story points worth of work in the next sprint.

Now the argument can be said that story points do in fact have a relation to time the fact that we have 20 story points within two weeks of completion says that 220 story points equals two weeks of time.

And that could be theoretically used as an estimate.

So why do we use story points?

It’s so that different developers have varying degrees of skill and ability to type code quickly can have an equal level of involvement in the estimation process.

So, across the board, all developers may say that this piece of work is twice as required twice as much effort as the other piece of work.

But whether that equates to 10 hours or 20 hours is irrelevant.

The difficulty though moving forward is if all the developers within the team change, then the historical velocity based on all the previous Sprint’s is a little bit out of whack and can’t always be used to correctly gauge what future estimates will be.

The other difficulties you will find the clients or the stakeholders, because they have a business to run, they have a limited budget, they will still come back and say, When is this task expected to be finished?

How long will it take?

How much will it cost?

It’s a little bit difficult to say.

It’s going to be completed with 50% effort of the sprint.

It’s not really something that’s tangible.

And when there’s deadlines within a business, they need to know where their money is being spent, and when are they going to get the product they’ve purchased.

There’s also the issue with billing.

A lot of our clients will be expecting a fixed price upfront cost for the project.

And this is understandable imagine trying to build a house.

And the builder says, we don’t know how much it will cost.

We’ll work through all your requirements and what you’d like to include within the build.

And when we’re finished, we’ll give you a final bill, or we’ll charge you on a monthly month, month-to-month basis.

Until it’s finished, there’s no way to budget there’s no way to understand what the expected costs will be.

You don’t know if the builder is purposefully delaying the project at the expense of you and having to pay more for the build.

So that’s where the upfront fixed costs are quite desirable for the customer.

You may have noticed that the actual entire development team is involved in the sprint planning typically in a scrum project.

This again is an added cost to the client, where you have may have five or six developers all using their time at once to estimate and plan for one particular task that all may not be involved with.

This is in direct contrast to how DSDM would work in that the developers individually can have the authority to estimate a particular task, as well as work on it.

They also have the authority to make decisions on behalf of the team in the best interest of the project and the client to expedite the development and ultimately decrease the costs of development.

With all of this in mind, we can take away that the DSDM methodology can deliver the right solution at the right time, and ultimately at the right cost.

This can all be achieved when all the stakeholders including the developers and the clients understand and bind to the business vision objectives.

They’re empowered to make decisions within their own area of expertise.

They collaborate to deliver a fit-for-purpose business solution and collaborate to deliver to agreed timescales in accordance with business priorities.

They accept the changes inevitable as the understanding of the solution grows over time.

And that a level of common sense and pragmatism is adhered to throughout the project by all those involved.

The team here at Qubisoft are following DSDM and if this is something that sounds attractive to you.

MORE FROM QUBISOFT

Process + Plan = Perfection

Start Reducing Your Operational Costs Today

Make an Enquiry

The Custom Business Software Show – Episode 2: Why “DSDM” Is Ideal For Custom Software Development For Businesses