EventStorming: Continuous discovery beyond software modelling • Hacker News Board

Re: EventStorming: Continuous discovery beyond software modelling

#11

Post by dragonwriter » Mon, Nov 26, 2018, 5:52 PM UTC

wpietri wrote: post #6

the_duke wrote: post #2

> EventStorming ... is ... a flexible workshop format for collaborative exploration of complex business domains. EventStorming is a technique that uses visualisation to minimises assumptions by engaging in deliberate, collaborative learning between different disciplines. EventStorming helps to solve complex business problems in the most effective way beyond silos or specialised boundaries. So, deciphering this Buzzwo…

I know you're being sarcastic, and I agree that marketingspeak is, as always, annoying. But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months. That's when they use them at all; most places just make shit up, write it into the software, and then experience a lot of pain when it is slowly discovered that the model expressed in the code does…

> Traditional processes for understanding the domain also tend to focus on nouns.

The most traditional requirements development and system analysis process I can think of, structured analysis (as developed by Ed Yourdon at others and first popularized in, IIRC, the 1970s), focuses on modelling a planned response system in terms of the events it needs to respond to and what it needs to do in response, and decomposing it into subsystems modelled the same way.

Using shared visual models is a common technique when applying Structured Analysis, too.

Re: EventStorming: Continuous discovery beyond software modelling

#12

Post by wpietri » Mon, Nov 26, 2018, 6:39 PM UTC

dragonwriter wrote: post #11

wpietri wrote: post #6

Earlier quoted context omitted.

I know you're being sarcastic, and I agree that marketingspeak is, as always, annoying. But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months. That's when they use them at all; most places just make shit up, write it into the software, and then experience a lot of pain when it is slowly discovered that the model expressed in the code does…

> Traditional processes for understanding the domain also tend to focus on nouns. The most traditional requirements development and system analysis process I can think of, structured analysis (as developed by Ed Yourdon at others and first popularized in, IIRC, the 1970s), focuses on modelling a planned response system in terms of the events it needs to respond to and what it needs to do in response, and decomposing…

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.

Re: EventStorming: Continuous discovery beyond software modelling

#13

Post by dragonwriter » Mon, Nov 26, 2018, 7:55 PM UTC

wpietri wrote: post #12

dragonwriter wrote: post #11

Earlier quoted context omitted.

> Traditional processes for understanding the domain also tend to focus on nouns. The most traditional requirements development and system analysis process I can think of, structured analysis (as developed by Ed Yourdon at others and first popularized in, IIRC, the 1970s), focuses on modelling a planned response system in terms of the events it needs to respond to and what it needs to do in response, and decomposing…

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 fi…

> 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.

[0] http://zimmer.csufresno.edu/~sasanr/Teaching-Material/SAD/JE...

Re: EventStorming: Continuous discovery beyond software modelling

#14

Post by dvlsg » Mon, Nov 26, 2018, 9:06 PM UTC

mrdoops wrote: post #7

kornakiewicz wrote: post #5

I recommend this book n which this method is described and explained. Also F#. https://pragprog.com/book/swdddf/domain-modeling-made-functi...

I'm especially fond of his description of boundaries and the trade-offs of different kinds of contracts between bounded contexts. There's also a lot of good insight into how we abuse the database and couple ourselves to it for the convenience of CRUD. Really feel like I should've picked up this book months ago.

It's always refreshing to see a writer that's honest about trade-offs, instead of spouting their preferred method as the one-true-way which will solve all your problems.

Re: EventStorming: Continuous discovery beyond software modelling

#15

Post by wpietri » Mon, Nov 26, 2018, 9:38 PM UTC

dragonwriter wrote: post #13

wpietri wrote: post #12

Earlier quoted context omitted.

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 fi…

> 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, tho…

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.

Re: EventStorming: Continuous discovery beyond software modelling

#16

Post by dragonwriter » Mon, Nov 26, 2018, 10:48 PM UTC

wpietri wrote: post #15

dragonwriter wrote: post #13

Earlier quoted context omitted.

> 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, tho…

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 progra…

> Is there some specific part of that 600-page book would I find illuminating?

The part most directly relevant to the point at which I raised it is Sec. 5.5, beginning on p. 91.

Re: EventStorming: Continuous discovery beyond software modelling

#17

Post by baasie » Tue, Nov 27, 2018, 7:57 AM UTC

jakubp wrote: post #9

wpietri wrote: post #6

Earlier quoted context omitted.

I know you're being sarcastic, and I agree that marketingspeak is, as always, annoying. But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months. That's when they use them at all; most places just make shit up, write it into the software, and then experience a lot of pain when it is slowly discovered that the model expressed in the code does…

Oh boy... "But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months." You must be aware that there is a large group of people who have largely solved the problem of learning about a domain when client is in the room. It includes Business Analysts, System Analysts, some portion of people who call themselves Solution Architects, some portion o…

I do agree with you, there is already a group of people that solved that problem, and eventstorming is nothing totally new. (nothing ever is tbh, all renditions of other tools). Looking at the history, it comes from Domain-driven design where we try (quoting Mathias) to put lot of emphasis on shared models between business, devs, testers, documentation writers, UX.

The problem I mostly see is that each of this body of knowledge has their modelling tool, one where you need to have some form of workshop or certification (UML, Archimate, BPM etc etc..). What EventStorming tries to do is minimise these handover from proxy domain expert to avoid cognitive bias made from telephone games. So it tries in a simple and quick way to share knowledge in a multidisciplinary group and create a shared mental model, and do this continuous. It tries to show ambiguity in the language (something DDD looks for to create bounded contexts).

About the facilitation, you are totally right. A good facilitator is what makes or breaks it. Besides EventStorming is not a silver bullet, it has its flaws and its blind spots. So then you need your facilitator to grab out their toolbox and see how to battle this

Re: EventStorming: Continuous discovery beyond software modelling

#18

Post by wpietri » Tue, Nov 27, 2018, 3:21 PM UTC

dragonwriter wrote: post #16

wpietri wrote: post #15

Earlier quoted context omitted.

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 progra…

> Is there some specific part of that 600-page book would I find illuminating? The part most directly relevant to the point at which I raised it is Sec. 5.5, beginning on p. 91.

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.

Re: EventStorming: Continuous discovery beyond software modelling

#19

Post by jakubp » Tue, Nov 27, 2018, 6:46 PM UTC

baasie wrote: post #17

jakubp wrote: post #9

Earlier quoted context omitted.

Oh boy... "But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months." You must be aware that there is a large group of people who have largely solved the problem of learning about a domain when client is in the room. It includes Business Analysts, System Analysts, some portion of people who call themselves Solution Architects, some portion o…

I do agree with you, there is already a group of people that solved that problem, and eventstorming is nothing totally new. (nothing ever is tbh, all renditions of other tools). Looking at the history, it comes from Domain-driven design where we try (quoting Mathias) to put lot of emphasis on shared models between business, devs, testers, documentation writers, UX. The problem I mostly see is that each of this body o…

Interesting point about trying to minimize the proxy expert game. I myself don't have full clarity on which level of proxy is OK. Should it be a dedicated person (typically an analyst)? Should it be the team? Part of the team? Someone mixing roles e.g. dev who talks to the client(s), or PM who also manages the backlog, etc.

There are many tradeoffs to consider here. If technical team has to talk to clients, well, we will lose some clients, period. Many types of clients and many types of engagements (for a software house) are simply unavailable, because we will lose out in competition with companies who will be given very good support by great client-facing specialists who will woo them, and actually give high quality consulting and value on the early stage of the project.

However, if we put those good business guys in front of the team (or as part of it), they start to lead the process, and our less developers who are usually much less ready to talk to clients etc. and have tech-related biases, suddently lose the best chance to learn. Because when someone takes away the difficult part of managing the client and trying to figure out what they need, you stop thinking about it on your own and you don't develop those mental models as fast (if at all).

There is maybe a middle ground where there's a mix of comms coming from technical and non-technical folks, who knows. In my experience this typically morphs into either model though.