Peter’s review at Agile Scout is a point by point discussion of what he’s witnessed in the training and his insights into the methodology. It’s very interesting for experienced Agile practitioners.
“I have no crystal ball. I can’t tell the future. One thing I can see happening is this: The SAFe model is the lowest barrier to entry for scaled agile work at the current moment.”
photo by Peter Saddington
The Software Testing World Cup (STWC) is an event for testing practitioners to show off their skills and compete with other testing professionals. It brings the testing craft into the spotlight and gives the profession a competitive event on a global scale. STWC is a global event with a sportive, competitive character for the testing community.
It will consist of a continental round of testing, done online, so that all the testing professionals out there have the chance to participate.
The continental champions will be invited to the Agile Testing Days 2014 in Potsdam, Germany!
Check out the official website: www.softwaretestingworldcup.com.
Photo Project User Experience Testing by Samuel Mann, on Flickr
We are in 2014 and still someone is challenging the fact that you can’t use an Agile approach to develop embedded systems, why? What’s wrong with embedded software development? Well, there are somethings which makes it harder than needed: Dependencies with hardware releases, fixed delivery dates, inadequate software tools, limited adaptation possibility due to hardware costs… and yes, one more thing, really special: culture!
We would like to focus the keynote we are giving to Embedded Meets Agile 2014 in analyzing some example cases that include the “limitations” listed above and also give you some hints on how to solve them. Finally we will also attack the “culture” issue. This is especially important for companies which grew out of hardware development and do not have a solid culture that include software, and therefore are stuck with waterfall development process and a traditional view on professional barriers for their employees. These companies are usually the ones not understanding that the complexity for years gone away from pure hardware, and landed in integrated product development. Without more focus in increasing quality of the process and the techniques to build – especially mission critical – functionality, the cost of failure are going to be very high, as the amount of bugs exposed to the users will rise and the competition sharpens at the same time.
Updated: watch the full recording of the keynote.
Photo courtesy of Ericsson R&D Italy, used upon permission. Ericsson innovation case will be discussed at the Keynote.
agile42 has always believed that Agile is more about a change in mindset than yet-another-process-definition. Becoming Agile as an organization goes beyond focusing only on Product Development and Delivery dimensions. It permeates the whole organization.
Over the past years we have been helping many companies to successfully convert into Agile organizations and we have created from our experience the Enterprise Transition Framework™ (ETF) that leads and supports an organization through the process of becoming more Agile. The focus of ETF is to allow an organization to implement continuous improvement and to experience change in an empirically controlled way.
The ETF is not only a unique approach to enterprise continuous improvement, but also a library of reusable tools and training modules which enable an organization to evolve very rapidly in their own way. ETF practices have proven successful across a wide-range of industries. Through a scientifically validated approach the ETF enables your organization to foster a continuous improvement culture, which will allow your business strategy to succeed.
The ETF provides the right tools and methods to become Agile. Since the Enterprise Transition Framework by agile42 is fully scalable, it doesn’t matter whether you are a local or small business or a multinational corporation – it will work for every organization.
To better highlight how the ETF can help your organization we have prepared an introductory 5-minute video you can watch here or on our YouTube channel.
Find extra information on our website and please get in touch with our team if you want to know more!
Best practice, the application of a single and consistently best method, can be a useful concept.
Unfortunately I see this concept commonly applied incorrectly:
One of the problems with “Best”, in practice, is what Jerry Weinberg calls the “Label Law”. The Label Law talks about how labelling something a certain way frames and potentially limits our thinking.
In the case of Best Practice, by calling it “Best” effectively labels it as un-challengable, why would you challenge what is clearly the best?
In complex or complicated environments there often isn’t a single best practice, and by incorrectly expecting this we elevate our practice to a status of “untouchable”.
Often the appropriate response should be to apply “Good” practice (or others depending on context). Good Practice being a set of options or approaches, each of which would be effective or have context specific trade offs.
Stay mindful of the consequence of labelling, applying and even searching for “best”, as it can lead to dangerous dogmatic behaviour, which misses better alternatives and ignores changes in context.
I worked with a group who often asked “What would Apple do?”. Newsletters were redesigned, websites tweaked and graphics quality increased to near pixel perfection. The problem was the product on offer was nothing like Apple’s at all. The industry, client needs and user skill and knowledge were completely different. The end result was looking like copy cats without actually delivering on what the customers really needed, confusing many of the less experienced users with overly simple layouts and massive amounts of time and effort consumed applying what had incorrectly been considered “best” practice. All of which yielded virtually no benefits at all.
Google famously A/B tested 17 different shades of the same color of a button, to find the one that resulted in the highest conversion. At their scale of hundreds of millions of users, something like this could potentially make sense. However when you’re dealing with a few thousand clients, it’s highly unlikely that you’ll benefit from this level of optimisation.
In both of these examples there is a distinct failure to understand the difference in Context.
Understanding why something works in a specific context before applying it to our own context is very important. What works for Apple or Google won’t always work for you. Take time to understand the problem you’re trying to address before looking for solutions.
As a colleague of mine often points out “Hope is not a Strategy”.
Our environments and context are constantly changing, under the influence of many different factors. As a result what worked before won’t work in near future. Best Practice seldom lasts forever.
In order to combat this, individuals and organisations have to develop their learning and change capability. We have to learn how to learn, and practice so we become better at it. We have to practice so we become faster at it.
By continuously experimenting and evolving our systems and practices we keep the wheels turning and improve our ability to notice and respond to change.
As the saying goes, the second best time to start investing in your future is now, the best time was yesterday.
Understand that things are changing constantly, and start evolving your systems today. Use techniques like Operations Reviews, Retrospectives, Visual Management and Metrics to understand what is really happening in your organisation and how you can improve.
A common definition of Practice is “repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it.”
Somewhat ironically, it’s Best to Practice.
Practice your practices. Create and develop habits. Habits of learning. Habits of adaptation and evolution. Acquire proficiency, then continue to practice so that you maintain it.
In closing be very careful what you label as “Best Practice”. Take time to understand the context in which it is truly applicable.
Always keep an eye out for potential improvements or changes so that you can adapt your practice accordingly.
Agile is mainstream. More and more companies are adopting it on the wave of enthusiasm, either of some internal successful experiments, or just because their competitors are doing it. Unfortunately though, the cultural change that follows the adoption of Agile within an organization can’t be constrained to the IT department – Here things become tricky…
I was happy to discuss these issues in Helsinki last fall at Scan Agile 2013. Thanks to Agile Finland the full video is available on Vimeo or can be viewed here.
You can check and download the slides as well.
The largest computer magazine in Finland, Tietokone, has published a three-page feature on organisational agility based on an interview with agile42 coach and trainer Martin von Weissenberg (Tietokone, 1/2014, pp. 66–68). The article touches on agile assessments, dimensions of change, leadership and storytelling, as well as the fundamental cornerstones of structured organisational change.
“We are happy to see articles like this in mainstream computer media,” says Lasse Ziegler, managing director of agile42 Finland. “This signifies that more and more companies are becoming aware that agility should not be restricted only to the development teams, and want to take advantage of the benefits of organisational agility.”
You can buy the 1/2014 issue of Tietokone in book stores and news kiosks all across Finland during the month of February.
What I’m going to relate here is a true story. I have two kids, aged seven and four, that are veritable fountains of ideas.
For some time now they have been earning a small allowance based on keeping their rooms clean, helping in the kitchen, leaving out the Friday candy, and so forth. Sometimes the “wage negotiations” can be a little tiring, but overall it appears to work out quite nicely. Greedy little worms as they are, they are always making plans about how to spend their well-earned money… even before they’ve earned it!
I’ve tried to introduce the backlog concept (one thing at a time, in order of preference) but found that they can really only think about one thing at a time, and that thing needs to be BIG… preferably a large Lego set with a three-digit price tag. They get a lot of enjoyment out of scanning the newest Lego catalogues, anticipating the next possible purchase and changing their plans on a daily if not hourly basis. I’m somewhat nervously looking forward to the day when they’ve actually scraped together enough money and want to go to the toy store: when we walk out of there, they can’t change their minds anymore.
One morning at the breakfast table the older boy sat silent for a minute, then stated that at the current rate of saving money, they would have enough money to buy one 100 € Lego set each in December. He had figured this out by himself, and I was impressed and proud. So I decided to push the boundaries a bit and conduct a breakfast table experiment.
What if, I put to the kids, instead of saving separately and buying two sets in December, they would put their money together and buy one set already in July? Since their Legos are stored together in one box (or to be precise, two big boxes and a small box), they could build and play together. And they would still be able to buy the other set on schedule in December, perhaps one of the new sets coming later this year? I’d have to drive to the toy store twice — extra fun for the kids, and no big deal for me.
Let’s take a time-out here and rephrase the breakfast table discussion in terms of agile and lean. My son used the established velocity to forecast a date of delivery for a package consisting of two components. I counter-proposed that by splitting the batch in two, the first component could be delivered early, without any delay in the delivery of the second component, and with only a slight increase in overhead. In effect, rather than getting the full delivery on schedule they would get the first part after only half the time, and the other part still on schedule. Yay! The choice should be easy! What’s there not to like?
This thinking is not limited to theoretical discussions about toys for children; it’s also very much applicable to normal business life. Many companies however want to maximize the batch size: common wisdom (which is wrong, as we will see in a moment) says that large batches bring lower overhead, which means larger savings and lower costs.
For example, Naive Inc., a supplier of bespoke software has found that delivering software to the customer is painful and has a large overhead. There is a lot of scheduling and negotiating to be done to determine the contents of the delivery package. Then someone must collect, package and deliver the components to the offshore system testing team. If it passes, the package can be delivered to the customer who needs help deploying the software, and when they finally get it up and running, the bastards start reporting bugs and change requests that feed the next scheduling and negotiating cycle. And so, logically, the managers decide to avoid the pain and make as few releases as possible. They decide to collect all the software features into one big batch and deliver that near the end of the project.
This is a prime example of one-sided legacy thinking. Firstly, it ignores the new rules and axioms brought by the information society. Secondly, it accounts only for cost and ignores value and risk. In a fast-moving world, fresh feedback is extremely valuable. Digital information can be handled in new ways that are not immediately obvious:
What this all means is that the holding costs of software are immense, while the transaction costs can be extremely cheap. In this scenario, big batches are not economical. While collecting components for the batch you pay high holding costs, and because the transaction costs are so low anyway the economic benefit from large batches is very small. Lose-lose! Instead you should reap the benefit from low transaction costs and deliver small batches often, avoiding the holding costs in one fell swoop. Win-win!
For example, Smart Inc., another supplier of bespoke software has found that delivering software to the customer is painful and has a large overhead. Rather than avoid the pain, the managers decide to remove the root causes and invest in automating the build-and-delivery process. They start with a continuous integration system that opportunistically gets the source code and builds the product. Next, they implement a test automation system that exercises the product from the ground up to the user interface, running unit and component tests as well as scripted acceptance tests. Both systems give instant feedback to the developers.
The managers can now on a daily or weekly basis select a package for sending to the customer. This is automated using a deployment script that in minutes installs the new version and sends a brief summary of the changes to the customer. The customer feedback (change requests and bugs together) is added to the list of things to do. Because the product is known to be stable and increments are small, negotiating what should be done next becomes quick and painless.
(Both Smart Inc. and Naive Inc. are real companies, but names have been changed to protect the… uh… innocent.)
Comparing Naive Inc. to Smart Inc., it’s clear that the latter has a very short turnaround time. The developers can change from one task to another in a matter of days, and projects can be ended or canceled in a matter of weeks without losing any of the invested money. This allows Smart Inc. to react to risks and make use of opportunities. Further, Smart Inc. and their customers are very aware of the current quality level and state of the products — they know pretty well what they have right now and controlling the project is comparatively simple. Customer communications are frequent and constructive, focusing on what can be implemented next (value).
In comparison Naive Inc. has a long turnaround time, on the order of months if not years. The company does not measure what they have implemented frequently enough, and must resort to indirect metrics (bugs found, or hours spent). Controlling a project without direct information is fiendishly difficult: the risk of failure is very high, and the risk of losing invested money is also high. Customer communications focus on bugs and missing features i.e. what has not been done (cost).
Despite this, many software companies routinely choose large batches over small. There is some kind of built-in blindness that causes people to avoid looking at batch size as a project variable that can be changed.
When it comes to running a business, people are well aware of batch size and inventory costs and the importance of e.g. not carrying large risks or committing to long-term investments in a rapidly changing world. Thinking like this is not weird or unique — executives do it all the time. People accept that the business world is unpredictable, and that you need to maintain your options, hedge your bets, buy information or get insurance.
Since projects operate within the same business environment as the company itself, they are subject to the very same uncertainties, and in addition often encumbered with inherent technical complexities. The process of developing an innovative product is in fact a balancing act between trial-and-error and progress. In hindsight the product may be blindingly obvious, but never in foresight — you cannot predict what will happen, and you must let the product emerge in collaboration between engineers and end users. It’s called Research and Development for a reason.
Yet in most cases projects are not allowed to react to risks except perhaps within very narrow bounds, and not allowed to exploit opportunities at all. Pure madness. People draw up multi-year project plans fully aware that they will be hopelessly outdated after six months. People make designs and plans at the beginning of the project, at the point in time when they know the least about the product than they will ever know, then go forward blindly in the hope that reality will somehow reform itself around their plans.
So how did our breakfast discussion end? Having thought about my proposal for a moment, the kids declared that getting just one package would be unfair, and that they’ll go with the original plan and buy two sets in December. Duh.
Funnily, I can see this thinking reflected in too many companies. “We are implementing an ERP system with ten different user roles, and it would be unfair if one role got served first.” Or: “Our product must be able to capture and edit material, it would be useless without both functions.”
Business is not about fairness. It’s not about unfairness either, but there is truth in the old saying that “all is fair in love and war”. Business is about grabbing opportunities and avoiding risks. If this means being “unfair” to some potential customer or user segment, so be it. You can’t cater to everyone all the time.
Still, I hope to give my kids a proper understanding of how the digital world works. Because, as it turns out, the established institutions are not doing that yet. I owe them that.
(photo by Alan Chia, source Wikimedia Commons)
The workshop will be presented on Monday, January 27th, at the meeting of Agile Denver and on Tuesday, February 4th at Agile Austin.
Too many companies focus on maximizing output rather than outcomes. Studies show over 60% of features built in the software industry are rarely or never used. You might deliver a lot of features, but if they are rarely or never used, does it matter how fast you do it?
To deliver the right outcomes, you need to learn your customers needs and validate your assumptions as early as possible. This means getting an early version of your product completed to start testing, validating and improving. This session will demonstrate how to combine Lean Startup and User Story Mapping techniques to determine where to start and how to learn early and often.
Participants will start with a partially completed Lean Canvas to flesh out and then define a product roadmap by building a Story Map. We will use Lean Startup concepts of Minimal Viable Product (MVP) and validated learning to focus on outcome over output.
Learning objectives:
The greatest challenges to adopting Agile at scale are organisational. Therefore any scaled implementation needs careful attention to communication, culture and change management. As CIO and agile consultant Marius de Beer observes: “When you scale, you scale everything. The good and the bad.” I suggest that you accept that there is no “silver bullet” solution to doing Scrum (or any form of Agile) at scale. With this mindset I suggest you read broadly what others have done and are doing. I especially recommend the Larman and Vodde books as well as Henrik Kniberg’s papers and presentations.
If you are a novice and are serious about helping your organisation get better, find and hire an Agile coach who has a verifiable pedigree in applying Agile at the scale you need. This will shorten your learning curve and lessen the pain!
Lastly, be prepared for a multi-year journey towards organisational agility. Whilst I have seen tremendous improvements within just a few months, serious “sticky” change, especially at scale, will take a long time: think five to ten years. The good news is that it can be a lot of fun with rewards all along the way.
Conway’s Law states:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” [Conway 1968]
Conway’s Law is never more evident than in distributed teams and organisations. Teams that are not collocated experience the greatest communication challenges by definition. How teams and their communication is structured has a major impact on how well they design and execute their products. I encourage managers to defer to their team members in designing effective structures!
The following sections will give you a short overview of a few scaling approaches and my opinion of each.
Henrik Kniberg has led this approach [Kniberg 2008]. The main idea is to create a single, unified Product Backlog, form multiple Scrum-sized teams and run synchronised Sprints with a joint Sprint Goal. This means Sprint Planning and Reviews are done jointly by all teams together. Daily Scrums are done team by team. These are complemented by some means of inter-team synchronisation, often a Scrum of Scrums. Retrospectives can be done jointly, team by team or in other affinity groupings. I vary this to achieve cross-learning. Facilitation of large meetings requires good skills. I use large-group techniques and multiple facilitators.
My opinion: I have applied this pattern in many organisational units with 12 to 50+ team members working on single and multiple products, with one or multiple customers. The results have exceeded my own and my clients’ expectations.
Henrik Kniberg and Anders Ivarsson have published an interesting paper on scaling at Spotify [Kniberg & Ivarsson 2012]. These authors all have deep experience in doing Agile at scale and have extracted the essence of what works (and what does not) into useful principles and patterns.
The figure shows a snapshot of Spotify’s organisational design and language.
My opinion: The Spotify story is inspirational to many practitioners (including me) who are trying hard to build agile organisations. It is a fountain of good ideas and thinking. It is not a recipe you can apply to your situation.
At the other end of the scale Dean Leffingwell has developed the SAFe model for Agile at scale [Leffingwell 2012]. The model contains concepts that some may find useful, such as the Release Train, but also contains a lot of “process voodoo” that will not be required in most cases.
Sophisticated models such as SAFe approach the scaling problem from the perspective of providing a menu of all the possible constructs that might be needed in any conceivable scenario. The result is a confusingly complicated framework that requires an expert process practitioner (or coach) to optimise it for your specific needs. Anyone with experience of the Rational Unified Process (RUP) will recognise this.
Moreover, SAFe attempts to codify what is inherently a complex problem requiring unique and nuanced solutions that will be different for every environment. Critics will recognise this as an attempt to describe simple/complicated solutions for complex problems (see our earlier article on the Cynefin framework for an understanding of complexity). On the other hand supporters claim that SAFe enables them to begin conversations with conservative PMO managers who were previously unwilling to discuss Agile methods.
My opinion: SAFe offers an appealing diagram for those who still believe that problems of project management are solvable by applying sufficient process and governance. I think SAFe heightens the risk of just applying “lipstick to the pig” and not dealing with the fundamental changes that are required in every organisation I have worked with.
The formal definition of DAD from its authors is: “The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.” [Ambler and Lines 2012]
DAD describes a “full agile delivery lifecycle” as comprising three phases: Inception, Construction and Transition. This is derived from the RUP. The DAD description goes on to describe three lifecycle variants: the “Agile/Basic DAD Lifecycle: Extending Scrum”, the “Advanced/Lean DAD Lifecycle” and the “Continuous Delivery DAD Lifecycle”. DAD’s authors appear to have repackaged Scrum and elements of Kanban.
DAD also adds more roles, both within the team (notably an Architect role), defining five primary and five secondary roles, as shown in the figure reproduced from the DAD web site.
My opinion: Scott Ambler has many useful things to say about Agile methods and practices. Nevertheless I find the DAD description less practical and helpful than starting with either Scrum or Kanban and iterating towards a better set of processes for your teams and organisation.
Craig Larman and Bas Vodde have both been working with Agile methods at larger scale and for longer than most other practitioners. They have resisted the temptation to derive a one-size-fits-all set of practices. What they have done is to document tools and practices that they have applied in different situations as a guide to what you might try and what you might wish to avoid.
The output of their work is named LeSS, an initialism for “Large Scale Scrum”. These have been documented comprehensively in two books: “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum” [Larman and Vodde 2008] and “Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum” [Larman and Vodde 2010].
The figure below shows the LeSS model for scaling up to ten teams or 100 people. LeSS contains a corresponding model for scaling to hundreds of teams and thousands of people.
Larman warns that organisational change is hard and that it is best to start with changing structure. He states the following “laws” from his observation of organisations over decades [Larman 2013]:
Ouch! The truth hurts.
My opinion: I like Larman and Vodde’s approach to this topic. I suggest you study their books carefully and try some experiments. Watch for more from them.
A helpful aphorism to bear in mind is “scale principles not practices”.
I offer below some principles and related practices I have drawn from Don Reinertsen’s Principles of Product Development Flow [Reinertsen 2009], from Larman and Vodde’s books, from conversations with other agile coaches, and from my own experiences with applying Scrum at scale with my own consulting clients during the past eight years. Understand that this is only scratching the surface of what it means to apply Agile at scale.
Minimise cross-dependency between teams, so
Form feature teams rather than component teams, and
Ensure each team is cross-functional.
Stick to the “right” team size, no matter what, so
Merge multiple products into one backlog feeding a single team, or
Let a single backlog feed multiple teams.
Reduce skill silos and dependencies within teams, so
Grow T-shaped people
Employ small batches to reduce cycle time, reduce variability and increase efficiency, so
Avoid large work items in Sprints, and
Use a regular cadence for all Sprint meetings.
Shorten queuing times for the waiting work, so
Feed multiple, synchronised teams from a single backlog.
Exploit scale economies of multiple teams, so
Synchronise sprints for multiple teams.
Retain slack to achieve flow, so
Allow teams to pull from the backlog, based on their observed capacity, and
Challenge teams to finish early as least as often as they finish late.
Keep feedback loops short, so
Ensure all teams’ outputs are tested and integrated into the Increment every Sprint, and
Work to eliminate constructs like “integration” or “hardening” sprints.
Optimise the whole, so
Measure outcomes at the highest possible level, and
Let teams seek on their own local solutions.
Pay attention to quality, so
Ensure “technical debt” is reducing, not increasing, and
Fix errors as soon as they are found.
Pay attention to communication, so
Institute formal meetings to synchronise teams.
Pay attention to learning, so
Form communities of practice for different disciplines to share learning, and
Hold large group retrospectives on a longer cadence (e.g. for releases).
Ambler, Scott M. and Lines, Mark (2012). Disciplined Agile Delivery: A Practitioners’ Guide to Agile Software Delivery in the Enterprise. IBM Press.
Kniberg, Henrik (2008). Multi-Team Sprint Planning. http://www.scrumalliance.org/system/resource_files/0000/0871/Multi-Team-Sprint-Planning.pdf.
Kniberg, Henrik and Ivarsson, Anders (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.
Larman, Craig and Vodde, Bas (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional.
Larman, Craig and Vodde, Bas (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional.
Larman, Craig (2013). Larman’s Laws of Organizational Behavior. http://www.craiglarman.com/wiki/index.php?title=Larman’s_Laws_of_Organizational_Behavior
Leffingwell, Dean (2013). Scaled Agile Framework. http://scaledagileframework.com/.
Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
'%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