Why the values of Agile are more important than you think!

I'm also excited as I'm continuing to take another step in my agile journey. I haven't talked about that much. I did over the weekend, just as past we can take a class on the professional, scrum master too , and work on getting that certification. And then the one after that would be the three. And my goal would hopefully be for next year or maybe in a couple years to become a professional scrum trainer. That is the PST. That is, as far as I know about the highest level you can go in scrum.

I really enjoy teaching. I don't believe I talked about that a whole lot. I taught, I touched on some of it, but I really enjoy doing this. Hopefully you out there listening are getting a lot out of this. I know I get a lot out of this , uh, teaching. Uh, I hope you , uh , get a lot of it too. I hope you can email me. Tell me where you're at on your agile journey. My email was Greg dot Miller or gregMiller@theagilewithin.com. Email me, tell me where you're at in your journey.

I'd like to hear from you , uh, talk about where we're at. Everyone's on a journey. So let's discuss that. So today, as I mentioned in the last episode on the agile manifesto was just a simple reading of it. Today is some commentary. I'm going to break it down into a couple parts. Today is about the values of the agile manifesto. And then there's a , there's four of them. Then there are the principles that are 12.

Now the 12 principles, I'll probably break that down into I'm thinking maybe three or four episodes, maybe cover three to four principles. Each episode is it's a lot to, that just is a lot to take on . As I mentioned in my introduction episode, when I taught scrum agile for a company a couple of years ago, as one of the scrum trainers, I would open up my basic class with the agile manifesto.

And we spent quite a long time, half hour, 45 minutes, depends on the size of the group and the conversation that was had just simply discussing the principles and the values. He , uh , we break up, each person would get with a partner, at least two people, and they would discuss the manifesto.

They would get assigned a principle and they would discuss if their company, if they were doing it in their company, if it was adding value to their company and try to explain what they think that it meant. So it's, I think it's very helpful if you're just getting started in agile, you want to start with this. You want to really understand this behavior mindset and how we interact with teams, our own team, and with the business. If you've been in agile for a while , this is nothing new to you.

I'm sure you've heard it. I found that it's always good to revisit this periodically, just like the scrum guide. As in my class this weekend, the trainer was saying he reviews it maybe six months to a year. You want to stay fresh. There's things in there that you forgot were in there. Uh, or maybe you want to take this. I would do that to tape it up in front of you or in your work area at home or at work wherever you are just as a constant reminder.

And if you have a favorite one, maybe highlight that and call it out. So just so you see it, and if you get used to it, move it to a different spot, change things up, that's agile, right? All right . So today we're going to go over the there's four values. I'm going to start by reading , uh, how it starts and then each value. And we'll dive into that.

So the manifesto for agile software development, we are uncovering better ways of developing software by doing it and helping others do it through this work. We have come to value one individuals and interactions over processes and tools. So now, if we look at this individuals and interactions, so that means they value people, individuals, they value the interactions with those individuals were not resources, which is one of my pet peeves that you find in software development.

If you've been around for a while, or if you haven't, you'll soon, find that out pretty quickly. They refer to you as a resource. I am not a resource. You are not a resource where people were individuals, just like everybody else on the planet. We have thoughts, feelings, emotions, ideas, all that good stuff. We're all together. We are not resources. I'm sure the CEO of your company is not think he's a resource either. So why should he treat you as resources?

So individuals and interactions are valued over processes and tools. So what does that mean? Processes following a strict process, right? Following scrum, we value interactions. We value scrum, but this is, this is not talking about scrum. This is talking about agile. This is not talking about XP. We don't value following a strict prescriptive process. Scrum XP, Kanban, the agile manifesto talks nothing about these , uh , forms of agile.

It just says we don't value the processes as highly and the tools. So tools like JIRA, version one, TFS rally, any other scrum agile tool that's out there that you may be using that you may have heard of. There are lots of ways to use it. Don't get hung up on the tool. I always say to teams I'm on.

And even to myself, if we're going to get wrapped around a tool, we have to the way we name things, the way things are set up though, the way a board has to be done using a tool, people get hung up on that, especially in big corporations. I think it's important to settle on one tool and only one, if you're going to do that, but if you get too wrapped around the axle, then you're low .

You've lost sight of what you're trying to do here, because this one says, put people in your interactions with those people, collaboration, communication, over getting hung up on how we use JIRA. If you're that hung up on it, put stickies on a wall. I've done that before. I've used a tool with that. We would do stand up in front of the wall with stickies on a wall every day at stand up and follow that. Not the tool. So keep that in mind. I thought that was pretty powerful.

Break it down to its base thing. If you think your team's getting wrapped around the axle on a tool, pull them out of it, just do it. Stickies on a whiteboard on a wall to do in progress done. That's it. If your team thinks they need other other columns, that's fine. Go ahead and adjust to that. But don't get wrapped around a tool. The inner individuals and interactions are more important.

We still value the process and tools because they are, they are needed, but not over the individuals and interactions.

If your software is not working properly, as it should has bugs, quality is low. They're probably not going to they, the business is probably not going to be very happy with your team. We value that over comprehensive documentation. A lot of people think that to mean, Oh, they don't care about documentation. That's not, that's not what this is saying at all . I was a BA I've gone through this quite a lot. So what is comprehensive documentation?

So in the waterfall world, you have these multi hundreds, tens of tens and tens of pages, long BRD documents. If you're a BA you know what that is, business requirements documents. And it's saying everything under the sun, up at the top before the project starts, this is saying we don't value that we don't value these big documents. We still value documentation in agile and scrum, Kanban, whatever XP you have, user stories, your product, backlog items, PBI our user stories. Your features.

You have epics . When it's saying here is we just want the right amount of documentation, focus on the word comprehensive. We still want documentation just just enough. So user stories are broken down into small slices. We want just enough to deliver value. The most value we can in the smallest slice of story for an iteration or a sprint for using scrum.

So working software over comprehensive documentation, number three, customer collaboration over contract negotiation kind of goes back to number one, customer collaboration. Again, we want to work with our customer, whoever that may be the business, internal, external customers. We want to work with them.

We want that communication, that open line of communication with them every day, if needed, usually in the form of a product owner, you'll see that a is your customer between your customer and your sometimes you may have as a scrum master or a team member direct contact with your business or your customer. That's great. That is great. As a scrum master, I should not get in the way of that. I'm here to enhance the collaboration, not to get in the way I've gotten that a lot on teams I've been on.

They say that I get in the way I'm here to block communication. Quite the opposite is true. I'm here to enhance communication. So we value customer collaboration. Working with the business over contract negotiation. A waterfall has a lot of contracts, right? We're negotiating the contract, working on that. They're trying to settle on the scope, the iron triangle of waterfall, project management. We want to settle on time, scope, budget, fixed iron triangle. None of those can move.

That's what they're working towards. So the negotiation with their customer in agile doesn't have that agile. You can give a date. You can give a, a budget, but usually the thing that the slow moves around in agile is the scope. So we have something called MVP. That's the minimum viable product or most valuable product. And that's what we're going to deliver in the beginning, small, most valuable slices.

And then we'll have all our , a nice to have in subsequent iterations , but we're going to get out the door quickly as we can for you. So you're getting value. So you're getting money from your customers as quickly as possible. We're not going to wait till we deliver everything upfront to the end. We don't want to negotiate contracts because we know scope changes quite a bit. We want to leave it open.

You want to leave the Proctor in the room to , to reorder stories in the backlog features in the backlog in different order, based on feedback from the business, you do a sprint review. They say, Hey, we don't want, we don't need this anymore. Uh, the next story we can skip down to here, if you're in a waterfall fixed contract and you can't do that. So we want to that collaboration with the customer, you get a lot of that in the sprint reviews.

You'd allow that during the, and as you're talking with your customers from sprint to sprint, we want that, that loose collaboration. We still do have some value in contracts. We understand that time budget. We understand that's important, but not as important as collaborating with our customers. The fourth value, responding to change over following a plan, kind of ties back into that one as well. We want to be able to respond to change .

If something comes up, even in the middle of a sprint or in the middle of, of, of we don't do projects, we do products. Even the middle of development during an iteration of work for the product, something comes up a business need changes, which happens all the time. Even in waterfall change still happens in the business world. Things still move at a pace. We've gotta be able to respond to that. We gotta be able to move things up in the backlog to respond to market changes.

Pandemic is a great, great example. It happened in my company back in March, and that's actually how I got laid off. So I was working at a company. They were going along. They were moving towards a digital is a lot of things are away from paper towards digital pandemic happened and everyone was working from home, but they still had to run their business. So they in , they sped up their digital and they laid a bunch of lump bunch of us contractors off. I was a contractor.

I got laid off, but they were there . They're agile. They were doing safe. They were able to pivot. They did have something on their back log , uh, to take the place of what the paper they moved that up. And they were able to save some of their business and continue. They did not go out of business, fortunately, but if you're not agile, you're waterfall. You wouldn't be able to pivot you right in the middle of something.

You you're going down that road, you're sitting your , uh, your deadline is in six months. You're in the middle of it. Something comes up, you're working through it. It's a lot harder to pivot. So we going to be able to respond to that change for the benefit of the business, for the value, right? To stay competitive. A lot of companies going out of business because they're unable to pivot quickly because they're in that slow waterfall cycle, responding to change value more over following a plan.

Just like I said, following a waterfall plan, going to go a lot more difficult for you. If you're following a strict plan where you can't pivot pivot without mercy, that means if you have sunk costs, that's why a lot of companies don't want to pivot. We spent $5 million on this. We've got to get that back ROI, right? Net would it not, not if it's going to not get you where you want to be. If you're heading towards a cliff, a cliff at a hundred miles an hour, Oh, we can't stop.

Cause we already sit through, we already locked it in the cruise control. You're going to go off that cliff and everyone's going to die. Whereas if you could just let go of that cruise control, slow down and take that corner and go around. You're going to be in a better place. So if you've sunk $5 million in there, you're working in a company you're working on a project that's done that they can't pivot quickly. Uh, you need to cut Bay .

Would you rather be six months down the line where you spent $10 million towards something that you know is going to be a waste, whereas you can cut. Now take that extra $5 million you were going to spend and put it into something where we'll get you a little bit better spot. That's what we're saying here. We still want to follow a plan. We do have planning, even if you're doing safe or scrum or any type of agile methodology methodology, you still do. We still have planning.

We do planning every two weeks, three weeks, four weeks in scrum for the next owner , but only for the next iteration. That's what we're planning for. We're only looking that far ahead because we don't know what's coming. So we still value following a plan. Want to make sure everyone understands that we just want to be able to respond, to change a lot quicker. So then those are the four values.

So then it ends with in the value section that is while there is value on the items on the right, we value the items on the left more. And that's what I was trying to get. The point across here is they value everything they're saying here in these four principles.

It's just where they focus their value on and their time on the items on the left individuals and interactions, working software, customer collaboration, responding to change is more valued than processes and tools, comprehensive documentation, contract negotiation, and following a plan. So that has been the values piece of the agile manifesto. The next three to four sessions, I'll be focusing on the principles area of the agile manifesto, diving into more of those dissecting more of those.

So that's it for this episode. Hope you've enjoyed it. Hope you come back and listen to this over and over again. I think it's very super important. You want to get in touch with me? It's gregMiller@theagilewithin.com. My website is the agile within.com. I'm also on Twitter at the agile, within.com. Facebook, the agile within you can contact me any of those ways. Be sure to review us on any podcast that you're listening to right here on Matt , on most of the big ones. Give me a review there .

Give me a shout out as always send me suggestions. Sosa show suggestions. Give me ideas. If I like it, I may choose one may want to choose to have you on the show. It's up to you also email me, let me know where you're at on your agile journey. I really want to understand that and really want to understand where everyone is. We're all in this together. Want to help everybody? Thanks for listening. Hope you're staying safe out there as always.

This is Greg at the agile within helping you to be more agile.

.