agile42 Finland coach Lasse Ziegler has been interviewed by Kauppalehti, the main economy newspaper in Finland, explaining how an Agile culture allows companies to respond faster to changes than their competitors, and how it needs to be entrenched in the company culture.
The Scrum community will gather once again in San Diego for the Global Scrum Gathering organized by the Scrum Alliance. It will be a whirlwind of meetings and talks for three full days, 10-12 April, and I will be present at the Sheraton San Diego Hotel & Marina together with the other agile42 coaches.
Being in California, the theme for #SGCAL is Looking Back, Looking Forward — Surf the Tides of Change. Conference co-chairs Vic Bonacci and Kim Brainard can’t think of a better town than San Diego for a Scrum gathering devoted to looking back and looking forward. “San Diego is a coastal town,” says Bonacci. “You can be standing on the coast with all this history behind you and looking beyond at this endless sea with endless possibilities.”
This gathering looks back to the early days of Scrum in the 1990s, explores the ways it is being used now, and looks to the future as industries and individuals find creative ways to use it.
On Wednesday, April 12 at 1pm I will facilitate a workshop Avoiding the Dilbert Syndrome: What Does the Agile Manager Actually Do? in the Life’s a Wave: CATCH IT track (again, it’s California!)
If you’re in San Diego come and meet us, or follow us on Twitter using hashtag #SGCAL.
At agile42 we are always interested in trying out new approaches. We have applied Nonviolent Communication (NVC) for a while now but feel that it doesn’t necessarily give the desired results fast enough. In our search for instant gratification, we instead created the Full-Violence Communication (FVC) approach.
Unlike the many ancient Japanese methods available for finding out the next steps, including genchi genbutsu and heijunka, FVC is a quite recent technique from the US. It follows the basic agile tenet of just doing it and asking for forgiveness later. As you will see, FVC embraces diversity and dissent and lets people bring alternative facts to the table.
agile42 coaches Simon Sablowski, Daniel Lynn and Bent Myllerup warming up before the FVC session.
The FVC method is fairly simple, bordering on obvious. Complicated processes require people to spend a lot of time on figuring out what actually needs to be done at any given point in time. Since FVC relies on primal reactions in the human brain, it totally bypasses the frontal cortex that is responsible for rational thought processes. This way the higher cognitive functions are freed up for tackling technical complexity in e.g. the software product the team is working on.
In a nutshell, when people have different opinions about something, we just follow this simple FVC process:
As you can see, the argument is settled by the simple expedient of seeing who is the last person standing. This lets the team rapidly and efficiently converge on the solution with the strongest backing. As a side effect, the team quickly becomes extremely motivated and gains an immense amount of focus. This obviously saves a lot of time and reduces the cost of delay. We do not know of any other method that achieves this kind of results in such a short time.
Martin von Weissenberg agrees that Daniel Lynn is right about story points.
Scrum sensei Daniel Lynn is one of the inventors of FVC and a strong proponent of the method. Asked to summarize the method in one sense, he thinks for a while and says: “Might makes right. In other words, if all we have is opinions, let’s go with mine.”
Gaetano Mazzanti notes that the agile42 coaches were not convinced at first, but that Daniel Lynn was very persuasive. “Having discussed the topic with Daniel, I now see that FVC is a fantastic tool in my toolbox. This could speed up the coaching process immensely.”
Daniel Lynn explains the finer details of daily standups to the not very stand-uppish team.
Simon Sablowski and Martin von Weissenberg agree. “Awareness brings choice. Thus if somebody makes a choice, and applies FVC, then the others will quickly become aware of it. Unless of course they are unconscious,” contemplates Martin.
Gaetano Mazzanti (AKT) proves to Martin von Weissenberg (CEC) that Kanban is better than Scrum.
For teams who want to practice FVC on their own, we can recommend the good old Finnish party game where you bring lots of vodka and one puukko knife each to a dark hut in the woods. This game obviously works best in a multi-team setting but can also work well within a single team. The vodka serves double-duty as internal cushioning for falls and internal disinfection of possible wounds. Naturally, the game can also be played alone, but that requires a lot more vodka.
Coming soon from agile42: Full-Violence Communication classes. Stay tuned!
Coach Marius de Beer presented a talk Agile Decision Making in a Flat Structure at the SUGSA (Scrum User Group of South Africa) meeting in Cape Town on 23 February 2017.
The objective of this talk was to give teams practical techniques for decision making in a flat structure. Most Agile frameworks are geared towards delivering software through self-managing, self-organizing, cross-functional teams, where all team members have “equal say.” Holarchy (completely flat structure) is also becoming more popular in the technology world. In both situations, teams frequently waste considerable time when a decision is needed and there is no clear “leader” to make it. This is especially true when there is also no “right” decision, just different opinions. The techniques discussed in the talk come from doing it and helping others do it (with a few spectacular mistakes).
The talk has been sponsored by Allan Gray and agile42 and can be viewed on YouTube and below here. SUGSA runs monthly meetings in Cape Town and Johannesburg, find out about more upcoming meetups.
This book is dangerous. It’s got magic. You read it in the train, commuting to work, and the stations just pass by. You sit nodding, mumbling “so true” and “hadn’t thought of that” to yourself. Every day I read this book I have to hectically rush out of the train with open bag and book in hand. It’s dangerously captivating.
The length of 280+ pages is deceptive – the book is very readable and the pages just fly by. The text is clear and to the point, the ideas are well described and anchored in examples that are both realistic, captivating and illuminating. The DRIVEN acronym and the way each letter is opened up in a separate chapter gives a nice structure to the book. This also means that the chapters are short enough not to feel overwhelming, but still contain a lot of content.
You can find a large number of books in the Product Owner space. Most books tend to focus heavily on the hard skills, and touch lightly if at all on the soft skills. Many of the best known books cover how to write good user stories, and there are some that discuss new and interesting methods for slicing backlogs. None of them cover the soft side of Product Ownership as well as this one – the balance between soft and hard skills is nearly perfect. In between tables detailing how to prioritize features using a spreadsheet, you will find thinking models and examples on how to listen and negotiate more effectively. But rather than disturbing the flow by bouncing back and forth, the new topics neatly build on top of each other, enhancing the previous topics.
What really makes the difference between Geoff Watts books and other books and articles is the depth he gives in understanding how you can become a great Product Owner. You can read a lot about a Product Owner to be decisive, communicative or empowered. But few authors cover the gap between reality and the desired state adequately. You have to find a way to overcome this gap on your own, or fill in with other books on e.g. leadership or verbal skills. Geoff explains why it is so hard to become a great Product Owner, which traps you would find on your way and, most importantly, how you can and should reflect on your own behavior in order to learn how to bring out the best in others.
Like an expert Product Owner, Geoff has decided what to leave out of the book, and covers the rest tersely but in adequate detail. This is in fact a great example of a Minimum Viable Book. That said, the book would benefit from providing pointers to related or similar methods. For example, Geoff has chosen to open up Story Mapping, a popular tool that works very well in many circumstances. But sometimes you find yourself in situations when e.g. Impact Mapping or Feature Injection work better, and I would like to see the occasional “Try these alternatives” box mentioning other methods and when to apply them.
At the end of the book is an appendix describing Scrum which frankly feels a bit out of place. While every PO must know the selected framework and can help a lot by doing the right things right, it’s more the job of the ScrumMaster to guide the team and stakeholders in the use of Scrum. The immediate beginner PO:s who could specifically benefit from this appendix would probably aim for one of the more basic Scrum books instead. And there are plenty of good Scrum guides available already, many of them free and some of them better than this appendix.
Minor nitwiggles aside, what we have in our grubby hands is one of the very best PO books out there. It’s a pleasure to read, the structure is excellent, the topics are wide, covered in adequate detail, and immensely useful. It’s a book that we can strongly recommend to each and every PO, regardless of age or experience.
As agile coaches, we are meeting with HR people more and more often. Whether at companies, or seeing them at events, increasingly it is common to be drawn into conversations requesting a short introduction to agile. In this article I will share my thoughts and experiences around agile and HR departments, what they should know about becoming agile and how they can apply agile in their own work.
Why does HR need to know what it means to become Agile?
Agile generally first starts growing in the software development teams to enable short time to market delivery and enhancing the ability to respond to changes. When people start working as agile teams some fundamental HR process changes need to be adapted in order for them to work better, collaborate, focus on value and commit to a common goal. If the HR policies and processes are not adapted to an agile context, these teams start facing impediments which they can’t solve themselves. This decreases the efficiency of the teams and prevents growth in the agile mindset. These are organizational impediments that HR departments should handle in order to support the teams. If companies desire their teams to be productive they must ensure their HR departments know what it means to become Agile. Becoming agile is not only adapting the practices, it’s also a mindset shift. For the cultural movement towards agility to begin, these teams need to be supported in a continuous learning environment by the HR policies.
Below are the top issues from my perspective that HR departments should address in their practices and processes when working in the agile context:
HR considers agility when recruiting new team members. Recruiting a super intelligent and skilled professional is not enough, you also need to look for people who are willing to work as a team member, people who are open to changes and can adapt to changing team dynamics. Recently, we have delivered multiple Agile & Scrum training workshops to a large company. Training was not only for the tech people, IT recruiters were also in the classes. When I spoke with one of the recruiters during the training he confessed that he now realized what it meant to be working agile and during the initial job interviews what he needs to observe and look for.
HR should work with management to provide an environment that enables teams to make decisions. For Agile teams to be productive and nimbly responsive to change they need to be authorized to make decisions according to the feedback they receive from their clients. If they are not able to make decisions and are always stuck with long decision making processes, this limits their agility. By enabling them to make decisions, even if only in a constrained environment, agility accelerates.
HR and management should provide an environment that enables growth of an agile mindset. The agile way of working is not something that only teams should care about. We generally notice that some time after teams start working in agile, some functional managers are afraid of losing control over their people or even their jobs. Before agile, they performed task assignment — so what do they do now? These profile managers should be encouraged to evolve into agile leaders, taking care of improving the business. They should provide their teams safe to fail containers to foster creativity, growing as teams. So HR needs to encourage Agile values in the management teams. They should encourage people to be transparent, bold, able to learn from their failures and develop themselves into servant leaders.
Training and talent growing are the responsibility of HR. Becoming agile is about a state of continuous learning and trying to change for the better. HR can’t enable this learning environment if they think they only need to provide some technical training to achieve this result. In one of my previous companies I was an internal Agile Coach, I was working closely with HR people to support continuous learning with tools, awareness workshops, cafe talks, and providing environments to enable people learn from each other. So to support this learning environment HR should know how to be agile.
The ultimate goal is organizational agility. Companies just can’t hit this goal if they think that applying agile practices in the software development teams is enough. Companies are living organizations formed from different departments. To be able to gain organizational agility all of these units should work aligned, knowing what is the value they need to deliver. They all need to see what is happening and what needs to be done in what order and collaborate with each other. HR again needs to work with management to support this collaborative working environment and cultural mind shift.
HR is generally responsible for developing and helping companies to apply the right performance management systems. If these systems encourage only individual performance or are stuck with the wrong KPI’s, you kill the heart of agile working. A system measuring success should be adapted and formed around encouraging teams to get better, being careful to avoid fake results created by cheating the system.
How can HR teams apply Agile practices to their strategic and daily work?
As I stated earlier I had an opportunity to work closely with HR teams when I was an internal Agile Coach. I had the opportunity to closely observe and be involved with their strategic initiatives and daily routines. HR teams transforming to become Agile is a critical and a must step. The HR division of the company I worked for was lucky to take this step early and started experimenting with Agile practices.
Some ideas for how an HR department can embrace agile themselves:
HR departments have many products, services, complex projects with varying domain knowledge and therefore need a variety of skills to handle this complexity. People from different HR departments need to work together to further develop their products and services. I coached an HR team who had a goal to acquire talented young people to the company and to strengthen the brand image in the young population. This was a 9 month project recurring every year and before applying agile it was managed in the traditional way. There were people involved from various areas, including: recruitment, training, communication and branding departments. There was a fixed scope with milestones, activities performed with different departments and a hand over to each other after they performed their own tasks. Every department was responsible for their own outcomes and sometimes the workload was heavy for certain departments. This was solely the responsibility of the department facing the problem. We changed the way they provided and developed this service. First, all related people had Agile & Scrum training. A Product Owner was assigned and we formed a Development team from different HR departments. They put everything in a Product Backlog and ordered it . They started applying Scrum and committed that certain amounts of work be done and goals were reached every Sprint. Some of the benefits after they applied Scrum: a) they reached the business goals, b) they had a chance to learn from each other, c) they quickly found emerging solutions to problems with a collaborative mindset and synergy, d) there was not a single department becoming a bottleneck as they experienced previously, everyone helped each other for the smooth flow of work.
HR departments have multiple projects running at the same time with limited access to domain experts. They generally have prioritization problems. It causes long lead times and a lot of half-done work with overburdened people. To overcome this, HR can use an ordered backlog including both strategic initiatives and operational work, implement a PULL system to decide what to work on first and deliver according to desired value. By implementing some metrics and the magic of visualisation, HR can focus, make quick decisions and deliver fast. When I was working as an internal Agile Coach we had an agility backlog to support the company. We pushed everything to do with organizational agility in this backlog. We ordered it, started to pull the work we could handle and produced working solutions after each iteration. At the end of each iteration we stopped to see the progress made, what we needed to add to our backlog, how we could improve our way of working and started again with the new knowledge we have. HR departments can eat their own food :)
HR departments also have multiple stakeholders of differing types. A lot of demands come from different parts of the organization. Every departments’ demand is their priority but HR departments also have limited capacity. I had this kind of experience with the Recruitment Department. I tried to help them to balance capacity and demand and to act to fill the most valuable positions. The first thing we tried to implement was a PULL policy. Then we visualized the workflow, from demand to the end of the recruitment. When we implemented these two practices they immediately realized some facts: a) to define an explicit PULL policy was very hard, because stakeholders also needed to be involved in this policy definition, but it was really vital; b) when the workflow was visualized it was easy to see the bottlenecks, who was stuck and who needed help, so visualization ended up decreasing the lead time; c) it was also helpful to use some metrics around success and open discussions to improve the process.
Summary
People in HR need to know Agile and can actually benefit themselves from applying Agile practices. Although Agile originated in software development, it is clearly understood that it is beneficial and an enabler in every domain. Agile is not only practices but also a set of values and principles that fit every domain. HR departments are in the position of being enablers and so are a natural fit for companies becoming Agile .
Please drop a line or leave a comment about your similar experiences, I’d love to hear them!
Elsevier is a Dutch independent weekly news magazine. The magazine focuses primarily on higher educated readers and various segments within the market sector. In a special edition on Business Agility, they published an interview with Niels Verdonk and Garbrand van der Molen, two leading Agile Coaches of agile42 in the Netherlands.
In the interview they discuss various aspects of Agile in particular why it is that organisations often don’t realize the full potential of Agile.
Niels Verdonk: “In many organisations Agile is still seen as something which is something for the IT Department, without involvement of the rest of the organisation.”
Garbrand van der Molen: “Invest in key competencies such as leadership, team coaching and product management. Implementing Agile requires a shift in paradigm.”
Some parts of the printed magazine will also be made available online. We will update this post with references to the online material.
Here you can find the article online in Dutch.
“In preparing for a battle, I have found planning is indispensable, but plans are useless.”
— Dwight D. Eisenhower
I love it when a plan comes together — but sometimes, you just have to let it go.
When coaching teams, you will soon find out that every team is different, and every meeting of every team is different. Just like snowflakes, no two are alike. The key is to be able to adapt your plan to the team’s needs at every moment of time. Even the best plan is made based on the knowledge and assumptions of that current state and point in time. Things change, and there are always surprises – it is crucial to stay adaptable.
As assuring as it is to have the plan all laid out, the number of times I actually had to ditch that “initially awesome” plan is countless. In fact, the number of times where we ended up sticking to the original plan was… guess what: ZERO! Most of the time, I actually end up adapting the plan heavily and tweaking it according to the team’s needs as we go – and those are the ones that work out best. “Responding to change over following the plan,” as in the fourth item of the Agile Manifesto.
One of the most recent cases had me redesign the initially oh-so-meticulously planned retrospective on the actual sprint change day during lunch break based on what I saw during the review. That “retro_version_12.0” was yet again re-adjusted DURING the retro itself – just like a custom made Italian designer suit, tailored to fit as you try it on. It was probably still not THE perfect plan, but it was likely the closest possible approximation.
What we can perhaps all agree on, is that there really is no such thing as “the perfect plan” – and even if it did exist, it would be impossible to preempt / predesign it. Here is the good news, though: You can get a pretty close approximation by having a good draft (call it MVP, if you want) to begin with, and adjusting it as you go. Start with a good plan, and inspect & adapt – sounds familiar, right?
Charles Darwin once said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Obviously, those who rigidly stick to the ‘original’ plan do not have the best chances of survival. What it all boils down to Planning too detailed & too far ahead is a waste, and there is a hard-to-hit sweet spot. It is best to stay flexible, keep your options open, and make decisions as late as possible to make more informed decisions.
Having a plan is good. Having a good plan is better. Being able to ditch that good plan and come up with a better one as you go – priceless!
Image by congerdesign from Pixabay
We are happy to sponsor once again ProductCamp Vancouver 2017, the premiere event in the British Columbia area for Product Management, Product Marketing, and Marketing professionals to teach to, learn from, and network with each other.
ProductCamp is an un-conference, meaning that participants can bring ideas, lead a session in their area of expertise, facilitate a round table discussion, network, or volunteer. This year’s event will take place at UBC Robson Square in Downtown Vancouver, BC next Saturday, 18 February.
A couple of years ago I have been asked what I like about ProductCamp Vancouver in this short video:
Merhabalar,
Bu yazıda sizlere, gerek yurt içinde gerekse yurt dışında gözlemlediğim, deneyimlediğim bir durumdan ve olası çözümlerinden söz etmek istiyorum. Agile olmak isteyen, bu amaçla yola çıkan pek çok firmanın yaşadığı bir durum bu: Tabir-i-caizse, ektiğiniz (Agile) fidanın tutmaması.
Agile Fidanı
Uygulayanlar bilirler, Agile yaklaşım, sadece geliştirme takımları kurup onlardan çıktı beklemekle olmaz. Bir süre sonra takımlar, bu yaklaşımı benimseyip doğru işletirlerse, kendi önlerindeki engelleri çöze çöze giderek, zamanla başka engellere takılmaya başlar. İç yapıdan doğan, süreçlerden, rollerden ve daha pek çok şeyden doğan bu görünmez cam duvarlar birdenbire görünür olur. Şimdi sıra, şirketin önündeki engellere; ‘business agility’nin, yani şirketin uçtan uca çevikliğinin önündeki engellere gelmiştir. Organizasyonel engelleri kaldırmadıkça da şirket hiçbir zaman tam anlamıyla agile olamaz, ancak belirli bir yere kadar gelip orada takılır, kalır. Bu noktada yönetim kadrolarının, liderlerin, üzerlerine düşen çok önemli görevler olduğunu bilmeleri gerek.
Lider Yönetim
Liderlik edecek yönetim kadrolarının desteği ve inancı olmadan, tam olarak anlamadan, inanmadan yapıldığında Agile, ancak yarım yamalak sonuç verir. Bu durumda, biz “change agent” ya da Agile koçlar çekildikten sonra ne olur dersiniz? O ellerinizle tohumlarını ektiğiniz, özene bezene sulayıp filizlendirdiğiniz, yeni yeşerttiğiniz agile fidanı sahiplenilmezse, bakılmazsa, tam da yeni yeni tutunmaya, kök salmaya başlamışken, ilgisizlikten, bakımsızlık ve susuzluktan kurur, ya da ilk rüzgarda kırılır. Belki de birinin “Şu daha hızlı büyüse ya!” diye aşırı gübrelemesiyle, yapraklarından çekiştirmesiyle can verir, ya da (belki de en acı olan), sonradan gelen birinin “Bu ne böyle? Yabani otlar bürümüş burayı, yolun şunları, buralar bize lazım.” yaklaşımına kurban giderek, sökülüp atılır. Böylece bu işe harcanan onca bütçe, çaba, zaman ve emek de çöpe gitti..
Bunun hemen görülmeyen, ama bir o kadar da ciddi yan etkisi ise şu: Agile olmayı (Scrum çalışmayı, Kanban yapmayı..) bir kere ‘denemiş’ olan ekipler ve şirketlerde, toprakta anız yakmaya benzer izler kalır; yeniden denemeye karşı direnç oluşabilir. Bir gün gerçekten Agile olmayı istediklerinde, aşmaları gereken (içsel ve dışsal) eşik her turda yükseldiği için, başarma şansları giderek azalır. “Biz geçen sene denedik, olmadı”, “Agile/Scrum/XP/.. bize göre değilmiş”, “Bizim şirkete uymadı” – tanıdık geliyor mu?
Bir Kanban Tahtası Örneği
Öyleyse Agile fidanının yaşaması, yeşermesi, boy atıp meyve vermesi için ne yapmalı? Aslında, bunun için yapılabilecek pek çok şey var. İçlerinden en önemli birkaçı:
Değişim Rüzgarları
Dönüşümün Kültürel Boyutu
6 Haftada 27 Metre Büyüyen Ağaç – Bambu
Domain’lere Göre İş Yaklaşımları – Cynefin Çerçevesi
Agile yolculuğunu kolaylaştırmak ve değişimleri kalıcı kılmak için yapabileceklerinizden bazılarına yukarıda değindik. Hepimiz biliyoruz ki, değişmeden, değişim olmuyor. Şöyle düşünelim: bu süreçte ‘büyüme sancıları’ yaşamak, aslında bir şeylerin gerçekten değişmeye başladığını gösteriyor. Engellerden korkmadan, inanarak, isteyerek yola çıktığınızda zaten önünüze çıkan şeyler sizi yıldırmayacak, yoldan döndüremeyecek, size ‘engel’ olamayacak.
Bu tarz bir dönüşüme (Agile dönüşümle ilgili, Regina Martins’in şu yazısına da bakabilirsiniz), tıpkı bir fidanı ekip büyütürken olduğu gibi, hissiyatla yaklaşmak gerek. Neye ihtiyaç var? Sıradaki adım nedir? Karşımıza çıktıkça, çöze çöze, adım adım ilerliyor olmalıyız. Biliyorsunuz Agile’da kullanıma hazır, kalıp çözümler yoktur. Sihirli bir formül olmamakla beraber, şu üç temel malzeme, “Agile fidanı” için hayati önem taşır: şeffaflık, güven, ve sabır.
Unutmayın – yolun yarısında inancınızı kaybedip geri dönerseniz, neler kaybettiğinizi asla bilemezsiniz..
'%3e%3cg id='Final-Copy-2_2_' transform='translate(1275.000000, 200.000000)'%3e%3cpath class='st0' d='M7.4,12.8h6.8l3.1-11.6H7.4C4.2,1.2,1.6,3.8,1.6,7S4.2,12.8,7.4,12.8z'/%3e%3c/g%3e%3c/g%3e%3c/g%3e%3cg id='final---dec.11-2020'%3e%3cg id='_x30_208-our-toggle' transform='translate(-1275.000000, -200.000000)'%3e%3cg id='Final-Copy-2' transform='translate(1275.000000, 200.000000)'%3e%3cpath class='st1' d='M22.6,0H7.4c-3.9,0-7,3.1-7,7s3.1,7,7,7h15.2c3.9,0,7-3.1,7-7S26.4,0,22.6,0z M1.6,7c0-3.2,2.6-5.8,5.8-5.8 h9.9l-3.1,11.6H7.4C4.2,12.8,1.6,10.2,1.6,7z'/%3e%3cpath id='x' class='st2' d='M24.6,4c0.2,0.2,0.2,0.6,0,0.8l0,0L22.5,7l2.2,2.2c0.2,0.2,0.2,0.6,0,0.8c-0.2,0.2-0.6,0.2-0.8,0 l0,0l-2.2-2.2L19.5,10c-0.2,0.2-0.6,0.2-0.8,0c-0.2-0.2-0.2-0.6,0-0.8l0,0L20.8,7l-2.2-2.2c-0.2-0.2-0.2-0.6,0-0.8 c0.2-0.2,0.6-0.2,0.8,0l0,0l2.2,2.2L23.8,4C24,3.8,24.4,3.8,24.6,4z'/%3e%3cpath id='y' class='st3' d='M12.7,4.1c0.2,0.2,0.3,0.6,0.1,0.8l0,0L8.6,9.8C8.5,9.9,8.4,10,8.3,10c-0.2,0.1-0.5,0.1-0.7-0.1l0,0 L5.4,7.7c-0.2-0.2-0.2-0.6,0-0.8c0.2-0.2,0.6-0.2,0.8,0l0,0L8,8.6l3.8-4.5C12,3.9,12.4,3.9,12.7,4.1z'/%3e%3c/g%3e%3c/g%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
Your Privacy Choices