 Hopefully you're here to talk about getting rid of Agile manifesto principle number 11. Everybody's on board with that Let's get rid of it So I'm Ken France with C prime I've met some of you this week. This is my first time to India. I I feel like I fit in already. I've been here about a week and a half I've adopted the local cultures. I can cross the street without a local with me now I can actually get across the street on my own. I Even drove a rickshaw myself for the first time last night Not true. Not true I'm not I don't fit in that well yet It's just a little bit about me. I've been a Agile software development for a lot of years originally as a practitioner and now as a coach So it kind of came up through that worked on large air traffic control systems initially and then I've helped clients across a variety of Industries as you see up there So we're gonna go through a little introduction of the problem. We're gonna talk about today I'll actually go through a case study of one of our clients that went through this journey as well And then I'll just talk about some of the best practices not only that that cop client applied But some other best practices you might want to think about yourself And then in the conclusion we'll decide whether or not principle 11 should really go away Okay, so the agile manifesto. I'm sure you've all heard of it. Hopefully Principle number 11 of the manifesto says the best architecture of requirements and designs emerged in self-organizing teams All right, so by the end of the session we're going to decide if that's really true can that happen at scale That was that what the manifesto was created for individual teams in mind really an individual team They should be able to emerge their own architecture. Well, what happens when you have 200 teams a thousand teams Should we just let it be a free-for-all? Everybody go ahead and figure out what their architecture should be go ahead and build it If you've attended some of Jez's talks today He talked about the goal is eventually you want to get to the point where individual teams are empowered to make decisions They have some control over how they deploy how they consume services How they emerge their design But can we just let teams go and do that on their own? Or do we have to give them a little bit of guidance for how to do that? So we'll go through this discussion talking about can we actually scale up architecture and design to large enterprises I've started a petition outside that will send to the agile manifesto sign ease That if at the end of the session we feel like the majority feels like we should get rid of principle 11 I'll have you all sign it Okay, and we'll send it to the authors and see what they say deal Let me jump right into the case study So there is a large retail organization with about 18 million customers About 2,200 stores 68 billion dollars of revenue and about 300,000 employees Sight spread across the United States and in here So a very complex environment The scope of the engagement was across their IT strategy security Operations enterprise architecture a very broad set of technologies and you can see some of the sample technologies that were involved there They had been applying some lean agile concept at a team level for a lot of years But now they were trying to scale it They were trying to take some of the success they had had on a small scale and scale it across the employees and the Systems that you see up at the top. And so obviously having been in business for a while There was a lot of legacy applications. There was a lot of legacy processes There was a lot of dysfunction in the way that organization operated And so the job was to take them from where they were instead of challenges that they had Projects versus products, right? You've probably heard about a lot of these challenges throughout the day How resources were assigned to those projects? How information was shared between them? How they deployed software slowly with errors Decisions were not data-driven so they were made largely by whoever had the most power or ever had the most authority to make those decisions And as we'll focus on in this discussion the last bullet Their architecture was centralized Right a very few people made a lot of the decisions and so the teams were not empowered to make decisions They had to go back to a centralized group So their architecture looked like this They had a few enterprise architects That put out some best practices You know define what the architecture was going to be and then establish review boards basically to ensure compliance with those rules So the solution teams that were out there trying to get software off the door fast in order for them to do pretty much anything They had to go to the architecture review board and get it approved So how fast do you think that was? Not very fast very slow right not empowered lots of interrupts lots of Decisions by people that maybe didn't have the local context completely to understand what needed to happen So it was a very inefficient process How does work come into the process? Well at the bottom you have all these different engineering and operations groups that would get possibly Production support items coming in new requests coming in And then you have the solution teams that were responsible for building it and what you ended up having was a lot of different point-to-point communications and discussions happening But there was not a centralized prioritization mechanism There was not a way to For the teams and solution teams to really understand who they needed to talk to within the engineering and operations group So it was sort of chaotic that everybody was talking to everybody And it got to the point where the solution teams would pretty much just say just just give us what you want us to do And we'll figure it out because they just couldn't deal with you know dealing with all those different folks at the bottom Then going back to the previous example when they finally did decide how they wanted to do it How they thought was the right thing to do it They had to go to the architecture review board to get approval before that I could actually head down that path on their solution So the very slow very error prone. So what do we start to move them towards? The the desired target state was a more decentralized architecture function Where you had a product owner a product manager somebody Centralizing the requests coming in and I'll go into more detail in that second a Principal architect responsible for longer-term architectural strategy, but then they coordinated with Domain architects that would work closer down to where the work is happening So you're starting to see the architectural decisions get distributed out They in turn would work with no architects possibly even embedded on solution teams But if not working very closely with the solution teams That again were aligned to the architect or architectural concepts and principles coming from the architects above yet they were now empowered more to take action make decisions and You'll see some of the other things that were put in place to really start to Ensure there was compliance to the architectural standards because they were offered as services as opposed to just standards So what intake started to look like is work would come into a centralized function Some of that work that was ready to be worked on from a solution perspective would go to the solution team Other work that needed maybe some architecture or runway some additional work before the teams are ready for it Would go to what was called a system team to start to work on centralizing some of that work there And I'll talk about how they started working with this engineering team So basically you started to have more coordination and distribution of responsibility Happening between the system team and the architecture team that would then feed services to the solution teams that would consume them And how did that start to happen a service catalog was created so basically a set of services that would have strapped these engineering services and What they would offer the solution teams to the point where if some of you attended jesus jesus converse presentation a few moments ago He would talk about this concept of if you have to ensure a compliant if you have to assure alignment to architecture Embedded in the services you're creating and then the people consuming those services in the service catalog can know that it Corresponds to the architectural standards because it was already validated that it does you no longer had to go to Centralized review board to say is it okay to head down this path because it was already approved tested vetted and the service catalog So those engineering service engineering services started to operate in a more templatized way So what there would be they would take and codify not only how to build infrastructure, but the services in templates They would create reusable components that those solution teams could then just plug together to satisfy to build the solutions they were building and And they basically would be able to get work out much more quickly and high quality by consuming these services As opposed to having to build them all as they had in the past the system team If you look at this system team think about it as a way to start to enable the teams over time to become more and more Self-sufficient and the early times because teams didn't have the skill set yet to build these services to do test Automation to do some of the things that would really lead to continuous integration and delivery So initially the system team had to stand up those capabilities for them and then teach the teams how to use them Okay The goal was not for the system team to do these things for the teams forever. It was to enable the teams So stand up a continuous integration server teach the teams how to use it Stand up a continuous delivery capability teach the teams how to use it Build a test automation framework that tests various layers in the architecture and teach the teams how to use it So that over time the teams become more and more empowered to take that work on themselves And not having to centralize it within that that system team that was supporting them So you can see build automation infrastructure as code test automation all these different capabilities The system team help enable the teams with to allow them to take more and more responsibility for the work themselves And so ultimately and they're still on this journey So it's not completely done yet moving to a multi-cloud and a microservices architecture That initially was centralized in its and its conception and in the initial creation of some of the services But then decentralized as those standards and services were created and validated so the teams now had the ability to Take some of that responsibility on themselves without having to go back to the architecture board over and over again KPIs and metrics started to emerge to really judge the health of is this team producing value on a regular basis Are they seeing the throughput? There's a lot of talk today about how do you measure teams and we don't want to measure on velocity? Right, so let's measure on how how frequently are we releasing? What is the throughput of features going through those teams? How quickly are we producing value? Let's let's measure those things So the whole goal was to upskill the teams make them more self-sufficient More capable of building a lot of this themselves So that's the client journey that they went on Now what we're gonna do is we're gonna talk about some of the best practices some of which I covered in there But we're gonna talk about a little more formally a lot of the best practices I'm sure many of you have implemented some of these yourself what I'm gonna focus on in this and the rest of this the talk here today is Agile architecture concepts and how some of those concepts scale Built into this to save the scaled agile framework And so safe talks about agile architecture as being a set of values and practices that support active evolution of design and architecture of a system While implementing new system capabilities So the whole concept of agile architecture as you want it to evolve over time while you're still supporting existing users You can't stop all development say we're gonna rearchitect and then start development again You've got to continue you've got to rearchitect While you're building new capability and supporting the current capability and it's all about continuous delivery and continuous flow If you're not an expert in safe just an overview There's four levels in safe a team level a program level a large solution level and a portfolio level And you can see there's architect roles embedded on each one And there may even be architects embedded on teams Enterprise solution system architect at each of these levels So going back to the concept I talked before You can't just let every solution team out there go to find their own architecture You've got to have some guardrails Some things in place that people will conform to So there's this concept of intentional architecture, which says here's the guardrails Here's what we're going to put in place to make sure we're all operating on a common set of architectures Some of you may that are familiar with safe You may know that one of the constructs that we'll mention here is something called an agile release train Which is a team of teams construct So you can almost think of the our attentional architecture and the architecture runway That's created from that as the tracks that the train runs across Then in order for the train to move forward there must be train tracks in place Well, who's going to decide what those train tracks looks like that's going to be some of the jobs of the architects at those layers Within that intentional architecture within that architecture runway teams then have the autonomy to emerge their design against that architecture So that they can start to operate more autonomously and still have flexibility to have, you know Local knowledge applied to what they're doing But they're doing it within the guidance of keeping everybody on the same page and make sure you can interoperate interoperate with each other So the balance between these two is the key You don't want to do too much upfront because then you're back to you know big upfront design But you also can't defer too much for the teams to figure out because then you don't can't interoperate and there's two Then you can't can ensure standardization So I'm not going to go into great detail, but each of those architects has a set of responsibilities There's certain things that they are responsible for That their job is to not only make those decisions But then rely on excuse me then take ownership of communicating that and staying aligned with the architects at the next level So that they can in turn continue to move that to the teams And you may not need all these levels in your implementation. This is the The scenario we're using all four levels So you may be using different versions of this and your enterprise depending on your complexity Those architects then operate across many different domains You may have business architecture information architecture application architecture technical architecture Each one of them is responsible each one of those domains has a different set of concerns and The architects may take different actions and use different tools based on those The enterprise architect is going to cut across many value streams They're looking at the big picture across many value streams within the organization Whereas the solution architect is going to focus across many systems within that and then a system architect may be looking at a single system Or a much smaller number Okay, so it's all about the span of responsibilities. They have so then there's a collaboration that takes place Notice I use the word collaboration not review board, right? It's not a it's not a Governance or compliance. It's a collaboration so that everybody understands what we've defined What their role is in it and ultimately for the teams how to implement it? So it's the collaborative aspect of These architects working together with each other and then in turn them working with the teams To make sure all of this is working well together architects role in DevOps Ultimately our goal is to get software out the door Okay What kind of things generally tend to hold us up and getting software out the door? How many folks have to go to architecture review board still today? How many folks have to wait for some other testing group to test your code first? All right, and I'm sure you could all come up with other examples of things that That you have to go and get approval for some sort before you can actually deploy So the goal in DevOps obviously we want to have this continuous delivery pipeline where we can get out the door very quickly So the architects role is really to help facilitate that at the end of the day making the solutions easy and obvious You know building components pre-built components together already defining standards Platform as a service and infrastructure as a service When it talks about the epic owner it means be the champion to establish those capabilities Right build those platforms that can then be consumed by the rest of the teams to really accelerate everybody's delivery out the door I like one of the One of the things just said earlier today that one of the biggest inhibitors is is change management Which basically makes sure that you don't change anything right Change review board is another big source of slowing down flow So how do we really make sure you know we get through that process? So really architects become the champions for DevOps to make sure that we're architected in a way that's going to allow us to do that So really at the end of the day architects really focus on enabling the teams And so a lot of what they do could be categorized as what safe calls enablers Enablers are really those things the infrastructure as a service those things those Prebuilt components a service catalog those are all things that in and of themselves in of themselves They're not directly delivering the business value that the end user wants But they're enabling us to do that faster because as a solution team my whole focus should be to get that business value out to the end user So the more that I can go to pre-built components and pull them and integrate them together and test them The better I'm going to be in that and so ultimately I lead to a model where I have Architects focused on how best to get this business value out the door that I see in my roadmap And the best way to ensure that we're getting the business value out quickly is to make sure that we're doing enablers Just in time for the teams to use and consume them Again, we're not too far out in front But we're getting there just in time that the teams have what they need to deploy the business value that they have So you you're able to incrementally look at and deploy enablement work through that architectural collaboration Just like you're able to incrementally deploy your business value And those two stay in lockstep So we have some architectural patterns in place We've had collaboration We're starting to put some infrastructures and service or infrastructures services in place Now when we're talking about executing day-to-day we have our plans We're executing day-to-day now what do architects do as the teams are actively coding and building? Well, they're helping remove those technical blockers So teams run into challenges. They're not fully enabled on a technology. They need help Architects stepped in and enable They help facilitate, you know, point-to-point communications between teams that need to collaborate Again, that could be done either by being embedded on teams Or but just by helping coordinate outside of that Some of the individual teams may actually be working on building some of those enablers Right, it's not necessarily the architects themselves that are writing the code for those enablers Some of those are actually going to some of those teams that have the capacity and the skills to work on those So those architects could be working with those teams to help them implement code and test them quickly Even by pairing with them on them So by enabling the teams to build some of those architectural components They'll be able to build more in the future easier to again continue to Allow everyone to be taking advantage of what those teams are building and this is something that For a long time was missing inside of the scaled agile framework There was a lot of collaboration happening around The scrum master and the RTE roles and the teams and the product owners and product managers But there wasn't a place for architects and and technical people to come together and synchronize on a regular basis So there's a new concept called an architect sink that basically allows it's a time and place on cadence for architects technical sneeze to come together Collaborate and align on strategy notice. It is not a review and approval board. You're not bringing your design for approval Okay, you're coming to learn about that intentional architecture You're coming to learn about what new services are being built You're coming to learn about or help contribute to what should the road map be for that enabler work So that we're building it properly and building it just in time for the teams to consume it So it's it's a more formalized way to facilitate that technical dialogue and communication That oftentimes happens in a very haphazard or non coordinated manner but the ultimate Sign that we're coming together is to be able to demonstrate value Okay, we want to get off the door as quickly as we can but as we're building these large complex systems Let's make sure we're demonstrating that on a regular basis You all familiar with the iteration review that happens in a sprint The system demo happens at the next level up the program level where you have multiple the output of multiple teams coming together Right drive to a demo On a very regular basis Same thing happens at the next level as you have multiple release trains So architects working with the system team can really help make sure we're driving to these milestones facilitated by that architect sync And allowing the teams to have that collaboration and demonstrate the value and get feedback and be able to adjust quickly to that Feedback as they move along So in conclusion How many people think principle 11 has to go you're going to sign my My petition out here anyone One person still think it has to go. Okay. He's a plant. I planted him So obviously principle 11 does not have to go right Conceptually the principle still makes sense, but you have to evolve it at scale Right, you can't let the teams all do their own architecture. So you have to figure out the proper balance between upfront centralized intentional architecture And decentralized emergent design based on the standards the guidelines the services produced by that That collaboration don't just assume it's going to happen set a cadence Right to find when those architects are going to come together with the technical smears from the teams to maintain alignment Don't make that just a firefighting meeting I've seen lots of organizations that they have what they call a tech triage or uh, you know The technical folks are coming together to put out fires Right make this a strategic meeting not a tactical firefighting meeting. Okay And then at the end of the day, you don't have to get it perfect up front Great is the enemy of good get started make some incremental progress and hopefully you'll improve your continuous delivery pipeline We have a few minutes for a question or two Five minutes any questions Yes, correct The the uh observation was the architect sink was not part of safe 4.6. That's correct. I am giving you a preview here I got it. I got special permission from scaled agile to give you a preview of something that's coming This content you might have seen a newly released safer architects course So these are this is some content from the safer architects course that's going to be in the course Before it officially makes it in the framework. So yeah, you're getting a little preview here. I meant to mention that earlier. Thank you This is a preview. Yes Yes Yes Yeah, I think a lot of the challenges that you had to overcome were just cultural, right that um the The architects that that traditionally would make those those centralized decisions had a hard time giving up some of those That decision-making criteria to the other architects. So I think it was just realizing that um In order to be able to leverage some of the more local information in the different domains And as you got closer to the teams the enterprise of the principal architects, you know Couldn't be the decision maker for all of those things that they had to allow some of those decisions to be made locally with some Guidelines from the higher levels. So I think the culture was a big part of it And then just really you know a little bit more formalizing when that interaction and collaboration occurs and really defining the boundaries for each Of those roles was a key part of that Yeah, so the the comment or the question was that that architect sink If not done well could look just like an architecture review board that you're used to having so what are the best practices around that So the so the first is is literally in the name itself, right as an architect sink You know so changing the name Um and obviously I only showed you a highlight of it But there's much more detail on on how you run the meeting and what it looks like So I think at the end of the day, it's it's understanding the context of the purpose of that meeting is to You emerge and evolve the architecture not to ensure compliance to the architecture That's correct. Just like the rte and st e facilitate improvement. Same thing you need there Absolutely. I think we have to cut it off. I will be outside for more questions. Thank you for coming