We found Event Storming to be the best tool to ask the right Why and to spot the right problem, hence - for the business to enable to understand it itself.
Talk about our concept around Alberto Brandolini Event Storming. We use Event Storming as a technique for a year and after a number of unsuccessful and successful sessions we wanted to share our experience - but also a new concept, around how it can glue together the whole business operations. From different roles in IT - Product Managers, Product Owners, UX and UI designers, Testers, Architects, Software Developers, Dev Ops and System Administrations to a tool that can reshape the business. Event Storming's outcome can be a base to build metrics, alerts, reactive policies, Business Intelligence platforms and more. It can enable a shift towards a data-driven organisation. In one sentence - it can enable Continuous Business Improvement.
Talk given with Mariusz Gil during the SegFault conference in Lodz, Poland.
41. DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
DOMAIN EVENT
X REQUESTS PER HOUR
X REQUESTS PER HOUR
X REQUESTS PER SECONDS
X REQUESTS PER DAY
Architects
All starts with a Dream - it can be investor’s, CEO’s, team’s, client’s or anybody else. Some day somebody wakes up having this great idea on his mind. The only thing is to find the team to make it happen.
So he does. He finds a great team with a great Architect. They plan. They come up with a perfect design for the project founder’s idea. This time they will show the world. Ideas greenfield.
Architect with the team shows the design to the client. Client gives her feedback, but the team is so proud of what they build.
And so they build it, continue their struggle in making the impossible happen. They sweat to deliver it. Often, somewhere else in the office management is having their 7th hour of their Strategic Idea Realisation Critical Meeting. They ensure smooth delivery of the idea to the Customer.
And so Architects unhappily make Changes to their Perfect Plan. It was great once, but they know - they need to struggle to deliver. Sometimes the team does not understand why Customer want to destroy such a beautiful Perfect Project.
But they work on it. Sometimes against the time or the technology that does not work as expected. Changes, why did client make them? The execution would be more perfect without them.
Dzięki zrozumieniu Big Picture możemy wychwycić wiele niuansów tworzonego rozwiązania, opisać je i być na nie przygotowanym.
Jak często management pokazuje / chwali się technikami stosowanymi w procesach?