Hello Modern Analysts,
By now you ave all heard of Agile software development. you are probably ware that there are several frameworks and processes that fall within the umbrella of Agile, and some of them are quite distinct from one another.
One of the common themes in agile software discussions is the idea of emergent design and emerging requirements.
The simple idea is this: You can't know everything up front. Also, things change and so in a 24 month or even 6 month project business needs have shofted since the beginning of the project. Development teams should accomodate this. And lastly (this is the theme of the question) planned design usually does no better than unplanned design.
I need to qualify this - I am excluding super large, national, cross organisational or international projects from this discussion. Those babies are way complex and need a whole new set of rules beyond what agile can provide.
Now - back to the question;
Have you got an opinion on the premise that emergent design works as well as planned design? Have you got a story about emergening design/requirements working or failing?
Please share.
Hi Craig,
I have an opinion but you probably know it by now! One thing I do like is that "Emergent design" does sound better than "make it up as we go along"!
I have loads of stories about projects failing to do analysis failing - but you are talking about design so I guess they don't count ?
Guy
I am interested in the point at which the requirements failed. At the system specification level or at the business knowing what they wanted level?
My hunch is the latter. Or if not, then the project team not bothering to find ot the business context and goals.
Craig,
It is unlikely that the business know what they want: our primary job as BAs is to use analysis to get them to analyse what they want, then challenge, then refine, then come to a better (true?) understanding of what they want BEFORE we go to design - as this saves so much time and cost (see Chaos report et al).
Failure to do this results in the question of what they really want just being shoved down the SDLC which means far more rework as what they really want emerges and so in response we have Agile...
What I mean here is - Are the business requirements & project scope/goals okay, aligned to strategy, sensible, practical etc?
Or is the system spec too complicated and too full of constraints? Is the systejm specifiaction disassociated from the business objectives?
At which of these two scenarios are we most likely to find critical requirement failure?
brought to you by enabling practitioners & organizations to achieve their goals using: