Development Experience(s)

Just like software projects benefit from first creating a walking skeleton  of its solution, we get a similar benefit from the risk assessment example in the previous article : If stakeholders cannot verbally agree on responsibility boundaries and terms, we cannot possibly produce a maintainable software solution to support the business. We need to find Software-to-Business Alignment . The hard part of software architecture lies where the boundaries intersect. What's inside of each boundary is, generally and relatively, easy. A  Walking Skeleton  is a tiny implementation of the system that performs a small end-to-end function. -  http://alistair.cockburn.us/Walking+skeleton As an example of an identified conflict (i.e. two bounded contexts) in our exercise was the fact that parts of the business process saw the individuals that visited the event as Attendees whereas parts of the process identified them as Customers . A Customer should probably have some billing informatio

What follows, is some reflection after the first exercise (which you can read about here ). Your big enemy is time. Domain Experts are a busy sort, so try to make the workshop as engaging as possible. Postpone any boring bits and don't focus on completing tasks. It's the facilitator's duty to mark hot spots to park any heated discussions and thereby avoiding the participants not participating in the discussion of getting bored. "Postpone ordering events into exact chronological order", Alberto said cheekily - "the developers will do this for you automatically, for free!". Invite the most important people you can, given your goal, and then spread the knowledge from the event storming throughout the organization. This will, in turn, spark interest for any upcoming discussions which might have a larger hit rate, even if the first meeting had a low turnout. Do remember, Alberto instructed us, that the stickies on the wall are not engaging for a third-p

Event Storming is something that needs to be experienced. That said, I'll do my very best to describe my experiences in words, hopefully illustrating its benefit when working in situations that reminds of Business Process Modelling  or requirements/business analysis. Last week, I had the pleasure of joining a one day Event Storming Workshop with the ES father Alberto Brandolini as he was visiting Stockholm. Alberto described ES as a "brain dump" of his - something he had formulated over the years and originally intended as an introduction to Domain Driven Design, but then took a life of its own. In this particular workshop, the average attendee had little to no experience with Event Storming, other than hearing about it from other conference speakers or seeing its name in a flyby tweet. Brandolini started us off by placing us in front of a huge whiteboard (about three average whiteboards in length), making an abundance of marker pens and sticky notes available,