As you're getting situated, please join in a moment of centering silence so we can be fully present with each other this morning. And for some more centering, as a group, let's turn to the words for our in-gathering hymn, which you'll find inside your order of service. Well, that was fun at 9 o'clock, and it's fun now to sing that song. Thank you, everybody. Good morning, and welcome to the March 1 service here at First Unitarian Society. It's March 1, or as we call it in my home, the month of the month. And here we are at First Unitarian Society, where independent thinkers gather in a safe, nurturing environment to explore issues of social, spiritual, and ethical significance as we try to make a difference in this world. I'm Steve Goldberg, a proud, pledging member of this congregation. And I'd like to extend a special welcome to two groups today. One is the group of people who are watching this at home. Hello. And also to any newcomers, guests, and visitors, if this is your first time at First Unitarian Society, you'll find, as many of us have, that this is indeed a very special place. And if you would like to learn more about our very special buildings, we offer very special guided tours after every service. Just gather over here by the windows, and we will take care of you after the service. But during the service, this would be a perfect time to silence all those pesky electronic devices that might interfere with your ability to really enjoy the service. So please take a moment and perform that simple but essential task right now, if you haven't already done so. Thank you. If you are accompanied today by a youngster, and that youngster would prefer to enjoy the service from a more private place, we offer two alternatives. One is our child haven at the back corner of the auditorium, and the other is some comfortable seating out in the lobby, or as we call it, the commons, from which you and your youngster can hear and see the service. This is the case every weekend. Our service is brought to us by a dedicated team of folks whom we call volunteers, and their names deserve to be read out loud so that you can thank them a little bit later. Operating the sound system so that you can hear everything clearly is Mark Schultz. Our lay minister today is Ann Smiley. Today, unlike any other day, we have five ushers, five to handle this unruly crowd. Okay, now you're supposed to hold your applause till the very end of the service. As I said, it's an unruly crowd, so it's a good thing we have five ushers, and they are Melinda Carr, Jennifer Boullet, Bob Bozeki, Stan Inhorn, and Shirley Inhorn, and Stan wants to announce that even though he's officially an usher, Shirley is doing all of the work for him. Our hospitality and coffee are provided by Rick DeVita and his daughter Elena Marie DeVita. The flowers that you see behind me were lovingly donated by Chuck Stonesifer in memory of his late wife Janet, and in honor of their grandson Leonardo. I'd like to meet Leonardo someday. And our tour guide after the service is Mark Hill. Three announcements. One is that if you're interested in attending the spring retreat, the adult spring retreat with Michael and Trina Shuler, they are hosting it April 10th through 12th at Green Lake, very popular event, and you have a chance to register now. The early bird registration fee is good until March 8th. Again, it's being held at the Green Lake Pilgrim Center April 10th through 12th hosted by Michael and Trina. This announcement, and you'll hear more about this a little bit later in the service. As many of you know, the FUS annual pledge campaign is starting right now, and if you make your pledge by midnight tonight, guess what you're eligible for? You're eligible for a drawing for a $100 gift certificate at Lombardino's restaurant here in Madison. So if you haven't brought your pledge form with you, fret not, there is an ample supply at the main table in the commons during the break. So please pick one up, register your pledge by midnight tonight, and you become eligible not only for a $100 gift certificate to Lombardino's, but freedom from further solicitations, mailings, and calls.  The last announcement concerns the number 54. There are 54 days left until what? Cabaret. Yes. This is the only organization in the world where cabaret is not only a noun, it is also a verb, because we know how to cabaret at the First Unitarian Society. April 24th, Friday evening, 54 days from now, this entire place is going to be converted into one huge cabaret. It's going to be a nonstop talent cavalcade, this stage being the primary venue for talent. Dan Broner and some others are putting together the entertainment for us right now. There's going to be a new menu, including both healthy and unhealthy food. That should draw some more people, right? It's a party, and it's the kind of thing where when you drive home from cabaret April 24th, you're going to be saying to yourself. That was the most fun I have had in a long, long time. They should do this more than once a year. So come and see why my kids still refer to FUS as the Cabaret Church. April 24th, Friday evening, please put it on your calendar. More details available later. And speaking of later, please sit back or lean forward to enjoy this morning's service. I know you will find that it will touch your heart. Hear your spirit and trigger one or two new thoughts.  To take up masks. To put on brave fronts. Silence the voices that ask you to be perfect. This is a community of compassion and welcoming. You do not have to be anything to earn the love contained within these walls. You do not have to be braver, smarter, stronger, better than you are in this moment to belong here with us. You only have to bring the gift of your body, no matter how able, your seeking mind, no matter how busy, your animal heart, no matter how broken. Bring all that you are and all that you love to this hour together. Please rise now and body your own spirit for our chalice lighting. And join me in unison in the words printed in your order of service. Does the match love the wick? Does the wick love the wax or the air it consumes? Yes, without question. To melt together, to burn together, to change together, the pieces of the candle must love each other, though not necessarily wisely and not necessarily well. And now I invite you to please turn and greet your neighbors. I would like to invite the children to come on up for the message for all ages. There you are. I knew that there were more of you. Come on up. Take a seat. So I have what I hope is going to be kind of a fun story for you today. I'm hoping that you'll all be able to help me tell this story this time. Anywhere you like. So later today, the adults and I are going to be talking a little bit about a word that maybe you've heard before called acceptance.  And that's OK if you haven't. You've heard it before? Yeah. So some people have heard the word acceptance before. Do you know what that word means? Any ideas? No. You don't know what it means. So I'm going to tell you a story real quick that talks a little bit about when I had to experience acceptance in my life. And then I'm going to tell a story and you're going to help me tell it that we'll look at that a little bit more deeply, OK? So when I was about your age, I was sometimes made fun of. People sometimes made fun of my hair and they made fun of my clothing. They made fun of the way I talked and the things that I like to play with and called me names that were not very nice. And I really didn't feel very good. And I'm wondering if any of you have ever been teased or bullied like that. Can you raise your hand if you have? Yeah. And how about the adults? Why don't you look out there? Has anybody out there ever been teased or bullied? Yeah, look at all of them, see? So maybe you've had to do something then that I've had to do, which was when I was being teased as a child, I had to learn to accept myself. I had to learn that I am still a good person no matter what other people say about me. And I had to learn that I'm worthwhile and that maybe the things that people are making fun of me for are actually good things that I don't deserve to be made fun of because of them. So the story that we're gonna tell a little bit together is a story about that and it's called Weird by Aaron Frankel, which I've adapted today. And the way that I would like you to participate is every time I go like this, I want you to say weird as though maybe it's something that you don't like or that you find a little strange. So let's try that real quick and yeah, you can make faces and yeah, that's good. So let's try real quick. I'm gonna put my hands out and we're gonna say it all together. So weird. Very good, let's try it one more time. Weird, good job. Okay, so my name is Louisa and I have a problem. There was a girl in my class named Sam who thinks everything I do is weird. I raise my hand to answer a question in math and she says I'm weird. I guess I'll keep my answers to myself. I try to tell a funny joke at lunch and she says I guess I'll just be quiet. I give my mom a kiss when she picks me up from school and Sam says I'm maybe mom can wait for me in the car. I say something in Spanish to my dad. Hola papa and she says, guess it's hi dad from now on. I wear my favorite pink sparkly scarf. Guess I won't wear it again. It's strange, I keep changing what I do but she doesn't change at all. It's like weird is the only word she knows and I don't know any words. I don't even feel like myself anymore. Everyone misses the way I used to be, everyone including me. Mom wants to know what's the matter, dad wants to know if everything is all right. My friends say they miss my funny jokes and wonder where my sparkly pink scarf went. But Sam just says, who should I talk to? What should I say? What did I do to deserve this? I wish it would all just go away. Should I maybe talk to my mom? What do you think? When I tell my mom that I have a problem that there's this girl at school who is so mean to me, she says it's not your fault, Luisa. You are wonderful just the way you are. After talking to my mom, I've been thinking that maybe it's time for another change. I think I'm gonna wear that scarf all the time. Only this time before Sam could say anything, I said, boy, does it feel good to wear this again. I told another funny joke at lunch and laughed along with my friends. When she said, I kept on laughing. I didn't hide my feelings when I got the right answer in math either. I told my dad I loved him in Spanish. I let my mom know how happy I was to see her when she picked me up from school. I even said, see you later, Sam. I discovered something really amazing.  And the more I, that she thinks I don't care, the more she leaves me alone. Now that's really thank you for helping tell the story today. And now we're going to sing you out to your classes with number 346. Have a good class. Bye. First reading today should hopefully be a little bit familiar to some of you. It's from the reflection that Michael offered a couple of weeks ago on Lincoln and Charity and is very relevant to my reflection today. Talking about the essence of charity, Michael said, it's about more than doing nice things for people on occasion or contributing to a few causes with which we sympathize. Our English word for charity comes from the Latin karus, which means deer. The noun form karitas translates as charity and appears numerous times in the Latin Bible. But karitas and charity are themselves translations of the Greek word agape, which the New Testament writers used to denote a sacrificial kind of love that can be transformative. According to the apostle John of all the gifts of the spirit, agape is the one that Christians should be the most eager to obtain. And now faith, hope and love abide. These three, and the greatest of these is love, Paul tells the Corinthians. Agape describes God's love for humans and God expects humans to show the same kind of consideration to each other. More recent additions of the English language Bible have struck the word charity and replaced it with love. Good arguments can be made for either choice, but the problem with love is that the English word lacks the precision of the Greek language in which the New Testament was originally composed. Love for the Greeks could mean Eros, the passionate carnal or romantic love that we celebrate on Valentine's Day. Eros is never mentioned in the Greek New Testament. Philea, the love that binds siblings or close friends together is cited on occasion. Philea exists between kindred spirits, but it excludes strangers or more casual acquaintances. Agape differs from both Eros and Philea because it is indiscriminate and disinterested. Agape rejects no one and expects nothing. If you love those who love you, what merit is there in that? Jesus asks his followers in the Gospel of Luke. After all, even sinners love those who love them. And if you do good to those who love you, who do good to you, what merit is there in that? After all, even sinners do as much. If you lend those from whom you hope to gain, what merit is there in that? Even sinners lend to sinners in order to get much in return. But I say, love your enemies and do good and lend without thought for yourself. That way you'll be children of the most high, who is generous to the ungrateful and the wicked. This second very brief reading is from Lila Gandhi's book, Effective Communities. Lila Gandhi is the great-granddaughter of Mahatma Gandhi. Friendship Aristotle writes seems to be the bond that holds communities together and lawgivers seem to attach more importance to it than to justice. This nativist conception of friendship developed in historic conditions of extreme vulnerability for the minuscule Greek city-state borrows heavily, if wishfully, from the sparse vocabulary of affiliation, which makes claims such as, a friend is another self, the basis of affection is equality and similarity, like is a friend to like, and so on. We need another model of the political, independent from the burdensome language of naturalness, sameness, and origin. For the moment we need not stray beyond the confines of post-socratic philosophy. For the Aristotelian model of Philia, with which we are quarreling, finds its most immediate challenge in the fragments of Epicurus and his followers, in which friendship is construed very differently as Philizania or love for guests, strangers, and foreigners. And in sharp contrast to Aristotle, this ethic of fidelity to strange friends is predicated upon a principled distaste for the racial exclusivity of the polis. Derrida's notes on ethics as hospitality are opposite here. The stranger, here the awaited guest, is not only someone to whom you say come, but enter. Come in. Come inside me. Come within me. Not only toward me, but within me. Occupy me. Take place in me. Song, thank you for your lovely song. You've lied at all of the day, but tell me, tiny songbird, learn some of the games we play for your hymn to joy. Listen, and you change this life for me. For in your song, I see a more gentle ne'er face. I see, look, I never count the lovely songs you sung. If you ever have to fly, Unitarian Universalists have had many names over the course of our history. Some we gave ourselves, others were given to us. We've been called Ariomaniacs, the name given to the proto-Unitarian followers of that great heretic Arius around the time of the Council of Nicaea. We've been called Puritans. We've been Congregationalists, Unitarians, Universalists, ultra-universalists, Restorationists, the love people. That's right, I said it, the love people. Mind you, we're not exactly knowing all over the world and certainly not all over the association as the love people, but that's what some local activists in Phoenix, in Phoenix, Arizona, started calling us. They saw us wearing these bright yellow shirts with love emblazoned on the chest for standing on the side of love at these protests and actions in rallies, right? And so they dubbed us the love people. Mind you, they also dubbed us the yellow shirts, which doesn't have quite the same ring, but the love people. Wow, did it feel good to be called that? The love people. How's that for a statement of religious identity? What religion are you? No, I'm with the love people. Now, when I give people my elevator speech, the one where you explain in the time that it takes to write in an elevator to someone who has never heard of Unitarian Universalism, what UUism is, I always try to make sure to drop something about love in there. It works much better than trying to explain that we're a post-Christian quasi-syncretistic faith or that we're the most protesting of the Protestants or the reformation that keeps on reforming. Yet folks new to Unitarian Universalism might be somewhat confused by a name like the love people if, say, our seven principles are all that they know about us. Have you ever noticed that not one of the principles actually mentions the word love? Ain't in there. There's a whole bunch of things that are necessary to love, like, you know, respect. There's compassion and acceptance, but no love. Respect, compassion, and acceptance are important, of course. I don't think that love can exist without them. In fact, if anyone ever tells you that they love you and yet does not show you compassion or acceptance, I tell you that is not love. Yet as important as respect, acceptance, and compassion are to love, they're not quite the same as love. I don't know if any of you or your kids have had the great fortune to have gone through our whole lives, the Lifespan Human Sexuality Program jointly created by the UUA and UCC. I know that we do a slightly different version of the program here that's a little bit broader. I still remember the riddle scale taught in my own young adult owl class. The scale is used to rank different degrees of discriminatory and anti-discriminatory attitudes, that the very, very bottom of the scale is repulsion, and at the top is nurturance. Acceptance lands somewhere about halfway up the scale, right above tolerance. According to this scale, when we accept one another, we imply that there is still something that needs acceptance, even if it is not something that we're trying to change about the other person. On Facebook the other day, I witnessed one friend saying to another, you are stubborn and close-minded, but I love you.  To which the other guy responded, you're a jerk, bro, but I love you too. Now I know these two guys and I know that they really do love one another really, but despite their words about love, this is not a demonstration of their love, only of their acceptance of one another, their willingness to overlook one another's flaws as they perceive them for the sake of their friendship. Acceptance at its best is a recognition that another human being is a whole person, a being of strengths, weaknesses, and infinite value. It is about respecting a person for who they are and making a real effort to understand where they're coming from, even if you don't like it or you disagree. In the children's story today, Sam needed to learn to accept Luisa. She did not need to like Luisa's scarf or language or even to like Luisa. She just needed to stop holding those things against her, to stop bullying Luisa, yes, but also to stop trying to change her. Now I'm not saying that acceptance is incompatible with love or that it cannot be a very, very good thing. I hope, I truly hope, that we all know what it feels like to be accepted. It is incredibly healing sometimes to know that you do not have to be perfect, that you are needed, that you are enough, that you are beautiful, flaws, and all. It is wonderful to be in a space among people where you can be your full self without fear, where you don't have to check yourself at the door. God, that feels so good. At the same time, sometimes mere acceptance can wrinkle. Acceptance carries a tone of judgment with it, a tone that can be rather annoying sometimes or even hurtful if a person doing the judging then tries to claim the moral high ground by claiming to love you anyway. You're overweight, but I love you anyway and wouldn't change anything about you.   These are not flaws to be overlooked. And yet when a person makes statements about you, like the ones I just shared, it can put you in a position where it feels difficult or even petty to take issue with what they've said because in a sense they've taken the topic off the table of discussion. Their unfair judgment of you is framed in a way to make it seem on the surface at least, loving and kind and beyond reproach, perhaps even virtuous. You may feel forced to accept their judgment to not argue back or defend yourself. Mere acceptance then can be loving and healing, but it can also be hurtful and can shut down rather than open up conversation. On that riddle scale I mentioned earlier, there are four steps above mere acceptance. There's support and admiration and appreciation and then nurturance. When we support someone, we may still be judgmental, but we at least strive not to act on our prejudice and we do what we can to create a safe and welcoming space for people to be themselves without fear of judgment. Even the passive aggressive kind of judgment we can sometimes get with mere acceptance. When we move from support to admiration, we reach a place where we may still sometimes be uncomfortable or judgmental about another person, but we recognize and admire the strength that it takes in order to be oneself in a judgmental and often an oppressive society. And we are willing to examine our own judgmental attitudes and prejudices. After admiration comes appreciation, a person at this point recognizes, intellectually at least, that other ways of being are valid and valuable and learn to appreciate difference. Though they may sometimes catch themselves being judgmental, they actively work to dismantle their prejudices and those of others. And finally there's nurturance. When we nurture others, we celebrate and support and help them grow in their differences and recognize that those differences are vitally, vitally needed in the world, in our society, and in our congregation. We can move beyond acceptance to support, admiration, appreciation, and nurturance. And I think we can even move beyond nurturance to that four letter word that we so love. Love. No, not only can we move beyond acceptance and nurturance, but we are called to walk that path, to truly become the love people. Now I don't mean to imply that UU congregations are loveless places or that our faith is a loveless faith if our seven principles fail to mention the word love. Even if we sometimes fail to live up to our desire to be radically welcoming communities, we still strive to be beloved communities. Take this congregation. Since 1879 in our continuing bond of union, we have pledged to accept into membership those of whatever theological opinion who wish to unite with us in the promotion of truth, righteousness, reverence, and charity among all. Charity as our earlier reading from Michael's recent sermon reminds us is love. This congregation does not unite for acceptance among all, but charity among all. Love among all. And throughout the UUA, many congregations covenant together using El Griswold Williams words, beginning, love is the doctrine of this church. No, we are not loveless places we UU congregations. We talk about love all the time. It may not be a word that appears in our seven principles, but it's all over the place in other parts of UU religious life. It's in our second and fourth sources where we refer to the transforming power of love and the call to respond to God's love by loving our neighbors as ourselves. And it is in our hymns. We sing after the message for all ages today about bringing a song of love and a rose in the wintertime. And in our hymnals, there are many others, so many others. But most of all, it is in the way that we treat one another time and time again. Yes, there are congregations that fall short sometimes. Congregations are made up of people and people sometimes make mistakes. But I have heard so many, so many people testify to the loving care that they have been shown by their congregations who make them feel held and needed and welcome. Who nurture them as people and want them to flourish, to have life and to have it more abundantly. Who see their differences as beautiful, as strengths, as vitally necessary to the wellbeing of our congregations and our society. Who celebrate and nurture and love their differences, love every part of who they are. In those times, we are the love people. But what kind of love is this? When I talk about love, I'm not talking about romantic love or the kind of love that a parent has for a child. And I'm not talking about the kind of love that a friend has for another friend, the kind of love based on shared interests or shared traits that Lila Gandhi was criticizing in that excerpt from effective communities that we heard earlier. The kind of love I'm talking about has nothing to do with what you feel or do not feel. It is not warm fuzzies or burning passion or tender care, but a commitment to act for the wellbeing of others. Love in action. It's the kind of love that is freely and abundantly given without the expectation that anything will be given in return. It is unattached and unconditional, like charity or karytas in Christianity, agape in Greek thought, has said in Judaism and Dona in Hinduism, Buddhism and Jainism. The love I'm talking about is the kind of love that Lila Gandhi pointed us toward in the earlier reading. The love that not only welcomes the stranger, not only invites the stranger into our community, but invites them into our very selves, invites them to not only become a part of us, but to change us. How's that for spiritual growth?  How can a person possibly go through anything so marvelous, so magnificent, and remain unchanged? Have you ever felt love like that? Love that cracks you open so that others can reach down deep inside you, bringing forth a whole other person that you never even knew could possibly exist? That kind of love rushes in when we allow ourselves to be vulnerable around one another, to risk the possibility of judgment, to reveal our full selves, to risk being hurt. And more than that, it requires us to accept change. Change can be scary, letting people in inevitably changes us without anyone intending to change anyone else. That's the paradox of love. We love one another as we are. Without expectation of change and without expecting anything at all in return. And yet, by so loving and so being loved, we are healed, we are nurtured, we become whole, and in so doing, we are transformed. That's the kind of love that we are called to share with one another and the world. That's the kind of love that can help move us beyond mere acceptance. That's the kind of love that can help transform us into a whole new people. I love people. And now I invite you to share in this morning's offering. Today's outreach offering will be shared 50-50 with Whiskers. Knowing the important bond that exists between a pet and its owner, the organization's mission is to provide free veterinary care to the animals of homeless individuals or others who are unable to pay for needed care. Please give generously. Good morning, everyone. My name is Karen Timberlake, and I am one of three co-chairs for this year's annual campaign that you heard Steve allude to a little bit at the opening of the service. And I appreciate having a chance to take just a couple of minutes to talk with you about what First Unitarian Society has meant to me and to my family. And I also wanna start by saying thank you to those of you who have already made a pledge and for others, I'd invite you to just think with me for a minute about what it can mean to make a pledge of financial support to this important community. Our campaign theme this year is investing in the power of us all. When we give, we change lives. And ever since I was asked to help with this role, I have been reflecting a little bit on how my life has been changed and how the life of my family has been changed over the now 20 years that my husband and I have been members. And here are just a few examples. First Unitarian Society has been a consistent source of both intellectual and spiritual challenge for us. That was true when we were putting together our wedding ceremony with Michael Shuler 20 years ago. And it was true today. Just think about the message that Sasha shared and all of the thoughts that I'm sure it has triggered. We find as a family now that many of our favorite rituals and traditions have their roots here. Our children shop with us every year as part of the family to family Christmas. We connect with friends through the indispensable ritual of the second Saturday potluck. I am a Saturday person and invite you, if you've ever thought about checking out Saturday, the second Saturday of the month is a great time to come join us. We have adapted one of the chalice lightings that we learned here as a table grace and we've taught it to our extended families. And that's meaningful to us because neither my husband nor myself was raised Unitarian and so it's been nice to share a bit of this tradition with our extended families. And it's the chalice lighting that ends. We kindle this light in celebration of the life that we share. And that's really the essence of it for us. This is a place that fuels and strengthens the life that we share together. We find that First Unitarian Society grounds us is a source of peace and hope and rejuvenation and is a touchstone for us as a couple and as a family. So we make a pledge every year because we derive immeasurable value from this community. To paraphrase the lovely song from the musical Wicked that gets performed here every now and then, I know that by being a part of First Unitarian Society our lives are changed for the better and our lives are changed for good. And I know that our experience is shared by many of you. For many of us pledging is an expression of how we feel about this place. It's an expression of our love for each other and for this community to Sasha's message of this morning. We find that the services, the music, the religious education programs, the community outreach, the social justice have changed our lives and we want to be a part of supporting First Unitarian Society in changing the lives of others and in really being that force for good that we seek to be in the world and that we talk about at the beginning of services. Others of us may come to the pledging decision perhaps more from a place of math and facts and logic and that's okay, we have that for you too. In this lovely brochure that you'll see out in the lobby on the inside will be all of the charts and graphs and numbers you could possibly want to know where the money comes from, where it goes, what it's used for, how important it is. Let me pick out just one fact to share with you that resonated with me. Two thirds of the church's operating budget comes from pledge revenue, two thirds. So we in the congregation, whether we are longtime members, new members, affiliates, friends, people who drop in now and then, all of us, we represent the financial foundation on which everything that you love and value about this place is built. If we want more, more classes, more music, more programs, more work on racial equity, more community outreach, the source of more is us. And even if we want to stay the course, the source of stay the course is us and it is those annual pledges that we make every year. So for you, maybe pledging is about a deep commitment and love for this place. Maybe it's about facts and math and logic, maybe it's both, it doesn't matter. The important takeaway for me is that we all are co-creators with the staff and with each other in the life of this place. As much as I love the musical Wicked and that song, this is not theater. We are not an audience waiting to be entertained. We are participants in this place and we have to invest. We have to invest our time, our ideas, our money in order to share in the community that is First Unitarian Society. So during this year's campaign, if you haven't yet made a decision to pledge, please take a few minutes to reflect on all of the ways that your life and the lives of those you care about have been touched by being a part of First Unitarian Society. Think about how your life has been changed and how you've seen the lives of others be changed. And please consider what you might be willing to give to support and sustain this important community because together we really do change lives for the better and for good. Thank you. May we leave this place seeking an uncharted and freely chosen way to wholeness knowing we have companions along the way. Amen, blessed be, go in peace and please remain seated for the postlude. What the world needs now is love, sweet love. It's the only thing that there's just too little love. What the world, not just for some, but forever. We don't need another mountain. There are mountains and hillsides enough to climb. There are oceans and rivers enough to cross. Enough to last till the end of time.  What the world, not just for some, but need another meadow. Worn fields and wheat fields enough to grow. There are sunbeams and moonbeams enough to shine.  Not just for some, but forever.


So, let's start. Welcome everybody, hope you all had well-earned coffee and are ready for the last day of DrupalCon. What we're gonna try here is a bit something new that we've never tried before in a DrupalCon and we're gonna see, so you're all part of an experiment, yay. What we're trying to do is, like Reddit-style AMA, or ask me anything, so for people who know we're just gonna do the same thing in real life. So, what we felt as one, I'm one of the content team members and we discussed about okay, we wanna have project management in or we wanna talk about more beside of the code, how do we do things? How do we run companies? How do we do a lot of things? And we feel a bit that there is not a lot of discussion going around how to organize a team, how to structure, how to handle specific situations and we felt okay, instead of just doing buffs where we talk about that, let's try to do an ask session. So, this should be it and we're gonna try how this works. So, basically, it's about we found some really great minds that are sitting over there really far away from me and they all have rather bigger Drupal shops in Europe and what we felt is a lot of smaller ones or other ones, they wanna know how you do things. Everybody wants to grow, everybody wants to try out new things, like which tools are you using and that's your chance to ask these people without haunting them down at their booths to ask them and the idea is really that it should be a discussion about how do we do things. So, if you have an additional question, raise your hand or walk up to the microphone, I can also repeat questions so there's no more walking around all the time and stuff like that. So, I'm Michael or people call me Schnitzel but more and more important are the three answers people that we have and I would like them to introduce themselves shortly who they are, who they work for and just a little bit about their company. All right, so me first. Hi, my name's Mike King. I'm the project manager with Anatec. We're based in Ireland. We're a reasonably small team of 10. So, for an agency point of view, we're agile, definitely. We focus quite a lot on the charity and public sector. From Amazing Labs based out of Zurich. I'm a project manager and we are a team of around 20 people in Zurich all over and I would say project management is a bit larger, defined at Amazing Labs so I'm helping in pictures. I'm doing business analysis for the client and handling the project. Good morning, I'm Steve Parks. I'm from Wunderkraut or Wunder as we know in the UK. We're in the beanbag business. So that's where our focus is comfy seating around Drupal Cons for all. But when we're not doing that, we run large scale projects, agile of course, methodology, scrum generally. Sometimes Kanban on particular areas and mostly Drupal. Cool, so does anybody already have a question to our people? Okay, no, that's perfectly fine, we're gonna come. And so I have one and what I would like to know is how much do you actually explain your clients about Drupal as a community? So for us talking about what we do for the community, is that maybe the question what we do in the community? I think more it's about, do you even explain them about the open source part, about the community that all these people exist? Yes, so I think first it's very important to explain the open source idea and the advantages of open source and the idea behind it, it's still not in everyone's head. And we strongly believe it's a selling point and it works really fine. And when I know this, it's also really important to talk about what you do in the community. And a lot of our clients really ask for that actively, say, hey, can you please prove what you do for the community? And as we are very involved, it helps us a lot. And I think also we get a lot of leads out of people that know us from the community. They know our names and they know our Drupal names. It's like, oh, I know this schnitzel work is working for amazing lab. So who is that? Can I meet this person? So yes, definitely talking about the community and talking about how Drupal works is very important. Thank you. Go for it, Steve. We actually include it from the very beginning in proposals. It depends, of course, whether that's appropriate but most of the time when it's a Drupal project, we're including in our proposals at the very beginning an explanation of the community are part in that and why that's a benefit for the client. And then we try and actively get them involved in the community. So we actually have clients here at DrupalCon but we also involve them in DrupalCamps and other events that are going on. But also trying to encourage their team members if they have internal teams to contribute as well and to either release some of the code back to community or to work on core issues and so on like that. So, yeah, we try and encourage, we educate and encourage a lot of community involvement. Thank you. As I'm going last, I can mainly reiterate what the others have said but I can also add that we identify specifically to all of our clients that we're coming to DrupalCon that as a business, we see this as a really important thing. So from a community perspective, yes, we absolutely encourage everybody to come and also promote that to our clients. Obviously, it means for a bit of an odd support system for a week but people seem to understand and they appreciate that. So, also I wanted to add something like thumbs up bringing your clients to a DrupalCon. So it's great team building event and last year I presented together with a client and we had great parties together and of course it helps. How does it help to make the client happy? Cool, does anybody has a, or maybe a question to the room, who of you thinks about the same? So do you all present or explain your clients what the Drupal community is or is there maybe somebody that says, okay, we didn't try that yet? Okay, maybe it's way too early for you but. Okay, one of the next question is how do you charge then that? So do you actually, let's say you work on a module and it has a patch that is broken and you fix it and is it then part of the bill or do you exclude that from actually charging to the client because he says, well, I'm not paying for the box that somebody else built and now you're fixing it. How do you, how do you handle maybe the discussions around that? Okay. Or do they don't even exist maybe? I think it's sometimes the discussions exist, sometimes people are made aware of that. It depends on their knowledge and their desire to be involved in that process. So if they're aware of modules and they're aware of the whole Drupal infrastructure, then maybe they will be aware that there are bugs and we tell them that there's a bug in a module and that we'll be fixing it and it will be fed back to the community. But a bit like Steve said, we include this in our responses and our tenders that code will go back if it's appropriate to do so. So I suppose it's being inclusive but sometimes people don't mind or don't care whether or not it happens but it's only appropriate code that will ever get pushed back. One of the things that's worth pointing out in discussions with client is that if they don't want to pay for that kind of work then perhaps they should just have a proprietary CMS with a license and full account for a million pounds a year. They're getting Drupal for free and a part of the price of that is some level of contribution to it and being part of that community. So there's a bit of an education process there around look at what you're getting and this is what you have to give for that and look really in the scheme of things how cheap that is. Yeah, for us sometimes we find solutions like 50-50 like sometimes we have the feeling it's harder for us to charge for really everything we do and sometimes we try really to go the extra mile. Like even if the client says or even if it would be really easy to do it only for the client we'd go the extra mile and do it for the client and then release it as a patch. So we actually actively approach the client and say to him or her, look we have this problem and if you would be ready to contribute to the community it would be great and we could find maybe an agreement. So we're not that maybe not that far as you are. We do also have sorry just the community time we have members of staff each week have community time so that also goes back and obviously isn't chargeable to the clients. Yeah but it's one of the things I think this is an interesting discussion because it's how do we make Drupal businesses sustainable and how do we make them grow and it's in the client's best interest that those two things happen. The clients do not want a situation where they hire a Drupal agency and it goes bust after a year. They don't want the situation either where the people running the Drupal agency are so crazily busy running around like mad doing crazy busy work rather than a focused clear plan and so therefore that's in their interests and it's also in the Drupal businesses interests and therefore it's really important that work that is done for the client is built for in my view and that includes part of the community work because if that's for their project and they need that but it can also be shared back to the community that's still for their project and you know what your clients build for everything they do. You know if your client is a big washing powder manufacturer or something then you go into the supermarket and say well actually if I buy that washing powder I don't really want to pay for that bit because it's the same as the other washing hands and you can't just say that they will charge you for that box of washing powder. So client businesses understand this and that's their language so we have to charge what we do. So the way we charge is I'm talking about the UK office mainly here around the Wondercraft Group we experiment in different ways each office has a lot of freedom to experiment with ways of working and the UK are approaches that we build for sprints and we say that these people are in the sprint for a certain period of time and therefore the cost of a sprint is this. Now within that time there is stuff that is directly on the project but there's also stuff that benefits the project but is for the community and that's still important for the success of the project so that does get built for me. Actually that maybe leads to the next question. Do you have a question in the audience? Oh, yes. Yay, thank you. So to repeat the question for the recording so how do you do the time logging and also if an employee or a developer works on a patch not specifically to the client that how this is time locked and how this is presented to the client at the end? I think there are two aspects to it like one is like how it is handled internally and how it is handled with the client. So what I would like to talk about from a basic point of view is how we handle it internally. So people in our company they are allowed to do community work as much as they would like but they have to do one half in their free time and one half in their work time. So if you would like to work on a two hour or a half a day community work you can do that two hours in your work time and two hours in your free time and we introduced this because it was for us really hard to get a system that works for everyone because we don't want to force people to do community work but we want to to a certain extent support those who do community work. And then additionally to what you do for the community you get contribution points which is a system that allows you to gather points to be able to go to conferences. And so if you gather a certain amount of points then you can go, you have a conference day. So because we don't only want people to go to conferences and not contribute back I think it's for us important that those who participate can contribute. So this is for the internal part. Well speaking again mainly for the UK office but it's an idea that's gradually spread it. Well every office has the principle we like to operate on the basis of transparency. Transparency is a really important thing for us. So in the same way of saying if we do some work we bill it and if it's something else we don't but one of the things is if it's general community work that gets done on Fridays. We have a concept Wunder Fridays across a number of our offices that's gradually spreading. And so the idea is that Monday to Thursday we do client billable work and we keep our focus there. Fridays that's where we do the work on improving the business on our community work and so on and professional development. So that means you've got real clarity Monday to Thursday that is billable work for the client. And we operate rather than time reporting in the UK office we operate on the basis of booked time. So the client when you're setting up the project you're booking people for a certain number of sprints working a certain number of ways Monday to Thursday and that's for a period of time. So they're then booked and that's the basis on which the billing is done. So we try and lift some of that burden of time reporting because again that's a context switching thing and we try and reduce that. So if you're very clear that Monday to Thursday is work that's focused on the client and Friday is work on the community that lifts a lot of that reporting burden that can otherwise be a bit of a pain. And it also gives you a kind of clear focus of when everyone can get together to work on a community issue. So we have a lot of core developers in the company and they can get together at a certain time and do kind of you know mini sprints on issues and managing the issue queues and so on. So people like Lewis Nyman and so on put a lot of time in on their Wunder Fridays and we find that's a system that works well and it's transparent. The client knows Monday to Thursday they have us, Friday they don't. Okay, I'll probably take it back and be a bit simpler on my response which is if the work is directly to do with a module used within a project then it's probably logged as part of the project. If it's not, if it's something that people are doing during their community time then it will be logged as community time. How do you handle the community time? Like how much do you allow your employees to do or how is it organized? Yeah, we normally allow, it's around 20%. Okay, okay. Is your question answered? Okay, we have a question. Hi, yeah, so my question is if, I've got a very small organization. There's only four of us. So we don't have like an isolated development team. So everyone kind of does get interrupted and does deal with clients and stuff. But, and I have read like the, is it the Agile Manifesto where it's like, you know, you have to do all of it. But I was just sort of wondering for a team like us that might wanna start adopting some of those principles without being able to do the whole thing what would be the bits that you would suggest that we focus on and how should we do that? The first thing is that concept that you have to do all of it. Agile rather than a religion is a toolbox.  Now it does work best. You know, they've all been proven to work many, many times on many large successful projects. And it works really well to use more. But it works also to gradually get that. So don't feel that you have to jump in and change everything 100%. Start experimenting and doing bits and build up and prove to the stakeholders in the organization, this is making a difference and this is working. So the things that I would adopt first in doing that, number one is visible communication. Use the walls, put things up, have everybody see stuff. Things like the scrum board, things like that where people can really see what's going on. And the other thing is in rather than requirements as they were traditionally listed, where it is, you know, install search module and then you've got the must Moscow prioritization and everything's an M, of course. And project managers have special keyboard that they take out, client project managers and it's only got the M key for doing Moscow prioritization. And so rather than doing that, start focusing on using that user story approach. And so you're really focusing on the who, you know, as a who, I want to what and the really key bit is so that and the why. So I want, as a I want to so that is the structure of user stories. And the why bit is the really key bit and that's not captured in most requirements documents. Really understanding that user need and treating that as a placeholder for conversation and have that as part of the visible communication. Have them on the wall, stand around the wall, talk about them and see them move across the board. That's where I would stand. I would like to add something to this. We're going also through a HL transformation, I would say. And I totally confirm what Steve says. Don't do everything at once, start small. And to identify what you focus on. It's very important just not to do agile because of the sake of agile. Ask yourself what your goal is. What you would like to improve on your process. And based off of your goal, you define which measures you would like to take. I think this is also important to get all your staff on board. Like otherwise they feel like the project manager or whoever is experimenting with their team and changing things all the time and no one knows anymore what should be done, how and why. So defining goals and getting the buying of your team is really important if you start this transformation. I think I'm probably only, again, speaking last, I'll say the same things in a different way. But in the same way that it's a bit of a misunderstanding that Prince II was never meant to be completely implemented on every project. You were supposed to take the bits that you needed. It's the same with the agile manifesto. Well, it is and it isn't. But the reality is that you can, as Steve has suggested, start with user stories. You could start with a stand-up daily, just to get the communication in the team going. You know, a lot of teams would have only one meeting a week, let's say. As soon as you start to get people talking amongst themselves for 15 minutes each day, you get a better flow of information and people know what's going on. Not necessarily just with each other, but within the business and there's a better awareness. And even without a scrum or an agile aspect, that's really important. So that would be my suggestion. Thank you. Yeah, can you walk to the mic as you're close? And now Mike has to answer first. I would like to add to that, to use also iterations that you work in iterations and you present to the client on a regular basis during the project. You will learn so much from what they actually want more than what they said in the beginning that they want. So use iterations. Yeah, the constant communication, it works with the client as well as within your team. Yeah, that's really important. Any more questions? Yes. So how do you implement UX and especially big projects? Like how do you incorporate that into the project workflow? And how do you do them within sprinting iterations? I think we talk about cards, we talk about user stories. If they are the only thing that's there for a requirement, then the requirement isn't enough. So there's no reason why you can't have a wireframe for a requirement, a process flow for a requirement, ideas about UX for a requirement. So I think sometimes people explain the idea of a card maybe as being a mini project. And if it's an isolated atomic piece of work, then it can be. But sometimes there's an easy way to write cards which have to rely on other cards. And then all of a sudden you don't have those atomic pieces of work. So if you keep it atomic, you can apply the UX to that card itself. So you keep going with design, you keep going with UX, you keep going with the whole process throughout the sprint and the whole project. I think it's important that it's almost never too early to start testing and test often and do it in a really simple way. We had amazing what we have as a process is that we do testing several times within the project and one test is just taking a day of work. So we really invite clients, we do it remotely so that we reach easily people to test and we test them on prototypes, really rough prototypes and we find out what is not right and we do maybe another iteration and retest. So I think the continuous testing is very important and don't do it too late. You don't have to have designs, finish designs to do testing. It's already too expensive to check it. And also we apply the concept of the export review. So the one, the person doing the wireframe, this person will always go to another expert in that field and get that prototype challenged. So this is also a very easy way to get immediate feedback on what you do and yeah, do that mutually. It makes people learn from each other. I would be kidding if I said there was a perfect way of doing this at the moment. It's a big discussion within the UX professionals trade and within our company we have a team that's got together with representatives from each of our offices that are working on adopting and experimenting with different ways of working and trying to find better ways of working all the time. The key words though are that it's got to be about dialogue throughout the process. So there's always been this traditional thing of and even within agile there's still a temptation for organizations to be asking for more design first approach. And it is this thing of as my two colleagues here have been saying is embedding it throughout the process and stories being the story cards involving the elements of the UX, the development and so on.  And also with all of those stories there should be the really clear question all the time what is the real user need for this? Have we actually got evidence? Is there an actual user need? Has a user really asked for this? And would they ever? And where is the data coming from for that? So that that's then a start for conversation and okay well if we've got no evidence there how do we get some? What's the cheapest way of testing that and getting some feedback, getting some data points? And then we can make a decision to make more investment. So it's keeping it as a conversation as a dialogue throughout the process with everyone involved and focusing all the time on the user need and it's all too easy to say we're doing UX but not involving real users all the time. So as Dagmar was mentioning, testing all the time as often as possible, research. We've done projects where people will just sketch something out on a pad and go out into the street and chat to people about it in the street and just get instant feedback there. So just whatever you can, the cheapest way of getting some kind of real user feedback is really important in that process and then embedding it in everything throughout the project. Can I just ask, just to start briefly, that when you talk about UX, make sure you also include in your thinking accessibility because they're not distinct things. It should be an inclusive thing. Thank you. What I'd like to add is like, UX starts at the very beginning of your project. So a lot of times the client comes with fixed requirements, right? Happens to all of us. And important is going a step backwards, asking the client what is your goal and then going into creating personas and creating customer journeys and to truly understand how the potential user will interact with the website. And you will, a lot of the times, you feel find out things you didn't know or all of the team that has written the requirements didn't know before. And in this process, we oftentimes include salespeople or people from support because requirements are often written by marketing or by the technical department and they have assumptions. But these assumptions are sometimes not proved and including sales and support in this process will open a lot more discussions. He was first. Maybe you wanna walk around, it's actually easier on the microphone. Yeah. Thank you. Hi. So how long are you... Can you come and be closer to the microphone? Sorry. Yes, thank you. How long are you usually sprints in your companies? Also, how are you planning the sprint?  So I think it was the question, how long are sprints? Yeah. Yeah, okay. Normally two weeks, pretty much always two weeks just because then it's predictable. I know some people change the length of the sprints but I'm a simple man so it kind of makes it easier for me. But as for planning the sprints, we would normally plan as we should as close to the start of the sprint as possible. And that would include maybe a few days before a backlog grooming process. So you normally have a Monday, Wednesday, Friday cycle for meetings that might be to do with particular sprints. So you'd have a retrospective on the Monday, grooming on the Wednesday, planning on the Friday, start the sprint on the Monday retrospective of maybe every two weeks. Yeah, totally agree. We do it the same way. Something I would like to highlight is the demo with the client. We have recently changed from including all the team into the demos, like all the technical teams and this has been to be very excellent. Like bringing clients and developers together is a great thing. Clients appreciate that their technical questions are answered right away. And our engineers like to feel how the client feels. Like to feel if it's good, what they delivered or if it needs improvements. And it improved a lot of our team dynamics. First of all, I would echo that. Having the whole team there in a sprint demo is vitally important because there's valuable feedback to be gained there. But there is also that reward for their work.  And to see the client go, wow, that's done already. That's fantastic. So it's really important that they get that kind of direct feedback from the client. Don't have a project manager in between the team and the client. The project manager is just facilitating the communications and supporting the communications that happen directly between the team and the client. So in terms of the direct question, the length of sprints, that's always got to be up to the team to decide. And each team when they're starting the project may decide on a particular sprint length. I would say we generally have two week sprints which for when we have the one to Fridays that's eight days in a sprint. But some offices and some projects sometimes decide to have one week sprints. Certainly because the velocity of development that you can achieve with Drupal is actually really high. I mean, if you think what you get with the core and some modules and so on, some contrary, then you're very quickly getting functionality implemented and you want a fast feedback loop on that. So as quickly as possible you want to demo that to the client and get some feedback. So some projects adopt one week sprints where functionality is simple enough that the speed is so great to get that regular feedback loop. But the team can decide and in retrospective they may decide they want to change the sprint length. But it generally gets set at the beginning of the project and then stays the same. Thank you. And one additional question. It's about quality assurance, actually testing. Do you allocate time for regression testing during the sprint? Because yeah, we know QA is involved to test the backlog task during the sprint. But what about the functionalities that are in the past sprints and then can be broken? Because new functionalities. That's a first to me. Go for it. I'll happily pick a smile first. So the question was about QA and testing and how's that integrated within the sprints? The first thing is these days a modern development workflow automated testing very, very important. And so that's a key part of the process. But also we adopt a peer review approach. So with every commit, then you get a colleague to review it before merging it in and that process is really important. That constant peer review and the testing that happens as part of that process. But otherwise, a really comprehensive automated testing approach is a very valuable part. But then you'll also have it part of the role of the project manager many times to do the kind of the dumb user testing. Because often developers are too clever and they know what to do.  And that's the more in the browser type testing rather than the regression testing which you may have automated, which is, you have an automated check that if, can I still log in? Can I still check out or whatever the functionality is? Nothing to add. Okay, yeah, I would only add that we include that in our definition of dumb. So when you're estimating a card you're always including the fact that you've got to have QA done on that work. It's not necessarily the full regression that you're including every time. But as Steve points out, automated testing you should get green lights across the code anyway. Thank you very much. Keeping up with tradition I'm gonna ask two questions again. Can you go closer to the microphone? I said keeping with the tradition I'm gonna ask two questions again. First is how many of your projects are in agile methodology? Because we've seen a hundred percent. Number two is at what point of time do you bring in a developer along with the UX guy because there has to be a word line. So how many projects do we do in an agile way? All our projects are agile. I would just say that some are more advanced than others. We are in a phase of transformation in this case. What is still a challenge for us is to include maintenance work into our sprints. So because in the past lines it really liked us to bring in work and we did it immediately. And if you do scrum, you have sprints and you plan in advance and you just don't put things in there just now and say it's someone go, go for it. So this process is still a challenge for us I have to say. And maybe someone of you has an idea but this is in terms of agile. And the second question was again... The developer getting in along with the usability guy and what point of time do you bring in? Okay, so we have our UX person here and they sit in the same room and important is that they talk before where you started because you have to validate the estimation. Was the prototype too complicated for what time we have allocated? Is it possible to do?  Again, we only do agile projects. So I think it's roughly about 200 a year that we do across the group and they're all agile projects. The next question kind of comes back to the earlier question about the integrating UX in the process and the key is that the proper agile team should have the talents that it needs within the team and collaborating completely together. So UX is not a separate part of the process that a brief gets sent to them, they do their bit and then they hand it over to Dev. They should be working closely together. Now they can be a distributed team but they are working as one and the same communications, the same meetings, they're taking part in the same sprint planning, same demos, everything is about that collaboration between a team that contains all the talents necessary to deliver the project. So they're completely involved together throughout. Okay, I think, I don't have too much more to add but yeah, all of our projects are agile after a fashion which sometimes means that we work in an agile way internally and not necessarily with the client in that way. So the client might see the calm swan swimming across the lake and we're pedaling away underneath in agile. So yeah, there are some smoke and mirrors sometimes and that's the honest truth. When the devs get involved as soon as possible but the reality is that they probably get involved around the first iteration of wireframes. So it'll be a case of talking the devs through making sure, they've already got all the documentation they've been involved in the meetings anyway but it's making sure that they can verify that A achievable and B can be done within budget. Thank you. Hi, I mainly work as a freelancer or a contractor and I often sense that when I'm contacting web agencies web agencies about work and I tell them that I do work remotely, I often get that sort of face that tells me to get out of there. So how do you manage that and if you don't manage people working remotely, why not? And how do you sell it to the client? Do you even have to explain it to the client that your people are working remotely and how are the clients affect to that? How do they react on this? Okay, I'll step in here. Hi Tommy, by the way. We're pretty upfront about the fact that we're distributed and people, there is some issue with acceptance in some cases where people would expect you to have an office or whatever but people are okay with it. As long as you're there at meetings and you're contactable, then you're okay. So I think we benefit from being distributed in that way. And so that was the answer to your second part, your question. So to answer the first part, we only work distributed so therefore it wouldn't be an issue at all. I wouldn't say we are distributed. We have a great office in Zurich and people love to come to the office and work from there. But it doesn't mean that you have to be there all the time. So people can work from home if they like and people can work at least three weeks in a year in one of our other offices in Austin on Cape Town. So there is a lot of, we are all virtual. There is no physical boards around. But still I think for us it's a good point to be not distributed. So a lot of times client come by our office and work from there. We encourage them to do so because we like them to be there when they enter their content for the first time. Because nothing more annoying than having to open 10 JIRA issues and you didn't manage to get your content in. You have to open a JIRA ticket and wait for hours until it's fixed. So better just walk over a developer, ask the question and get it solved. So working with a client in our office is for us a point and then the social aspect. We do, we go running over lunch, we go out for beers, we just are there. We see how people feel, we are there for them. So for us being in our office is more choice than an obligation and it works well for us. We have been experimenting with distributed working. So our entire UK team works in a distributed way. There is no London physical office. We all work in a distributed way. And it's an idea that we're starting to experiment with elsewhere as well. It's worked very well for us and it's worked very well for clients. We actually get clients saying sometimes that they have a better quality of communications with us than they do with their colleagues in the same building in their company. And you know, because within these organizations you end up with silos and or you've just got people in this big open plan office and they're just sort of zoned out focusing on their screen and checking Facebook or whatever. And so we actually, you know, because we put the effort in because we're distributed, there is a better quality of communication because you're focusing on what communication do we need to do. Part of that is having an open chat channel with the whole team and the client team all in one chat channel. And they're just constantly throughout the day little bits of updates and information. That's one of the information radiators. The other thing is, you know, sharing project management tool and everybody having access to that and having that report into the chat channel as well using the Hubot bot is a fantastic thing and connecting up GitHub and Jenkins and everything else. So everyone can see the commits, they can see the states of builds, they can see everything and a client doesn't need to know how to log in somewhere else to do that to just go straight into chat. And then having those sort of set meetings whether it's the daily stand up or the sprint demo and so on and having those very clearly planned and even ad hoc communications. We have a thing that was just, we just know as a tea break hangout where a member of the team will say, we're British. A member of the team will say, I really fancy a cup of tea. Does anyone else fancy a cup of tea? I'll go, yes. Okay, five minutes, let's have a hangout. And we'll just have a chat and have a cup of tea on a Google hangout. It's weird, but we're English and we like it. I love you. Tommy likes tea. First of all, thank you for mentioning the distributed teams topic because everybody else in the conference talked about remote teams and I think that's not the same. And the second thing I wanted to ask is actually, there was a talk earlier about testing and finding things that you didn't thought of before, the testing that are missing in the project. So if you miss something in the discovery phase and any other phases prior to testing, how do you go back to the clients and say, okay, you are missing a whole feature or whatever. So what is the point that makes you to go back to the clients and not cover that yourself? So how do you handle that, actually? You're missing a whole feature. I don't know, so something that's... Something's gone wrong. Yeah, exactly, exactly, exactly. I suppose let's say you have, you've missed something. The clients missed something, they haven't told you something. The answer to when do you go back is as soon as possible. And that immediate communication is paramount. And you squeeze it into the next sprint. You do something that's got to give. This is the classic why you use agile answer. You've got a list of 10 things that have got to be done. You've now got a list of 11. If you've only got enough budget to complete 10 of them, which one is the least important? It's kind of a short, pithy answer, but hopefully it will be the right one. I agree. Yeah, definitely communication as soon as possible. So say, for example, you've found out that perhaps they haven't, you know, someone was off sick and they haven't mentioned the right thing in discovery and this thing is really needed. And it comes up at a meeting about, you know, well, aren't you going to put the magic button in or whatever else it is? And it comes up as a request. And yes, it is that unique prioritization that's really important. We explained very early on, in fact, let me just go back a step. When we start a project with a client, if they don't have what we believe to be really solid agile experience, we give them a two day training course in agile for all of their key team and stakeholders. And then we do trickle downs for other people in the organization. We do an hour session for everyone that will be around the project vaguely. So they know what we're talking about when we say a user story and they know the format for it and they know why that's key and they know what this big board on the wall means. So that's a key thing. And so therefore, we help them write this new user story and we talk about it and then we help them figure out the prioritization and we explain that there is no such thing as magic time. There is none. So it's this thing as well, that you've got a backlog and you believe you can get this far down the backlog within a certain amount of time. So it is, where does this go in that stack and what else gets latched out? And that is exactly the right, I would agree with that, the right way to approach it. So Agile is actually your safety net. Exactly. And you can take the stakeholder that's raised this up to the wall and show them all the cards and say where would you put this new one? Where would that go? And they have to be part of that discussion, that conversation about prioritization. And you use the word safety net there or the phrase safety net. I think that may be the wrong way to look at it. And if you turn that around to say this is the solution to change management. Change, the only thing that we know that will happen is that requirements are incorrect and there will be change. So therefore Agile allows us to continue with that change and adapt to that change throughout the process. So rather than being the thing that we have to fall back on as the safety net, it is the thing that we're using through the project all the way. Thank you. I would echo that. Change is good. Yeah. Hey, I have a question about teams. Probably I know something how it's done in Wunderkraut but it would be interesting to hear from others as well. How you decide who is going to be in the team for a particular project? Like which they and AMAZ Labs has also more than one continent. So do you split teams between Europe and US or how you decide on these things? Of course, availability is like most probably number one but like skills primary and previous experience or? So there's a geographical and the expertise level, I would say. So on the geographical level, it is best that the office deals with the clients at that location. At least this is the case right now. So Austin has their own clients. Zurich has their clients and Cape Town as well. We could imagine to extend this model so that Zurich gets supported by other locations. Especially this case is really interesting because the rates abroad are lower than they are in Switzerland. So this is a case we will maybe build up in future. And then it is really nice to have this relocation and they can also help each other out. Like our two offices outside of Zurich are really small still. So if they have a big project to get started to grow, they need our support. They need the Zurich support. Otherwise they can never do really cool projects.  So the idea is that what we practice is that they get support from Zurich to handle their big project so that they can grow. Then on an expertise level, this is the other thing. So they are site building and they are steaming and they are back end. There are a lot of different things in Drupal and this is a challenge because people are in one thing very, very good maybe. But then you don't have to accept people for the two parallel projects. If you have too much of a specialization you will blocking each other. So you have to go away that is kind of combining the two. Like giving people a specialty. I strongly believe that specialty is something important. It motivates people to be really good in something. But at the same time they have to have something else they can do as well. They have to understand the cross functional work they do because as a site building you have to prepare for theming and you have to understand how that works. So that's why we try to keep a balance between expertise and this really scrum way of doing everyone can do everything. I would say that my favorite type of developer would be a generalist with a favorite specialism. But they're very rare. I think the answer to your question which is from my point of view, I would love that it's based on skill but it's mainly based on availability then skill. I want to add more to that. I know you already know this, but for everyone else I'll just mention briefly how we do this. We have 170 people across nine countries and we're more and more trying to get cross country teams, you know, multi-country teams because that encourages knowledge sharing, it encourages, it allows us to pick from a much wider pool of talent on each project. So within 170 people you have people with real specialisms in certain areas and we take on fairly large, fairly complex projects that often can have real business critical projects to our clients and so we therefore want to have people with that deep specialism. I like the phrase you used about sort of the generalist with a specialism as well and we kind of refer to this as T-shaped people. They've got a broad knowledge which is the top bar of the T and then they've got a deep knowledge which is their specialism and you want to build up a large number of those around the company and then be able to use them to their best scale all of the time but they know how they fit into the right place in the organization generally because they understand a broad range of things too. So having 170 people means that we can pick fairly widely. Working in a distributed way means we can pick fairly widely as well and it means that we don't arrogantly assume that the best people in the world for this project are the ones that happen to be sitting within arms reach within the office. We can find them anywhere they are and recruit them and bring them onto our projects. So that's a key thing. Scheduling is always difficult, really difficult because there are so many projects in place, so many moving parts, projects will get extended which is always a nice thing when clients go, hey, this is great, we want to do more on this. That's a good thing or projects will sometimes get delayed because large organizations can move quite slowly at times and so you've got all these projects moving around and we're figuring out at the moment what the best way of doing that is at the moment like most agencies we have this big unwieldy spreadsheet. There's got to be a better way. So we're looking at that at the moment and then yeah, the project manager, the consultant that's been putting together that project then looks around the group and talks to people about what the project is and whether they'd be a good fit for it and bring this together that team. We're about to do an experiment with the next projects coming up where the consultant will pitch the project internally to a wide audience and then team members will select themselves onto the project managing their own schedule. That's just an experiment for one bit of the company but it could be interesting and we're going to see what results that have. Okay, thanks. Do we have still time? No, sorry, no, we are over time. Yes, that was already an hour. Wow. Thanks for all of you for the questions. I think they were really important and really interesting ones and we definitely cannot fix everything in an hour because then we definitely would have fixed other things as well. But I really thank you. If you liked that, please go to the Drupal Con Barcelona website. There is an evaluate tab or a button and write in. If you like it, if you didn't like it, also write it in because it's definitely something that we want to know from the content team if you like these type of sessions and stuff. Yes, Steve. One thing I've mentioned as well is part of our policy of complete openness and transparency. We publish all our ways of working on something called the Wunder Way. So it's way.wunder, W-U-N-D-E-R, .io. And it contains all our ways of managing projects and we're doing a sales process. It's basically our intranet, but it's public. So feel free to go there and borrow materials. Cool, thank you.