SlideShare a Scribd company logo

Rex Sprint 0 - how build the data model with 2 BA and 3 IT architects

•
•
J
Jean-François Nguyen

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

Related slideshows

Introduction to scrum
Introduction to scrumIntroduction to scrum
Introduction to scrum
 
Agile Methodology Assessment
Agile Methodology AssessmentAgile Methodology Assessment
Agile Methodology Assessment
 
Agile Project Management: What is It and How It Works
Agile Project Management: What is It and How It Works Agile Project Management: What is It and How It Works
Agile Project Management: What is It and How It Works
 
1 of 7
Download to read offline
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.
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
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
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).
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!
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
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.

More Related Content

Rex Sprint 0 - how build the data model with 2 BA and 3 IT architects

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