 So, thanks to everyone for coming. You know, huge crowd. Agile being a very important topic at Flock and so on. But what I'm going to talk about over the next 50 minutes or so, it probably won't last that long, is open source Agile and to try and give an overview of where the CPE team are going. There are a number of the CPE team here, so thanks for coming along for moral support. You were in no way forced to come to this talk, blink twice if your captors say so. Thanks for the cameras facing this way so no one can see that. So, let's give a little bit of background about myself. My name is Lee Griffin. I'm one of the co-managers of the CPE team along with Jim Perrin here. I joined the team back in January and one of my backgrounds and expertise is in Agile transformations. I've done this with a couple of companies and one team within Red Hat. So, I want to give a kind of general overview of why Agile, why we want to move in this direction and try and color it with some of the challenges that we face within this team. The first thing I suppose is to define what Agile is, right? So, Agile, depending on how it's spelt, is actually two different words. So, Agile with a lower case A is quick and well coordinated in movement. That is something I am not anymore after many injuries playing football over the years. When you see Agile with a capital A, it talks more about the mental side of being Agile, that quick thinking, acuteness, awareness in what you're doing. And Agile with a capital A is all about the mindset. It's that mindset shift of wanting to continuously innovate, continuously improve and ultimately break down complex problems and make them a little bit simpler. So, just beginning with a definition there because marketing terms have ruined the word Agile and Red Hat plays very large part in that talking about Agile integrations is the wrong kind of Agile in this context. Now, Agile for organized teams is really, really, really hard. It is a cultural and a mindset shift. You are trying to change patterns of behavior that have been ingrained in people and teams and products going back decades. I think Brendan had it on the slide yesterday saying the Agile manifesto is 18 years old and the devil process in and around Red Hat and rel is going on 20 years or so, right? So, you're predating even the standards that are driving a lot of the Agile innovations that are out there. And here's the thing, teams aren't prepared for it. They might want to move that way. There's a certain set of prerequisites before you can actually start working in an Agile manner. So, for example, you need good test beds, you need good repeatability in your processes. You need time, you need head space, and you need focus, right? So, a lot of teams don't actually have that. And teams might want to move this way. Why do we want to change? Well, not everybody embraces change. It's one of the things people fear for very good reasons. Now, I attend a lot of Agile conferences. And if you're to believe the conferences and if you're to believe people on Twitter and LinkedIn and other places, this is easy. It's child's pleasure. Why can't you do it? Just go and implement Scrum. Hire me as a Scrum coach. Give me 200K a year and I'll solve all your problems. That is one of the problems within the industry is that kind of model of paying for a quick win. You don't get a quick win. And success stories are the biggest problem with Agile. Because success stories don't exist. There is no perfect version of Agile. Anybody that says they follow a perfect version of Agile is lying or trying to self-promote themselves to get a job as an Agile coach. I'm in the wrong industry, I think, here. I like to talk about the failures in Agile and I turn up the Agile conferences and talk about how difficult Agile is and the problems we had and why it didn't work. And half the room are looking at me amazed that Agile failed for you and the other half is not in their head going, yeah, we've hit all of those problems. We've invented some of our own problems and Red Hat has a certain amount of uniqueness that other companies do not have, as you can imagine. But there's a story behind why there's a picture of a plane here. So back in wartime, one side was losing the war and a general came to an airfield and said, right, we need to win the battle in the air. So I'm getting all my engineers going to gather around the table and we're not leaving until we have a plan to go on Windows. So he said to his engineers, on this picture of the plane, can you please put a dot where you have to repair most of the damage? And the engineers were scratching their head and they were looking at it and putting dots on the fuselage, dots on the wings, dots on the tail of the plane. And after a couple of minutes they were all nodding and going, yeah, that's where most of our work actually is. And the general said, okay, here's the plan. We're going to put extra armor on the fuselage, on the wings and on the tail of the plane. And we're going to go on Windows war and there was fist bumps and booping and everyone was delighted. And there was one engineer just said, respectfully, no, that's not going to work for us. We need to put armor on the cockpit and on the engines. And the general said, why the hell would we do that? All your friends and colleagues have said, this is where the damage we repair is. And that engineer said, they're the planes that don't come home. So they're the stories that we don't hear, the failures, the problems that we hit. The failures that will not just fracture a team, but will kill any agile transformation that you're trying to do. I've seen so many planes not come back from initiatives I've led. I welcome failure. Failure is actually something that you should embrace because there's a chance to learn. You know, we need to shepherd failure so that our ship doesn't hit the rocks and completely sink. But, you know, getting a light graze is not a bad thing. And this is what a huge problem I have with agile. Everyone talks about how perfect it is and success stories should not be believed. So that's why I'm telling you this is hard. This is going to be a long journey. It's going to be fraught with danger. And we're going to question why we're doing it. And it's about sticking with that for the longer plan. Now, open source can never be agile, can it? I've seen something only yesterday and it said, there's actually a law. The name escapes me. I'll find it later on. That sensational headlines that end in the question mark will really lead to an answer of no. So I'm going to circumvent that law and say the question is actually posed wrong. The problem with agile right now is scrum is so ubiquitous that people replace the word agile with scrum. Oh, we can't do agile because we can't do sprint planning. We're across three different time zones. Agile doesn't talk about sprint planning. Oh, we hate doing daily stand-ups because we have too many meetings. Agile doesn't talk about daily stand-ups. And he can replace Kanban in there as well because Kanban is starting to become more scrum-like even though they're two separate things. It's possibly at odds with our values. We've got a lot of values for being an open source company and open source team and open source project. Could be at odds with them. I don't know. We'll talk about that later. And we don't want to have a style enforced on us because we volunteer. That's absolutely true. Again, you are assuming that we're following scrum and you've got to do sprint planning at 10 p.m. at night when the family are in bed. Stay on it for two hours and story point everything. That is not the case. You can do it if you want to, but that's why open source agile hasn't worked to date because people try and gravitate towards scrum. This is the agile umbrella. It's a very dated picture and now there's a lot more buzzwords could be added to it. The problem with the agile umbrella is people gravitated the bottom row. They look at scrum, they look at XP, they look at, and you remember RUP? They made an agile version of RUP, which is equally horrible called AUP. They look at Kanban and they look at a lot of other full frameworks. Frameworks are fantastic because they give you a set of railroad tracks that once you get on, you know you're going to get off at a destination provided you follow the rules of the framework. It's like taking Angular or React or any of those UI frameworks that are going around in JavaScript land. If you follow that framework you will get a UI, but we don't want a full framework. You can go that route for sure, but when I talk about agile, I talk about the layer above that in the umbrella. Are you capable of doing test-driven development? Are you capable of looking at your overall release plan and trying to break it down into smaller chunks that help you manage the risk, that helps you get features out there faster to the community? Are you able to self-organize as a team? Do you actually want early feedback? We just released the first version of Rohe Gating, which Pierre spoke about in the last hour. We could have waited another three or four months and released the whole thing and realized we delivered the wrong thing. We've delivered this now, we've got great feedback. It might not be the feedback we want to hear as developers, but it's feedback. You've got to take that to good with the bad. What I really like about this, though, is the word sustainable pace. Nobody wants to be working 60-hour weeks and doing the heroics to get a release at the window. This is what agile and the whole mindset actually preaches about. That we should be maximizing our value in the time that we have and actually delivering stuff early enough into the community and to our customers. The agile manifesto is now 18 years old. For those that don't know, in 2001, they got the leading tinkers in the software engineering world, brought them to a ski resort. They got very drunk for a couple of days and they came up with the bottom of this chart. That's pretty much what happened. Because the reality is software is still in its infancy. If you take professions like accountancy, for example, that is in every religious books or text, regardless of your creed. Accountancy is referenced somewhere in there. They have 2,000-plus years of best practices. Software best practices kind of started emerging into the 90s, into the early 2000s, when people got fast internet connections, when they actually got laptops and desktops that they could work on at home, that it wasn't shared resources. They had to come together and figure out, well, how the hell are we going to build better software? This is what they came up with, a set of values or principles which are on the bottom. The interesting thing to talk about is it's one over the other, but that doesn't say we ignore what's on the other side of that. So we still like processes and tools. We still like having a plan. We still like having a contract and getting paid when we're dealing with real customers. But we place much more value on dealing with individuals and interactions, which is effectively what the Fedora community is, dealing with people every day. We want to have small, useful pieces of software being released. We want to have customer collaboration. Remember, this was in 2001. Everyone assumed that people were paying for software, rather than giving it away for free. So customer can be replaced with community or anybody that effectively wants to have a say in what you're doing. And more importantly for me, responding to change. I liken an agile methodology versus this waterfall way of taking an old cannon and I want to shoot Pierre there in the center. So I'm going to line up the cannon and Pierre is still sitting there and I'm lining it up and I'm saying, stay where you are now and we're going to fire it. And don't move when that's going through the air, please. And Pierre sidesteps and we missed the target. That's no good. That was the original plan to kill Pierre. So now we're going to take a laser guided missile, we'll fire it and wherever Pierre goes, we'll hopefully hit him. That's what agile talks about. Sorry, Pierre. HR aren't here, we're okay. So how does all this align? So that's a little bit of history of what agile is and where we're trying to go. The value alignment is actually there. We just probably don't realize it. The last thing you want is a difference in value alignment because one side think you're building a bridge, the other side think you're building a tunnel. This is what happens when engineers and Kiwi don't talk by the way in most products and so on. You get that difference of opinion on it. But you look at the values, particularly for Red Hat and I'm using Scrum because they have actually pointed values versus the agile manifesto which has these broad sweeping statements out there. And it already talks about things like commitment and accountability. And those words are almost there word for word in it. But you look at opensource.com's value statements about open exchange, participation, rapid prototyping is pretty much the definition of agile. Meritocracy and community. Those words and values echo across all of it which for me, when I went to join Red Hat as a company it actually aligned with the value statements I had from working as a Scrum master and Scrum coach prior to that. So I really, really like the value alignment going through it and when we start talking about agile in the context of the words and context they used earlier bringing that into an open source community like Fedora should be very easy and should be welcomed because at the end of it all we're trying to add value. We're trying to do it in a very open way and we're trying to allow more people to participate in exchange information and that's really what our transformation in CP is going to be about. Now agile is all about teamwork and it's that continuous integration kind of chain where we want to continuously plan, innovate, deliver and improve on what we're doing. Now that mindset should not be a mindset that we associate with agile. All good engineers and all good engineering teams should strive to try some of these things. We do want to have a plan so that we can let people know when to expect things. We do want to continuously improve and iterate on that plan. We want to have systems that are integrated so that we can open them to the community, allow more self-serve opportunities in there with the knowledge that you can't break too many things. So this is all good team practices and these are practices that our team CP want to try and embrace and want to try and bring forward with them. But we need to do it together. This is not me going off on my own deciding we're going to do an agile transformation or the team going off doing it in isolation and say hey, like it or lump it, this is exactly how we're going to work with you. We've already issued a lot of blog posts about it. We're opening a Friday with Infra which Mikhail posted only yesterday, I think, to try and open our doors and get people to come in and talk to us and tell us how you want to work with us and how we want to work with you. We are identifying our stakeholders which in fairness as every single community member is a stakeholder. We will take people's view seriously because Red Hat is a meritocracy and that is the definition of a meritocracy. We want to involve them and we want the stakeholders to express their needs. What do you want? Why do you want it? Maybe when, right? Because setting a hard date in the sand can be a little bit complicated because there's obviously other initiatives and things going on. But work with us. Work with us on a compromise, work with us on a plan. How can we break that plan down into smaller, about-sized chunks that give you that value when you want it? So one of the first things we brought in is a requirements gate for the CPE team. And this is to stop the long arm or the law reaching over IRC and tipping someone on the shoulder and say, hey, can you spend the next week or two working on this because it's really important to me and doing that in the vacuum and doing it in isolation. We want minimal information. So this gate should not be too tall to get over. It should be minimal. So what is the scope of what you're trying to achieve? Tell me what it is. What are we trying to do? What's the kind of value output of this and what are the gaps that are involved? Because we need to take that information, bring it in as a team, and talk about it as a team. So we don't want to talk about it as siloed individuals anymore because that is a problem that we've had, and I'll speak about that in a couple of minutes as well. But we want you involved in the process. We don't want the application request thrown over a figurative wall and then you ask us six months later where it is. That's not what we want. We want you involved. We want you to work on the requirements, help us understand what it is that you want from our team and from this piece of functionality. And we want this fair to everyone, right? We don't want things sneaking through the gate like the cow is trying to do there on it. We don't want that, right? We want to make sure that even our own team, CPE, are held accountable to those measures. So any initiative we're trying to draw for self-improvement and organization will be backed by a requirement spec. And those specs right now are on the wiki. So they're completely open. People can come in, get involved, make edits, comment on it. We will have ultimately a better forum for that where people can participate and communicate. But we're doing this openly because we want to do it openly. That's our way. That's our creed. That's our mantra. Now here's the thing. Everybody wants something, right? So our team represents both Fedora and Sentos. We're also paid by Red Hat as a company. They might want something. Rel might want something. Fedora might want something. The team themselves might want to do something because, believe it or not, we have a lot of good ideas within our team. AMD is for improvement, for scalability, for performance. Things that might not matter to you the end consumer until you really need them. So when your builder composes taking 18 hours instead of 18 minutes, that's when it becomes a problem. So like that, everybody wants something. So we have to come up with a means of value-driven planning to assess all of those options and all of those opportunities. And the reality is we're a finite team. We're about 18 to 20 people. We have a mix of responsibilities from an infrastructure side. We're maintaining hardware that's over 1,000 physical and virtual machines to a services side that's over 100 services that we're maintaining. That team is very small. That footprint is very big. That means we're going to disappoint, treat the four of those stakeholders at any given time. Because we can't move those things in parallel, not at the quality we want, not at the resiliency we want, and not at the long-term maintenance footprint that we want. So we're trying to maximize our value because we are snookered like that. We have minimal resources and minimal time. And our mission should be to provide the most value for our time. Deliver the most value for Fedora as a project, as well as our other stakeholders. We're going to have a high priority queue that will be regularly reviewed and iterated on. Items near the top will be much more granular so that we're able to break it down a little bit more, fully understand what it is, talk about when we can hot drop versions of it, staged releases, and so on. Items near the bottom are things we want to do. We know they're important. We're not dismissing them, but we need to spend more time on them in the future to get into that level of granularity that we need. The thing with having what we call a backlog like this is there is a firm commitment if something lands on the backlog and stays on the backlog that we will do it. And that's important, right, because we need to review that backlog periodically, and if we can't do it for whatever reason we should be telling you that to set expectations. Because again you might log a ticket in one or six months later why it's not done while it's still sitting on the backlog. There will be an expectation on you to keep annoying us or annoying your friendly fedora representative and match you and others to say why this is hugely important to you and the community as a whole. So we will have a constant, transparent prioritized queue of work to feed off of. So you should know at any given time where your request is in that, and you'll know how to try and influence and work with us to get that request further up the line. Now where the hell do we start, right, that's a lot of things. Any questions before I move on? So we will talk in a very mature way with the stakeholders. Can you hear me now? Oh sorry. So consensus is a very overloaded word. What do we mean by consensus? Paraphrasing. What I mean by that is having an adult conversation with the stakeholders involved. So the stakeholders will be representative from the sent us project, a representative from the fedora project and possibly representative from Red Hat. We don't know how much of a say they want in her work right now, none thankfully. Also the team are representing themselves. You know we're here with ideas that we would hope other stakeholders would listen to. You know when a very smart engineer tells you that if we don't address this the whole system is going to fall over in two months time we should probably be paying attention to something like that. So consensus needs to be among friends, have a critical look at what the asks are, do some horse trading and try and figure out where the best value for our time is right now. Will that lead to kicking and screaming in arguments? Possibly. Will we walk away as friends? Hopefully. But this is all about transparency and how we do that. Our intention and it's going to something that you mentioned on the first day in these keynotes is to have CPE up on the priority list that Ben is going to send out every week. So we're giving a constant update about what we're doing and why we're doing it and if there's movements in priority the community will know. Now, ultimately we cannot open a priority discussion to the whole world. Maybe we can. We can discuss that in the future. But we pretty much want one voice to represent that wider group and leave that voice potentially open to the world. That's to avoid 50, 60 or 500 or 600 opinions coming in and not getting anywhere. Okay. So for the benefit of the recording and folks at the back of the room the fedora priorities will filter through council. So get on to your friendly council representative, get on to the council meetings, the council list to try and bubble up high level concerns. Obviously at a very, very granular level you don't need to go through council with that. The CPE team are open. We have a lot of open meetings where available for questions, comments, concerns and so on and it just stops match you've been at two and fro with information like that. Kevin. Yeah, and just again to summarize that you know, talk with your fellow stakeholders because this will be transparent. Each initiative for us will have a singular point of contact again just to avoid that blooming comms kind of scenario. So if you do find yourself further down the tree for whatever reason, have a chat. This is where horse trading and you know, among friends can come in, scratch your back, you scratch mine kind of thing. Yeah, so match you was correctly saying that when in Fedora is important because there's time sensitive, there's key dates, there's releases and so on. From our side, when is something we definitely want to know, but when that when becomes a mandate and allowing the sand we can't cross, that's when the whole priority queue can get turned on its head and once everybody is aware that this is now the most important thing we're working on and all of those other things that we were working on have now been bumped down to queue, that is perfectly fine. But when for some people can get translated into a firm commitment versus I would like this in this release or this time frame. Yeah, and yeah, and that should then become a higher priority because of the mission critical and the time nature of it, yeah. Okay, so where do we start? The first thing we've actually done as a team was understand or remit. That word cloud you see there was taken from a spreadsheet that had 112 line items on it which each represented a service or a team that we owned or were responsible for. Some of those things were Fedora infrastructure as one line which is probably backed by a couple of thousand tickets and over a thousand VMs. One line was rail edge which again is backed by an equal number of huge tickets and so on. Some of them are code bases as big as Bodie and Pigour which probably need 8 to 10 engineers each to realize their full potential and so on. Some of these are really really small footprint items but every one of them for better or worse the CPE team has been designated as the maintainer of. I don't know the full history about why we ended up with a lot of them, sometimes it's because we stepped in, sometimes it's because we volunteered sometimes because we were volunteer told. It doesn't matter, right now we're deemed as the main maintainers of them and us understanding that can help other stakeholders realize why we can't do things as fast as they might want. The second thing we done was define our mission and I was really happy to hear the second speaker yesterday talk about missions and strategy and the need to have that statement and it becomes a funnel. For me it also becomes like a lighthouse in the dark that you can figure out exactly where you are and have a kind of true nought when you have a question or a problem. Now I'm not going to read that word for word because it went down in the blog but effectively we had to take a real look at what the mission statement for our team is to allow us legitimately say no to a request. That does not mean no as a default answer it means you as the requester should expect no to be an answer if you're asking for something that's outside of this remit. There are of course exceptions, we will listen, we're not heartless covalent human beings we will take every request seriously but it gives us that level of protection and also allows us address the huge footprint that we have which is what our next phase is at the moment which we pretty much kick started in the last week or so and this needs to be important because and I love this quote there's nothing quite so useless as doing with great efficiency something that should not be done at all. So the view is that we should probably own all of these things for eternity so why the hell are we trimming them when in you know six months time they'll all come back in for us right? It gives us wasting time and it's not efficient but we need to gracefully step away from these things we're not going to do a mic drop and walk out of the room and say hey we're done with this app so we've engaged with Fedora council we've kick started a blog post we've opened a tread on devil announce and we want to let people know why we're stepping away from it what our plan are for those applications and how you can help us. So I think part of what's happening here is not just an agile transformation in the team but that historically this team was kind of thought of as the Fedora team and it may be a little bit the Fedora engineering team but this is a specific intentional narrowing of the mission of the team to focus on this platform enablement mission and that's part of why some of the things that the team owns seem very out of scope with the mission so it's easy to look at them and say what's this crazy badges thing that has nothing to do with what we do why are we doing it this is something that shouldn't be done at all but when those things were created by the team they were part of the scope of the mission so I think it's really I don't think this is necessarily bad in fact I think it's going to get us to a good place but it is a difficult transition because it is a very specific intentional design of the scope of this team which I think will enable everybody to be less stressed out, less burned out more efficient and get more things done and there's a lot of good outcomes but we should go into that really aware of what's happening and then it's left to a lot of the rest of us to figure out what that means for the rest of the project which we should be aware of too and really just to echo that I suppose we're not doing this for the fun of it this is literally to allow us unblock ourselves and actually start adding value to the wider ecosystem and having more targeted it bloomed and grew over the years organically I don't think anybody took these applications on for the wrong reasons they were all for the right reasons and what we're saying is that we still value some of these apps is just we cannot commit to owning them from a maintenance perspective from a backlog perspective and from adding new features and so on and that's what we're trying to avoid with it let me jump back up here so the camera can pick me up easier so our step back strategy right which from a timeline perspective is not going to say we're doing all this in 30 days some of these apps could be here in 6 months, 9 months, 12 months time we've set a kind of upper limit of about a year to give us enough time to help identify new maintainers new contributors to help onboard them in some cases we as a team might need to do some work to help enable them to get that level of access or the level of features and functionality that allows this to become more self-serve so we've had four kind of designations for this the first is to stay the same because this is so critical that also the CP team step away from it the Fedora project could ground to a halt so we'll continue to own it, maintain it, host it and love it the second one is we'll try and host it and we'll do our absolute level best to keep it alive so we'll go in, we'll try and do restarts we'll try and hot fix something because if this goes down it's going to cause problems but ultimately another team or another contributor actually codes against it they develop the fixes, they develop the features we just happily host it for them the third one is you the community will own this so this is where the likes of badges which is very important from a community growth perspective but not so important from a CP perspective we start developing against it and keeping it alive every day and we, Trio Kevin are after putting together an OpenShift instance where we're happy to host it for you we'll provide power and ping, match you so just to clarify CP CP are part of the community they always will be part of the community but the remit of our team within the community is now changing based on this kind of strategy sure and the last designation we're just going to retire this application okay so some applications are on life support they're hanging around with no users it's occupying headspace, it's occupying power we're just going to retire them the thing is, anything we do here it's not an RM minus RF and we're nuking to code base and it's gone forever more yes, sometimes it should be but we will work with the community and like I said we'll get things wrong, we will fail we can change our mind and we'll insist that this is the wrong approach so if you do disagree with an application or a strategy that we've put up, we want to hear from you because we're in the middle of a desert and the only way out is to start walking and we've picked the direction and we've started walking and we might get that wrong and we want that feedback another thing we're starting to do and think about within the teams is defining ready and done we need to know when we're ready to actually start working on something so this is where that requirements gate will come into it, this is where stakeholder identification this is where we prep the team so no longer is it a silo of an individual with that 112 app footprint that we have where each individual in our team owns in excess of 10 applications we want a team to own them for various reasons from redundancy to knowledge sharing to bringing different skills and perspectives to it we want the team to be formed and ready to go, we want this to be prioritized and ensure that this is the most important thing that we get to work on right now then we want to work on it but more importantly we want to know when we're done two of the biggest problems engineering teams face is over-engineering a solution or under-engineering a solution so we're going to do things like acceptance criteria to make sure whomever has requested it has told us in advance that when you achieve A, B and C you know you're done because the one thing we want to do and really get into that habit of is to stop starting so we want to stop starting a load of new initiatives and just start getting things done, getting things to the community, getting things finished and I had this slide about the MVP the minimum viable product and Clemont sent around a great blog post which reminded me of the earliest testable product and there is a distinction here so we want to try and get something in the hands of the community that's usable so if you go and request a car and this is the great analogy to use here and why do you want a car? Well I want to get from A to B faster I want to have air conditioning I want a nice radio comfortable leather seats and it needs to look good so me giving you a tire after the first two weeks of working is no good to you two weeks later you get a second tire and maybe a chassis and then you start getting the body of a car and so on your first iteration might be a skateboard it's going to get you faster from A to B and you're getting free air conditioning and you can get your head and go why the hell do I have a skateboard that's nowhere near what I wanted but it's starting to serve a purpose and then you iterate on that and you might add a steering wheel or make it into an electric scooter or a bicycle or a motorbike and then the analogy starts getting silly but you effectively want to build on it and not discard the prior prototypes you want to use them and try and carry as much forward as you can but not be afraid to try something and get it wrong and learn something and we move forward with it so this is the approach we want to take the earliest testable product and we will advertise and release note that this is not perfect, there is going to be bugs there's going to be problems, it's not what you've asked for but it's enough for you to play with it and enough for you to get some value out of it now where are we going to next one tracker to rule them all so we have Tyga, there's Gira instances there's Gore, GitLab, 400 other ways of doing it I joked yesterday and said we can get a whiteboard and get a camera and hook it up to it permanently and we'll have that as a tracker right why do we want a tracker the big one for me as a team a tracker is hugely important because it gives you metrics you should not make decisions on a gut instinct it should be based on good historical data it allows us to plan better it allows us to self-improve as a team so for example if our tracker is shown that we're getting a huge spike in activity in bugs every single Thursday between midday and 2 or 3pm that should be enough for us to start spotting a trend and say we need to examine this, we need to increase our observability or our logging or resiliency or if that's an open shift let's add an extra pod and start scaling it out and setting specific rules up we can't get that if that's fragmented everywhere or if that's in one person's head or if that's in a tracker trackers also help the community know what's going on so we want you to know what our priority queue is we want you to know where your bug is, what the status of it is we want your input and because this is a community we want your assistance because again small team, huge footprint if we can enable you land a bug or land a PR change we're happy to do that and help so we need to figure out a tracker issue and make that visible so that we can be applicable into all of our other sources of information and we want to do this openly so there's the tree pillars of empiricism which Scrum is actually based upon but it snips Scrum out of the top of the picture because this is not a talk about Scrum it's a talk about agile that talks about transparency adaptability and inspection so we want to inspect what we're doing we want to see what the problems are we want to figure out what each 10 things at once and flip a table you don't know which change is actually taking effect you don't know if changes have conflicted against each other and we want to do it transparently so what we're going to tell our team and tell our management chain and tell our stakeholders should be the same message we're not going to send one message and dress it up for different groups and so on and because we're going to do this in the open you get to be involved with it as well you get to be a stakeholder and see what we're doing and why we're trying to do it and possibly tell us that is a horrible idea because you've done it before or seen it and seen the implications and we want to learn from that and we are forming teams within the CPE team we're moving away from this siloed individual way of working by sharing knowledge Rohit Gating and Bodhi was our first real team and we've had our first real success with that release recently teams work working in silos is horrible for so many reasons for the team and we don't want that as managers and we don't want that as human beings people are social creatures by nature and working in teams helps accelerate everyone's abilities and similarly for the community dealing with an already overworked individual who's working in a silo and you're adding a request to that it's easy to get lost that request can just get sucked into a vacuum in a black hole and disappear at least going into a team there's a higher chance that you'll get picked up but more people have an opportunity to see it and going back to the transparency aspect and the tracker aspect it's there and it's visible and it becomes a hell of a lot easier to action and here's the thing trials and tribulations await us the dictionary definition for those who are non-English speakers and might not have heard of that but I think Peter Robinson used it in one of his titles so it's cool troubles and events that cause suffering changing a way of working making people more self-aware of their actions making people aware of problems that they've caused inadvertently or deliberately who knows right and this is going to be tough it's tough on the team, it's going to be tough on the community and this is what's going to be in front of us it's going to be a hard couple of months as we adjust to this style of working as we hit hiccups and road bumps and we're going to get it wrong and we're going to get it badly wrong and the one thing I would ask for is patients and know that we're doing this for the right reasons know that we're doing it because we love Fedora, that we love the community and that we want to try and add more value to that than the current value that we're adding which is very scattered at the moment and this is a journey for those familiar with business and economics there's this model called the J-Curve Effect or the satire change curve which looks like that and basically people assume that hey Agile it's easy we're going to just jump from our current state to our desired state in a very simple manner we are going to get worse before we get better we have to drop applications gracefully and step away from that footprint we have that's going to drop us that's going to drop our performance or output that's going to cause a lot of heartache it's going to cause the team to feel overwhelmed and it's going to cause the team to feel a bit of despair that's when most teams actually give up that virtual transformation when you're at the bottom of that curve because more often than not you're in the satire one on the right which is oscillating you'll have good days and bad days and it's very hard to know when you've come out the other side of it without metrics how do you know we're a better team we're in an oscillating part on the curve right now so in reality the transformation has begun the ideas have been socialized the team want to move in this direction we've involved the community we're deliberately going slower then an enterprise team and I use that in air quotes would go because we have a lot more footprint we're on a lot more critical path and we have immovable release dates with the likes of the Fedora F30 F31 F32 all well advertised and we know what's going to happen so we are in the dip how far down who knows because this is an imaginary model that we have on this here but we are going to have we are going to have good days and we are going to have bad days with it and that's going to translate into weeks and months but the reality is by the time we're at flock this time next year we should have seen massive improvements in the team the average duration of an agile transformation is 12 to 18 months and we're maybe 3 or 4 months into that so we still have a long way to go on it now get involved right so again we welcome involvement we want to share blogs, share your thoughts catch any of us that are here at the conference join our meetings and our intention is to hold all of our agile ceremonies in the open we want to share our backlog we want to share our board we want to get your input we want to get your help feel free to progress anything you want on that backlog that will mean that we have to change as a team we need to be more self-service we need to be more enabling of the community we need to remove ourselves as bottlenecks part of that removal of bottlenecks is moving away from total maintainership of those 112 plus applications that we have there so that is me have we any questions I know we took questions during it yeah, to the back so the question is is this agile transformation for all of CPE or just the Fedora part and the answer is all of CPE so we are unifying as a team we don't want an us and them kind of scenario so one thing that Jim and I in particular have focused on is trying to have a shared methodology and understanding and approach so that we can help each other going forward and the thing with where we're going and where we're heading to and so on it's like how a GPS works so I live in Ireland, I want to head from Waterford to Dublin, I pop into GPS for how I get into the airport and that will take me and hopefully the most efficient path forward right, but I'll go on that path and I'll get distracted and I'll see something shiny and I'll pull off the motorway and I'll head a completely different direction and the GPS starts screaming at me to turn around because you're gone off the path right, you're gone away from that plan and if I don't turn around it'll eventually recalculate and we'll pick a new plan and that's the approach we're going to take to this right, so access to team members, access to services access to questions and answers that you need in a timely manner we want to have all that and we want to have it right now and we know that that's on our plan that might shift as the GPS moves and we take a different direction and a different path forward on it, but we're not going to move away from that end goal of where we want to go to we're just going to take a very windy road of getting there but it's great that people know where we want to go now and we're doing our level best to do that, but if people are still concerned about specifics that's where we engage, that's where we talk because I don't have all the answers, the team don't have all the answers and I think if we did it would be a very poor agile transformation because we've done this in a vacuum and done it without talking to our main communities so this is stage one in that kind of plan okay I'm happy to wrap it there, we'll grab coffee I'm going to be around for the next couple of days if people do want to catch me and thank you for your time in attendance, appreciate it