Ray Arell: 0:32

Good morning and good evening everyone. Welcome to the Agile Community Network. I'd like to welcome you to episode 105. Today we're going to be talking about tooling over people. And that's a little bit of a twist on the Agile Manifesto, which is put people first. We want to talk about that today. If this is your first time here and you want to hear all the other episodes, you can go over to acnpodcast.org or you can go subscribe to it on almost any podcast service. You can just go look for ACN, put that in your put that in your subscribe button. That way you'll get the latest drop when it comes out. Also, if you could hit the like button on there because that helps the magic of the algorithm. That does help us overall because it gets the show out to other people. We are brought to you by a number of different companies as well as individual subscribers to New Agility. Our main title sponsor, they got a new logo now, the Agile Alliance. We also have Cicada Organizational Agility, Diana Larson.com, Engine for Change, and of course I just mentioned New Agility, which is the company that produces the show. Please, if you want to support the organization and help us deliver the podcast, we have some uncertainty coming into next year. It's unclear whether or not we'll have all of our sponsors next year. I am having those conversations to help mitigate that. If you are a company and you're wanting to be a sponsor of this show, please just go up to acnpodcast.org. And there is a button there that says, I want to become one of those nice subscribers, or I want to support the show. For those who are supporting us right now, thank you. We couldn't do it without you. I also can't do this without these wonderful people. Uh, Shauna, Diana, York, Sheila Eckhart, Sheila McGrath, as well as April and Hendrick, are my co-hosts that join me. They're a part of the Agile community. They've been a part of the Agile community for a long period of time. They help to bring the conversation or bloom the conversation as we get going. So, tooling over people, this is a classic problem inside of Agile. I see this multiple times as I go into different companies. This happened when I was a part of other companies and watched them get so obsessed about the tools that they suddenly lost what we were trying to do with Agile in the first place. If you think of the whole manifesto, it's really weird when suddenly Jira becomes the most important step. You know, when you got to get up, a daily stand-up doesn't occur any longer if you're practicing Scrum. People are just offline updating really long Jira cards or whatever your favorite tool that you're using. And in some regards, it becomes the driver of the process. And that's really wasn't the intent. It does help sometimes in training and other things, but it replaces the human factor in a lot of things that we do inside the agile space. I've seen this also a bit with the metrics obsession, people collecting every single metric that you can possibly do. I've talked about the human collaboration component to it, but the metrics themselves going up to the upper echelons of your company are seldom looked at. Overall, we as a community are looking to see those sparks occur when people collaborate. I want to see the people working together to solve the problems because the more brains you can put on a problem, the better things work out. The way I look at a fix this, at least for myself, is it deserves a decent discussion about the role of tools within the organization. Not as a policy discussion, but could turn into a policy discussion, but what's the role? What are we trying to achieve with it? Prioritizing the human rituals. And if you don't have them, go create them. Also, just simplifying how the tools are used. How many data fields are you collecting? Sometimes these cards that are created will the expectations of filling some of these things out. It's just too many fields. How do you simplify the measurement of what's relevant? If we're suddenly starting to work on increasing or stabilizing our velocity, then that's a metric we want to go look at. Otherwise, if it's not that important, then that's something we don't need to measure right now. Or we're not working on that, meaning that we're not trying to fix or improve it at this time. We might check it from time to time, but it's something we don't need to check all the time. Face-to-face communication. I know since COVID, face-to-face has been hard. And if you work in a multinational company, it's hard. But prioritize that. Have a couple of meetings where you will be all in the same space. I know that sometimes is expensive and it's hard to get everyone into the same place, but per project, just at least once. So my questions for the group are number one, how would you fix the problem of tools over people problem? How would you do that? What's your approach to it? And then I added this one as a little bit of a joke. You've seen the tools elots. They're the enforcers of the process, the enforcers of the tools. Sometimes that's a scrum master and scrum teams. Sometimes it's management. But how do you address it? And specifically, what do you do in order to have that conversation with somebody and fix that? And then lastly, if you have any questions beyond this topic that you want to ask, that's also fair game too. So to kick us off, Hendrik, you're here. How would you approach this?

Hendrik: 6:21

I agree with all you said, and it is a challenge. I think it is a bigger challenge, especially after COVID. On the XP conference last year, there was a keynote where somebody talked about the Agile Manifesto saying individuals and interactions over processes and tools. Since COVID, it's individuals and interactions only through processes and tools. Because when you want to have a team meeting, it needs to use one of these board things like a MIRO board, and that needs to be prepared and structured and so on. And all of a sudden, it's all about the tools. I completely agree with what you were saying. In my experience, there's maybe two things that I have done in the past, and that is really challenge the tools. One thing I experienced was that there was a tool provider and they got traction in our company. I asked them for a meeting because I did not see how their tools were supporting my way of working or my team's ways of working. So they talked to us for a whole day and they show how we can tweak the tools somehow to get closer to our ways of working. But in the end, what became clear is that my team needs to start working in a different way if we want to use the tool. And I just refused. So I sent them home and we did not start using the tool. But neighboring organizations did, and they fell into the trap that now, more or less, the tool was taking over the process. And when a tool has taken over the process, adapting the process becomes more and more difficult. I think in the first place, you need to be very cautious with what tools you source before you really destroy your agility in the process. So that's at least one experience I have had in the last years.

Ray Arell: 8:07

One person wrote in the chat line that people sometimes don't feel that they have agency to change those things. You said you talk to the tool vendor. I think that's great. But the people in the process sometimes don't feel they have the ability to change it. How do you do that at your company?

Hendrik: 8:25

Yeah, that's a problem, actually. Over the years, we have been after our agile transformation, we had an organization that was scanning through the tools and checking are they now helpful or not for our processes. I believe process is missing. I completely agree. In the end, it's the process, the way you work that should be in the center, and that process should be adaptable. And the tools usually lock you in. Often in companies, there's a sourcing department that determines which tool they talk to a lot of people. More often than not, something suboptimal is chosen. I do not really have a fantastic answer to this, other than teaming up with the sourcing department and making sure all voices are heard and then picking tools that are very adaptable. You mentioned things like gyra. It's a very powerful project management tool, and you can use it and misuse it for any purpose. And the problem with Gyra, for example, is people start filling it with fields that need to be maintained, updated all the time. Sooner or later, it's not updated anymore because it's too many fields, and then the whole data consistency falls away. Another thing to fight the whole thing is to keep things as simple as possible and not use a tool where people communication should happen. Tool should always be so small that it enables a conversation, but it doesn't take over the conversation.

Ray Arell: 9:47

Fully agree with that.

Hendrik: 9:54

The tool for that is good because it shows you which team needs to talk to which other team.

A: 10:15

This is more compensary control. When organizations feel like they are not in control of their destiny, they'll grab at anything. We see this in human behavior. They do anything to maintain the illusion of being in control. They grasp whatever they can to maintain control. The best way that I've found to always talk about that is through the idea of this is why we are doing this and maintaining a narrative and a focus on their personal story, whether as an individual or an organization. We do agile this way so that we can maintain agile. I think it's more of a symptom of organizations feeling like they don't have control, feeling the need for control lean into the explosion of tools rather than the other way around.

Ray Arell: 11:20

That makes a lot of sense. Thank you for clarifying that for me. I appreciate that. I'm curious in your coaching, do you find that, and I think I put it on one of the prior slides, but it wasn't clear everyone was seeing the slides as they were going by, posing the question from time to time, is this tool helping us collaborate better or is it getting in the way? Do you find yourself in coaching that with your teams?

A: 11:43

I find myself usually saying we don't need tools, trying to remove as many tools, but you get a lot of people who want things. For example, they want to use the AI because they think that it'll make their process easier. They think that, and then they get used to doing that. Making any sort of change is hard for people. So it's really difficult for any of that. I think as people who are working in organizations to encourage change, one of the things that we really need to do is just say, let's try it without that. Let's find something else, let's see how it feels. We can't force them to do anything, but we can try and prevent further harm from happening.

Ray Arell: 12:35

God, you've had your hand up as well.

Speaker 01: 12:39

Yeah, good afternoon, everyone. The first thing I do when we start talking about whether it's JIRA or ADL or TFS or RTC or whatever tool is usually being forced upon us, is I bring up the Agile Manifesto. The first value in the Agile Manifesto is individuals and interactions over processes and tools. So we talk about that and what does that mean and why is that important? And we talk about, especially in this distributed world, we need a tool to make our work transparent because nobody's in the office on the team that I work on. They can't do a physical board if no one's around to see it. But as we all talked about, you can overuse these tools as well. One of the things I talked to the team about is we're using ADO now. So we can use ADO as lightly as we need to do what we need to do, or you can have our dev team filling out all these fields and playing around in ADO all day, or you can have them work on customer outcomes. What's more valuable to you? And I've never asked that question and had anybody say, oh, I'd rather have the team play around in ADO all day instead of providing outcomes for our customer. The other thing that I've done is de-emphasize metrics that don't matter as much. An example of that is we have developers using tasks. So our stories are a little bigger than what they've been in the past because they have these tasks instead of individual stories, and it's easier for them to track. But trying to be flexible and getting the tool to work for us, we've gone that route of saying, use the stories, use the tasks, but your stories are going to be a little bit bigger than normal. So we don't have developers working on five or six stories of sprint. They're working on one to two stories of sprint. We don't spend as much time on the metrics as far as burn down because we don't have that steady burn down throughout the sprint that we've had in the past. We will still use velocity. So we'll de-emphasize metrics where it makes sense, emphasize ones that do make sense. And then the other thing I've done, and Ray, it was very similar to you, is I was asked for burndown charts and velocity charts so that they could be compared to other teams. I sat down with my PO and I'm like, what do you think? He's let's not send it and see what happens. Three months later, no one ever came to talk to us, so we never did it. That's how we got out of providing those kinds of things. We just took a chance and that became a mantra for us that if we didn't agree with something, we just didn't do it. And we waited for someone to come slap our hand. And I can tell you I never got my hand slapped.

Ray Arell: 15:16

I can tell you the way they frame that is the most dangerous thing that someone can actually do and say, oh, well, I'm gonna compare the number of points burned by team A and team B. Like, ooh, that's bad. It's not apples and oranges, or it is apples and oranges or bananas. I would never ever give them that trick for that one. Thank you for that. Sure. Well, let's see, April Mills. What do you got?

April: 15:45

I love the conversation around agency because that's the mechanism through which we address any overages of an organization's focus on the tools over the people, but also advocate for the right tools to solve the problems we have. I've encountered organizations that wanted to accelerate software development, but didn't want to invest in CI CD systems to enable the developers. So I've seen times where the tools were deficient to the task and the outcomes. It was incumbent upon the leaders and the developers to band together to advocate for the right tools to solve the problem. So a lot of times we talk about it from a they're making us focus too much on the tools, which I've seen that happen countless times. But there's also deficiencies in tools which a lot of people struggle with to be able to make and meet the commitments that are expected of them. And so as a community, I think focusing on how do we band together to get the tools to help us succeed and what does that look like is important strength building for individuals and for teams so that the systems are set up for current and ongoing success.

Ray Arell: 17:05

What about the standardization problem when suddenly everyone's gotta go use the same tool?

April: 17:14

Yeah, in those cases, you're always balancing the cybersecurity contract fees with the specialization. And that's where I think it's about accessibility and effectiveness versus preference. So many teams couch their arguments against a standard tool as we don't like it. And I think that's the wrong argument. It's better to say here's why it causes us to be unable to make and meet our commitments. That's a more useful enterprise first argument than a preference argument. So you can not like say JIRA or something else, but the enterprise probably isn't going to react to your preference-based argument the same way it would to a business value-based argument. We've seen countless times where tools have gotten in the way of business value causing developer delays. Right? Talking to the folks in IT trying to drive an enterprise consolidation. I understand you're being measured by the spend, but we don't exist to have the cheapest IT. We exist to have the best products delivered as fast as possible to meet the market. How can I partner with you in IT to make the argument that it's actually better for the business to have multiple tools, even if it has a slightly higher IT spend, if we're going to make a lot more money from it? That's where organizations end up being pennywise and pound foolish, optimizing their IT spend versus optimizing their product flow.

Ray Arell: 19:03

Yeah, I agree with that. I've seen that many a times in companies when you actually sit down with a spreadsheet and go, this is the lost productivity, and this is what the dollar cost is going to be for us by doing that. Yeah. Let's see. Luan? Am I getting your name correct?

Speaker 03: 19:18

Yes, there's Luan. I wanted to have a clear, and let me just pull out this disclaimer. I'm new to learning project management and agile. This is my second time joining one of your podcast series. So thank you. I wanted to ask a clarifying question for the question on how would you fix the tools over people problems? Is it the preference of using the tools versus utilizing the people? Or is it people relying on the tools versus their people?

Ray Arell: 19:51

It comes down to where if you look at back in the good old days, we used to do daily stand-ups in front of a Kanban board and everyone was sharing what they did yesterday and having conversations in that stand-up. But that's gotten replaced with a tool where the stand-up might not take place at all and people are just updating status through the tool. And the tool itself becomes the main communication to the rest of the team.

Speaker 03: 20:24

Which I'm thinking is getting in the way of the engagement of the team, the duty of working together. And for agile or just it's a team, you want that people interaction.

Ray Arell: 20:34

Exactly. If you look back at the agile values and principles, very human-centric. And if you think about the way problems get solved, as humans, we all always get stuck. Move forward faster. And so the tool sometimes just gets in the way. I spend more time updating my my and I keep bashing Jira, I'm sorry. Rally. We'll say rally this time. Is Rally even around anymore? But you just spend your day updating those things. And that's not getting your product out the door. It's care and feeding of a tool.

Speaker 03: 21:14

Thank you. Thank you for that. Because I I wanted to approach the question, but in the in a because I have an idea of way to approach this question, but I just wanted to clarify just so I see if my approach would be a good way to approach it. And the way I'm thinking is combining the two. Because I think both are valuable. People are valuable, tools are valuable. But with people, like you said, sometimes you just don't understand something because it's blatant in front of you. But when someone can explain it and articulate what it is, it gives you a better, deeper understanding of how to even utilize the tool or that the tools even benefit for you. So like you said, the one tool, Jira, Jira, is that the name of the tool? Jira, yeah. I don't know how to use it, but I've been listening to how you guys have been explaining it. And I think I got a sense of it. But if somebody was to explain the update, I will be able to connect the dots to know how I can utilize that to bring whatever part of the project that I'm working on, better knowledge to it once we do actually meet in person. But I think that's just a matter of setting those ground rules before everything starts, letting people know I'm all for using tools, but I want us to understand these tools so that we can put the human element to the tools as we utilize them. That will be an approach that I would take for fixing that problem. It's just combining the two together.

Ray Arell: 22:33

And I think what you said about having that meaningful discussion with the team in the very beginning helps because then they understand why the tool exists, why it's there.

Speaker 03: 22:42

Exactly. And how it benefits the project or the task or whatever it is. Because some people I think it's like, why are you even using that tool? Now you're actually expanding somebody's knowledge on the way to use it for something. I know I've stumbled across things like that. Even listening to everything. And like I said, I'm still new to this and trying to learn it. I would use it even outside of a project that will be agile. It's something that I could use it for keeping track purposes for just myself, or just being able to have the experience of even utilizing the tool when I do need it for what it's used for. I already have the experience to be able to do it. And that's the way I would approach it.

unknown: 23:14

Shh.

Ray Arell: 23:15

Yeah, and that's the reason why I use Trello. I love Kanban boards. As much as I've used the paper tools, I just find that I have it everywhere. I can reference it. We all have our preferences.

unknown: 23:29

Yeah, exactly. Yeah.

Ray Arell: 23:30

And if it improves me, it can definitely improve the team. And by you using it, it also influences others to potentially use it as well. Thank you for your comments. I appreciate it. Diana Welcome back.

Diana: 23:44

My experience, I don't work directly with delivery teams anymore. And so my experiences with the tools of actually being a person who is using the tool is somewhat limited. On the other hand, I often get invited to observe how people are using their tool. And one of the things I find myself saying a lot is wait a minute, folks, you get to use the tool. The tool doesn't get to use you. I see that happening often when there's an on-site expert in the tool or whatever that they're just not being accessed enough, or they don't have maybe enough bandwidth to come around and talk to all the teams. But in one specific instance, I was asked to sit in on all the boundary meetings of a team. It was a very large team, well over 20 people. And they they were doing their review and their retrospective and their planning, and they wanted my feedback. When we got into the planning, most of the people were in one location, but a bunch of the people were in a couple other locations. And when they got to the planning, they popped open their JIRA tools, and there were 218 items on the backlog. All you could see in the field, because the description was longer than the field would accommodate, was as an engineer, I want. So they had to go through and open up every single one of those 218 to do any prioritizing or any understanding of what is actually on this list or those kinds, and that was the tool using them. That somebody had told them, oh, just write what you want, without really telling them how to write a story problem or a task problem. They had grabbed the connextra format and run with it in a way that didn't really work for them. One of the things I always recommend is if there is an on-site expert in the tool, given the responsibility of really understanding this tool and then explaining it to people and helping them set it up in a way that works for them, make sure you're accessing that person. Make sure that you are getting the whole thing set up in a way that is actually going to work well for you. And in this instance, 218 items, there was it's going to be very difficult to fix because every single one of those, whether it was high priority or not, was going to have to be looked at and going to have to be rewritten in a way that expressed it so that you got the nugget, the essential element of it in the field that where people could see why that was why it was there and what it was trying to accomplish for the team. And it's those kinds of things that they had another tool that they used that presumably was a retrospective tool that didn't encourage them at all to get to actually improvement actions. It encouraged them to make lists of what they thought went in the last sprint and what they thought they could have done differently or should have done differently in the last sprint, but nothing about what they were actually going to tackle and agree that they needed to change and do differently. Or anything about what they had learned during that sprint. I'm not completely opposed to the single question or the three question list retrospective. I think it's not the best way to go, but I know people who get value from that. It's got to lead you to that place where you are making improvements or deciding that what the most important thing to do that time was to have a team conversation about some topic so that you could digest it over the next front and then come back to it. Or whatever that action is, the tool needs to facilitate you getting to that action. And if it doesn't do that, it's not a good tool. It's just letting you make lists that you go, huh? Look at that and move on. This is particularly a problem when an organization is not providing the teams with a dedicated uh scrum master or tech lead whose job it is to make sure that the boundary meetings happen. And but and what they do is they conflate that with that person is also the product owner, or that person is also has another role. And so the their competing roles get in the way of those meetings, staying focused on what the team needs to improve and what's possible for them. So that's been my frustration with a lot of the tools. And now with AI, which AI agent are you using and what's its sweet spot? Because I see people choosing AI tools to do a thing that it's not really meant to do. Like to be creative, the one that you choose is better suited to helping you do research, finding out what's already known, not putting things together to discover some new possibility. And knowing what the tool is capable of, what its limits are, its limits may be very useful. You may say the fact that it does this is a really good thing. And you might want to use it in some cases, but you need to know which cases you aren't going to use it in as well. A lot of what I see is people getting tools without really understanding why they have them, how they work, getting support and making them work as well as they possibly can.

Ray Arell: 30:04

Love all of that. And I've seen the same problem, by the way, just the write only memory systems where people throw in their data and you know what? It's never used. And that's that is really bad. Thank you. Dylan, how are you doing today?

Dylan: 30:19

I'm doing well. Thank you very much. I've been looking forward to this conversation and it is not disappointing at all. So glad. To be here.

Ray Arell: 30:27

I'm glad you made the time for it.

Dylan: 30:31

So many thoughts, Dan. My brain was exploding while you were talking. One central thing I've really been thinking about is that when it comes to teams or companies or individuals choosing the tools they use, this is actually a really great time to lean hard on a product mindset, a product operating model, but flipping the perspective and from the customer's perspective, really take the time to talk about what problems you want to solve with any given tool and why those problems are important. Dig with additional questions patiently and curiously to get down to the essence of what is the most important value these tools can deliver to us. And then choose your tool, experiment with it, move forward, and rinse and repeat. What people have a hard time doing is taking the time to have those conversations. However, the efficiencies you can gain and the amount of frustration and resentment that you can avoid from the employees by taking that time to continuously make sure is this tool solving the most important problems that we want to solve goes a long way. So that's a way that I like to frame it up in some of these conversations.

Ray Arell: 31:56

I like that approach. And it does go a long way. Sheila?

Sheila: 32:01

I was just making my list of things nobody'd mentioned. I think it's interesting that we're focused on Jira and tools like that. JIRA started as a bug tracker and it shows. So you're automatically forced into a certain perspective when you start by using a bug tracker to track everything. And it's not necessarily the right place to be. In organizations where I've worked, a lot of the time you have the project or the product rolling up to the portfolio. And whether you're looking at it from a product management portfolio or a project management or a value management, ties into the accounting systems. So it's worse than I always talk about big enterprise level projects as being like turning a battleship if you need to change something. When they tie all these things together and automate it, which a lot of companies do more and more of, and they think they can get information that's usable from the system without having to consult people. And that information will be reliable for making future management decisions. It gets to where you can't really change it. And the product people, it depends also on who is really in charge. I've worked in insurance companies where most of the people at the very top started out as agents, for instance. That gives a certain perspective. And I think in a lot of ways, senior management thinks that Agile is just a bunch of new jargon. Unless they've really learned Agile, they don't understand how it's different than waterfall, except in the way things are organized. They don't understand the mindset. They don't understand why they're losing some value by relying so heavily on these tools. And I don't think it's a simple problem to solve because there are some efficiencies of scale in using these tools. But then you're limited by whatever the limitations of the tool are. And I don't have any good answers. That's not great, but this is where we are.

Ray Arell: 34:16

Yeah, no, and the interconnectedness is again, most systems are they seem to be easy to install, but very hard to get rid of. I used to say, don't fall in love with your tools because there's going to be a new one that's going to show up. The corporation's going to go settle and say, okay, we're now using X. And I also said that they have the life expectancy of a good dog. We're going to we're going to get it replaced. But in the same regards, it's it just is really unfortunate that if you just pulled the plug for one week, who notices?

Sheila: 34:49

I had a friend who worked in brokerage. Every once in a while they'd turn off systems and see if anybody noticed. And a lot of times they didn't.

Ray Arell: 34:56

Yeah. That's something it's interesting as an experiment. Just shut it off for a week and see what people do. Karen, you had your hand up. What's up?

Speaker 02: 35:06

Okay. Being a consultant, it just seems it's like you're taking a little kid and showing them there's a two-wheel bike and just telling them, okay, just get on and try to ride this bike. When that the kid falls over, it seems the sequence is counter to what Diana shared, to use a tool, wait for problems, and then address. So my question is what is the pre-work that would help establish the correct balance, the mindset, the purpose to avoid all the pitfalls? It's why start a tool without giving it the understanding and limitations that the team needs to understand. It's okay, now we're in the quicksand. How do I get out? You know what I mean?

Ray Arell: 36:00

I I do, and I think that's when we lose sight on the fact that could we get away with distributing a product to our customer and not teaching them how to use it? Could we get away with that?

Speaker 02: 36:14

Has anyone done that and work with them as far as the mindset of you to use this tool and how to establish the expansion of use in application?

Ray Arell: 36:31

As a person who goes out and trains people with agile, I know that the discussion typically starts with let's go learn the values and principles first, and then we ease into tools. The tool discussion isn't day one. We want to first do it manually so you can see it operate. And I agree with you on the fact that most people are not taking that step. And they're just there was your 10 minutes of training. Bye.

Speaker 02: 37:02

It just seems it's like the same problems in a different context over and over again.

Ray Arell: 37:09

I think the total cost of ownership of something is never really looked at. And loss of productivity specifically, when the tool becomes the impediment, meaning we're spending too much time in this. And I think it's back to Diane's question about her comment about retrospectives being done well. Nobody's flagging it as an issue, or they're flagging it as an issue and then taking no actions. And last thing is probably never roll out a tool where it's like everyone's, we're gonna do it all at one time. We pilot. We want to make sure that it's the right choice, if that makes sense.

Speaker 02: 37:47

What is the approach to look at the total cost of ownership?

Ray Arell: 37:55

I think it goes in where it's not just the deployment of the tool, but it's also the training costs and other things that need to be uh included into it. And then there's a refresh cycle that occurs because you always have new people coming in and out. Yori, you put your hand up. Did you have something to add to this?

Jörg: 38:13

For me, this goes way before my first contact with Agile because we were forced by our customers to use a certain requirements management tool. It was either do it or lose their business. And that was pretty simple. So the question we started. What is in it for us? And we started with the why. Because we were lucky to have enough money to ask for a consultant to teach us the tool because we wouldn't want to screw up in front of the customer. Very simple. If you don't know what you want to do with it, don't use it. Find out what you want to do with it first. If you just try the demo, you will learn a process that is total crap but looks great in the tool. And you will never unlearn that process again. And he was totally right. I think seven guys who really later on used the tool, he made all the things going. One guy installed the early version, he never grappled with the process that was much slimmer, much more effective, went through all the audits and delivered what we needed. But as soon as you're blinded to a tool telling you what to do, it's really hard to unsee this thing. And that is my main learning. Most people hope that a problem is solved by a tool that they can't name and that they just feel as a burden. You can probably relate to this. I'm dyslexic, so obviously I want typos just to go away. Whatever you use, that doesn't happen. Never fully. So you you just have to arrange yourself with it and really know which kind of investment is worth doing it. And I think that is always the question for the tools. What's the real benefit you want to have from it? And then you can have great tools and great use. One of the tools I immensely love is a blue plush elephant. Just a little toy I bring into meetings, because that's the elephant in the room. I can throw it at anybody who's just stepping around things. And because it's smiling and positive, I can get a conversation started that I can't get to in another way. And that is one of the tools I love because I know what it's going to give me. I think that is very important. Understand what is the benefit you expect from the tool and do early verifications if that benefit really arrives. If it doesn't, either you're using the tool wrong, the tool is wrong, or if your expectation is not achievable, which is quite probable as well. You need to make the tool decision irreversible. You need to be allowed to drop that tool again. And don't expect a screwdriver to tell you how to build a bed, because there's much more needed than that.

Speaker 02: 40:54

So you said you were forced by your customers to use a certain requirements management tool. I'm just curious, what was the process between them saying, we want you to use this tool and you starting to use it? How you found this tool to be productive and valuable?

Jörg: 41:14

Yeah, we had that conversation in a workshop and we said, what is it that we are lacking? We are lacking the information if you really have everything complete at the end of the project, if you didn't the right tests at the end of the project and we need to prove that to the customer and then match it to what they wanted, did we address everything of that? In the end, the engineers told us that they wanted much more detail to be documented because it helped them prevent misunderstandings and contradictions. But then that came much later. And with that in mind, we knew all we needed to do is what's really needed in terms of the requirement, who's gonna do it, is it done? How is it tested? Is it in review? Is we don't mind if the right thing is written and everybody confirms we tested it, how the review process is, whether the wording is right, that wasn't our purpose. Is the detail right? Do we need to check that there are at least 100 words? No, we don't. It's much easier to add a benefit that you see than to take an overhead away that you have gotten used to.

Ray Arell: 42:15

Thank you for that. Let's see. We've got a few other hands that are up. Let's see if we can get you guys through before we hit the top of the hour. Z, what do you have?

Speaker 09: 42:25

So I just want to make a comment. I think somewhere along the way, we started worshiping uh tools and not paying. I see that where I am. And I think we forget that Scrum is people powered. So when the process in the tools are louder, then the people, it's time to turn down the volume on those days. No tool will replace the magic that happens when smart, passionate people sit down and talk. And yeah, the dashboards just don't deliver the same value as people. So I really enjoyed hearing everybody.

Ray Arell: 42:54

Yeah, I agree with uh everyone. We had a really lively conversation today. I want to thank everyone for their participation. It turned out to be a livelier topic than I was expecting, which is typically most of the time when we get together, that turns out to be the case. Just as a reminder, our next live event is going to be in October, October 24th on a Friday. Always on a Friday. Also, if you can go up to ACNacnpodcast.org, please go up there and hit the donate button. We could use the dollars to pay for the webinar system and all those things. Those are coming due. I thank all of my co-hosts. I couldn't do it without all of you, and thank you for your time on this lovely Friday. I hope you have a wonderful month. The ACN Podcast is for educational and informative use only. If you'd like to know more about the ACN community, please come up to ACN Podcast.org and support our show.