Reply to: Out Of The Mouths Of Clients

[DimPrawn]

I created FUDGE and FUMBLE - and have used both to great success throughout my career

I like a good FUMBLE, but not so keen on ending up in the FUDGE.

HTH BIDI

[NotAllThere]

I tend to use MIUAIGA*. Most people do, in the final analysis.




* Make It Up As I Go Along

[mudskipper]

I created FUDGE and FUMBLE - and have used both to great success throughout my career

[malvolio]

Many years ago I created ECNIRP, essentially Prince in Reverse (or Prince as it is usually done, to be more accurate), where you start with Execution and proceed through the various steps back to Planning. Never really caught on at the time, but real life has clearly caught up...

Anyway Agile is brilliant at what it does - then again, so is Prince and its brethren - but it has to sit inside a waterfall plan, else how do you know when you've arrived? They are not opposing methodologies, they are complementary.

HTH. BIDI...

[SpontaneousOrder]

'Agile' is about fostering agility. It says nothing about what you should and should not do - only that particular project types (most) may benefit from agility over up-front central planning, and suggests what priorities may or may not, in an entirely context-dependent fashion, promote or undermine that agility.

That's all.

Now, *if* you think that not designing everything up front is a good idea because the market is dynamic and you don't know for sure the full design will still be relevant in a year's time, then perhaps you don't want to design everything up front. Perhaps you *do* want to design the core of your solution to ensure that it's pluggable, flexible, scalable, etc? In preparation for the unknown.

*If* you're testing the market by putting out a product and seeing the response, then perhaps you don't want to design it all up front, and perhaps you want to be able to change direction very quickly as you;re expecting to have to change tack a few times before you hit the sweet spot.


The realty is that a huge number of projects fail (officially or implicitly) for those reasons, and 'agile' is a recognition that some of the thing we often do are digging us into a hole that is impossible to climb out of, should we be unfortunate enough to fall in. Worse than that, sometime we should expect to fall into that hole once or twice.

Saying 'agile' doesn't work is like saying flip-flops are unsuitable footware.

[suityou01]

Don't fall into the monochromatic SDLC=Good;Everything else=Evil way of thinking.

eg:

Not all projects are the same, so treat them differently

Save your breath, most on here can't spell SDLC.

[Cirrus]

Being even older,

No way

[Cirrus]

Don't fall into the monochromatic SDLC=Good;Everything else=Evil way of thinking.

eg:

Not all projects are the same, so treat them differently

[suityou01]

Technical design was the original post, or lack of. Fads do come and go but Agile seems here to stay.

Like it or loathe it, any successful project needs :

A definition of "done".
A way of validating this definition.
A way of proving what was delivered is "done".

Agile really only covers part of this process.

[DimPrawn]

Being smarter, I've seen these fads come and go, given different names for the same bollocks, I've learnt to jump on every bandwagon, and it's paid off very nicely

FTFY

[NigelJK]

I built RAD systems for eg BP and Shell. There was never any 'design'. If you'd asked me about such a thing then, we'd have had to go down the pub to mull over the consequences of such a new and fangled concept.

Well you were doing it wrong then. We still had Functional Specifications and RAD part was for the 'Development'. In essence we built 'prototypes' which we walked through with the end users (basically the screen equivalent of wireframes). These were then meant to be used to build the 'real thing'. Usually they were 'fleshed out' to become the 'real thing'.

[Troll]

Being even older, I've seen these fads come and go, given different names for the same bollocks, I've learnt to ignore them all and it doesn't seem to have hurt

+1

[Bee]

How do you know how us "lads" or "lasses" are, errrrrrr, you don't

Which is fine until you realise you have nothing signed off, just a bunch of "walking requirements", who change their minds all the time and put the delivery at risk.

Sorry, I prefer things being signed off and delivering to specification and guess what? It works

Can became complicated with all the documents sign off, I can imagine without them.

[MrMarkyMark]

Being older than you lads

The Business told you what they wanted to achieve and you built them a system.

When I go out shopping on a Saturday I don't have a plan. Or a design document.

You young people are so bureaucratic I just can't get over it.

How do you know how us "lads" or "lasses" are, errrrrrr, you don't

Which is fine until you realise you have nothing signed off, just a bunch of "walking requirements", who change their minds all the time and put the delivery at risk.

Sorry, I prefer things being signed off and delivering to specification and guess what? It works

[Bee]

Talking to one of the third party suppliers, trying to get a grasp of the documentation etc for the client (kinda knew the answer as I had been brought in to try and reign in some of the processes), asked about what happens if an error is found and a new version of code is created?

Word or word answer is:



I am not a BA or a Dev, but can anyone please tell me how is this even possible?!

I have gone back and asked how do they know what to build, but I am scared of the answer to be fair!

This is a project without a plan, in addition, they didn't answer your question.
If the code is wrong certainly they will blame the developer…or you.

After the requirements approval, the design documents should to be ready for review and approval before the development. This will prevent problems while coding and save time.

Good luck