BDUF or LDUF? Which one does your shop advocate and why? [closed]

Question

Our shop is undergoing some changes in different areas when it comes to how we carry out our development projects. Originally, being a large organization, we've traditionally followed an only slightly modified waterfall model (not my choice!!!). Essentially spending time first on requirements, then lots on design, then lots on coding, then showing things to the customer. Can't start the next phase until you complete the first!

Guess what? That hasn't exactly panned out the best over the years! I'm trying to get everyone on board and move to a model more centric on agile methodology and rapid prototyping. I know for a fact that it will work far better than current practices .

At any rate, when doing design, what are some of your processes around it? More specifically, how do you know when you've done enough, what processes do you follow?

Answer 1

"At any rate, when doing design, what are some of your processes around it? More specifically, how do you know when you've done enough, what processes do you follow?"

Actually, it starts before design.

Start with the inception of the project. You have two ways to define scope. All or Just Enough.

• All is handy because it sets a broad, distant, probably unreachable goal. But, it also sets out a cost and schedule that's vast, huge and has a lot of zeros in the price.

• Just Enough is uncomfortable because it looks like you've put the target laser dot on a single micro-problem and you'll never build something scalable, comprehensive and blah blah blah. Just Enough has the advantage of setting and achievable goal followed by a trail of potential future goals that will likely come into play.

Advice: The Scope should be the smallest thing you can do and solve someone's problem. This is followed by future goals that come into play, later.

When you gather requirements, you have two approaches: All and Just Enough.

• All is handy because it allows you to cover your @$$ and start endless arguments over what and what's not required.

• Just Enough is scary because you gather detailed requirements for the first goal only, and set the other requirements aside for later consideration. Some people feel that every little brain fart is "required". Other people are more enlightened and realize that there's a MoSCoW spectrum (Must, Should, Could, Won't).

Advice: Aggressively and constantly prioritize all requirements. Work with everyone involved to realize that "later" doesn't mean "never". Create a formal backlog, and prioritize it constantly. Meet with the users as often as they have a question, comment or brain fart and let the adjust the priorities. They love that stuff.

And it allows you to plan the high priority items. You can then draw some "done" lines through the backlog showing how much will be done by a given date and how much will be done for a given amount of money.

When you get to design, you can look at the future requirements for possible future growth directions. But you don't have to overdesign everything to meet all of the things called "requirements" (many of which aren't even required.)

By the time you get to design, the Agility of the project will already be in force.

Answer 2

Question: When have you done enough design?

For my process the answer to that is: When there is enough information to confidently hand off the implementation of the simplest thing that could possibly work to another developer.

This covers two major parts:

• The simplest thing that could possibly work: This is a solution to the customer's problem that has withstood some close scrutiny by the domain expert, technical consultants, project manager, product manager and very importantly, the customer. This need not take long - spending a few hours on this is usually enough.
• Enough information to hand off development. This should be the case even if you will do the implementation yourself. Basically there should be just enough documentation that someone who is not familiar with the specific feature (but familiar with the overall goals of the application) has good coverage of what needs to be done for this feature.

In my experience the saying "build one to throw away, you will anyway" usually goes. Your first implementation will usually uncover some misunderstandings between you and the customer, or between other members of the implementation process. You can't avoid this, and that's why you try to make the time-to-first-implementation short.
Once you get the first version out of the way you'll find communication becomes easier because everyone's understanding of the requirements and the process is a lot clearer.

You may even find that right after this first prototype you can do a longer design phase because you have a much better idea of what and how.