Example Reflection – Learning Launch 

 Challenge : I ’m part of an organization of ~50 members involved in developing and sustaining software with a good installed customer base . The engineers in this group comprise of both Development &   QA and undertake multiple engineering activities which includes but now limited to new feature development ( as requested by the installed customer base ) , sustaining older software   releases(defect fixing ,   troubleshooting issues reported by customer &   providing patches for   customer issues ) besides engaging in research and development and quality improvement   initiatives . All of these activities are with dynamically changing priorities almost on a daily basis . The team has subgroups working on different components which have their respective QA   teams . The challenge here is twofold 

 1 . To   improve the workflow from development to QA and finally to the customer ( thereby 

 increase turnaround and improve customer satisfaction ) 

 2 . To identify slack if any to introduce more quality improvement initiatives ( to improve 

 long term quality of product ) . All the work undertaken by this organization is greatly   influenced 

 Selection : The team is already moderately familiar with agile development methodologies and scrum   process and have some knowledge of Kanban processes . For the purpose of this experiment   only a smaller team of 8 people working on one of the component was chosen . This team   includes both Development & QA . The learning launch is an experiment meant to quickly   validate the idea and the tool to be used . 

 Application : For the first learning launch experiment , the focus was on gaining clarity into all the work   undertaken by the team and to establish the right priorities improve workflow . In particular , the   aim was to see if Kanban methodologies & free tools ( for online Kanban board ) available can be used for visually representing the work items undertaken by the team members which can aid   in removing blockages thereby improving the workflow ( from development to QA to customer ) .   The team was given a quick overview of the Kanban process & the tool to be used . Next during   the 2 hour kickoff meeting the work items were added to the tool reflecting the current status .   A daily stand up / scrum meeting was planned for 2 weeks to discuss the status of each work   item and removing impediments causing blockages to the workflow .   For the second learning launch , the focus was on gaining insights on slack that could be used for quality improvement initiatives . This tested our assumption that the lack of clarity of priorities   was the cause of no time being available for quality improvement . 

 Insight : 

 By applying the learning launch tool , we anticipated to get better insight into the complete set   of various activities the team is engaged on in at any given point and to validate our   assumptions that management intervention in setting the right priorities to the various tasks   would help improve the work flow . This assumption was indeed validated when it was noticed   that many engineers were multitasking and were not clear about the priorities and sometimes   to the point of being overwhelmed with too many things to do on their plate . Also , the daily   stand up meetings brought the work done by all the team members into everyone ’s else focus   which improved peer appreciation and thereby morale of the individual working on the task .   For some of the tasks , engineers were able to get unblocked with help from their peers . Also , it   came out clear that the QA was not making as much progress as was assumed by everyone else   in the team . It was also noted that lack of awareness of the developmental processes was also   the reason for below optimal workflow . Going forward , the insights would be incorporated as   changes to the Kanban board for future designs . This ongoing incorporation of insight will   continue till the full rollout of Kanban to the entire organization . 

 Approach : Given that Kanban was found acceptable to the team in proving some of the assumptions   before the launch of the experiment , the team will continue to do more launches to gain further insight into the work flow , identify wasteful effort with the purpose of eliminating & also   measure the throughput of the QA which seems to be the main blocker in the organization .   The experiments will be continued to identify slack in the development teams to introduce quality   improvement initiatives without impacting the customer commitments . The implementation   will be broad - based to the entire development team at the appropriate time . 

 * * * * 


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: Example Reflection – Learning Launch 

 Challenge : I ’m part of an organization of ~50 members involved in developing and sustaining software with a good installed customer base . The engineers in this group comprise of both Development &   QA and undertake multiple engineering activities which includes but now limited to new feature development ( as requested by the installed customer base ) , sustaining older software   releases(defect fixing ,   troubleshooting issues reported by customer &   providing patches for   customer issues ) besides engaging in research and development and quality improvement   initiatives . All of these activities are with dynamically changing priorities almost on a daily basis . The team has subgroups working on different components which have their respective QA   teams . The challenge here is twofold 

 1 . To   improve the workflow from development to QA and finally to the customer ( thereby 

 increase turnaround and improve customer satisfaction ) 

 2 . To identify slack if any to introduce more quality improvement initiatives ( to improve 

 long term quality of product ) . All the work undertaken by this organization is greatly   influenced 

 Selection : The team is already moderately familiar with agile development methodologies and scrum   process and have some knowledge of Kanban processes . For the purpose of this experiment   only a smaller team of 8 people working on one of the component was chosen . This team   includes both Development & QA . The learning launch is an experiment meant to quickly   validate the idea and the tool to be used . 

 Application : For the first learning launch experiment , the focus was on gaining clarity into all the work   undertaken by the team and to establish the right priorities improve workflow . In particular , the   aim was to see if Kanban methodologies & free tools ( for online Kanban board ) available can be used for visually representing the work items undertaken by the team members which can aid   in removing blockages thereby improving the workflow ( from development to QA to customer ) .   The team was given a quick overview of the Kanban process & the tool to be used . Next during   the 2 hour kickoff meeting the work items were added to the tool reflecting the current status .   A daily stand up / scrum meeting was planned for 2 weeks to discuss the status of each work   item and removing impediments causing blockages to the workflow .   For the second learning launch , the focus was on gaining insights on slack that could be used for quality improvement initiatives . This tested our assumption that the lack of clarity of priorities   was the cause of no time being available for quality improvement . 

 Insight : 

 By applying the learning launch tool , we anticipated to get better insight into the complete set   of various activities the team is engaged on in at any given point and to validate our   assumptions that management intervention in setting the right priorities to the various tasks   would help improve the work flow . This assumption was indeed validated when it was noticed   that many engineers were multitasking and were not clear about the priorities and sometimes   to the point of being overwhelmed with too many things to do on their plate . Also , the daily   stand up meetings brought the work done by all the team members into everyone ’s else focus   which improved peer appreciation and thereby morale of the individual working on the task .   For some of the tasks , engineers were able to get unblocked with help from their peers . Also , it   came out clear that the QA was not making as much progress as was assumed by everyone else   in the team . It was also noted that lack of awareness of the developmental processes was also   the reason for below optimal workflow . Going forward , the insights would be incorporated as   changes to the Kanban board for future designs . This ongoing incorporation of insight will   continue till the full rollout of Kanban to the entire organization . 

 Approach : Given that Kanban was found acceptable to the team in proving some of the assumptions   before the launch of the experiment , the team will continue to do more launches to gain further insight into the work flow , identify wasteful effort with the purpose of eliminating & also   measure the throughput of the QA which seems to be the main blocker in the organization .   The experiments will be continued to identify slack in the development teams to introduce quality   improvement initiatives without impacting the customer commitments . The implementation   will be broad - based to the entire development team at the appropriate time . 

 * * * *
### Output: 