Example Reflection -Learning Launch tool

Challenge

I am a member of my organization’s software development department and my  challenge is to improve the capacity of quality department in order to increase  overtimes for quality engineers and do not delay the software deliveries for  customer. The main duties of quality department are to compare existent developed software  with requirements from customer, report defects and be sure that defect is fixed and  users can use software functionality according to their goals without any problems. The quality department has 5 engineers and 30 developers for software  development. Development works according to Scrum the sprint for 30 calendar  days and delivery to customer each 30 day. Instead of planned scope at the begging  of sprint the quality department has lots of customer request and tasks that  impossible to estimate and predict. Scope of each release can be very different, so it  led to lots of overtimes and stress for the engineers. While the engineers switching to  urgent tasks deadlines for planned activities begin to start.  We will focus on trying to avoid delay in software delivery with no losses in software  quality.

Selection

The team is try to using the learning launch to test their assumptions on a real  project in one sprint and see what assumptions of the team can be the potential  working to achieve their goal.

Application

For the first learning launch team we focused on varied tasks that do each test  engineer every day. In particular we want to see all the tasks that each engineer has  in one sprint. Then we try to understand what from the tasks may have urgent or  asap priority. Then we try to understand what the correlation between the tasks that  we can plan in release and tasks/requests that can’t be prognosed. The session  include all test engineers and test manager. The result of first session was the data from what we can understand the proportion  between planned and unplanned tasks in release, their root cause and teams  understanding of urgency of each unplanned task/request.  For the next session each engineer prepared current actions that was able to help to  control the scope if they have such. In other case the possibilities that were lost to  control the scope and its reason. On the second session we discussed all activities  that as last engineers think help them to control the tasks scope. On the third session we assume that some of the ideas from previous session can  help if we transform them a little. We added common understanding of tasks  priorities at the team.

Insight

First assumption was that we undestand priorities of customer inefficient and we  begin to work closer with customer at asking to add at each task label with priorities

and approximately deadline for each request. It help the team to understand the real  priorities of each «urgent»  test that customer has. Some of them could be done at  the time that test engineer has low capacity and do not affect customers work. At the end closer communication with customer give the team the opportunity to  cover some request not in formal way e.g just answear in chat instead of big official  letters with of detail in tread. Moving forward, the team working with the priorities created a set of tasks that calls  as arrears and do them as soon as allowed workload. It was big surprise that when capacity was planned and meeting customer  expectations was achieved the arrears task also was done, stress for team members  was increased.

