 All right. Thank you everybody for coming to this session today. Really great to see some familiar names and faces and some folks that I don't know as well. So a little quick introduction to myself and then the topic and we'll get into it. So my name is Lee Griffin. I am an engineering manager for what we know as the CPE team, which is the community platform engineering team. We'll hear a little bit more about the team in a couple of minutes. But they work exclusively in the community and they're an open source facing team. And that's where this idea came to me to do a talk on how our team tries to serve the community. I'm not saying we're perfect. I'm not saying we're there and we're definitely on the journey. And I see Sarah Finn in the virtual audience there. So Sarah is a rather a practitioner. So a lot of this goodwill and ideas and implementation details are down to her energy, her drive and her passion. So thank you very much Sarah from the team as well as from the communities. So I want to kick into it and just give a little bit of background about the team. So the CPE team, we have two communities that we serve. We serve the Fedora community and the CentOS community. And we've got this fantastic logo that was created by Mo Duffy, one of the Fedora community members for us, which if you're into symbolism and into design, you can see elements of the logos from both Fedora and CentOS in there and a bridge from the unification perspective. So it's a very cool logo that we have. But the team has a very broad remit. We deal with the system administration of the infrastructure that is used to effectively build and release the Fedora and the CentOS operating systems, but we're much more than just an operating systems house. We manage the pipelines, which we know is release engineering to help packages flow into the system for release time. And we manage a huge suite of services, over a hundred at last count, which enables our community and enables the success of their applications and their interactions within both Fedora and CentOS. On top of that, we don't just maintain things, we try our best to add value. As a good agile team, adding value is exactly what you want to do. So we proactively engage with the communities and we build out initiatives and their new service offerings or enhancements on existing offerings that are out there that will hopefully make people's lives easier and bring some form of value to the wider ecosystems that we work in. I want to talk briefly about the open source intersection. So this is actually becoming a norm across the industry and you're attending an open source dominated conference. So I don't need to go into too much detail about why open source, but more and more enterprise teams are slowly coming to the realization that there is communities out there that are working with technologies that are part of their stack. There's also very robust technology stacks out there, which means the enterprise doesn't have to develop every single piece of the pie and they can take various slices in various communities and focus on their value add and their unique selling point from that. Now, this should be a symbiotic relationship, so the community should get as much value as the enterprise-driven teams from this. That's not always the case and that's just how somebody's communities plan out, but the benefits can be huge. And I've pulled a really great article on a shameless plug for opensource.com here. There's some fantastic blogs and content on it and this talks about the enterprise open source advantages, but I've kind of enhanced some of the keywords, which I feel resonate with me from an agile perspective. Faster time to market, crowdsourcing, transparency, merit-based. They're all things that most agile teams strive for and here you've got a community doing this day in, day out. So there's a very natural intersection point for me speaking from an agile perspective and now more teams are starting to discover this and the whole point of this talk I suppose is to show you some of the changes that you might have to make to your flavor of agile to leverage these opportunities and to enhance the offering that you'd love to deliver to your customers. What really struck me a couple of years ago was the value alignment and anybody that's seen me present before would have seen this slide several times so apologies for the reels. Red Hat has a very strong values-driven approach. Most teams do. It seems to be the norm in the industry and it helps define your culture really. And if you take agile and I'm focusing on scrum here because it is one of the most prevalent from a software engineering perspective and they have value statements out there for us. And if you take open source.com's values which kind of manifest themselves as the wider open source values, you'll see steel threads running through them. You'll see they talk about freedom, openness and open exchange across all three. Commitment appears word for word in two of them. Red Hat has actually found it on a meritocracy and that's pretty much what open source is about. And what you have there is what we call a frictionless environment. As a team, you don't want your team's processes and your team's values to be at odds with anything else be it other teams, be it the company or be it the tooling and the communities that you're using. When you have this steel thread running through that gives a really unique experience because everybody appreciates why we're trying to work this way and it level sets the values across the board so people effectively speak the same language. And this was eye-opening for me and when I had the opportunity in Red Hat to move internally to an open source centric team this is primarily what attracted me to it. It attracted me at a values point of view. Now agile is all about teamwork. I often call it the continuous integration kind of tool chain at a software perspective but at an actual agile perspective we continuously want to be improving. We want to continuously plan, innovate, integrate, deliver and get better as a team. Now all of this mindset is really what good engineers and teams strive for. This isn't anything unique about agile but open source doesn't change that and that can scare some teams that are going to try and open their processes and try and do more things in the open. I can't do my planning how we always do it. I can't innovate as really because customer secrets will get out there. A lot of people familiar with Scrum will often hear this is Scrum but this is almost agile but we can't do all the things we normally do because we're now working in the community. To me it magnifies us because you have a ready and willing and exceptionally passionate user base that want to innovate, that want to work with your tools and your teams, that want to benefit from your delivery and equally want to improve at an individual level as well as at the collective project level which is fantastic. So there's no issue from your day to day teamwork values and what you put time and energy into when you transition into an open source facing team. So one of the first things that we have to do is a team when we really started to gather together and put a path in the plan forward for us. We needed to define our scope and our mission. Now this is particularly true at a team level but in communities they're absolutely huge. People associate Fedora with just the operating systems and in paraphrase in Matthew Miller here the Fedora Project Lead, when he talks about Fedora, he talks about it as a collection of people and services all coming together with an open source at heart. And that means the community can be huge and your interaction point might be a very narrow sliver within that community. So by you defining your mission and sticking to it, that helps the community have clarity about what your role is. We regularly get requests for items outside of our scope. We absolutely consider them, we absolutely engage but we know there's no ownership on us to go ahead and work with that idea or try and fix that issue. And from a team perspective that creates a very safe environment and I'm not going to talk about psychological safety after the last call, which is fantastic by the way. But that clarity for the team, it helps them in a very public manner and I'll talk a little bit about some of maybe the more negative aspects that the team's experience in open source. But having this defined scope and mission, it provides huge clarification for everyone and that was really the beginning of our journey and we shared that journey through blog posts with the communities so everyone understood who we were, what we were and what our identity was, which was hugely important. Now you need to work together in any relationships. So this can be any stakeholders let alone community-facing stakeholders. Now the difficulty with a community is it is a collection of individuals who all have very strong opinions and like anybody with very strong opinions, we rarely agree. But what you'll find in communities is their structure is set up to enable the communities to grow and to thrive. Fedora and CentOS have governing bodies. In Fedora it's a council and CentOS is a board and they have different meanings and different mechanics behind them but effectively they become the voice for the overall project at a steering committee kind of level. You also have community of practices and this is really where your team needs to identify who their stakeholders are because you cannot identify every single individual user in the community as a stakeholder with an equal voice. You want to try and group them, you want to try and get a singular voice coming through to avoid denies and avoid the confusion. And of course you want to evolve them. You don't want them on the periphery. You want to try and get them involved as many of your activities include them on the right communications and make them feel part of your agile framework. Now your stakeholders generally should be expressing to your team their needs in the form of what you want and why you want it. So really value proposition for investing your team's finite resources into a project. I was really great about open source communities. They rarely come with the business pressure of a paying customer saying and I need this by this day. So the when aspect is rare. Sometimes it happens if they want to try and leverage an opportunity and of course you're willing to work with that. But given the team that freedom that they don't feel under pressure to deliver immediately or on a very tight time scale actually allows them enhanced their agile processes and allows them worry about delivering when it's ready rather than when the date was set for them in the sound. Now open source is a very communication heavy experience. Prepare for a lot of emails. Multiple email lists are the norm in open source communities for development for infrastructure for all of those things in some groups that I mentioned earlier. You need to be on them. You need to be listening but set up good filters and watch for your keywords and watch for your interactions. You will learn a lot passively from just observing and you will gain a lot of valuable feedback about your team, your product, your interactions and the perception of you and the team. A little tip, get in line. A buy by their style. So emails in open source go with the in line style which when you get used to it becomes fantastic and then you try to mail people who don't get it and it becomes very confusing. IRC is predominantly the approach to instant messaging communication within communities. Discord and other applications are starting to gain traction but IRC provides records of the chat that people can refer to and all of this emails and all of this IRC is set up for asynchronous communication because people who are involved in open source communities have day jobs, their parents outside lives and they can't commit to being on a keyboard responding within a couple of minutes which is why IRC emails are de facto means to communicate. Issue trackers are something that the community use when they're trying to fix bugs or raise issues or get a resolution to an ongoing task and this is something that your team has to start focusing on. Worry about manual syncing later because I do understand the power of Gira, I am an absolute fan of Gira and some of the other tools but the community aren't and I'll explain why in a moment why they're not such a fan of tools like that. We also try to use the open decision framework so the open decision framework is a great way to scope your communications and help involve the community in why a decision has been made. This is really, really important and we tried it and we done our best to use the open decision framework and we made mistakes and we learned from it and that's a great agile journey to mess things up and move yourself forward and try to learn from it again but the community respect the intent of using the open decision framework perhaps the execution didn't match it but if you become an open team and you want that level of feedback the ODF is something you should definitely consider. Realigning your tooling so every agile team and every strong manager or program or project manager or the other hierarchical roles that want to get a pulse somewhere your project are they have a set of tools they want to use internally in Red Hat we have Gira we have Google Docs, we have Google Meet they're all fantastic ways to communicate, track projects and asynchronously share information across the organization. A lot of those are closed door tools though they're behind VPNs they're unable to be accessed by the community so one thing we had to look at was ditching a lot of those tools where we could and where it made sense and I'm not saying throw everything out there's times when you do want to work on Google Docs, there's times when you do need to have a quick Google Meet or Blue Jeans or whatever other voice comms you're using so we looked at taking a public target instance which is an open source version of an issue tracker we use HackMD for sharing notes collaboratively with the community some of our teams use Jitsie which is a free open source web conference software and you might have noticed the tread and the commonality there, they're all open source tools the community in the open source world really respect and love the fact that we try to use open source where we can this is ubiquitous across most open source communities and they will respect that you are trying to engage with the philosophy the mindset and the approach by compromising on the functionality Taiga versus Jira there's no comparison in terms of what Jira gives you as an enterprise grade tool that comes with a massive cost as anyone who's had to pay a bill for Jira will know you take the hit on the functionality but does that matter that's entirely up to your team and I'll leave you all on that with the quote from the agile manifesto about individuals and interactions over processes and tools so we try and open our communication lines to the community we do run our team meetings through IRC we run backlog refinements, bug discussions some teams do daily stand-offs asynchronously through IRC and that means the community can dip in and dip out and like I mentioned earlier with time zones and with people having personalized and professional lives then the intersection there is the open source world they can dip in and read a meeting that happened eight hours ago or eight days ago and still in the same context and still be able to respond and engage with our team we do a weekly email round up to the community we showed them what we worked on, we invite comments, we try and get a sense of progression as the work is going through and hopefully we'll get some kind of responses on us what's really interesting here is a survey recently and people said that the emails were one of the most valuable mechanisms we had to communicate yet week on week we might get zero comments or one comment on us and you start to doubt is this the right way to communicate but that's a lesson learned in the volume of emails that come into an open source mailing list not every mail is going to get a response but people do read them, they do process them and they absolutely do appreciate them coming in to allow the community to discover you and your team the information that you share is usually important because you want to root in you want the community to be able to communicate which you find you discover you work with your projects and track you so wiki pages usually popular for communities they might seem a bit antiquated for enterprise grade teams but usually important for the community it's the first place I go to when I'm looking for information before pinging people on IRC Twitter has emerged as a huge communication vehicle for open source communities so get social, go to where your community interacts I follow a lot of the community contributors they follow me and it is great to see their insight, great to see what they're thinking about, great to see their perception of our team and the last point here is something we're only starting to think about recently, it's humanizing the team it's very easy for open source communities to criticize the corporate culture, the corporate team very difficult to criticize people as individuals everybody in our team is trying their absolute level best, nobody gets up goes to work or work from home as we're all doing now to try and cause harm or annoyance to anybody in the community, sure we're doing things and building things people don't agree with or they try and do it differently but like I said earlier, opinions are out there, everybody has one and we need to be able to communicate and deal with them and work through those opinions but we're now starting to try and humanize our team and we're going to try a couple of experiments in the coming weeks to record small segments to some of our meetings and make them available so people see us to know the person and the face and the voice behind the email moniker that goes now I didn't mention the mail in this multiple times and it's showing the importance of them but you can't just be in read only mode, get involved even if it's encouragement, even if it's a plus one on an idea if you can default to open where the topic is not sensitive, if you're talking about an architecture decision or how to resolve a bug why would you do that behind closed doors why would you do that on one of your internal mailing lists when you could open it and possibly involve the community who might come up with an idea who might have an opinion on it and even if they don't, you've made the effort, you've opened that transparency aspect to them this is one of the slightly negative sides of this you're going to get negative comments this is life, you're going to get somebody that doesn't agree with what you're doing and they won't be long about telling you about us it's generally not at a personal level which is why I mentioned to humanize an aspect a few minutes ago but you're never going to satisfy everybody and in one sense you have to grow a tick skin but in another sense you want to engage not at a tit for tat kind of verbal sparring with someone but you want to try and get to the real cause of what the negativity is you want to help understand where they're coming from and that can be a kind of coaching exercise for people involved in that capacity you can jump on IRC sometimes the written word is awful for trying to interpret people's real intent and we've had some community members jump on the call with us when we had some tricky conversations and within five minutes we clarified the intent that's just one of the more negative aspects but this happens in every team and unfortunately you're going to encounter it and just knowing that will harm you with the right tools now I'm not expecting people to read the initiative flow that we have there but you'll see it's a flow you'll see it's a flow based diagram there's action points there's entry points on it and what we want to really focus on here is allowing the community to have an input to your backlog to be able to suggest an initiative for consideration community members will fall into really two camps it's the camps that want to get items fixed your typical bugs, your problems, your annoyances and they're very easy to deal with because they're often just in time and there's something that the team consume naturally as part of their work so the initiative in our world is a commitment in about a three month window we do quarterly planning and we try and work six weeks ahead of ourselves so we know what we're going to plan roughly for Q1 next year we'll know that in kind of late October early November kind of time that gives the community a chance to see the capacity of our team to see what we have coming forward to look at our roadmap to look at existing initiatives to get our route into us and we involve the community as much as we can in that we haven't got a huge volume coming from the community but we get massive feedback on in-flight initiatives that we're running and we're hoping over the next year that we get more community involvement and ideas for consideration going to us and again it's the intent you're opening your doors and you're welcoming this level of involvement we do need to check the temperature regularly we've ran two surveys and it's something we're going to try and do maybe once every two to three months we go on mail threads, we go on IRC we attend conferences that the community attend and this is all designed to almost run a retrospective in the open without calling it a retrospective we want to get that feedback and that perception because otherwise we're living in a vacuum and pattern ourselves on the back we want to make sure that we're doing our level best for the community and not doing something that is causing more harm than good and by doing this recently we have the chance to course correct our most recent survey we pulled at least 10 data points from it which are now being worked through our own internal backlog for improvements that we're going to make going forward and this is what a good agile team does and that should not change from a stakeholder perspective it just changes from the volume of stakeholders and individuals we want to deal with because these surveys are aimed at a little contributor level we definitely do it with stakeholders we do that more in depth in a more formal retrospective but this is a chance for every voice to matter and if we're annoying one or two people it can become a trend and that's something we want to try and nip into the body as soon as we can now I mentioned earlier about the mutually beneficial approaches so the community should get some value from an enterprise grade team that has X number of developers working a 40-hour week which is hopefully going to transition to some value for the community and here's some of the value that we've observed and that we've commented back to us from the communities they receive much more focused deliverables so they're going to see the benefit of putting five or six engineers on a piece of tightly bound work that will deliver that promised value at the end of it the previous model that we had in our team was individuals working on a lot of siloed projects which was fantastic we almost became omnipresent by the fact we were moving 20, 30, 40 things at once and that's just one or two individuals in that example but this focus means we can get more complex features out we can get more resilient deliverables which ultimately is a quality output that is going to be appreciated by the community now communities in general have their own vision they have their own focus and their own goal and as an agile team we're all about visions and we understand the importance of that but by having this dedicated team and having proposals come in we can shortcut a lot of the organic growth that would need to take place for a community to achieve a milestone along their vision goal so us putting six engineers into a piece of work for three months could shortcut something by 12 months or longer which is fantastic from a community perspective and the last point is about stronger collaboration and a deeper sense of association with the project so open source developers have a very strong relationship with the project they really associated with it they identified themselves as a fedorian or a community when you have a team that is constantly investing their time and constantly delivering and moving that vision statement forward and adding value the community reciprocate that and they want to come back and work with you on bug fixes on feedback on giving you the tools for your team to succeed and move forward because ultimately it helps the project and that creates a tighter association with the project which will hopefully lead to a retention within the project's domain and this should be obvious but it is a journey we're not just changing how our team works at an agile level we're changing the habits that have been brought up and ingrained for several years in the open source community we're trying to do this in the open which means there's a spotlight on us and that brings its own pressures and its own unique challenges with it as well you're also trying to change the community's perception now Red Hat has been very lucky as a sponsor and a guide really for Fedora for many years and similarly with CentOS but that's not going to be the case for every enterprise team engaging with this the community might be very wary of your team especially if your team and your enterprise is monopolizing the community and making a lot of dollars out of it so you have to work on the community's perception of your team your product and your overall company but for me this has been a very enlightening experience about the flavor of agile that has a marriage with the team it's almost a pure reform because it's done in a transparent and an open way and that can give very raw feedback but ultimately it will enhance the mental agility that a lot of teams struggle to achieve most teams get mechanically agile very very quickly they can follow the process they can follow the guardrails they can do all the things the book where their scrum master or their coach tells them to do but they don't get it up here they don't get it in their head and this open source way of doing it I firmly believe is starting to change the mindset of our team as well as giving appreciation for the community for what agile is and isn't and that everybody is the end of my presentation that's my email address and I'm on Twitter I need to take people's comments into chat as we go and please don't all rush it once with your first question that in case I missed anything okay if people don't have questions I'm happy just to stay here on the chat if people don't want to connect with me one on one or email me or hit me on Twitter and hey thanks everyone for your time and attention great to present to you I hope you got something from it I do have the YouTube link I can drop into the channel as well because I did pre-record this before it so I'll drop it into the channel if folks want to look at it as well and I'll see everyone around enjoy the rest of the day