WEBVTT
00:00:00.000 --> 00:01:15.510
Thanks. Hello, everybody, this is Kurt Bittner, and I'm standing in for Dave West today on the Scrum.org Community Podcast. And we have usually this is an outgrowth of a conversation that my fellow podcasters, Peter and Thomas had a couple of weeks ago. And we thought, hey, this is really interesting. Let's Let's expose this to a broader audience and talk about some interesting topics. And our topic. Today we're going to talk about agility and software architecture, and try to figure out how agility and software architecture fit together. Are they complementary? Are they competitive are they complete anathema? So with that before we get started, so I'm, again Kurt Bittner I've been with scrum.org for I don't know, probably what, since 2016. But after a long, long period in the industry, and my interest in scrum.org have mostly to do with scaling, agility to enterprises, and leadership and various topics.
00:01:11.700 --> 00:01:22.950
And so I think architecture fits really well into that. And we'll talk about why I think that and why Peter and Thomas think that But Peter, Thomas, why don't you introduce yourselves?
00:01:24.420 --> 00:01:40.019
Yeah, awesome. I can start. My name is Peter. I'm a software developer. I've been in the industry for the past 20 years. I have mostly worked in Agile teams working with Scrum.
00:01:41.189 --> 00:01:49.379
And I'm a professional scrum trainer. I've been a professional scrum trainer for the past, I think for the past 10 years since 2012.
00:01:51.840 --> 00:02:52.439
Yeah, and I'm Thomas. I also scrum trainer since 2010 for Scrum.org. My favorite training is the APS - SD class, which is all about how to really apply software development practices in a Scrum context. And as Peter, I'm really passionate about software development, or the technologies stuff, what you can really achieve and how you can tie these things into an HR environment to really build great stuff. And yeah, software architecture definitely is a very important topic in this area. And it is something I really love talking about, because here's so many misconceptions about this. And I hope that we can create some more clarity around the topic during this podcast.
00:02:53.520 --> 00:02:59.699
Peter, Thomas, before we go further, maybe you could expand the acronym, APS- SD.
00:03:00.360 --> 00:03:03.539
Oh, yeah, it is.
00:03:00.360 --> 00:03:08.340
It's even a long acronym. It stands for applying professional Scrum for software development.
00:03:08.639 --> 00:03:21.060
That means it is a training, Scrum.org offers with a very distinct perspective on software development, and how to apply scrum in this context.
00:03:24.569 --> 00:03:53.520
To start off our conversation, and this is where we started on the phone a couple of weeks ago, that it always seems to me that architecture is regarded by many people as a kind of taboo subject for agile teams. And I'm wondering what your opinion is, is that, you know, how did software architecture come to be so unappreciated by teams, what, are they missing something?
00:03:50.759 --> 00:03:57.360
Because I know all of us think it's important. But a lot of people don't share that opinion.
00:03:57.419 --> 00:04:03.090
And I'm curious what you think, you know, how did we end up there? You know, what are people missing?
00:04:05.310 --> 00:05:26.670
I think it is a problem that we created ourselves. We meaning scrum practitioners and agile teams and people working in Agile teams. Because often we hear of a concept or we read of a concept, but we don't really read the article, we just read the headline. And I think when people read about emergent architecture, and they read about Iterative incrementally building software, and continuously improving that they incorrectly assumed that software will, software architecture will just emerge from nothing. So and I think that's a big misconception, and it is, in my opinion, it's more like a counter movement to the very strict software architectural practices from 20 plus years ago, where Are, we had, like these big phases where we did analyzes and design. And we made all these charts and how to how to cut off the building blocks of our software. And we assumed, or many people assumed that software architecture will just take care of itself, which is true, some some architecture will emerge. But it's, it will most probably not be the software architecture you want to have.
00:05:27.930 --> 00:05:30.779
And that's really go ahead.
00:05:32.040 --> 00:07:10.920
Just to add on what Peter just said, I think, in the old days, it was exactly that we tried to design a software architecture, that is a perfect fit for the software that we are building for the problems that we are solving here. And that was a great for the old waterfall approaches, because that requires that we know all the requirements for the software upfront before we can come up with a great software architecture before we start implementing it. So once we transitioned in an agile way of way of working on planning, we agreed that we cannot know all the requirements up front. And I think that is probably a huge challenge that emerged there to say, okay, how can we then create the perfect software architecture for a software product if we even don't know all the requirements, and I think that is probably a big change. At least, it was a big change, for me to really realize that we have to think of a different type of software architecture, when we work in an agile way, it is probably less on finding the perfect software architecture to solve a specific problem. It is more building software architecture, that is evolvable, over time that allows us to adjust to ever changing requirements. And I think that step is probably also part of the problem.
00:07:12.120 --> 00:10:29.250
Yeah. The other thing, I think that is also I agree with what both of you say and the other misconception, I think is, is even with that older conception of software architecture, because the belief that you can somehow take a set of requirements, and come up with a perfectly for perfect solution, without actually building and testing something is a fallacy. And so, you know, when we used to build systems, and I have to maybe have the disclaimer that I've never actually worked on a waterfall project, even going back to the early 1980s, I was always building things incrementally and iteratively. And part of the reason for that was that I was doing things, you know, on hardware that had just come out, I was doing things with problem domains that weren't really well defined. And so the only way to do it, the only way to successfully build something was to build it, incrementally test it and keep refining that. But in the process of doing that, I discovered some of the problems with emergent architecture of my own because the the for me that the essence of architecture is not about what we used to think of as diagrams and, you know, Architectural Review meetings and, and other kinds of things like that. It actually is the decisions that you're making, about what you're building and how you're going to do that. And so I've always found that you couldn't make those decisions without the kind of information you get from building a little bit of it, and then testing it out. And then evaluating your assumptions. And so that that notion that architecture is about decisions is something I've I've been writing about lately. But I think it's it's an interesting thing to build on a couple of things that you both said, you know, Peter, your comment about, you know, you'll always have an architecture, the question of whether it's good or not, is sort of the thing that you're trying to achieve. And I think out of out of building something, you can figure out whether it's good or not. And so I tend to think of traditional architecture as being a lot of unproven assumptions about how things are going to work. And the only way to test those assumptions is to build a little, a little bit of it, not all of it, but build a little little bit of it. And so, for me, I find that there's a perfect fit between Agile processes and Scrum and architecture because well you know how I mean scrum basically says you need to produce something valuable and working every Every single sprint, well, you know, here's your opportunity to build a little bit of the solution and test some of your ideas. So I think that that's it. For me, it's not so much that actually, it's the opposite of architecture and agile don't fit together. It's like they fit together perfectly. But it's because of a mis misconception about what architecture is and how you do it. So I don't know what of your experience has been with that?
00:10:30.210 --> 00:12:11.909
I would, I would like to, to pile on top of that, because the one thing you said about decision making, this is the core of architecture in my understanding as well. But the question is, I mean, when we, when we create software, we make decisions all the time. So the question is, what what is architecture? Like? How is architecture is different from all of these normal decisions that we take. And when I think about that, I always use a very loose definition. And this is, architecture is about the important things. I think Martin Fowler said something like that, and I really liked that, because it's about those things that have a high risk or a high cost of change, if we need to re evaluate them if we need to redo them. And, and I think that that these types of decisions qualifies architectural decisions. And then the question is, I mean, when do we when do we decide on these important things, whatever important means, and in my opinion, there is something that is quite underappreciated in most Scrum teams and from from my experience, it is that the product owner has a very, very important part when it comes to software architecture, because it always starts with what is the vision of the product? What is the most important or what are the most important 123 Maybe five quality criteria or quality goals that we want to achieve?
00:12:08.070 --> 00:12:59.129
And then we optimize our important decisions on reaching these goals. And in my opinion, this is something that many product owners do not appreciate enough, many Scrum teams do not appreciate it enough. And I would like to, to have and work with product owners who are more interested in what is the vision? What are the quality goals? And then what what type of architecture do I get, because architecture is not something that is hype driven, or that is where we use the technologies that are currently on voc architecture and software architecture in particular, is something that is dedicated to solving a concrete problem to reach a specific quality goal or quality criteria.
00:13:01.200 --> 00:15:10.139
And I really liked the part where you were talking about the validation because I, I couldn't agree more that all those decisions we are making are based on various assumptions and those assumptions can be true or wrong. And the validation part is really important and I have been on traditional waterfall projects and I can I can really if I think back to those days, it was very, very late in the project, when we were really able to validate those assumptions. And it is I think, by nature, in the tradition of waterfall, you try to prepare all the decisions with a lot of analysis thinking around it. So, your expectation is that you have considered everything which is in fact it is impossible in my opinion, that is probably the big misleading idea behind the traditional waterfall that we can if we plan carefully enough we can come up with all the details then we have to take into account and if we later find out that we took wrong decisions, then probably our planning was not good enough you should do better blending next time and then it will work. That was probably the biggest misconception in the old waterfall days. I think it is exactly what you said that we have to validate those assumptions and course correct as early as possible in our development cycle. And that is only true if we are actually building software if we are building working software and that is the essence of Agile and Scrum for example, that we in small increments have something where we can validate assumptions and this is not only assumptions in regards to the requirements or business value, but also our technical assumptions in regards to software architecture.
00:15:11.759 --> 00:16:00.089
Now, there are a lot of interesting things. And in what both of you said, I think one of the misconceptions that people have about architecture is that, that in a sense, if you think about the suitability for agile, we often talk about that we're dealing with problems in the complex domain. And architecture, especially in today's world is especially complex, because there are very complex interactions between user workloads, response times, memory, throughput on networks, latency of networks, you know, compute power, use of all these different components and services from different vendors.
00:15:53.759 --> 00:16:00.298
It's not predictable at all. And all
00:16:00.299 --> 00:16:14.009
those parts you're mentioning are changing all the time. So it's not a stable system. Inside we are planning and building stuff.
00:16:08.340 --> 00:16:17.070
It's all changing apart all the time. And that even increases the complexity, I guess.
00:16:17.850 --> 00:18:19.650
And the interesting thing about something tying that into something that Peter mentioned, is this notion of quality goals, or in some of the writings I've been doing with another colleague, Pierre pure, we've been talking about quality attribute requirements, but what that basically means is that, you know, what are our goals for, you know, response times and for number of users and for throughput, and for, you know, even some things like, like the, you know, the maintainability of the system, and supportability system and resiliency. So oftentimes, these architectural qualities, you know, you talk about LEDs, and English and, and that, that notion of having quality goals, and that the architecture is focused on the quality goals, and, and the functional requirements are focused on maybe more behavioral goals of the system, I think is an interesting addition for people. And I find a lot of Scrum teams don't necessarily even think of quality goals, but that, you know, to both of your points, that's, that should be something that the product owner is very concerned about, and maybe even puts those things on the product backlog. To say, you know, there was another thing I wanted to add, in addition to that, and that there's an interesting concept called the last responsible moment. Because you know, that saying, We have to meet all these quality goals might lead some people to say, Oh, we're gonna spend our first you know, five Sprint's dealing with quality goals, and then we'll deal with product, but you know, the more functional requirements and that's not, that's not right, either, because what we need to do is that we want to postpone decisions as long as we can, but in a responsible way. So that, you know, the question each sprint is like, Okay, here's this quality goal is that it's anything that we would do in this sprint going to potentially lock us into a particular solution, or maybe prevent us from achieving this quality goal? And if the answer is no, nothing will do in this sprint would would lock us in, we still have complete freedom on that.
00:18:19.769 --> 00:18:57.029
Great, then we don't have to deal with that right now. But if you say no, you know, in order to to achieve this particular product backlog item, or this group of things, or maybe the sprint goal, we're going to have to deal with that latency issue to pick an example, then, then, okay, that's going to have to, you're going to have to do some architectural work in that sprint to do that, because the cost of delaying that decision is too high. You might you might have to rewrite everything, you know, if you find out a different answer, you know, five, Sprint's on, you might have to rewrite everything you've done up to that point that would be very responsible.
00:18:57.569 --> 00:20:13.589
So I think that notion of quality goals, and then thinking about what's the last responsible moment, or, you know, do we absolutely have to handle this issue in the sprint in order to have a sustainable solution. And using that as a filter on on the sprint planning is, I think a really interesting way to think about doing the architecture work instead of loading it all upfront. Because sometimes, you know, you, there's an interesting interaction between between functional requirements and those non functional or architectural quality goals is that is that sometimes in order to achieve a particular, you know, sort of user oriented outcome, you've got to solve some particular architectural problem. And so that the two of them interact, it's not like you can deal with all the quality goals first and then and that was sort of that I think the problem with with the waterfall approach architecture is that they they tried to solve all the quality gold problems first in some big design, and then build the funnel nothing's on top of it. And what usually found out this time, as you mentioned is that some of your assumptions turned out to be false. And that content causes you to completely rethink. And the later you find that out, usually, the worse it is.
00:20:15.599 --> 00:20:28.529
And I think this quality goals also play a very important role. In the evaluation part, they allow you to close the feedback loop.
00:20:23.279 --> 00:22:02.819
Because if you want to validate the decisions you made in terms to your software architecture, you have to come up with specific questions. Did this decision make our system no more resilient, more secure, more maintainable, whatever your quality goals are, and those quality goals give you the right questions to ask to validate your architecture decisions. And I think that is probably even an opportunity where you cannot only involve the product owner in this kind of conversations, we could even go one step further and include our stakeholders in this to say, Okay, we have now changed over probably the course of a couple of weeks, this architecture things, do you feel this products closer to the quality goals? Does it feel better to you? And what are the next goals that we should focus on? Where should we try to make the most improvement in two, and for example, that could be an amazing conversation during a sprint review. To come up with this kind of discussions, if you just share with stakeholders that you choose platform, a Overbey. Because of this, and that technical reasons, there will not be a conversations with them. But as soon as we bring in those quality goals, we find a connection between the technical world and the business world.
00:21:59.130 --> 00:22:04.230
And that is what the quality goals really do for me.
00:22:06.000 --> 00:22:33.690
And I what I what I really like about this idea to bring it back to the product owner and to the stakeholder or stakeholders is that we can also talk about the trade offs that we have to make. Because if I asked my, my customers, do you want to have it secure? Yes. Do you want to have it maintainable? Of course? Do you want to have it reliable? Of course, do you want to have it performance efficient? Yes, I want to have that. But you want to have it functionally correct?
00:22:33.720 --> 00:22:59.849
Yes, I also want that. So if I give them a catalog with all these abilities, they want all of that. But the question is, if we if we make it a bit more performant, if we if we improve our resource utilization, but that in that impedes our maintainability, is that alright? So that we want to take that trade off. And this is something that I really liked discussing this, because this is often it's a business decision.
00:23:00.539 --> 00:23:04.230
It's not a technical decision.
00:23:00.539 --> 00:23:07.200
It's a decision that we have to make with the stakeholders with the product owner most probably.
00:23:08.009 --> 00:24:03.029
And I really like this type of conversation, because it makes it more graspable shell has introduced scenario based modeling in the 80s. They have, they have used it for many different things to for example, to model the, the the climate change, or to model political development in different countries. And the interesting thing about the scenario is that it makes something abstract concrete. If I talk about maintainability, I can I can wholeheartedly say, Yes, I want to have it maintainable. But if I have to make it concrete, and make it clear, what is this maintainability that you're talking about, then I need to find the concrete scenario, and this is something that really helps in in talking about this.
00:24:03.029 --> 00:24:40.410
So if I say we would like to be able to, to add a new language to our website, in within that most five working days and this should be should be mostly done by one person. So this is a concrete scenario. And then I can look at the decisions that I have made in my important decisions. I can look at them, and I can figure out or I can think about if if I think it plausible and probable that we will be able to make that quality goal or scenario. And if not, then we have to maybe we have to adapt something, we have to change something.
00:24:41.609 --> 00:27:34.740
I really liked that. And one thing that I think is is important too in the quality goals is that is that they're not binary is that it's not it's not performance or not performance. It's you have to be very specific about what you mean by performance. What you mean by responsive what you mean by maintainable no This scenario has helped you to be more specific about that. And then back to Thomas's point about validation, you can, you could validate that, okay, during the sprint, we tested that scenario, you know, we ran through and we made the kind of, let's say that you want to make the system very maintainable for certain kinds of changes, like, like changing language, or adding a language, then you can actually say, Well, during our sprint, we actually did that we added a new language. And this was, what the cost was, this is what the outcome was. And then you can present that information to the stakeholders and say, okay, is that Does that meet your quality goals for the product, and you know, that, then you can evaluate and say, Well, you know, maybe it mostly did, but you need to make some changes in the next sprint, or in the future sprint may not be the next one might not be the right time to do that. But that being specific about the quality goals, making it measurable, and actually using the work that you do during the sprint to gather information about whether you're meeting the quality goals, instead of having it be a subjective, you know, so often, those architectural quality goals are, are subjective, and they shouldn't be, they should be very precise. And, and if they're not, then there's some more work that might be a good opportunity for refinement, for example, to refine the goals. So we have probably only, maybe five or so minutes left, and we I know, the three of us could go on for hours. And it would be really fun, although we probably would need to do it over a beer and you know, somewhere in Germany. But the, I think an interesting thing to maybe wrap up with is, you know, if most Scrum teams today are not really embracing this architectural work, and we've talked about some some ways that they might be able to do that, but you have any advice for those teams about how to get started, how to start incorporating the architecture work into the work that they do in the sprint, because, you know, most teams that I've run into, they have too much work to do in the sprint anyway, they have trouble, you know, really scoping the work enough so that they get it done and produce the working increment. And now we're asking them to add a bit more.
00:27:31.259 --> 00:27:42.720
But is there a way for them to basically do the architectural work in a way that doesn't put all the other things they need to do completed to the side?
00:27:44.220 --> 00:27:51.029
I probably want to start with a slightly different angle to it, because I think you're absolutely right.
00:27:51.390 --> 00:29:25.529
One of the big misconceptions I see and I get this question frequently is, why isn't there an architecture role defined in Scrum? So if we don't define a role for it, then probably it's not important. And that's probably one of the reasons why people think well, then we don't do architecture just emerges magically, or whatever. So and I think, and that ties, again, back to the quality codes that we talked about. In my understanding, I would say that the developers on a scrum team, they are software architects, and they should make all this architecture decisions. But they do not do it in isolation. But the quality goals that come from the stakeholder and the product owner primarily, they give direction that the developers know to which goals they are optimizing. And that they know how to compare different options they have, because they will then probably choose the one that helps most with their quality goals. So this gives the direction and that's how, at least I see how we could split the work of architecture making architecture decisions within a scrum team. And probably more to the technical side. I'll leave it to Peter to go into this in more detail.
00:29:27.359 --> 00:30:02.519
And I don't really want to go into much detail because it should be something simple to get started. So I always compare things to other things. So if I would, if I would ask someone who is really good at running marathons, if I would ask them to give me give me some advice to how to run my first marathon, and they come up with a with a 20 something pages long training plan, I would most probably not get started. And I think it can start with very simple conversations. I think during that Talk refinement, we should talk about quality goals.
00:30:02.519 --> 00:31:29.910
So I like this architecture quality attributes, I think our quality requirements that we sometimes hear in architectural discussions, and, and maybe explicitly from a development teams perspective, ask, okay, well what is important not from a functional but from a qualitative aspect regarding this requirement, and then take maybe only five minutes to think about is this something where we have to make an important decision, a decision that is hard to change that is quite costly to change. And then give it some time to and maybe maybe 10 minutes of discussion is enough. Or use, use the daily scrum explicitly to talk about things that are currently high risk, high cost of change. Maybe also something that currently you described, or you proposed at the very beginning of of today's session, which is putting architectural work on the product backlog. In my opinion, if if it is something that has to be done, it should be on the product backlog. But it's also a misconception that many teams have, that everything on the product backlog always has to be from a from a functional from a user's perspective, I disagree. The product backlog contains all the work that needs to be done for the for the product. And if architectural work is the work that needs to be done, we should put it on the product backlog.
00:31:31.619 --> 00:32:26.250
And, and I think with these small things, and with these small, let's say reminders of where to focus on architectural decisions, I think it becomes a habit. And then architecture becomes more natural to everyone on the team. And what I've realized in the teams that I work with, and currently I'm working with a development team that is quite Junior, but they are making all the decisions on architecture, I guide them a bit, I give them advice, I mentor them, you can say, but I do not decide because I'm not the architect, they are the developers of this team. And they grow very, very fast. And this is something that I really like that there does not have to be the architect, we can we can build that up like any other skill in the team as well, we can build that.
00:32:27.750 --> 00:32:31.980
I think that's that's also spot on advice.
00:32:33.000 --> 00:32:48.630
There were a couple of points in there that I think we can sort of pull out as a summary to our talk. One is that architecture is focused on decisions, that it's fundamentally about the technical decisions that they that are made about the product.
00:32:49.200 --> 00:33:10.319
I think that one of the other things that we talked about earlier that are important is that exposing those decisions to the product owner and stakeholders ends up fostering some really interesting conversations. So being explicit about we made this decision, this is why we've made it and these are the implications of it. And are you okay with that?
00:33:11.069 --> 00:33:15.059
Does that sound right to you?
00:33:11.069 --> 00:33:43.529
That the other piece that was interesting in what you both talked about is that architecting isn't a role. It's it's an activity that the team, primarily the developers on the team, do, but that the team collectively does in order to solve or meet these quality goals. And so to me, it that kind of viewpoint, and starting simple is, is really practical.
00:33:36.359 --> 00:33:52.859
It doesn't require you know, do lots of studying, in order to do it, it you know, you will learn by doing it. And, you know, there's no reason to put it off.
00:33:53.789 --> 00:34:29.250
You know, when you know, I would say that my advice to a scrum team out there is that, think about these things, talk about it when you're doing sprint planning. And the next time, talk about when you're doing refinement, and think about how you can start addressing the quality goals that you have for the product. And maybe the starting point might be just having, you know, being explicit about the quality goals, and then fostering those discussions. So I think this has been I know we're running short on time. And maybe we can have a follow up discussion sometime.
00:34:25.139 --> 00:34:59.969
But I want to thank both of you for taking the time today. It's always interesting to talk to both of you. And this is a topic I know that the three of us are really passionate about and hopefully the listeners are now passionate about it too. Or at least we've given you some things to take home and try and do on your own teams. So I want to thank everybody. Tune in next time for the next scrum.org Community podcast for another interesting topic. But anyway, thank you for this one.
00:35:00.840 --> 00:35:03.329
Thanks so much Kurt Thank you
00:00:00.000 --> 00:01:15.510
Thanks. Hello, everybody, this is Kurt Bittner, and I'm standing in for Dave West today on the Scrum.org Community Podcast. And we have usually this is an outgrowth of a conversation that my fellow podcasters, Peter and Thomas had a couple of weeks ago. And we thought, hey, this is really interesting. Let's Let's expose this to a broader audience and talk about some interesting topics. And our topic. Today we're going to talk about agility and software architecture, and try to figure out how agility and software architecture fit together. Are they complementary? Are they competitive are they complete anathema? So with that before we get started, so I'm, again Kurt Bittner I've been with scrum.org for I don't know, probably what, since 2016. But after a long, long period in the industry, and my interest in scrum.org have mostly to do with scaling, agility to enterprises, and leadership and various topics.
00:01:11.700 --> 00:01:22.950
And so I think architecture fits really well into that. And we'll talk about why I think that and why Peter and Thomas think that But Peter, Thomas, why don't you introduce yourselves?
00:01:24.420 --> 00:01:40.019
Yeah, awesome. I can start. My name is Peter. I'm a software developer. I've been in the industry for the past 20 years. I have mostly worked in Agile teams working with Scrum.
00:01:41.189 --> 00:01:49.379
And I'm a professional scrum trainer. I've been a professional scrum trainer for the past, I think for the past 10 years since 2012.
00:01:51.840 --> 00:02:52.439
Yeah, and I'm Thomas. I also scrum trainer since 2010 for Scrum.org. My favorite training is the APS - SD class, which is all about how to really apply software development practices in a Scrum context. And as Peter, I'm really passionate about software development, or the technologies stuff, what you can really achieve and how you can tie these things into an HR environment to really build great stuff. And yeah, software architecture definitely is a very important topic in this area. And it is something I really love talking about, because here's so many misconceptions about this. And I hope that we can create some more clarity around the topic during this podcast.
00:02:53.520 --> 00:02:59.699
Peter, Thomas, before we go further, maybe you could expand the acronym, APS- SD.
00:03:00.360 --> 00:03:03.539
Oh, yeah, it is.
00:03:00.360 --> 00:03:08.340
It's even a long acronym. It stands for applying professional Scrum for software development.
00:03:08.639 --> 00:03:21.060
That means it is a training, Scrum.org offers with a very distinct perspective on software development, and how to apply scrum in this context.
00:03:24.569 --> 00:03:53.520
To start off our conversation, and this is where we started on the phone a couple of weeks ago, that it always seems to me that architecture is regarded by many people as a kind of taboo subject for agile teams. And I'm wondering what your opinion is, is that, you know, how did software architecture come to be so unappreciated by teams, what, are they missing something?
00:03:50.759 --> 00:03:57.360
Because I know all of us think it's important. But a lot of people don't share that opinion.
00:03:57.419 --> 00:04:03.090
And I'm curious what you think, you know, how did we end up there? You know, what are people missing?
00:04:05.310 --> 00:05:26.670
I think it is a problem that we created ourselves. We meaning scrum practitioners and agile teams and people working in Agile teams. Because often we hear of a concept or we read of a concept, but we don't really read the article, we just read the headline. And I think when people read about emergent architecture, and they read about Iterative incrementally building software, and continuously improving that they incorrectly assumed that software will, software architecture will just emerge from nothing. So and I think that's a big misconception, and it is, in my opinion, it's more like a counter movement to the very strict software architectural practices from 20 plus years ago, where Are, we had, like these big phases where we did analyzes and design. And we made all these charts and how to how to cut off the building blocks of our software. And we assumed, or many people assumed that software architecture will just take care of itself, which is true, some some architecture will emerge. But it's, it will most probably not be the software architecture you want to have.
00:05:27.930 --> 00:05:30.779
And that's really go ahead.
00:05:32.040 --> 00:07:10.920
Just to add on what Peter just said, I think, in the old days, it was exactly that we tried to design a software architecture, that is a perfect fit for the software that we are building for the problems that we are solving here. And that was a great for the old waterfall approaches, because that requires that we know all the requirements for the software upfront before we can come up with a great software architecture before we start implementing it. So once we transitioned in an agile way of way of working on planning, we agreed that we cannot know all the requirements up front. And I think that is probably a huge challenge that emerged there to say, okay, how can we then create the perfect software architecture for a software product if we even don't know all the requirements, and I think that is probably a big change. At least, it was a big change, for me to really realize that we have to think of a different type of software architecture, when we work in an agile way, it is probably less on finding the perfect software architecture to solve a specific problem. It is more building software architecture, that is evolvable, over time that allows us to adjust to ever changing requirements. And I think that step is probably also part of the problem.
00:07:12.120 --> 00:10:29.250
Yeah. The other thing, I think that is also I agree with what both of you say and the other misconception, I think is, is even with that older conception of software architecture, because the belief that you can somehow take a set of requirements, and come up with a perfectly for perfect solution, without actually building and testing something is a fallacy. And so, you know, when we used to build systems, and I have to maybe have the disclaimer that I've never actually worked on a waterfall project, even going back to the early 1980s, I was always building things incrementally and iteratively. And part of the reason for that was that I was doing things, you know, on hardware that had just come out, I was doing things with problem domains that weren't really well defined. And so the only way to do it, the only way to successfully build something was to build it, incrementally test it and keep refining that. But in the process of doing that, I discovered some of the problems with emergent architecture of my own because the the for me that the essence of architecture is not about what we used to think of as diagrams and, you know, Architectural Review meetings and, and other kinds of things like that. It actually is the decisions that you're making, about what you're building and how you're going to do that. And so I've always found that you couldn't make those decisions without the kind of information you get from building a little bit of it, and then testing it out. And then evaluating your assumptions. And so that that notion that architecture is about decisions is something I've I've been writing about lately. But I think it's it's an interesting thing to build on a couple of things that you both said, you know, Peter, your comment about, you know, you'll always have an architecture, the question of whether it's good or not, is sort of the thing that you're trying to achieve. And I think out of out of building something, you can figure out whether it's good or not. And so I tend to think of traditional architecture as being a lot of unproven assumptions about how things are going to work. And the only way to test those assumptions is to build a little, a little bit of it, not all of it, but build a little little bit of it. And so, for me, I find that there's a perfect fit between Agile processes and Scrum and architecture because well you know how I mean scrum basically says you need to produce something valuable and working every Every single sprint, well, you know, here's your opportunity to build a little bit of the solution and test some of your ideas. So I think that that's it. For me, it's not so much that actually, it's the opposite of architecture and agile don't fit together. It's like they fit together perfectly. But it's because of a mis misconception about what architecture is and how you do it. So I don't know what of your experience has been with that?
00:10:30.210 --> 00:12:11.909
I would, I would like to, to pile on top of that, because the one thing you said about decision making, this is the core of architecture in my understanding as well. But the question is, I mean, when we, when we create software, we make decisions all the time. So the question is, what what is architecture? Like? How is architecture is different from all of these normal decisions that we take. And when I think about that, I always use a very loose definition. And this is, architecture is about the important things. I think Martin Fowler said something like that, and I really liked that, because it's about those things that have a high risk or a high cost of change, if we need to re evaluate them if we need to redo them. And, and I think that that these types of decisions qualifies architectural decisions. And then the question is, I mean, when do we when do we decide on these important things, whatever important means, and in my opinion, there is something that is quite underappreciated in most Scrum teams and from from my experience, it is that the product owner has a very, very important part when it comes to software architecture, because it always starts with what is the vision of the product? What is the most important or what are the most important 123 Maybe five quality criteria or quality goals that we want to achieve?
00:12:08.070 --> 00:12:59.129
And then we optimize our important decisions on reaching these goals. And in my opinion, this is something that many product owners do not appreciate enough, many Scrum teams do not appreciate it enough. And I would like to, to have and work with product owners who are more interested in what is the vision? What are the quality goals? And then what what type of architecture do I get, because architecture is not something that is hype driven, or that is where we use the technologies that are currently on voc architecture and software architecture in particular, is something that is dedicated to solving a concrete problem to reach a specific quality goal or quality criteria.
00:13:01.200 --> 00:15:10.139
And I really liked the part where you were talking about the validation because I, I couldn't agree more that all those decisions we are making are based on various assumptions and those assumptions can be true or wrong. And the validation part is really important and I have been on traditional waterfall projects and I can I can really if I think back to those days, it was very, very late in the project, when we were really able to validate those assumptions. And it is I think, by nature, in the tradition of waterfall, you try to prepare all the decisions with a lot of analysis thinking around it. So, your expectation is that you have considered everything which is in fact it is impossible in my opinion, that is probably the big misleading idea behind the traditional waterfall that we can if we plan carefully enough we can come up with all the details then we have to take into account and if we later find out that we took wrong decisions, then probably our planning was not good enough you should do better blending next time and then it will work. That was probably the biggest misconception in the old waterfall days. I think it is exactly what you said that we have to validate those assumptions and course correct as early as possible in our development cycle. And that is only true if we are actually building software if we are building working software and that is the essence of Agile and Scrum for example, that we in small increments have something where we can validate assumptions and this is not only assumptions in regards to the requirements or business value, but also our technical assumptions in regards to software architecture.
00:15:11.759 --> 00:16:00.089
Now, there are a lot of interesting things. And in what both of you said, I think one of the misconceptions that people have about architecture is that, that in a sense, if you think about the suitability for agile, we often talk about that we're dealing with problems in the complex domain. And architecture, especially in today's world is especially complex, because there are very complex interactions between user workloads, response times, memory, throughput on networks, latency of networks, you know, compute power, use of all these different components and services from different vendors.
00:15:53.759 --> 00:16:00.298
It's not predictable at all. And all
00:16:00.299 --> 00:16:14.009
those parts you're mentioning are changing all the time. So it's not a stable system. Inside we are planning and building stuff.
00:16:08.340 --> 00:16:17.070
It's all changing apart all the time. And that even increases the complexity, I guess.
00:16:17.850 --> 00:18:19.650
And the interesting thing about something tying that into something that Peter mentioned, is this notion of quality goals, or in some of the writings I've been doing with another colleague, Pierre pure, we've been talking about quality attribute requirements, but what that basically means is that, you know, what are our goals for, you know, response times and for number of users and for throughput, and for, you know, even some things like, like the, you know, the maintainability of the system, and supportability system and resiliency. So oftentimes, these architectural qualities, you know, you talk about LEDs, and English and, and that, that notion of having quality goals, and that the architecture is focused on the quality goals, and, and the functional requirements are focused on maybe more behavioral goals of the system, I think is an interesting addition for people. And I find a lot of Scrum teams don't necessarily even think of quality goals, but that, you know, to both of your points, that's, that should be something that the product owner is very concerned about, and maybe even puts those things on the product backlog. To say, you know, there was another thing I wanted to add, in addition to that, and that there's an interesting concept called the last responsible moment. Because you know, that saying, We have to meet all these quality goals might lead some people to say, Oh, we're gonna spend our first you know, five Sprint's dealing with quality goals, and then we'll deal with product, but you know, the more functional requirements and that's not, that's not right, either, because what we need to do is that we want to postpone decisions as long as we can, but in a responsible way. So that, you know, the question each sprint is like, Okay, here's this quality goal is that it's anything that we would do in this sprint going to potentially lock us into a particular solution, or maybe prevent us from achieving this quality goal? And if the answer is no, nothing will do in this sprint would would lock us in, we still have complete freedom on that.
00:18:19.769 --> 00:18:57.029
Great, then we don't have to deal with that right now. But if you say no, you know, in order to to achieve this particular product backlog item, or this group of things, or maybe the sprint goal, we're going to have to deal with that latency issue to pick an example, then, then, okay, that's going to have to, you're going to have to do some architectural work in that sprint to do that, because the cost of delaying that decision is too high. You might you might have to rewrite everything, you know, if you find out a different answer, you know, five, Sprint's on, you might have to rewrite everything you've done up to that point that would be very responsible.
00:18:57.569 --> 00:20:13.589
So I think that notion of quality goals, and then thinking about what's the last responsible moment, or, you know, do we absolutely have to handle this issue in the sprint in order to have a sustainable solution. And using that as a filter on on the sprint planning is, I think a really interesting way to think about doing the architecture work instead of loading it all upfront. Because sometimes, you know, you, there's an interesting interaction between between functional requirements and those non functional or architectural quality goals is that is that sometimes in order to achieve a particular, you know, sort of user oriented outcome, you've got to solve some particular architectural problem. And so that the two of them interact, it's not like you can deal with all the quality goals first and then and that was sort of that I think the problem with with the waterfall approach architecture is that they they tried to solve all the quality gold problems first in some big design, and then build the funnel nothing's on top of it. And what usually found out this time, as you mentioned is that some of your assumptions turned out to be false. And that content causes you to completely rethink. And the later you find that out, usually, the worse it is.
00:20:15.599 --> 00:20:28.529
And I think this quality goals also play a very important role. In the evaluation part, they allow you to close the feedback loop.
00:20:23.279 --> 00:22:02.819
Because if you want to validate the decisions you made in terms to your software architecture, you have to come up with specific questions. Did this decision make our system no more resilient, more secure, more maintainable, whatever your quality goals are, and those quality goals give you the right questions to ask to validate your architecture decisions. And I think that is probably even an opportunity where you cannot only involve the product owner in this kind of conversations, we could even go one step further and include our stakeholders in this to say, Okay, we have now changed over probably the course of a couple of weeks, this architecture things, do you feel this products closer to the quality goals? Does it feel better to you? And what are the next goals that we should focus on? Where should we try to make the most improvement in two, and for example, that could be an amazing conversation during a sprint review. To come up with this kind of discussions, if you just share with stakeholders that you choose platform, a Overbey. Because of this, and that technical reasons, there will not be a conversations with them. But as soon as we bring in those quality goals, we find a connection between the technical world and the business world.
00:21:59.130 --> 00:22:04.230
And that is what the quality goals really do for me.
00:22:06.000 --> 00:22:33.690
And I what I what I really like about this idea to bring it back to the product owner and to the stakeholder or stakeholders is that we can also talk about the trade offs that we have to make. Because if I asked my, my customers, do you want to have it secure? Yes. Do you want to have it maintainable? Of course? Do you want to have it reliable? Of course, do you want to have it performance efficient? Yes, I want to have that. But you want to have it functionally correct?
00:22:33.720 --> 00:22:59.849
Yes, I also want that. So if I give them a catalog with all these abilities, they want all of that. But the question is, if we if we make it a bit more performant, if we if we improve our resource utilization, but that in that impedes our maintainability, is that alright? So that we want to take that trade off. And this is something that I really liked discussing this, because this is often it's a business decision.
00:23:00.539 --> 00:23:04.230
It's not a technical decision.
00:23:00.539 --> 00:23:07.200
It's a decision that we have to make with the stakeholders with the product owner most probably.
00:23:08.009 --> 00:24:03.029
And I really like this type of conversation, because it makes it more graspable shell has introduced scenario based modeling in the 80s. They have, they have used it for many different things to for example, to model the, the the climate change, or to model political development in different countries. And the interesting thing about the scenario is that it makes something abstract concrete. If I talk about maintainability, I can I can wholeheartedly say, Yes, I want to have it maintainable. But if I have to make it concrete, and make it clear, what is this maintainability that you're talking about, then I need to find the concrete scenario, and this is something that really helps in in talking about this.
00:24:03.029 --> 00:24:40.410
So if I say we would like to be able to, to add a new language to our website, in within that most five working days and this should be should be mostly done by one person. So this is a concrete scenario. And then I can look at the decisions that I have made in my important decisions. I can look at them, and I can figure out or I can think about if if I think it plausible and probable that we will be able to make that quality goal or scenario. And if not, then we have to maybe we have to adapt something, we have to change something.
00:24:41.609 --> 00:27:34.740
I really liked that. And one thing that I think is is important too in the quality goals is that is that they're not binary is that it's not it's not performance or not performance. It's you have to be very specific about what you mean by performance. What you mean by responsive what you mean by maintainable no This scenario has helped you to be more specific about that. And then back to Thomas's point about validation, you can, you could validate that, okay, during the sprint, we tested that scenario, you know, we ran through and we made the kind of, let's say that you want to make the system very maintainable for certain kinds of changes, like, like changing language, or adding a language, then you can actually say, Well, during our sprint, we actually did that we added a new language. And this was, what the cost was, this is what the outcome was. And then you can present that information to the stakeholders and say, okay, is that Does that meet your quality goals for the product, and you know, that, then you can evaluate and say, Well, you know, maybe it mostly did, but you need to make some changes in the next sprint, or in the future sprint may not be the next one might not be the right time to do that. But that being specific about the quality goals, making it measurable, and actually using the work that you do during the sprint to gather information about whether you're meeting the quality goals, instead of having it be a subjective, you know, so often, those architectural quality goals are, are subjective, and they shouldn't be, they should be very precise. And, and if they're not, then there's some more work that might be a good opportunity for refinement, for example, to refine the goals. So we have probably only, maybe five or so minutes left, and we I know, the three of us could go on for hours. And it would be really fun, although we probably would need to do it over a beer and you know, somewhere in Germany. But the, I think an interesting thing to maybe wrap up with is, you know, if most Scrum teams today are not really embracing this architectural work, and we've talked about some some ways that they might be able to do that, but you have any advice for those teams about how to get started, how to start incorporating the architecture work into the work that they do in the sprint, because, you know, most teams that I've run into, they have too much work to do in the sprint anyway, they have trouble, you know, really scoping the work enough so that they get it done and produce the working increment. And now we're asking them to add a bit more.
00:27:31.259 --> 00:27:42.720
But is there a way for them to basically do the architectural work in a way that doesn't put all the other things they need to do completed to the side?
00:27:44.220 --> 00:27:51.029
I probably want to start with a slightly different angle to it, because I think you're absolutely right.
00:27:51.390 --> 00:29:25.529
One of the big misconceptions I see and I get this question frequently is, why isn't there an architecture role defined in Scrum? So if we don't define a role for it, then probably it's not important. And that's probably one of the reasons why people think well, then we don't do architecture just emerges magically, or whatever. So and I think, and that ties, again, back to the quality codes that we talked about. In my understanding, I would say that the developers on a scrum team, they are software architects, and they should make all this architecture decisions. But they do not do it in isolation. But the quality goals that come from the stakeholder and the product owner primarily, they give direction that the developers know to which goals they are optimizing. And that they know how to compare different options they have, because they will then probably choose the one that helps most with their quality goals. So this gives the direction and that's how, at least I see how we could split the work of architecture making architecture decisions within a scrum team. And probably more to the technical side. I'll leave it to Peter to go into this in more detail.
00:29:27.359 --> 00:30:02.519
And I don't really want to go into much detail because it should be something simple to get started. So I always compare things to other things. So if I would, if I would ask someone who is really good at running marathons, if I would ask them to give me give me some advice to how to run my first marathon, and they come up with a with a 20 something pages long training plan, I would most probably not get started. And I think it can start with very simple conversations. I think during that Talk refinement, we should talk about quality goals.
00:30:02.519 --> 00:31:29.910
So I like this architecture quality attributes, I think our quality requirements that we sometimes hear in architectural discussions, and, and maybe explicitly from a development teams perspective, ask, okay, well what is important not from a functional but from a qualitative aspect regarding this requirement, and then take maybe only five minutes to think about is this something where we have to make an important decision, a decision that is hard to change that is quite costly to change. And then give it some time to and maybe maybe 10 minutes of discussion is enough. Or use, use the daily scrum explicitly to talk about things that are currently high risk, high cost of change. Maybe also something that currently you described, or you proposed at the very beginning of of today's session, which is putting architectural work on the product backlog. In my opinion, if if it is something that has to be done, it should be on the product backlog. But it's also a misconception that many teams have, that everything on the product backlog always has to be from a from a functional from a user's perspective, I disagree. The product backlog contains all the work that needs to be done for the for the product. And if architectural work is the work that needs to be done, we should put it on the product backlog.
00:31:31.619 --> 00:32:26.250
And, and I think with these small things, and with these small, let's say reminders of where to focus on architectural decisions, I think it becomes a habit. And then architecture becomes more natural to everyone on the team. And what I've realized in the teams that I work with, and currently I'm working with a development team that is quite Junior, but they are making all the decisions on architecture, I guide them a bit, I give them advice, I mentor them, you can say, but I do not decide because I'm not the architect, they are the developers of this team. And they grow very, very fast. And this is something that I really like that there does not have to be the architect, we can we can build that up like any other skill in the team as well, we can build that.
00:32:27.750 --> 00:32:31.980
I think that's that's also spot on advice.
00:32:33.000 --> 00:32:48.630
There were a couple of points in there that I think we can sort of pull out as a summary to our talk. One is that architecture is focused on decisions, that it's fundamentally about the technical decisions that they that are made about the product.
00:32:49.200 --> 00:33:10.319
I think that one of the other things that we talked about earlier that are important is that exposing those decisions to the product owner and stakeholders ends up fostering some really interesting conversations. So being explicit about we made this decision, this is why we've made it and these are the implications of it. And are you okay with that?
00:33:11.069 --> 00:33:15.059
Does that sound right to you?
00:33:11.069 --> 00:33:43.529
That the other piece that was interesting in what you both talked about is that architecting isn't a role. It's it's an activity that the team, primarily the developers on the team, do, but that the team collectively does in order to solve or meet these quality goals. And so to me, it that kind of viewpoint, and starting simple is, is really practical.
00:33:36.359 --> 00:33:52.859
It doesn't require you know, do lots of studying, in order to do it, it you know, you will learn by doing it. And, you know, there's no reason to put it off.
00:33:53.789 --> 00:34:29.250
You know, when you know, I would say that my advice to a scrum team out there is that, think about these things, talk about it when you're doing sprint planning. And the next time, talk about when you're doing refinement, and think about how you can start addressing the quality goals that you have for the product. And maybe the starting point might be just having, you know, being explicit about the quality goals, and then fostering those discussions. So I think this has been I know we're running short on time. And maybe we can have a follow up discussion sometime.
00:34:25.139 --> 00:34:59.969
But I want to thank both of you for taking the time today. It's always interesting to talk to both of you. And this is a topic I know that the three of us are really passionate about and hopefully the listeners are now passionate about it too. Or at least we've given you some things to take home and try and do on your own teams. So I want to thank everybody. Tune in next time for the next scrum.org Community podcast for another interesting topic. But anyway, thank you for this one.
00:35:00.840 --> 00:35:03.329
Thanks so much Kurt Thank you
