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.

****


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