Learning Launch 

 Challenge 

 Being part of an IT&S business process design team a user interface tool to place orders from   customers to request services needed to be replaced as the existing tool reached the end of live   service and was not compatible with the cloud which is the strategic direction of the company for   customer applications . In the past , the company used for projects the classic waterfall concept   ( select / design / build / deploy / support ) . As this was a time critical project and the results should be   achieved faster and more cost efficient , the agile approach was selected . To overcome the   knowledge gap of how to apply agile working in projects , an external consultant was hired to lead the   scrum sessions . The IT&S team was a diverse team where development activities have been   performed offshore . As product owner for the new user interface tool the business key stakeholder   was nominated . 

 Selection 

 In a first step the business requirements for the new user interface tool have been gathered and   confirmed by the business key stakeholders . The technique of learning launch was applied , prototype   the solution for the user interface solution based on understanding of the requirements in a very   short timeframe to show the product owner the developed product . The prototype included daily   scrum meetings between the design team and development team via conference calls including the   product owner to share the proposed design & design options for knowledge transfer , issues &   defects in the build phase of the prototype solution etc . 

 Application 

 One of the first steps was to evaluate design options based on the agreed business requirements .   An integrated activity between the design team and technical build team is required to exchange   functional process design and technical feasibility documented in a power point presentation . The   outcome of the agreed product needs to include the deliverables for the different sprints as part of   the agile approach . 

 The prototype process has been started to apply the basic / core design ( minimal viable product )   agreed in agile sprint 1 into a technical solution provided by the offshore team after explanation of the   key desired functionality ( i.e. log on to a customer hub , request a service based on a catalogue ,   workflow functionality to agree on the contract incl price for the service and confirmation ) . To follow   the agile approach , no detailed documentation of the functional specification has been provided , only   the key elements on a high level documented and communicated to the technical team . As a   documentation tool visio process flows and where applicable narratives have been provided and   communicated in a Q&A session via conference calls to the offshore team . To save time and money   the technical team was not requested to provide a technical specification . The show and tell   approach was used supported by a demo of the first draft of the technical solution which was   validated by the product owner who provided feedback on expectations and usability . Questions to   the product owner have been raised to evaluate if the solution meets the needs , it improves the   process and would improve customer experience & satisfaction . After feedback which functionality   are good vs not sufficient a review process has started to discuss required changes and   enhancements taken into consideration feasibility in terms of time and costs . Iterative review   sessions have been conducted to analyse progress and issues and improve the user interface tool 

 step by step . Part of the technical build had to be trashed as it was not compatible with the required   fixes and enhancements . 

 Once the product is agreed and signed - off by the product owner in a final show and tell session , the   functional design and technical build has to be documented and stored in a central space for audit   purposes . 

 In the next sprint the user interface tool should be enhanced to cater for budget and reporting   capability . The same iterative approach as in sprint 1 applies which requires a final review and sign - off   from the product owner . 

 Insight & Approach 

 What I have learnt from prototyping a product based on an agile approach is that the product   specification requires a detailed description of the expected outcome clearly communicated to the   offshore team to avoid too many failures of the draft solution and iterations . In addition I feel that it is   important to think ahead of the additional requirements and add - ons to the product in the next sprint .   If the additional requirements ( i.e. budgeting and reporting functionality ) are not considered and   addresses , the issue arises that the signed - off product in sprint 1 requires major modifications which   can be time consuming and even require a re - design . This can be quite frustrating for the team as the   achievement needs to be reworked . Also it is important at the end of a sprint phase to provide a   proper documentation of the design , functional and technical specification . Due to time pressure to   move on to the next sprint and deliver the next milestone , documentation deems to be the least   important , but it will have repercussions in the long term in the sustain phase if a different team   ( Production Support ) will have to take over and do n’t have enough information for know - how transfer   and reference documentation . 

 Reflecting the achievements of prototyping in iterative steps there is a clear benefit for the business   stake holder to see a draft product at a very early stage of the project and the stake holder can   influence the development providing feedback . On the flipside there is to mention , that the stake   holder needs to be managed to avoid that continuously additional requirement are added which   impacts time line and costs . Once the scope of the product is agreed the focus should be on the   delivery of the agreed solution . Scope creeping from the business stake holder should be avoided to   avoid jeopardising the timelines . Also documentation is important to complete at the end of the sprint   phase to have an auditable product and know how transfer to the Production Support team can be   performed . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Learning Launch 

 Challenge 

 Being part of an IT&S business process design team a user interface tool to place orders from   customers to request services needed to be replaced as the existing tool reached the end of live   service and was not compatible with the cloud which is the strategic direction of the company for   customer applications . In the past , the company used for projects the classic waterfall concept   ( select / design / build / deploy / support ) . As this was a time critical project and the results should be   achieved faster and more cost efficient , the agile approach was selected . To overcome the   knowledge gap of how to apply agile working in projects , an external consultant was hired to lead the   scrum sessions . The IT&S team was a diverse team where development activities have been   performed offshore . As product owner for the new user interface tool the business key stakeholder   was nominated . 

 Selection 

 In a first step the business requirements for the new user interface tool have been gathered and   confirmed by the business key stakeholders . The technique of learning launch was applied , prototype   the solution for the user interface solution based on understanding of the requirements in a very   short timeframe to show the product owner the developed product . The prototype included daily   scrum meetings between the design team and development team via conference calls including the   product owner to share the proposed design & design options for knowledge transfer , issues &   defects in the build phase of the prototype solution etc . 

 Application 

 One of the first steps was to evaluate design options based on the agreed business requirements .   An integrated activity between the design team and technical build team is required to exchange   functional process design and technical feasibility documented in a power point presentation . The   outcome of the agreed product needs to include the deliverables for the different sprints as part of   the agile approach . 

 The prototype process has been started to apply the basic / core design ( minimal viable product )   agreed in agile sprint 1 into a technical solution provided by the offshore team after explanation of the   key desired functionality ( i.e. log on to a customer hub , request a service based on a catalogue ,   workflow functionality to agree on the contract incl price for the service and confirmation ) . To follow   the agile approach , no detailed documentation of the functional specification has been provided , only   the key elements on a high level documented and communicated to the technical team . As a   documentation tool visio process flows and where applicable narratives have been provided and   communicated in a Q&A session via conference calls to the offshore team . To save time and money   the technical team was not requested to provide a technical specification . The show and tell   approach was used supported by a demo of the first draft of the technical solution which was   validated by the product owner who provided feedback on expectations and usability . Questions to   the product owner have been raised to evaluate if the solution meets the needs , it improves the   process and would improve customer experience & satisfaction . After feedback which functionality   are good vs not sufficient a review process has started to discuss required changes and   enhancements taken into consideration feasibility in terms of time and costs . Iterative review   sessions have been conducted to analyse progress and issues and improve the user interface tool 

 step by step . Part of the technical build had to be trashed as it was not compatible with the required   fixes and enhancements . 

 Once the product is agreed and signed - off by the product owner in a final show and tell session , the   functional design and technical build has to be documented and stored in a central space for audit   purposes . 

 In the next sprint the user interface tool should be enhanced to cater for budget and reporting   capability . The same iterative approach as in sprint 1 applies which requires a final review and sign - off   from the product owner . 

 Insight & Approach 

 What I have learnt from prototyping a product based on an agile approach is that the product   specification requires a detailed description of the expected outcome clearly communicated to the   offshore team to avoid too many failures of the draft solution and iterations . In addition I feel that it is   important to think ahead of the additional requirements and add - ons to the product in the next sprint .   If the additional requirements ( i.e. budgeting and reporting functionality ) are not considered and   addresses , the issue arises that the signed - off product in sprint 1 requires major modifications which   can be time consuming and even require a re - design . This can be quite frustrating for the team as the   achievement needs to be reworked . Also it is important at the end of a sprint phase to provide a   proper documentation of the design , functional and technical specification . Due to time pressure to   move on to the next sprint and deliver the next milestone , documentation deems to be the least   important , but it will have repercussions in the long term in the sustain phase if a different team   ( Production Support ) will have to take over and do n’t have enough information for know - how transfer   and reference documentation . 

 Reflecting the achievements of prototyping in iterative steps there is a clear benefit for the business   stake holder to see a draft product at a very early stage of the project and the stake holder can   influence the development providing feedback . On the flipside there is to mention , that the stake   holder needs to be managed to avoid that continuously additional requirement are added which   impacts time line and costs . Once the scope of the product is agreed the focus should be on the   delivery of the agreed solution . Scope creeping from the business stake holder should be avoided to   avoid jeopardising the timelines . Also documentation is important to complete at the end of the sprint   phase to have an auditable product and know how transfer to the Production Support team can be   performed .
### Output: 