Module 4 - Example Reflection – Learning Launch    1. Challenge  We are a small legal chapter in a company with over 160 other team member from  different disciplines, backgrounds and 35 nations. The company language is  english, the minimum common ground. We are working in the IT/ Creative  industries.  As the team lead, I face multidimensional blockers. We had too many tasks or  requests addressed to our very small team of 3 persons. Everybody would keep  asking us again and again, when the assessment in our queue would be delivered.   We had to check repetitive and recurring issues. The request were coming in via  Jira, a task tool out of the agile toolbox. The Jira notifications were spamming us  with an average of 40 notifications per task. As a result we spend too much time  searching for specific topics or relevant information.  The peers around us were changing many times due to the heavy  rotation/fluctuation in the specific industry, so we face a constant drain of  coworking expertise and our knowledge transfer efforts have to start from zero. We  are part of an increasing number of meetings, were we took part on demand.    We are too slow, the work is too repetitive, too expensive, too exhausting.   Something has to change.      2. Selection  Then we focussed on the expectations and needs and started a research phase to  include involved team member and to hear all concerns and Ideas.  During the following weeks we wanted to visualize dependencies, identify our  assumptions and start launches to test the assumptions.      3. Application  Our first step was to collect all of the different input from all the involved  stakeholder with the help of the APM team.This first expercise led not only to the  choice of the Team Member that we needed to interview but also crystalised the  fact that we had way to many peer persons for such a small team.      a. Visualization of request flows and dependencies  We began with visualizing all the dependencies and the involved stakeholders. We  gathered opinions and needs of other teams in one on one interviews.      b. Refining the challenges and validating findings with peer groups  In three workshops we detected negative patterns and defined the following key  challenges:

● Fast changing interfaces in other chapter (disciplines, like Marketing,  CRM)This is how our challenge was:

● Prioritization: first comes first served, or importance (not transparent to us)  etc, lots of discussions

● Poor onboarding of new team member in other teams led to lack of  knowledge transfer. So we took over this task again and again. The team  member asked us the same questions asked before.

● Time to delivery and tracking: once the task was sent to us, team member  asked over and over again if and when the assessment would be ready. It  took us time to answer and we there was tension on both sides.

● We had not enough time for the core work (thinking about topic) due to  many meeting requests

After refining the challenges we started with the learning launches. We gave them  two titles “Learning Launch Tech” and “Learning Launch Orga”:

c. Learning launches on Tech  We had a learning launch with the apm team to tweek Jira in a way that we could  get less notifications, but relevant ones. We tested the fine tuning of Jira. The  efforts failed early, so we decided to only use jira for simple tasks with little  notification needs to keep the notification traffic low.  We did quick tests and  decided to take out the rest.  Second assumption to be tested in the launch was: can we make the deploy system  of our website detect (automatically) non compliant wording and send us an alarm.  This was a way to save time screening all products proactively all the time (Goal:  time saving). The outcome of the test was that this is nearly impossible as the  judgement about compliance needs context and tech could not reflect the context  at least not without a huge and expensive project to implement the needed context  to the system.

d. Learning launches on Orga/Structure  During the learning launches on Orga, we tested assumptions with a more positive  outcome as in the tech launches, as the changing effort was lower:    We introduced and tested the “legal interface”, a person in each chapter  (discipline) that had experience in working with legal teams and had an overview  above all the requests from his/her team to ours. This person would check the  request first, refine and share the knowledge internally. This already led to less  requests, as the non needed were filtered out.    My favourite tweak is this one, that was positively tested: in the product life cycle,  the project went first to legal for a check, then to the UX team (user experience). We  switched the order. Now the check of UX should be before the legal check. When the  request comes to legal, many compliant relevant measures are already

implemented. The assumption was right: what is good for user, is mostly also more  compliant. This decreased also dramatically our checking time.    The 3rd test was: ​Introduction of deadlines​ instead of tracking and reporting about  time to delivery. This was also an inversion: instead of asking us all the time, the  team should provide us a deadline for a task, so that we could better prioritize  internally and no asking all the time was needed.     4. Insight  We are now 98% in time with the checks. We have more fun working and we  developed a culture of cooperation with other team chapters instead of the old  blaming culture. We learned that organizational changes are sometimes quicker  and cheaper that technical ones, and that even in a Tech Company, tech does not  solve all the problems. We also had the feeling that we are now more living the  scrum manifesto claim: people over processes. We are not accepting Jira Tickets for  complicated heavily related tasks anymore and had to explain first a lot, but as the  results are now quicker, everyone is happier than before.    5. Approach  We are continuing evaluation the new measures. We have already seen a huge  amelioration and a better organic integration of the legal chapter into the product  development. See also the insights above.  We have still topics to solve and are planning constant evaluation and adjustments.

