Good point. Perhaps instead of "traditional" I should have used a different word. Here I'm referring not to documented formal processes (which I almost never see used in the wild) but to what I have seen, which mainly seem to be folk wisdom. So tradition in that sense.
As I said, I think a lot of this folk tradition arises out of the practical needs of developers. They are asked to build a hazy thing; in trying to figure out what that thing is it's easy to reach for concrete representations, like business forms and database tables. And of the class structure in object-oriented languages, which is obviously noun-focused.
I suspect another source of difference between what I see used and most formal processes is that the most formal processes tend to come out of a waterfall tradition. There's a stop-the-world-for-months aspect to them that I think is incompatible with a lot of what people do today. Certainly with the dynamic world of startups, but also with the short-cycle processes that modern tools enable for everybody.
I could totally see using Event Storming and Story Mapping as two one-day activities as part of a kickoff week for a new project. Structured analysis, not so much.
> I suspect another source of difference between what I see used and most formal processes is that the most formal processes tend to come out of a waterfall tradition. There's a stop-the-world-for-months aspect to them that I think is incompatible with a lot of what people do today.
It's true that a lot of formal methods were first defined then. Those that weren't abandoned entirely were refined beyond that time, though; you might find Yourdon’s last (before throwing it to a Wiki which was somewhat unsuccessful and vandalized) documentation of the Structured Analysis method, his freely-available PDF Just Enough Structured Analysis from 2006, illuminating. [0] There's no stop the world aspect (except in one of the two polar extremes of approaches to application, both of which are described as impractical for real projects.)
> I could totally see using Event Storming and Story Mapping as two one-day activities as part of a kickoff week for a new project. Structured analysis, not so much.
It's true that Structure Analysis is a full-lifecycle activity, not a kickoff event; OTOH, there are certainly parts that map out the problem space that work as kick off events.
Is there some specific part of that 600-page book would I find illuminating? From the intro, this is clearly a phasist approach, so essentially waterfall. E.g.:
"Regardless of its name, it becomes the input to the person (or people) who are responsible for actually building
the system — that is, designing the overall architecture of computer hardware and software and ultimately writing and testing the computer programs. This leads us to Part IV: life after systems analysis. We will explore the transition from systems analysis to systems design and briefly discuss the final details of programming and testing."
I'm sure there are people out there whose domains are stable enough that they can work like that. But fewer and fewer. And I suspect even the ones who can would be better working in a much more iterative, exploratory way.
I see what you're saying, although I'm not sure it's really moving in a direction I'd call agile. He clearly paints the fully "radical" end as unthinkable lunacy, when it's entirely doable in practice. And looking at figure 5.4, it's very much a document-oriented process. When compared with a modern, short-cycle Agile approach (continuous delivery, unit-of-work size in the 1-3 day range) all of the documentation he describes ends up being pure waste.
This part strikes me as especially absurd:
"How does a project manager decide whether to adopt a radical or conservative approach? Basically, there is no right answer; the decision is usually based on the following factors:
* How fickle is the user?
* What pressure is the project team under to produce immediate, tangible results?
* What pressure is the project manager under to produce an accurate schedule, budget, and estimate of people and other resources?
* What are the dangers of making a major technical blunder?"
The contempt for users wrapped up in "fickle" is ridiculous, and ditto making business needs about "pressure". Most importantly, he hasn't even begun to recognize that a shorter cycle yields significant business benefits, even though that was being written about at least a half-dozen years before this book.
So I read this more as typical waterfall thinking with some concessions to practical reality (which is how waterfall has always been done) than anything relating to a modern approach. He doesn't say, "You must stop the world for 100% of your project!" But the fastest he's willing to describe is, "Stop the world for 50% of your project!" The notion that you could stop the world for 1% or less of your project (which is what happens with weekly cycles for a project of 2 years or more) is to him beyond ultra-radical. (Let alone a good kanban approach, where the cycle time drops into the hours-to-days range.) When instead I'd submit it's in reality the most conservative approach, in that it minimizes all sorts of risks.
As I said, I think a lot of this folk tradition arises out of the practical needs of developers. They are asked to build a hazy thing; in trying to figure out what that thing is it's easy to reach for concrete representations, like business forms and database tables. And of the class structure in object-oriented languages, which is obviously noun-focused.
I suspect another source of difference between what I see used and most formal processes is that the most formal processes tend to come out of a waterfall tradition. There's a stop-the-world-for-months aspect to them that I think is incompatible with a lot of what people do today. Certainly with the dynamic world of startups, but also with the short-cycle processes that modern tools enable for everybody.
I could totally see using Event Storming and Story Mapping as two one-day activities as part of a kickoff week for a new project. Structured analysis, not so much.