Join Murray Robinson and Shane Gibson for a conversation with Raj Nagappan on using Agile 2 to create awesome products. The early Agile movement was a rebellion against traditional command and control waterfall development that was failing everyone. Agile is a very important paradigm shift that has led to great improvements but it hasn’t evolved as we have learnt more. Agile 2 is an evolution of Agile that brings it up to date with a focus on Thoughtfulness and prescription.; Outcomes and outputs.; Individuals and teams.; Business understanding and technical understanding.; Individual empowerment and good leadership; Adaptability and planning.

Read along you will

 Shane: Welcome to the no-nonsense agile podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson 

Raj: and on Raj Nagappan. 

Murray: Hi, Raj. Thanks for coming on to the podcast. Today we’re going to talk about agile too. And this podcast is going to be a bit different because we both authors of agile too. So we’re going to get Shane to ask the questions and I’ll probably talk quite a bit more than usual, but tell people a bit about yourself to start with. 

Raj: So I’m a software engineer. And I’ve worked over 25 years in the engineering area including a whole bunch of different places, banks and start ups and government and some commercial software vendors to. Many years ago, I wrote a PhD in computer science and that was at the intersection of virtual environments and data mining.

In the subsequent years, my interest has turned towards the intersection of product management, functional design and software engineering. And in a lot of the roles which I’ve had, I’ve always been trying to bring those three spheres together to say, okay, how can we actually craft software, which a customer wants rather than just following the processes of just building code off the code how can we actually morph it into something that the customer really wants to buy? I started writing a blog and this led to quite a bit of discussion. And I met cliff Berg through that. And cliff was setting up a group of people who was taking on the project of iterating the agile manifesto. So he wanted to create a new version of it. And that’s how I came to be involved with. agile. Took 

Murray: Similar story for me, I been quite active on LinkedIn and I was reaching out and talking to people during COVID and click, they invited me to get involved. 

Raj: So I think. The agile movement had moved on from when the original manifesto was written and software practice have moved on. So there’s a much, much broader spectrum of activities, which people do. And there’s a much, much wider area of application that paperwork in. So we felt that the original manifesto was a bit dated and a bit narrow. And we wanted to take a broader look and bring in some more diverse perspectives. 

Murray: For instance, the manifesto doesn’t talk about product. It talks about adding value to customers, but it doesn’t have anything to say about product.

Raj: So let’s take product. at the time that the manifesto was written, most if not all of the authors of the manifesto were consultants and contractors and coaches to bespoke applications. So back in those days, the vast majority of software was being done in-house. So if you’re a bank, for example, then you would start a project and you would get a team to come and work for you and build an in-house basis software for you. So it’s very much contract-based in-house based bespoke custom software, and that was the environment in which the original manifesto took place.

And in the time, since then the tech boom has just taken off like a rocket. And so what we’re hardware products back in those days have now become software products. Marc Andreessen, said, software is eating the world and it’s true. So there’s a lot more commercial software products, whether they’re frail, whether they’re paid, but people are using suffer a lot more.

 So it’s no longer, so much bespoke. In-house a lot of it is more commercially driven, more the customer is outside your building. So we need to target a wider audience. So that focus has really shifted a lot, the way that people build software and think about it. 

Murray: There is an order taking mentality to the original agile manifesto. Is that the business people going to tell us what’s important and what the priorities are, and then we’re going to build it. So there’s a lack of consideration of real customers and uses, and of, this idea that maybe the technical team can have an important role in talking to users, and coming up with product ideas And setting priorities as well. 

Raj: That’s exactly right. In extreme programming, which predates the manifesto there was the concept of the on-site customer. So the onsite customer was a representative from the business. And what that meant was someone who down the corridor or another floor, or, not very far away who you could both go and Badger and say, what is it that you actually mind first to do here? So that customer was in very close proximity, 

so that doesn’t work if you’re making software, which is not bespoken, which you’re selling to the general market or even which end users I using. And then that kind of goes more towards the lean startup ethos where the saying there is, nothing interesting happens inside your building, your customers, aren’t inside your building. They’re elsewhere living their own lives 

Murray: It’s a pretty big gap in the agile manifesto, which is just a result. I came from and the time, but I think we’re all agreeing that things have moved on from that. Now we do have the lane startup approach, and, customer discovery. That’s all being brought in, but it’s not in the manifesto because I hadn’t thought about it. 

Raj: I say this schism a lot. A lot of organizations, treat product and engineering as two separate disciplines. So the product people go do product discovery as a completely separate exercise. And then they throw some specifications over the wall in the form of user stories, and then they assign to the engineers. Okay. You got to build this. 

Murray: And there’s still people in the product management world who say that’s how it should be. Marty Cagan doesn’t though. We’ve had Marty Cagan on it. And he says that, he wants a team that, is given customer problems, to solve not solutions to deliver. So that’s a much more modern approach. 

Raj: I agree with that completely. It’s hard to do in practice though, especially for a larger organization, because that idea of a cross functional team and you give them. Nebulous problems to solve and say, come up with something. It means that you’re relinquishing a lot of control to that team. And you’re accepting a lot of faith in what they do. 

Murray: Another my jet gap, I seen the agile manifesto is the whole concept of leadership and management. There’s this idea that there’s this small self-organizing team. It’s going to deliver things and that’s all there is. I think we should be talking about agile leadership and how latest can support and empower teams.

Raj: I totally agree. Leadership was a big thing which was missing from the original agile manifesto. So you’ve also got to remember that back then. The dominant way of working was command and control waterfall projects. So this was a real backlash against that command and control structure. But we’ve found that leadership is incredibly important to the success of a team. So I think one of the lines in the book agile too, it says, if you have good leaders, then I can make any system work. And if you have bad leaders, then nothing else is going to counteract that problem. So there are great leaders and there are woeful leaders and every Stripe in between, and the latest can make an enormous difference in making a team work well or supporting every attempt at success that they have. 

Murray: Quite often we’ve seen latest kill off agile implementations because they were uncomfortable with how much, autonomy the team had. So they decided to kill it.

Raj: Because as an element of giving up control. If you have a cross-functional autonomous team you have to let them do their thing and see What they come up with as opposed to dictating every single feature that they work on. And every, T is crossed and every I’s dotted. I’ve been reading this book recently, slack by Tom DeMarco, not about the company, but about the concept of having slack time. And so in that he says that he asks latest. Do you believe in empowered teams doing believe in plowed employees and they all say unequivocally. Yes. And then he says do you give up any control when you empower them? And they say no. And he goes doesn’t that struck you as being a paradox. In order to empower a team, you have to give up some control yourself at the texts in the a while to get that. So I think there’s a real tension to especially feel larger organizations, your more older and traditional organizations, which are driven at the top level, more traditional KPIs. They find it really difficult to cede control to the agile teams to say, okay, you guys find your way and we’re here to guide you. We’re not here to tell you what to do. I see leaders as being a guide or as a mentor, I don’t see them as being, dictatorial managers.

Murray: What do you think about that shine? 

Shane: Leaders, the leaders, managers, and managers lead to see the goal and then pal the teams to achieve the goal as much as they can and managers control the work to be done. We will see leaders take our management stance when they have to, they will drop down and to the work to be done if they need to, but a good leader will then get the hell out of Dodge as soon as they can get the team to get on with it. I think, it’s based on the person, not the title. So I’ve seen some great leaders who had the title manager.

Raj: I’m not saying that, teams should have a free for all and that they should be not a control. I think that there’s a real notion of balance and balances I fame, which runs straight through everything and agile too. And which was absent in the original agile manifesto. So in the original manifesto, as said, we value these things over those things. Whereas in agile two, it says we value a balance of both these things and those things. 

Murray: so we value individual empowerment and good leadership. For example.

Raj: Yes. 

Shane: What the hell is this Agile 2 thing?

Raj: It’s not a manifesto in the same way that the original manifesto was. I would just call it a set of values and principles. It’s a broad set of ideas of things which you should think about and things which might be important and influence the way that you work. It’s an evolution or an iteration of the agile manifesto to be more diverse, more inclusive in the sense of taking in a wider gamut of issues That businesses and organizations come across in modern day software practice, technology practice, and related areas of knowledge. So it’s very comprehensive. It has 43 principles as opposed to the 12 and the original manifesto. And it has six pairs of values as opposed to the four pairs of values in the original manifesto. And that can seem quite overwhelming, but one of our co authors Lisa Cooney, says, there’s something in agile too, for everyone. Not every point will be applicable to every case, but you should always be able to find several points which are applicable to your use case. 

Murray: Do you want to just take us through the values at the top level? 

Raj: So the first value is a balance of thoughtfulness and prescription. The second one is outcomes and outputs. The third one is individuals and teams. Then there’s business understanding and technical understanding. There’s individual empowerment and good leadership and there’s adaptability and planning. So it sounds very terse when I say it like that. But if it actually got to the agile to website, which is agile to.net with a number to click on the link for values and principles, then you’ll see each of those values listed. And then there’ll be a short paragraph underneath each one to explain what each one means in greater depth. To pick one at random individual empowerment and good leadership that kind of dovetails back to what we were saying earlier. That you need good leaders who can set direction for the team, but you also need to give individuals freedom to work out the best way of working for them. 

Shane: So just getting back to what age all two was though ? So it’s not a A3 picture with a whole lot of moving parts and a methodology that I have to follow. It is a set of values and principles, statements that are looking to fix some of the problems that you perceived with the current manifesto and that’s what it is. That’s all it is.

Raj: Yes. Each principle has a lot of depth to it and all of that depth is available on the website. So you can click on the link for any one of those principles, and it will take you to another page, which will explain all of the background thinking and all the background insight that went into that principle. So the principal, which shows up on the list is just the heading. And then if you click into it, then you’ll get all of the in-depth understanding of it. So there’s a lot of rich information which is worth digging into, it’s not just the top level list, which you see there. 

Murray: But I wouldn’t say that is not a process framework. There’s no process in there really is there?.

Raj: So it’s not a process framework to follow. It’s designed to be agnostic in exactly the same way that the original agile manifesto was agnostic. And there should be multiple ways that you can implement this. It’s not a how-to guide. It’s think about these different things and implement them in your own process. Just, make sure you’re taking them into account and make sure you’re thinking about them. In fact, one of the principles is that an agile framework has to fit to your work, your culture and your circumstances. So it has to be tailored to your needs. 

Shane: one of the things I like about the way it’s articulated, when I read the principles, is it states a problem and then it gives some insight on why, as you may be able to solve that problem going forward. But before I deep dive in there, at least just check. Is there a certification, is it a great way to make money? Can I go on a one day course and adopt agile too? And then go out, be certified agile tourists. Is it one of those things? 

Raj: There’s not a certification as such. There is a training course which texts substantially longer than one day to do it. So agile, to the principles and the values is open source into the community and it stands on its own . Separate to that there’s another initiative called the agile to academy and cliff Berg, myself, and a couple of other people are involved in running that. So I think the course runs over about 10 weeks or so. And then there’s also a health assessment. If you wanted to check how well your company’s doing or your organization is doing in terms of the agile two principles, you can take that health assessment. So that’s the training part of it. And it’s a separate service to the agile to values and principles themselves.

Shane: We don’t look at the principles and I look at some of the problems statements. It seems to me that lot of the focus was around the problems we’ve seen when people are scrum centric. We’ve seen in the market that there is a habit of thinking that scrum. The only form of agile. All the teams I work with, adopt patents from some of the agile practices. We see a lot of XP behavior. We see a lot of lane. I don’t think I’ve ever seen a scrum team that didn’t use a Kanban board to visualize their work. So we see that kind of hybrid way of working, which I’m a great fan of. So when I read through some of the principles, it looks like it’s calling out some of the scrum centric behavior that may not apply in different contexts. Like When you want more of an individual flow based approach then these other things you think about is that one of the things that agile too tried to bring some discussion around how to take some of those scrum behaviors as anti-patterns when the context. 

Raj: Yes, so we have a diverse group of opinions and some of the authors of agile too, like scrum and some far less. And so because of that diverse set of views, we had some quite good debates about, is way that scrum works is that the only way to do agile or not, are there other ways to do it? What circumstances should you do scrum centric practices in and what circumstances should you be moving more towards continuous flow. So it just says look beyond the boundaries of scrum. There are far more ways to do agile than just scrum. They’re not exactly the same thing. 

Murray: They was a agreement that technical practices were very important to agile and that they had been overlooked by, some of the approaches. We said technical agility and business agility are inseparable. You can’t have one without the other. And also technology leaders must understand technology delivery. And they both have to understand the business. So we thought the technical aspects, which you see a lot of NXP and DevOps are really important. 

Raj: Yes. I think so. And you see this companies which understand this, they get into a virtuous cycle where the business understands what’s capable from the technology and vice versa. The technology people understand what’s required from the business. So for example, if you’re moving to a cloud infrastructure and you understand how the cloud works and you understand what the opportunities with the cloud are and how that changes your business and how it changes your offering, then that can be a real great driver to propel you, in your business. So for example, if you switch from being downloaded software into the cloud, then you switch your business model from being, you bought once and you pay for an upgrade every year to a subscription model instead. So that’s where the technology and the business are leapfrogging and leveraging off each other to work to each other’s strengths. And then you have other companies which do the opposite, where one hand doesn’t understand the other hand, and then they get stuck in a quagmire 

Murray: Shine, you talked about working individually rather than in a team. And, I think we’re supportive of that, but we said that we five, a mush, autonomous end to end delivery teams and, fostering collaboration with teams and the whole team solves the whole problems. So we think that this idea of, empowered product teams, is very important, but it’s just, we need to consider individuals and leaders and the organization structure as well.

Raj: I’m glad you came back to the individuals because wanted to return to that. At the original agile manifesto, the first value is individuals and interactions. It doesn’t say anything about teams and yet the ways that most software is developed today in pragmatic agile frameworks and agile context, is all about the team? The individual doesn’t get credit. The individual doesn’t have a place where they can say I made this. This is a piece of software or a feature, which I built on my own. And I’m really proud to release that into the world. So the team has subsumed the individual, even though it doesn’t say anything about that in the values of the agile manifesto. So coming back to the idea of balance, we need to recognize teams and individuals. Most software, it needs teams to be effective, but you also need to recognize the contribution of individuals because teams are made up of individuals. So for example, you have a flat structure because flat structures are trendy and everybody likes to work in that flat structure. But what does that make for career development of your individuals? You’ve got 20 year veterans who are experienced coders and they’re working side by side in the same team as a novice. Who’s just a recent graduate. So how do you explain to that person while you essentially doing the same job, even though your title says something different?

Shane: There’s because self-organizing teams T skills, all those things that we encourage the scrum patterns. They come out of the scrum thinking and they really successful. So if that’s how you want your organization to work and that’s how your teams want to work, then there’s a great pen to the top. Lots of organizations and teams and individuals have had success in that. But there’s not the only answer because agile is not scrum. And so one of the things this does is it calls that out, it says, it’s okay if you’ve got a bunch of individuals that want to work outside of a team shared construct, but we then have to focus on other agile patterns. So for example, how do we do peer reviews? how do we stop that one developer going off on their own and not engaging in collaborating with anybody until it’s finished. And then we got it wrong. There are patterns for how we collaborate earlier when that person’s working . So people think agile is scrum and it’s just the set of patterns that help us be Agile. As the same as one that you called out, which is the idea that working software is not proof of value. So if you’re a software development team then working software is a good proof of delivery, but it doesn’t prove that we’ve achieved the value the organization wanted out of that effort. It was not until that software effectively is in front of our customers and the customers are buy more products that we can see the value come back into the organization. And we sometimes forget that. 

Raj: So the idea that software isn’t, the proof of value is a really key idea. And in fact, one of the principles in agile too, is that the only proof of value is a business outcome. it actually goes even further than what you’re saying, Shane. It’s not only that you have to actually get the software into the hands of your users or into the hands of your customers is that they have to actually see value in it, and want to use it. I want to recommend it to their friends or colleagues. So you could be pumping out feature after feature. And I’ve seen many organizations which do this, pump out feature after feature, and nobody uses them and nobody likes them. And they could have sat on the beach and done nothing and the bottom line would look better than if they had been working on all of this stuff, which nobody actually wants. 

Shane: I’m with you in terms of the feature factory with no value. 

Murray: Scrum quite deliberately says that there’s no roles in the development team and we don’t distinguish between team members. There’s only the team. So there’s this idea that people are equal and exchangeable. And that means that all developers are the same so we might as well get the cheapest possible developers in the world, into our team. We don’t acknowledge that anybody’s an expert and other people are novices. Everybody’s the same. Cause it’s all just the team. And, ultimately you’d say we’d pay everybody the same and treat everybody the same.

Shane: I’m with you in there. It’s one of the problems of that self-organizing T skills approach ? Is that people I called that term and that’s on purpose. I think they are good patterns but they come with consequences. And I think the conversations that you’ve gotten the documents are discussing some of those consequences. So people can think about it. 

Raj: Right. , Once again, I think that there needs to be some balance because on the one hand, I really disagree with the idea that all developers are interchangeable and fungible. As a career software engineer named myself, it doesn’t bode well for me to think that I’m just completely exchangeable with any other software engineer. And I know having worked with people who are more experienced than me and people who are novices, that there are people who are much, much better coders than me. And there are also people who are not yet to the level which I am. So the idea that, developers are all of equal value in all of equal ability. It doesn’t hold water. So, you need to come back to the idea of having some balance. On the other extreme, you don’t want to have an individual developer, wedded to an individual idea or to an individual feature and, for there to be no dissemination and no spread of that intellectual property around the team, because, what happens if that particular developer gets hit by the bus or leaves and goes and works for your competitor. You’ve lost all that intellectual property. So have to have a balanced, you have to have recognition of individual ability and allowing individuals to develop deep expertise versus group ownership and protecting the intellectual property of the organization.

There’s one thing I want to add. I fundamentally disagree with the idea that any developer can pick up any piece of work. Some pieces of work that will be the case, but you can’t develop deep expertise in a particular area unless the individuals in that team out working in that area all the time. So for example, how could you develop an autonomous car if the developers just doing whatever stories happened to come their way. The development of that expertise, in the AI and the ML takes quite considerable amount of time. And it takes quite considerable amount of knowledge transfer, which has to happen into the minds of those people. And you can’t do that. If everybody’s fungible, you need to develop expertise. 

Murray: I think we’re saying is that individuals are important and the team is important. And one way we’re combining those ideas is to say that a team could have more than one leader. You could have later in the team for machine learning at a later in the team for testing a leader in the team for the product. You could have leaders emerge for a while because the team focuses on a particular thing and then, go back to being, more focused on their own work. So teams can have multiple leaders. 

Raj: And they shift as different ladies can have a different Cod of influence that can have different focus on the work that they do. And if you don’t appoint a leader explicitly, then one will arise. So not a case of, a completely democratic process where everybody’s on the same levels. Somebody is going to be in charge. And we ever noticed this in social settings. So let’s say that we’re all down at the pub or all down at the bar and we’re having a drink. And someone says, okay, we’re hungry. Let’s go to a restaurant, get something tonight. And everybody looks at each other and goes where should we go? Eventually someone will step forward and take charge and say, okay, we’re going to go to this place. I’ll ring them. I’ll say if we can get in.

Murray: Yeah, cause that’s providing a service to the team. The team’s happy with that because the person is adding value and they’re providing a service to help everybody. If somebody else wants to organize it, that’s great. Happy with that. But what I don’t want is some toxic person to come in and dominate and, start making bad decisions and, favoring certain people over others because they’re friends with them or they drank with them or, they went to the same school together. 

Raj: If you don’t pay attention, if you’re not explicitly appointed later based on good principles, then I later will emerge and that laid up might not be the most appropriate and they might be a toxic later or they might not have the companies or the organization’s interests at heart.

Shane: One that I’ve always struggled with is the idea of pastoral care. So if we’re taking a scrum stance, focus on this idea of a team in a sprint for the rest of their life. We don’t give them time to upscale and train on new things. And teams that I see doing well, there is always a person on the organization that provides pastoral care. They focus on that individual, what they want out of their career. How can that be achieved while still delivering the value they deliver? And I might’ve missed it but I dont, see a lot what was written around those things. 

Murray: So if you look on the leadership, we’ve said that professional development of individuals is essential. We need a leader who’s going to help people learn to work together, help them develop their career paths and their expertise, invest in them, make it easy for them to learn from each other. So We definitely did talk about pastoral care.

Raj: Yes. And I also want to add pastoral care of teams. So in the team versus organization area. We’ve got a principle, which says five along live teams and turn their expertise into competitive advantage. So I think that also talks to how you want to actually nurture the team as a whole, as opposed to only the people in it. 

Shane: So how did you focus on which topics to cover, which problems to identify and articulate some insight on and which ones you weren’t gonna do. 

Raj: We had a few different phases of our discussion and in the first phase, people said what common issues and problems people were facing. 

Shane: Was the COVID you didn’t meet in a ski lodge. 

Raj: So it was an international group. We’re all over the world. We have different experiences. We worked in different areas. There was a diversity of populations of people from different countries and different ethnicities and different genders and so on. And so it was pretty much impossible for us to all meet face-to-face. We couldn’t all, even have a group video call together because we’re all over the world and couldn’t find a common time zone. So a lot of this was done online and it was done by sharing documents back and forth or small group discussions. So it was very asynchronous and distributed.

Shane: So what’s next. How are you going to update it? Cause one of the criticisms of the manifesto is it’s been around for a while and it hasn’t changed. It hasn’t adapted it. Hasn’t iterated. We haven’t inspected and adapted it based on where the world’s gone. What’s the plan for this? How are you going to speak to an adapted as people move on and we’ve got other problems where we could get some good insights using the same technique.

Raj: So we’ve left the door open for an iteration or an improvement to it. So right at the bottom of the values and principles, you’ll say that it says agile to release one point or so. We’ve left the door open that we could iterate on this and improve it in the future. We haven’t any specific plans at the moment about when that would happen or exactly what it would look like, but , never say never. 

Murray: I think the reason is because it’s quite new and we wanted it to settle in first. Raj and I have got some ideas for making some improvements, particularly around clearing up some of the why it’s communicated . But let’s let it settle in and see how people respond to it. 

Raj: Yes. And there’s also a book which is in print. So if we were to make substantial changes to the agile to principles themselves, then the book may require an update as well. So it would be a case of coordinating all of those activities. Having said that we don’t have any immediate plans to do it. It’s something which we’ll probably do in several years time. 

Shane: So outside the ones that you’ve highlighted what are some of the bigger problems that you’ve seen that you think the insights are the highest 

Raj: So my favorite out of all of them is the whole team solves the whole problem. And I find a real anti-patent with a lot of organizations, especially larger organizations is that they break up the value stream into small components. So you’ve got product group, which is just doing product discovery. You’ve got a design group, which is us doing designer. Then you’ve got a engineering group, which is just doing the coding and implementation. And then each of these three groups reports to a different reporting structure, to a different hierarchy.

And then they throw the work over the wall to each other terms of handovers. And that really breaks the spirit of a cross-functional team. So I really liked this principle the whole time solves the whole problem. It doesn’t mean mob programming. What it means is that the whole team solves the problem from start to finish. So they pick up the problem to solve. They go through all of the discovery that go through the design as a cohesive team, and then they do the implementation and then they also do the feedback and analysis to see if people actually like it and then follow that into future iterations. The whole team does that. So it’s not just, one or two people on the edge of the team who are doing their own thing. It’s actually the team as a collective who are all putting their collective heads together. And they’re all giving their input to say, I think we should do it this way. And somebody else will say, I think we should do it that way. And the juxtapose their ideas, and come to a better resolution. 

Murray: So in that way, it’s very similar to Marty kagan’s empowered product teams. I think he has the same idea. And so it’s a bit annoying when he says that’s not agile was, we think it is part of job. 

Raj: I think that it’s agile with a small “a”, I think broader than just agile software development, but I think it points to the true meaning of agility and naturally small startups work this way because you’ve not got a lot of heavy processes and controls. small startup, which is a small team, everyone’s sitting next to each other and they are able to pivot and adjust very quickly like this. 

Murray: I think we’ve got quite an expansive view of agile, a more modern view. That’s bought in a lot of the ideas about product development, business agility and leadership. I don’t think these ideas are that controversial, I’ve given a few talks on it and people go, that sounds sensible. That sounds like what people are talking about these days. So in a way we’re just talking about what makes sense now that we’ve been doing this for 20 years.

Raj: I think it makes common sense in theory and people nod their heads when you say that, but in practice, I find that it’s actually quite hard to do. For a very large organization, how do you break up that organization into small cross-functional teams and coordinate the work amongst all of those different teams, that’s quite a difficult problem to solve in practice. 

Murray: The one part that we hadn’t talked about much was organization principles. So, I think we are very aligned with the unfixed model from Jurgen Apello and the team topologies approach. One of my favorite principles is that you should fit an agile framework to your work, your culture and your circumstances. So where opposed to just having, a framework like safe and just jamming it in. We think that whatever you do has to be tailored to your situation.

Shane: So rather than fitting at I’d say that we crafted because fittings still means we take it off the show front like a tire and try and get it on the air. Really what we’re doing is crafting our and way of waking using these patterns. So there we go. We can do 1.01. You can put my name in as the request to fill that one.

Raj: It’s actually very interesting what you said about fitting versus crafting. And it comes back to what Marie said a moment ago about not taking a framework or a system off the shelf. And I think the reality is for a lot of large organizations, I say, we’re not experts in agile. We don’t study this stuff. We’re relying on the consultants or the trainers to tell us what to do. We don’t want to reinvent the wheel. There’s a lot going buying a car from the Casha room. Okay. That model looks the one which I want and it suits most of my needs. So I’ll just buy one of those please.

So I think there’s a real difficulty there. I think the agile community, has a lot high expectations of industry. To be thinking about all of these things but industry is going to say we’ve got our own problems. We’ve got our own domain, which we’re trying to gain competitive advantage in there, which we’re trying to solve problems for our own customers. So thinking about how to do agile, isn’t really critical issue for us. What’s a critical issue is delivering value. 

Shane: When you look at successful startups, you see a lot of agility, a lot of agile mindset, you see a lot of patterns, they have been written down and some of their John methodology’s, but you typically won’t see a methodology and its entirety, they have crafted their own way of working. And they’ve either adopted a pattern they’ve seen, or they’ve somehow reinvented the same pattern that had value to everybody else. I think of it as Lego blocks. It makes building a tower faster, but there’s lots of different Lego blocks and you pick the ones that fit you and your context, and you always want to change the Lego blocks at some stage. And that’s okay. So you are crafting a way of working, using the patterns. You’re not implementing a methodology 

Raj: I would certainly agree with that. Yes. Lego blocks is a fantastic way to look at it. 

Murray: I think we all agreed with it, partly because we’re all really experienced, agile practitioners in different areas. So we see as being part of our job is to title or something for people’s situation based on patterns. If we have to use scrum or something like that, then we’ll tailor it for the situation.

Raj: I liked the way you said that if we have to use scrum, if it’s forced upon us. 

Murray: that often is though, We just had a good conversation with Michael Costas about safe and his main point was quite often, senior executives will decide to implement safe. And then you’ve got to decide as an agile coach. Are you going to leave the field and it’s all going to be rubbish or are you going to stay and try and make it work?

Shane: Yeah, I liked the way he articulated it, which was a company adopting safe, opens the door to have a conversation with a company about the problems they’re going to try and solve. And once you understand the problems they’re going to solve, then you can look in the toolkit. One of which is safe and see how they can solve the problems using those patterns. So it’s not implementing safe ? It’s not an agile transformation, cause they’re just bollix at is fixing problems or adding more value to the organization. Using some patterns that we know work in a certain context.

Raj: Yes. And as I was saying, that requires introspection, that requires, spending time to think about how do we need to be more agile with a small eye as opposed to just buying an off the shelf solution and expecting that to solve all of our problems. 

Murray: We said to any significant transformation is mostly a learning journey. Not a process change. So It’s a step by step approach. 

Raj: The way I see a lot of organizations implement an agile transformations is that I think it’s going to be a big bang approach. I think it will disrupt everybody for a little while and then the dust will settle and then everyone will just settle into a new way of working and everything will be fine and dandy, but it rarely happens that way in practice. As you say, it’s a learning journey. And so as the agile consultant or as the agile coach, he wants to be that mentor or that guide

Murray: shine. my belief had go to summaries. Maybe you could summarize what you’ve heard and we can comment on it.

Shane: So I hate anything starts with 2.0. I just white radar to me. So when I heard this thing called edge Alto, I didn’t read it. And the reason was because it was cool to now I’ll go back and have a bit of rate. I liked the idea that describes some problem that had been observed by some experienced practitioners in the space. And it provides some insights and teams of how you may solve those problems by working in a different way. I’m not sure I align with the term principle. And again, it’s a terminology thing and just the way my mind thinks.

As soon as I see a principal, I want a set of guard rails, a set of exoskeletons as my new team off the podcast last week. , I want some things that are relatively immutable and if I stay within them, I know I’m safe. And if I’m outside of them, I know I’m dangerous. And for me, it doesn’t read as a set of principles, breeds as a set of problems or anti-patterns and some good high-level descriptions of things you could do to solve those. that’s the value for me. I liked the idea that it could be extended. There as a community we could feed back into. I wonder how the hell there’s going to happen ? Because there’s a lot of noise in the agile space. How do you get a whole community behind it? How do you actually get everybody adding to it? Without it becoming, a moneymaking certification processes, the only way of getting eyeballs which is what safe has been particularly good at?

I like the coverage I hate it when I pulled out an example of Marie actually answered the bloody thing. So I will go and have to go and read every one of them to see that one game that you forgot about. It is good from a coverage point of view and it seems to. Start to breach into that area of product development ? How do we bring that whole UX design product, thinking into the software delivery version of agile that we’ve been focused on for so long? And I think just again, briefly scanning it, there seems to be solving some of the problems from a business agility in terms of organization. The one I’m going to definitely go look for is the idea of scale. Are you solving the problem that as we scale these patterns to more and more people in an organization, have you identified the problems and the insights on how to fix that one? think words are important. The agile thing put me off now that I’ve taken the time to start reading it I think it’s actually quite a good piece of work.

Murray: Well, If not agile to what would you call it?

Shane: Ah, I got no idea. If it was problems you might have using agile and things we think might help. It was almost agile beyond software delivery. Now we’re using little way outside of software delivery teams. We have a whole raft of new problems and contexts that we have to deal with, and this is covering a lot of them. So that’s good and valuable. The question is how do we make it more accessible to people more relevant so that they do use it. 

Raj: The night imagine all to was an interesting choice. As a group, we divided the name quite a bit and everyone agreed the agile two had quite a bit of cut-through. Cause , it bounces off the original agile. So we locked that and we went with that and it suggests the next iteration of agile, which is what in the tagline that there are many other variants of agile, which are out there. A model agile you mentioned. And there’s pragmatic, agile. There’s a bunch of different variations, but we felt the agile to have the best counselor. 

Murray: We didn’t think of calling them patterns. But, they are good patterns.

Raj: I liked the fact that they patents actually. Cause I find that they’re more directive and they give you more of a clue of what to do and how to go about things. One of the common criticisms of the original agile manifesto is that it can be a bit vague. So actually locked the idea that some of our principles are a bit more concrete. And if you click into each one of them, there’s a lot more information there, which will give you a lot of ideas on how to adapt them and install them for your own organization. 

Murray: So people who are listening to this might wonder what to do about it, but I’d suggest the first thing is to go and have a look at agile to.net and have a read through it. And then think about how you can apply it in your situation. There are potentially health checks, Roger, you and I could do health checks for people against these values and principles. 

Raj: So you can buy a health check from agile to academy.com which asks questions in all of these different areas , to guide your level of health. And then agile to academy does some training, but I would agree. The first thing to do is go to agile, to a.net, click into the values and principles and just skim through the top level of values and principles, and then just click into the ones which resonate with you. And then you can read about them in more depth. If you try to read the entire thing, you’ll be there quite some time. So I suggest pick the ones which resonate with you to start with and just go from there. 

Shane: When you get to the page that sees the gory details as the page you want. So good naming on that page.

Murray: Raj, how can people find you?

Raj: Okay. So for agile to, as we said agile to.net is the best place to go. Or for training go to agile, to academy.com. If you want to get in touch with me directly you can reach me on LinkedIn. That’s the best way. So my handle on LinkedIn is just Raj, Nick pen. And you can also read my blog on medium, which is Roger gigapan.medium.com.

Murray: Yep. All right, good. Let’s wrap it up. Thanks for coming on, Raj.

Raj: Thanks very much for having me.

Shane: Thanks guys for taking me through. It’s been good and we’ll catch you later.

Exit: That was the no nonsens eagile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact marie@evolve.co that’s evolve with zero. Thanks for listening.