How facilitate workshops to make Business Analysts and IT Architects build a Data Model

1. Methodology
REX Return on Experience: Sprint 0
Sprint 0:
• it is always difficult to launch a big project.
• the temptation is strong for IT architects to modelize everything even if it is not required at the beginning
• Even if they need quite quickly a rough and global view of the scope to anticipate the big targets of the projects
Sprint 0
2 Business Analyst with 3 IT architects have to build the
Data Model
First meetings:
• Lots of discussion but almost no outcome
• frustration from both parts even among the IT architects
How we helped them run efficient workshops
and draft the first versions of the Data Model in a few weeks
Key Points: the sprint 0 in Scrum is quite difficult to manage. Most of the literature talks more about the framework once the machine is
launched. But Sprint 0 is key has it has to setup the key elements of the Team, the Agile iteration and the Code factory so that the
project can ramp up efficiently. Database Data Model is one of those key elements of the architecture to define.

2. Methodology
Tips for an efficient workshop: let run the first meetings, observe and make a small retrospective
People progress faster when they fail first. So, as a facilitator:
• Let the first meetings run without your intervention and just observe
• If you point out problems, propose to the group to do a small retrospective
• The main goal of this retrospective will be to define team rules if they don’t exist
Key points: Sprint 0 is also particular period where the Team (if it is not yet a Team) will go through the different phases of a team
building: Storming, Norming, Performing. Those moments are really important and as a facilitator your goal is accompany the group to
go through those steps quite quickly. If they remain too long within the Storming one, they re will always be conflicts within the group.
Before
• Several 2-3h meetings
• Lots of discussion but almost no outcome
• Frustration leading to irritation from both parts even among the IT architects
Retrospective outputs
• Plus:
• BA & IT architects really wanted to work together
• They had the functional and IT architect experts in the same room
• Delta:
• Workshops were not prepared in advance leading to confusion
• No leader during the workshop leading to disorganised discussions
• Everyone frustrated about the lack of outcome and leadership
• Everyone tired to spend 2 to 3 hours in inefficient meetings
After
• a 1h workshop every 2 days to let people work on the questions pointed out during the previous workshop
• 1 leader accountable of
• the preparation: scope & agenda definition based on the Story Map built with the key Users and Sponsors, all data
required is always visible in the room
• the run: maintain parking and keep people focused
• the conclusion: action plan, 5mn of retrospective to improve the next workshop
• 1 BA accountable to write down in session the use cases catalogue used during the workshop
• 1 IT architect accountable to update the data model in session

3. Methodology
Tips for an efficient workshop: display, write and design all you talk about to ensure a common understanding
First, we start with simple rules regarding an efficient meeting
• Meeting efficiency = Team Rules
• Efficient meeting = “Work + Shop”
• efficient meeting = meeting prepared before the workshop
Key points: display, visualize, write so that everyone can see. Especially when the functional domain is complex. Check with
attendees they feel to progress workshop after workshop

4. Methodology
How do you build & test your Data model? All the knowledge comes from your Use Case catalogue
If you observe the meeting, 80% of the time, people are talking about Use Cases. Normal, all the knowledge comes from Use Cases, so:
• Someone has to write down all the use cases that are in the scope IN (you can also write down the OUT to prevent future digression)
• From the use case catalogue (you can also call User Story), IT architects will retrieve Entities and relation between those Entities
• Instantiate the entity with object to test the modelization is really working and covering also specific case (if in the scope)
Key points: for a large scope, build iteratively your Data Model i.e. define & follow your scope In/Out and increment your scope
workshop by workshop. At that stage, forget the formal Specification document as actually it is your Use case catalogue. Start with
nominal case (standard) and complete with specific case (exception).

5. Methodology
How do you build & test your organization model? With your User Case catalogue
From your Data model & sequence diagram deduce
• For each role, what it can do & what it cannot do
• A RA(CI) or read/wright matrix
Key points: “As a [role], I Can do [action] so that [goal]”. Funny no, to see how the User Story template is well done to retrieve
those organization model information … thanks Scrum guys!

6. Methodology
How do your build & test your entity life cycle? With your Use Case catalogue
From your entity life cycle, deduce:
• The list of status
• The action/event to pass from one status to another one

7. Methodology
Work Breakdown Structure (WBS) evolves with the team maturity on the subject
Work Breakdown is not a goal but a mean: so don’t spend to much discussion on it
Key points: there is not just One good WBS. They are several good and several bad. Your goal is to avoid the bad ones. So
once again, don’t spend too much time on discussion if it is not relevant.