 All right, so I'm not gonna spend too much time talking about what the panel is about Hopefully people have seen that I want to quickly introduce the panelists or rather them introduce themselves. It's easier that way Hi, my name is Jess Humble. I write some books on continuous delivery and DevOps. I run a company called DevOps Research Assessment Hey, I'm boss photo I Created a scaling framework called less I'm Kurt Bittner. I'm a team member at Scrum.org I'm Jutta Eckstein and I Created wrote the first book on scaling agile which was called agile software development in the large and I wrote this in Well, I wrote it in 2002 and it was published in 2004 Hi, I'm Chris James. I work with a guy who invented a framework called safe Dean Maffin well, my name. I'm the president and CEO of Obscaled agile which is the company that invests in developing safe so The objective of the panel is to kind of try and bring different perspectives and look at what's the current state of scaling Agile what's going on? What specific challenges are we trying to address? How are different frameworks or models that are out there kind of doing it differently and What's the larger problem that we're trying to solve as a community and how we can take it forward? That's kind of quickly setting the context of what we want to do I have a few specific questions that I'm going to Get started with and then we're going to open the floor for people to ask questions Which can be either directed at a specific individual or can be to the entire panel, right? So let's see who do we pick first? I Actually go with just because he's smiling too much So just what's your viewpoint on scaling? I know you had to talk, but maybe you can give a quick summary of that Yeah, I think a lot of people Who try to implement agile at scale? they take low-level stuff like scrum and implement a bunch of governance stuff on top of it and They keep the same overall software development life cycle with these big up-front budgeting and requirements Processes and these kind of heavyweight downstream Integration and testing and delivery processes that doesn't work And I think probably no one on this panel is going to disagree with me about that But it's the reality of what we see in the wild a lot It's very difficult to change that because you have to change every part of the company You have to change the way budgeting works. You have to change the way that lead people lead these organizations That's a difficult and time-consuming Task that requires substantial investment, but it can be done. I Was working for the last year in the US federal government where we implemented Agile on a number of different projects and a number of different contexts if we can do it in the US federal government You can do it anywhere So it's possible It's hot All right Boss you've been The at the center of the whole development around less What do you think is the core challenge that you guys are trying to address less? Keeping things simple. Yep That's Keeping things simple. Can you add into that would contradict the statement? Now Usually organizations once growing make first of all Now if you can do a project or a product without much people then I would always recommend not to scale Just much on strange for somebody working with large product But one of my experiences is that most products simply have way too much people And the first thing they should do to speed up is remove some of those people But practically often that's Unfortunately, not impossible or not possible so then in larger organizations, they tend to make things more and more complicated and You know that just Costs us a lot of problems. So trying to simplify remove that complexity out of the organization It's an important part of scaling agile in my opinion. So simplify reduce before you scale If at all you need to Well reduce as I said reducing like sites or people Is a good idea for most development and it's just practically not possible for politics or law or Simply figuring out which people to keep it which people not to keep is impossible. So I Try to avoid getting to that problem by not having too much people. Okay, cool Utah you have been in this space for a very long time forever Remember writing a little chapter for one of your early books on Distributed So, how have you seen over the years this whole thing evolved in front of you? Oh my god So Yeah, well the one thing that I'm seeing it it seems When I came up with that and I was doing it I wrote the book because I Implemented agile in large settings. So with like 300 people working on the same product and When I wrote about this well people were kind of surprised but it Wasn't really interesting from the perspective because people were just starting into a actual so What's now a big topic was a big topic for me what 30 and 15 years ago and That that's kind of surprising to me because I feel like oh my gosh We we are over that for a long time, but now it's just starting right now. So that that's the one thing the other thing and I Don't know. This wasn't exactly your question, but I See like two things the one is that a lot of people are focusing more on on scaling Like what we are doing as product or or project work no matter how you define that But often we are not looking what it means outside of it Because if we are scaling up over several teams and I see most of the people are talking What does it do then on the portfolio level or something like this? But we are not talking what does it mean for accounting or legal or anything? So and we are still like to focus on it. So that's the one thing the other thing is what I really miss for from a lot of script frameworks is That I think they are not focusing enough on the actual values and the principle so not going really back to the manifesto but coming up with something which seems like one size fits all which doesn't Sorry took too much time. I think sure. I think no one on this panel probably disagree that You know one size fits all that doesn't work and all of that stuff, but yet we do see You know a lot of talk around here is a framework and this is what will work So good. I think you've you've been working at scrum.org and nexus. So what are your thoughts on that? I'd like to echo what you just said that the I Think things that are more principles-based are more adaptable to different situations that it's also really important to Figure out ways to engage teams and engage empower the teams let them self-organize and so To the extent that that frameworks help them to do that by reducing complexity That's a good thing to the extent that frameworks sort of disable their ability to make decisions by in the sense getting to Prescriptive or even even in a sense to pattern oriented Is a risk so But as organizations scale there's this natural tendency that you know, I think maybe Scott who's not here mentioned that that this morning that there was there's this tendency for You know you start off with the A players and the best people and all that and gradually as you move through the through the organization, you know The his statement was that they That you know you end up having to deal with sort of more B and C players and all that and I would flip that that around and say How do you make everybody an A player really? How do you empower them? How do you because you know we live in you know, we all have complex lives outside of our work environment We managed to get ourselves dressed in the morning and you know to work and all these other things And you know, we're a lot more people are a lot more capable than I think they You know are allowed to be sometimes and so that's I think the real challenge is that letting getting the organization to kind of let you know free people up and Take advantage of all that creativity that's kind of penned up in Roles that don't fit and processes that don't fit and other things that don't fit And so I think you know getting more back to principles and then letting letting the teams figure out how to how to organize to deliver on outcomes and not You know not basically just you know deliver up somebody's wish list I think you touched up on a very good point about this tension or this dilemma of how much empowerment and how much autonomy you give to teams and How much of it you make it consistent or prescriptive in terms of what you know people do? so Chris over to you How are you guys dealing with that kind of a tension of giving people the autonomy the freedom to think and do things? contextually while also Having some kind of a consistency and like it from a safe point of view. How do you try to strike that balance? Yeah, I As people have said this is a difficult Problem we're trying to solve when you're trying to scale and support people change the way that they're trying to work and with safe It can appear Prescriptive it can appear that it's a set of rules But in actual fact is based on lean agile principles. It's based on the agile manifesto both of which are taught in every class and Form the lens through which all of the training is provided We are trying to support Big companies build Very important systems and it would be great if they could start from scratch if they could start with Team of five team of ten team of fifteen and build it, but often they already have thousands of people that they're trying to Move through an agile approach to work and if what we do is safe is give them a sense of what it could look like what the principles are what the practices are and It absolutely gets configured differently depending on the context, but we can't Change and be changed leaders and industry leaders of agile We don't Acknowledge that this is a big problem They are big companies trying to move through to agility and people's livelihoods Individual livelihoods the company future are you know at risk if they can't change so we need to provide and We try to do this with safe We need to provide a bigger picture of how things will operate And identify how roles can operate in a different mindset, and that's what safe tries to do Obviously it does come in for some criticism, but it it really is based on lean agile principles and the agile manifesto Okay Just what's your viewpoint on striking that balance and how do you think what you've seen in practice? Yeah, I mean It's it it's difficult and the risk is and I've seen this many many times Organizations adopt the practices that are easy to implement and ignore the practices that are hard to implement and You know they'll they'll do the stand-ups and they'll implement the processes and they'll create the backlogs and but you know Fundamentally, they're not changing the way that anyone behaves or interacts. They're not saying well listen, you know, we've got this 1500 person team working on this thing that actually, you know We could probably build with a 20 person team if we put our minds to it Which is a weird paradoxical thing to say but it's absolutely true And this is something we've done in the US government It was what the US that the UK digital service the government digital service did They took systems that were being built by huge teams of people by contractors and built them with a small team of ten people in You know a tenth of the time less than a tenth of the budget Those things are very difficult to do politically because they affect the way that Power and control is distributed through companies, but fundamentally that's what you need to do You need to change the way power and control is distributed. I know a lot of people say, you know You've got to empower people you can't the leadership can't tell people to be empowered the art of bogsiness who write Beyond budgeting implementing beyond budgeting says you can't change command and control through command and control Which sounds dumb, but it's true. You can't say you were empowered. Oh, I'm empowered like no I mean leaders empower people through demonstrating fundamentally different behavior And I see a lot of times leaders adopt a framework and push it down through the organization and expect the way People behave to change doesn't work Let's Turn up the heat a little bit So I know boss and I met long time ago and we had this long debate about certification You knew it was coming And I think we we had an interesting conversation you had a had you had a viewpoint on why You know with less you guys went ahead with the certification So I just wanted to kind of have you share the thought process behind Certification and why you guys ended up having certification. What's the what's the objective behind the certification? Sorry to put you on this spot. I'm gonna Get everyone to answer that because I think it's an important question everyone's asking right like what what is the problem? Certification is trying to solve why why are why are all the frameworks out there putting certifications? And if if there is a real problem that we're trying to address How is it helping? What's what are we learning as we are doing this? You sure yeah I Consider a certification mostly useless and It doesn't really add anything it just adds a label and from less perspective we Purposely try not to have much meaning to the label certified We try to make it Being a certified less practitioner literally means you've joined a three-day course And we never want it to mean anything more than that Why do you have it at all? the only reason why it is there is because Two two reasons one some people do care about it, and I don't want to judge them for caring about it too much to Especially in organizations the people will decide to put people on training They often care more about it even though they don't know why or what it means so a Long time ago me and Craig made a decision that calling something certified if it allows us to teach more people something useful Then we'll live with them Yeah, and I think that's that's the precise answer that I was looking for because our Conversation if you remember long back was centered around that is that we acknowledge that this is this is bad But you know if there is a demand and if we think we can do something good with it Then let's embrace it to you know to influence that change I think most of you would agree that that's been at least part of the thought process For adopting that but then we've also seen a lot of criticism about that in terms of the Effecteds have on the community And and you also rightly pointed out a lot of organizations where people who have the money are making the training decisions They don't have the knowledge to decide Which training is better and then certification becomes a way for them to basically Make it easy to make that decision right but is that in so I'd probably go to cut is is that in your opinion? Good or bad is it hurting us? As a community like yeah, it's certainly confusing You know, there's all sorts of various certifications. I think and I'll share one Basically a story that that Ken's talked about about why we ended up doing these professional certifications And it was basically because he got a call At one point With the very unhappy executive at a company and basically said, you know, we hired this Scrum master came in they were they were certified and they're complete rubbish You know, we ended up firing them. So what the H does you know, your certifications mean now? This was an organization that he was associated with before and So out of that what he decided was that the certifications or the professional certifications that we have now are intended to provide some Level some measure of whether the people actually learned anything Mean can do they have a grasp on basic in our case scrum principles? you know, can they can they apply them at least in some some Meaningful way, although we can't measure practice We can't measure whether somebody can go out and and lead a good retrospective or lead a good Some of the skills are hard to measure, right? It's hard to measure But we can at least say that you know, they can Talk the talk if you will Even if we can't measure whether you can walk the walk and he felt that that had at least some quality control value If we set the bar high enough to you know, our pass rate was was not you know hundred percent not eighty percent but you know a reasonable level I Think that's useful from a You know looking back in my practitioners experience There's a huge amount of confusion that happens on a team that's adopting agile if you can't agree on some basic concepts and principles even if it's just you know Let's let's say unless you know what you know, what's the definition of it? How do you run? You know, how do you run the sprint if if everybody has a different definition of you know What a sprint is and what a and what the scrum master does and what the product owner does It's just hugely destructive to even just for the basics now Eventually you know very quickly a team should get beyond that and it should be more on how the team performs and What they're capable of delivering but there's some value in just having some basic understanding and basic agreement on what you mean About terms otherwise you can't even communicate So basically if I were to summarize or what I've understood you're saying that two reasons one is basically it gives some kind of It's at some kind of a bar if you have a certification to know if you know people have at least got Can can talk that talk right and the second is the vocabulary and kind of getting some basic Agreement across people that this is what it means So getting some basic rules around what is what and that is what I'm and I take out as the Motivation behind certification Right. All right. Cool. What's your viewpoint Chris on on this? Well, I think Yeah, I think most of us would rather fly with a trained and certified pilot than a pilot Who just went to a four-day course or a five-day course? We we we have some It makes us feel better that they you know, they are trained and certified and I think that speaks to the rigor of the certification and You know we in the agile community have to keep working this rigor into certification I think Digital badging gives us an opportunity to do that because digital badging and the ability to Look at what a certification means as an employer We'll start to add some rigor in that they can at least ask the questions at interview and they know what that certification stands for I think You know the the opportunity is there through digital badging Certainly When we are certifying we're only really testing in today's world The knowledge part we don't really take the skills and the behaviors into account and If employers would take the pay more we could do more on the behavioral side and they observe behaviors in You know in in the workplace We could certainly do more there, but I think I think the opportunity is there And I think certification will be around for a while We have to show some management empathy in that we have to give employers some way to understand Who can do this role now? It's not definitely this person because they have a certification, but at least it narrows it to an interviewer Interviewable group and we're digital badging. They'll know exactly what that means in terms of experience And I think that will help us and also we're moving into a blended learning context You know where we can link, you know reading a book read, you know watching a video attending a class on the job experience we can start to gather that into Identifiable units of learning that add to certification. So I'm optimistic We'll get better at it and we need to work at it as a as a an agile industry that You know, I don't think what we've looked at a certification in the past is what we will see going forward So one of the challenge I have is it looks like every organization wants to come up with their own Certification why not collaborate and come up with one certification that we all agree on I Just want to challenge this idea of certification a little bit. I mean, I've never had a certification in my life for software really so Yeah, exactly. So none of you should ever hire me Either that or maybe certification is neither a necessary nor a sufficient condition for actually being good At what you do in this context, which is what I would claim So I'm very uneasy with the idea of certification as anything more than I did this course I don't think it necessarily demonstrates anything more than that Actually, it's similar for me. So I have I am certified as a scrum master because Ken Schraber invited me years back and so that was kind of the reason however, what I really want to say Of the right dislike certification. I think it really helped our industry I think we wouldn't sit here without the certification because what it really does is marketing and Of course, it makes a lot of money as well for the ones who are doing the certification I really like what you said that we are at the moment more looking at the knowledge and not the behavior and and the skills and also not on the continuous learning which I think is even more important and I Think taught you were also on the ball at that time when the Agile Alliance and well in Kent I saw him somewhere back there, right When we came up with the statement from the Agile Alliance that how we regard Certification and actually I still link to that statement because I think it's very important I don't know it from the top of my head, but it really points out that Certifications right now are only looking at knowledge and also the risk that well if you are relying on Certification only you might miss out really good people like chair Right, so if you only if this is if this is your first scan You're saying you're looking for people who have whatever certification you would never get chess on on your team so and and therefore, you really should look for what what people really can do in terms of skills and behavior and Hmm, maybe a last point. I'm a certified scuba dive master and that's Right, and that's a complete Different way of how you get certified You really have to approve stuff and I always thought of if I take what we are doing in our industry to scuba diving It would mean that I am certified Although I have never approved that I'm well that I actually have been in the water I'm talking about how it would be and I can Answer questions around that but I've never been in the water and I still would be allowed allowed to lead a team, so That's kind of weird from from my perspective, but well scuba diving Maybe it's also more life-threatening than some of the stuff. We are doing but still and I started with I think It was a great success Well when especially it can travel when he and chef started the whole certification business I think without that Etcher wouldn't have been so successful, so Todd you want to chip in Todd you want to chip in Yeah I mean fundamentally Software development is a team sport and individual differences are dwarfed by team level and system level Effects, so that's why it's different from like scuba diving and piloting Well scuba diving is at least a buddy system, so you're not doing it by yourself. Well, you shouldn't That's true true bass said don't argue with me because I'm certified very good The one of the other challenges that I see and I keep getting a lot of emails from people in India is Hey, I did a scrum master certification now scrum.org has come out with its certification And now less has a certification and safe has a certification. So which certification should I take? maybe to sort of Veer off and what might seem to be a tangent on Certification issue ultimately we I think we what we want to measure is can To back to Jess's point can teams deliver good software the you know, we're measuring knowledge is A weak proxy for that probably perhaps not even you know, maybe no correlation It as I said it has some perhaps utility just from reducing the frictions of adopting a new set of practices, but Ultimately, you know, I think the question is broader than agile. It's really about software delivery there's a broader set of practices and You really should be able to demonstrate similar to the to the scuba diving example that you've delivered Some level of complexity, you know complex solutions That had great results. I mean that that's ultimately what we'd like to measure We can't we don't have a good way of measuring that but could we evolve toward that? Maybe yeah Let's hope as a community. That's what we focus on in terms of coming up with something like that Yeah, I find the question rather strange because you know for me at least what certification should I get is Absolutely the wrong question to start with I would agree with you hundred percent. I Usually reply saying I'm the wrong person. You're asking the question You need to take You So that's, that's actually exactly the thing that we tried at that time on the Agile Alliance ball to take a position and write this up. It's still there, but it's not obviously there. So it, at least again, I still link to it and the web is finding it, but it's not that it's put prominently. Maybe, maybe however the Agile Alliance doesn't make any money from certification. So at least that. Can we now talk about some real content? Yeah. One last question there and then change gears. I think we can break the interpretation of meaning of certification into two parts. One is the meaning for the individual who does the certification and the meaning for others who are looking at that person as a certified individual and mostly what we're discussing about is the second part. For someone who doesn't know anything, it gives them some confidence that I've been evaluated for the information that I know. From an employer's point of view or someone who wants to judge the competency, maybe it doesn't mean anything. So until we can evaluate that part, that is, we can wait for certification 2.0 or the ways in scuba diving or something like that. Until that comes in, it's only for the individual. That's all. I want to move forward. As Bas mentioned, we spent too much time on certification. Didn't plan to do that, but however this is, this is an important issue at least in India and I did want to spend some amount of time just to clarify what the position of each of the organization is, what's the thinking process behind it and I think we've beaten the horse to death now, so we should move forward. Basically, I had one last question and then I wanted to open the floor up. I know I'm hogging too much of the mic time, but my last question was in terms of scaling, where do you see things going forward and it would be great to hear from different individuals on stage where they see things are moving forward from a scaling perspective. What do you mean from a scaling perspective? From the work that you guys are doing at Les, for example. What's your current... I don't know. Are there open issues that you guys are trying to address? Are there things that you guys are working on currently in terms of incorporating it in Les? Are you trying to get rid of some of the things that you have in Les, because you think it's redundant, it's not required? What's coming up next is basically my question. If I would know that, I would have done it already. Okay, so you guys had... I don't know. We never really originally... I mean, we never sit down and say, let's create a scaling framework. It just happens to be a thing that happened. I don't like creating scaling frameworks. I'd like building products. So I'd prefer to spend most of my time on building products. I definitely hope that I haven't learned everything yet. So I definitely hope that I'll learn new things. Maybe that will be incorporated in Les and maybe not. In a way, I hope not, because as the name already suggests, it should stay minimalistic and not become this ugly big thing. So we try to see what we can do to simplify it rather than what we can do to add to it. So the next version will be shorter. Yeah. Most of my time right now is... We've got the Nexus scaling framework. It's got a very almost cursory description in the Nexus guide. We're just trying to write a book right now that really tries to illuminate some of the... Not so much the thinking behind it, but actually how would you apply it? So it's more kind of an extended case study. I think that'll be interesting just to get people to think about scaling in a different way or to understand maybe how they might apply the concepts. Because right now I think the Nexus guide is pretty theoretical just to try to illuminate that. Beyond that, I think kind of what Baz said, look at interesting problems and see if there's a way... My general feeling is that we need to stay consistent with the scrum values and with the basic principles. Agile values, sorry. Fair point. But to stay consistent with that, which really means that self-organization and really letting people decide what makes sense for them is at the core of that. So I think Nexus first and then we'll see where it goes. Okay, cool. Chris. Our working days are about continuous improvement of SAFE, taking the feedback that we're getting about SAFE in practice and finding ways to continually support the people building these important systems. And finding ways to build that community, support that community, finding ways that make sense. We see certification as the start of that journey and if we can help them then develop and have professional access to professional development that makes sense for them and things that support their roles, that's what we're focused on. As a growing part of the Agile community now, we take that responsibility very seriously and we want to make sure we're doing the right thing for the community. Jutta and Jess, what would you like to see in the future? So, actually, I can also answer it in the way you asked before. What do I see next and also what am I working on at the moment, which is really more looking a holistic view on what does Agile mean for a whole company and it doesn't mean that the board of directors is doing a daily scrum and having a sprint backlog and moving stickies around, so I really mean what does it mean for a company to be Agile, maybe more in the sense of being really adaptive flexible, but actually the original meaning, because the original meaning was focused on software development and now it's really what makes the company itself that adaptive and I think that's the next thing. I also see that a lot is going on in that area so Jess mentioned for example already beyond budgeting, which is one area from the finance perspective looking at how can a company be more adaptive. That's what I think. Yeah, I think implementing a framework is better than having chaos, but I think implementing a framework is not an end. Implementing a framework is getting something in place that's standard that is then a basis for improvement and so what I'd like to see is organizations focusing less on implementing frameworks than actually solving the problems that they actually have by observing the situation in their company and helping the people at the front line doing the work to actually solve the problems they are facing themselves and seeing that behavior throughout the organization and I think Yuta's quite right, it has to be pervasive in every department. You know, there's no... The only way you solve these problems is by thinking them through yourself and there's no replacement for that and so I guess I want to see more of that. All right. Could I just build on that? I think too, as agile leaders, I hesitate to say agile royalty, I think we should take the focus on is this framework better than that framework and bashing a framework. You know, I think our focus should be on how we support leaders make the change, how we support individuals make the change. The time is right. The multi-generational context that we're working in now, there is a challenge to the way things are being done. You know, people don't want to be managed in the way that their fathers were managed and we have an opportunity as agile leaders in the industry to do something. But if we waste time with all this sideways bashing, I think we will lose this opportunity. And I would like to see an end to discussions about one over the other and really focus on moving the industry forward, focus on leadership, focus on how we deal with certification of skills and see if we can collaborate and have more respect for each other to move the practice forward. And all this time we waste bashing each other, I know we won't participate in it, but I find it adds no value. Yeah, I think very well said. Now we'll open the floor for questions. My question is to you, before that, I like all these certifications because they help us to put up a conference like this. They do sponsor. Since there is a commercial activity, you are sponsoring us. Good. You wrote this book way back in 2002, right? Since then, a lot of things have changed. The paradigm of the problem solving have changed. So if you have to rewrite that book today, what are the areas we'll be focusing on? I think I would make clearer what I came up with or we came up with at the time, how it relates to the principles. So because this is how I also built the book, always looking at the principles and saying, okay, what do they mean if we scale up? But I didn't succeed at least not at every place. At some places I did better than at others to make this really clear that it relates back to a specific principle because I think that would help people better to adjust it to their own context. And, well, I still think scaling. It is not easy and it has to do with thinking. Yeah, right. All right. I have been attending Agile India conferences for a while. The last couple of things I missed. But I remember distinctly, way back in 2005, 2006, 2007, those conferences we used to discuss exactly the same point. Agile is meant for small teams versus how do you scale Agile and then how do you apply it for large teams? And then what in your opinion took 12 years? Today is the major theme for scaling Agile and then after 12 years we are talking about the same thing. Do you think you've solved the problem or do you think it's still there? This is exactly what we discussed 10, 12 years ago. Well, not with the same audience. That was my first statement that I feel like I'm over that. I'm done, but which is not really true because it still is a difficult issue and that's why we keep talking about it. It's not easy. Yes, why? What do you think in your opinion is not at the point? One of the problems with large-scale development is there's so many people involved. And we love people, right? The other problem is that new people come out of college every year and join the industry. And, you know, we've done a terrible job and I mean just we as the industry and academia in actually taking stuff from real projects and teaching it to university students. This stuff is still taught very rarely and often quite badly. And so unfortunately, you know, every time a new batch joins the industry, they need to be educated and there's no thoroughgoing program to do that and there's no way. I mean, the academic system, the university system doesn't allow for, you know, a unified approach to teaching this stuff. Every university, every lecturer, every professor has complete autonomy to do whatever they want. So that is just a problem that is enormously hard to solve. Did you just suggest that certifying the university professors? No. I think that there's also, it kind of gets back to Conway's law that the architectures of the applications end up sort of constraining the way that the team structures work. There's also a cultural problem. So we're struggling with some things that are basically hard to solve. It takes a long time to change the architecture to make it loosely coupled if you can ever really do that. And there's some evidence that says basically it's never done. You just replace it. The second one is that the cultures of the organizations are, they change over decades. I mean to some degree, people just have to retire and move on. So as long as we've got these sort of long running problems we're not going to solve them with process and methodologies and facilitation techniques and all that. You can do it in the small with the team. You can change the culture of the team. It's difficult to change the culture of the larger organization getting back to the business. We have a problem. I run into this problem quite often where the developers and basically everybody say it on the IT side of it wants to change. They want to basically do faster cycles, faster delivery. And the business is still stuck in this, we need all these requirements and we need to have a commitment that you're going to do it by September. And Jess made some great points this morning with some data and I've seen the same data that basically, no they don't. They don't know what they want. And until they start seeing data coming back at faster cycles they're going to keep asking for the wrong things. We're in this long sort of change where it takes new data, new ways of looking at things to some degree new people, new architectures, looser coupling. We're getting there. It's better now than it was 10 years ago and so on. But there's still some long standing problems and I think we undervalue the difficulty of changing architecture and the value of having loosely coupled architectures that allow you to change things more independently and that gives you the ability to get faster cycle times, etc. And just to confirm the point you're making is that if you did that you wouldn't need to do scaled agile. Is that what you're suggesting? To a very, so that's the interesting thing is that if you really can get loosely coupled then it certainly changes the nature of scaling so you can do it with smaller teams and over shorter time horizons and so it changes the nature of things and to some degree the scaling techniques that we have today are fighting with some constraints on both the culture and the architecture, the applications that eventually may go away or we're dealing with a different problem that we need to essentially change things on the societal level in terms of the way people think about problems. Yeah, I think that's a really good point and if we could keep everything small let's just agree that would be good. I mean, just do everything in a small team. I think we could all agree that. However, that's not the reality of where we are. We're building very important systems that have a lot of people working on them and we're adding security, big data, install, mobile, all of these things that we're adding and adding to that complexity that we have to deal with and we're dealing with it here and now and so I don't think we can just say let's keep everything small without starting this journey. I think people will get there and over time technology will help and take out some of this complexity and we won't need as big teams. However, here we are today, we have to get started and I think we should be focused on things that help companies get started on this journey. It's going to be a long journey. It is cultural, it is very ingrained. We don't get the support we need in the schools and the colleges and the universities to give us that momentum but I feel the time is now. Managers are realizing they can't do what they used to do. They want to change, individuals want to change, people coming in, the young people, millennials coming into the workforce want to change. The time is right for us to take advantage of that and I don't think we should spend time telling them we'll keep it small when they're dealing with these big systems. Over time I think that will resolve but right now we have to deal with it here and now and give people a path forward. So I think the motivation for doing Nexus is more that and I sort of would apply because there are a lot of similarities with less as well is that a lot of people are starting from the perspective that they're doing Scrum today and in a sense they want to get started on that and they want to deal with a slightly larger product problem. They're not trying to tackle the problem, the broader organizational problems but they've got a concrete problem that when they go to three teams or four teams because of the velocity that they need in order to deliver something they struggle with just sort of a somewhat ad hoc Scrum's approach. So they need a bit more structure but they want to keep that as minimal as possible. So these techniques behind Nexus we've sort of put a name on it but it's not really that we invented it it's more that we've sort of gone out and seen how people are using Scrum and we've noticed that there are these patterns about how they plan and how they do retros and how they do some of these other things and so you can think of Nexus being sort of an incremental extension of Scrum to deal with a slightly larger product context or in some cases dramatically larger but it's still sort of the three to nine teams problem so it's not trying to deal with the enterprise challenges that let's say SAFE would be dealing with. That's the motivation, it's simply a practical thing it's evolved in parallel in many different places and we're just trying to in a sense synthesize those different evolutions into something that is consistent and that reflects what the practice is out there. We've forgotten that what we're trying to deliver impacting them is part of forgotten it. There are multiple things to say but ultimately, oh I remember what it was you keep correlating the size of the system to the number of people that we need and I think that's false. I think actually we need to make our problems really discrete to the level of people who deliver those values and our problem issue is that we have some fact systems from big companies working on important things that were actually in a good job of helping those companies and those teams make their problems smaller and certainly not that they can understand what they're trying to do. So I think those are my challenges to you. So we agree there's a great deal of focus in SAFE on delivering value. I'm reacting to the change that leaders have to go through because they sometimes can be part of the problem when you're trying to change the organization and transform the organization. And so I raise it as an opportunity for us to collaborate and focus on helping managers, leaders change and adopt servant leadership, lineage or mindset. I think is part of what we need to challenge but I agree with you on delivering value. It is the key and if we can help simplify that and make that more discrete, I think that's good and that is an element of SAFE. What we also focus on is synchronization and collaboration across the teams which is an important part of delivering value between those discrete elements of value. So we think we are aligned with what you're suggesting. I've got a problem after all the certifications. So me and my team lead the enterprise agile transformation for an organization called Optus in Australia. When I started on this journey, certified scrum master and the certified scrum product owner, certified scrum professional, I had a team member who did the scrum.org variant. We did SAFE. We've got a 6,000 people organization that's on a 10-year journey. That's a very conservative view. And I happen to sit in this interesting layer called management. So we are often abused and it's fun being on conversations. I see two worlds. There is a world which is very much here and it's painful. I listen to conversations about processes and frameworks and systems and I think you mentioned that earlier. So that is an interesting point you made about systems and people. We've forgotten why we did this whole thing, why we are all here. It's about people. It's nothing about... Yeah, I mean these things come into play, but it's about making the world of work fun. It's about changing where we are and where we come from, from worlds like waterfall and resource driven and come to mind. To a future world, I see people talking about values, people talking about beliefs. You don't need a 10, 15 minute stand up for that. We're talking about a whole different world which I'm seeing in my role right now where we've done the certification. That's awesome. And we have a lot to thank you guys for. But where we are evolving as not just about software, not just about products, not just about IT, but businesses are evolving at a terrific pace where you've got a situation where I call it a McDonald's drive through version. And I've had these conversations with my peers across management. And they've gone and seen someone else do. I think we spoke about this earlier, Chris and I. The Spotify model. So the question I have really is, there's a new world that's emerging where a lot of these frameworks and certifications and applications of these, I don't see them playing a role. Am I dreaming or is that a valid comment? Because that's what I'm seeing in my teams who are doing agile really well, but they're not necessarily following any frameworks and practices. Is that where we're getting into where it's a different world where none of these things are applicable? As I said in my talk this morning, I think a lot of frameworks are really just reflections of what happened to work in a particular situation, in a particular environment. And I think, viewed in that light, they're really valuable. Some of you will have heard of ITIL, the IT infrastructure library. And that was always presented as here's a bunch of practices which you can adopt if you want to. And I think from that perspective it's good to have this stuff. But what you see is high performing teams adapt to the situation they find themselves in and they rapidly evolve based on not common sense but on a scientific approach to process improvement which is where are we right now? What are the measurable goals we want to achieve? How do we design experiments to improve our process to achieve that goal based on our context and our situation? So there is a scientific approach to process improvement which is very well known and well studied. That fundamentally is what high performing teams do. Not take something and blindly just implement it. I would like to comment on what you said which is you said we are all here because we are here of the people and that we want them to be happy and all of that. And maybe you dislike that but I disagree. I think we are here because well the preamble of the edge manifesto said we uncovered better ways for building software and if we figure that well if people are happy we build better software then still it's because of building the software and now the point is more and that's maybe the scaling issue and looking into the future maybe now it's not building software but we hopefully uncover better ways for making clients and therefore also the companies more successful and I think that's why we are here and it wasn't exactly your question but I couldn't hesitate to comment on it. So the question was kind of why do we need these things? Okay. Well I'm with Jazz I would promote everyone not to follow any frameworks but for me a framework is a way that at least for me that we've learned that work for building products and when you start to change the way of working and you have nothing except for hey do something, see if it works, do something else then for a lot of organizations that are not enough and then a framework can help them to get started in that cycle and if they understand why the parts are the way they are and they stop using it, excellent. In fact I'm serious I would promote that because once people start doing that then that allows to get back to Utah's point that allows our industry to actually learn more. If everyone is going to follow all the frameworks to the letter then that means we are not learning anything anymore. But again we also don't want to solve the problems that we have solved as an industry over and over and over again which is what we are doing. I think we are almost touching 7 o'clock so I would like to wrap up the panel. Happy to stay on and have more discussions but I do want to acknowledge that some people might want to leave and we should try and wrap this up. All these folks are still going to be around except Bas is going to catch a flight right now and you're probably running late. Twenty-four, twenty-three hours so I need to leave again. You need to leave before you hit twenty-four hours. But I really want to thank the panelists. I know we threw some hard questions at you and you guys handled really well so I appreciate the honesty with which you guys have answered and the wisdom you bring here. Again thank you all for joining us today.