About this podcast episode

Rather than pushing uncertainty away, embrace it! ⤵️

Today, Bill Raymond speaks with guest Jonas Neumann, who will cover various software development and agile topics.

In this podcast, you will learn the following:

✅ The promise of agile in software development

✅ How organizations can adopt agile

✅ Breaking down planning and budgeting barriers

✅ Dealing with uncertainty

✅ Measuring work based on value

✅ How to foster fun, safe, and effective software development teams

Transcript

(transcripts are auto-generated, so please excuse the brevity)

Bill Raymond: Hi, and welcome to the podcast.

Bill Raymond: Today I’m joined by Jonas Newmann, full stack developer at Accenture. Hi Jonas. How are you today?

Jonas Neumann: Hi, I am good. How are you?

Bill Raymond: I’m doing great. Thank you.

Today’s topic

Bill Raymond: Today we’re going to talk about the value of agile from a developer’s perspective, and I’m really interested in having this conversation with you because I know you have a lot of good ideas.

Bill Raymond: We found you on Medium, you’re a fairly prolific writer there. And you have some excellent articles that we read and wanted to maybe have a deeper dive conversation with you on this topic. Before we get started, can you introduce yourself, share a little bit about yourself?

Jonas Neumann: I’m Jonas, originally from Germany. I’m in Singapore now. I’m a full stack developer and architect, working with clients in various agile projects. But yeah, the, the reason I’m here today is because I like to share my thoughts, yeah, specifically on Medium about different things that I touched on.

Jonas Neumann: Some of it are very technical, some are quite business-like, and quite a bit of it is also on agile. I guess it’s quite important to actually the everyday job that I have and do and the way we interact with, clients and actually deliver things.

What is a full stack developer?

Bill Raymond: That’s great. Thank you. And maybe you could just share what a full stack developer is for those that may not know.

Jonas Neumann: Sure. So in development, typically we would focus on either making nice front end, which would be a mobile app or a website that you see, or on the more hidden things, which would be backend systems. Full stack developer sort of does both, and can switch seamlessly from front end to back end. Is probably not as good or expert in either, but about 80% I would say. And the value from an agile perspective there is that you can seamlessly work on the most important task at hand, rather than having to wait for what’s the next task on backend. Even though our website is broken, we only have a single word up there, and that would be more important.

Jonas Neumann: So a full stack developer can switch and do that.

Bill Raymond: Okay, so this is like if I were to think of maybe some ways of managing software development projects, you might have a person that writes a little bit of the front end or the webpage, for example, that you might see or that sign in page on your app or whatever. And then you have someone that maybe creates the database that stores all of that in the backend and you might be playing both of those roles

Bill Raymond: Correct.

Bill Raymond: Yeah. And I’m sure there’s much more to it than that.

Jonas Neumann: Yeah, absolutely, but I guess that people are interested now.

Bill Raymond: Right, right, right.

Jonas Neumann: To find out more or reach out. Yeah.

What is the promise of Agile?

Bill Raymond: Cool. Yeah. So let’s just start at the very basic level. What to you is the promise of Agile?

Jonas Neumann: So agile, going back, is really the manifesto and the things written in there. I recently wrote an article that talks about agile in itself. It’s the values, it’s not the things we do. So it’s about emphasizing people and interactions over processes. It’s emphasizing getting things done over long circles of planning.

Jonas Neumann: It’s about adaptation rather than following a plan. So these core principles rather than things that we do, which might be a framework, which is helpful, but it’s the values, it’s the core that will enable us to go and move beyond.

Jonas Neumann: And then actually there’s another part to it.

Jonas Neumann: So if we have those values, then it’s basically applying LEAN thinking and getting your processes and the ceremonies that you do, which are helpful to follow what values you have, to a space where they make sense and they deliver on these values where you can be fast, you can deliver with high quality quickly, and have all these practices in place.

How might an organization start adopting Agile?

Bill Raymond: Great. Thank you. And how might an organization start adopting Agile? Because I think it’s interesting in the software development world, I feel like it’s very close to, everyone does agile in some way, shape or form. However, that doesn’t necessarily mean that software developers are always aligned with the business and how they do their work.

Bill Raymond: You mentioned that for example with agile, one of the key elements here is that you’re not necessarily following some detailed plan. However, your customer, the end customers, the people that aren’t software developers might feel a lot more comfortable managing a plan. So how can an organization think about adopting agile so we can see some of these benefits that you mentioned?

Jonas Neumann: Right? Yeah. I totally agree. A lot of companies and a lot of our clients do agile, and they have implemented SCRUM, but then there’s a pain point at some point, which leads to them maybe listening to this podcast or reaching out. And I know this is not the promise, we’re not there yet, what’s missing?

Jonas Neumann: And the pain point is typically, I said in, in two areas, which one, was we are not actually fast. So, if for example, I work and I write my software and I actually only deploy it after three months. Then there might be processes in the organization, which in the terminology of LEAN would be waste, which would, I guess, slow me down as well.

Jonas Neumann: So there’s a lot of blockers along the way that one can look at. And other than just, oh, I’ve implemented some basic rules of SCRUM, I work in sprints, maybe I don’t really know what they mean.

Jonas Neumann: Maybe I don’t have a definition of done, to actually go there.

Jonas Neumann: So I guess with any change project there is, start by finding something that has some sort of urgency. Right? And go from there. How bad is the pain? The pain is bad enough? Yes. People are willing to do something about it.

Bill Raymond: And I guess since we don’t necessarily have a detailed plan, it does sound like we probably have some ideas to what we’re trying to accomplish still though, right?

Plans are nothing but planning is everything

Jonas Neumann: Yeah. That’s the other part of it. The plan. What is the plan? And I really like the quote: Plans are nothing but planning is everything. Right. So, the idea of thinking things through before we do something is very valuable, but sticking to the plan might not be.

Jonas Neumann: And recently I got a new perspective on that, where if we think about it, when we plan something, especially when we deliver software, most things in business are sort of like a hypothesis. I hope by building a mobile app for my company, I can open up a new sales channel and let’s say, increase my revenue by 30%.

Jonas Neumann: Right? If, If we formulate it that way, it’s very clear that it’s an hypothesis. And in this time, by achieving that, we definitely want to have quick iterations where we learn things. And if we adopt this mindset in agile, that’s very valuable.

Jonas Neumann: If you think I have a plan, I need to have a plan to focus on something, but I want to prioritize learning. And at each and every step of the way, maybe find out I’m wrong and correct so that I’m right.

Budgeting in Agile

Bill Raymond: I think the other thing that comes along with this is budgeting. I think very often when we think about a large enough project, there’s usually some semblance of a big plan that we might do at the beginning of the year or maybe projects that we might do at the beginning of the year, and then we might budget for them. And then we try to keep track of the variance between the plan and the budget and things like that. How is, how does that change in an agile situation?

Jonas Neumann: Yeah, that’s, I think that’s one of the most honest points where an organization can look at itself and say, how agile are we? How flexible are we with budgets? Yeah, how well can we actually adapt to changing plans? I think that’s a good way to look into the mirror and say, are we there yet?

Jonas Neumann: Budgeting typically in most organizations I see are either on a yearly or even longer basis, people fight for their budgets and write down things that they think they can achieve. But really, just hypotheses with experiences back up. Yeah. It’s not, it’s not made up, but it’s hypotheses. Budget is allocated and then it just depends on how many friends you have in the organization.

Jonas Neumann: If you can get more from somewhere, that’s usually the game that is played. But really, um, as an organization we say that, if I plan today and I learn within the next six months at least something, I hope we learn something right in business and that doesn’t change my priorities, I should be thinking of what I’m doing, right?

Jonas Neumann: The The point is to grow my business and growing my business means I need to find out more things about my customers, I need to develop new ideas, and if I don’t have any way of assigning money, which is the thing that gets people to work and actually do things, then I have a big problem.

Jonas Neumann: So in agile, we need to have a mechanism to get access to these budgets, and if we apply lean thinking there, then how much process, how much waste am I accumulating in doing that, which might stop people from trying at all.

Bill Raymond: And I guess that can lead to some level of uncertainty though, right? Because, you know, I hear what you’re saying. You have a team that is doing work and they’re doing that work iteratively and they’re getting things out to the customer as quickly as possible. And that allows you to figure out very quickly if you’re adding value, if you’re doing the right things, you’re getting immediate feedback.

Bill Raymond: You’re not just throwing a set of requirements that you built over three monthsover the fence to the software developers, and they do something for three months, and then we all come back and find out it’s not what the expectations were. Now we’re doing this on a very fast cycle, usually in a few weeks’ time, where you’re continuously reviewing this.

Bill Raymond: So I can understand that part of it and I can understand how a plancould change, because as people start reviewing it, maybe they see more value in something you’ve created over something that they thought was really important before. And it turns out it’s not. So the only concern though, is when someone might be starting this at the beginning and maybe not be familiar with agile, not having that detailed plan and not having that detailed requirements document, can lead to some uncertainty.

Overcoming uncertainty

Bill Raymond: And I guess I’d be curious if you have any thoughts on how you can overcome that uncertainty?

Jonas Neumann: Absolutely. And that’s real, very real, right? I don’t mean to play it down. The position that the person that basically gives the money, right? That would be the manager, the one who does the project, I have someone doing the work for me and they give me a promise. In three months I will get this.

Jonas Neumann: And that’s a very comfortable position to be in. Because if they don’t deliver, I have this promise, I can act on this promise. I might not be able to make them accomplish this because they are still, the uncertainty is pushed over to whoever is delivering it, but it’s a comfortable position for me.

Jonas Neumann: And that’s, that’s very real. And it’s something, you will lose in the agile way of things. And that’s probably also one of the main reasons, at least that’s what I think, why a lot of the organizations are sort of stuck in the middle of an agile-ish thing instead of doing full agile. It’s exactly this uncertainty.

Jonas Neumann: How do I get certainty? And basically my answer is, you don’t. Even if someone else promises you they’re going to deliver, you just push this uncertainty to them and sort of pushed a lot of responsibility, but also a lot of the decision power to them. Because they will, in order not to disappoint or even pay contract penalties, make every, like, take, take turns, steer along, steer the way and, and try to convince you of, of maybe it’s still changing plans um, just, just to meet your expectation.

Jonas Neumann: So rather than pushing uncertainty away, embracing it. Uncertainty doesn’t have to play off that, right. The promise of agile is I’m learning quickly and from a science perspective, that’s the best thing we can do. Right? We want to discover new things, we want to test our hypothesis and adjust accordingly.

Jonas Neumann: In the business area, of course, when there’s money related, it’s hard. Yeah. If I suddenly have to accept I’m spending $500,000 and I don’t even know what I’ll get at the end, that’s very scary and sounds unreasonable. I’m with you. But if we take and look at the other side of the coin, I’m spending $500,000 on everything I know now, which is the best idea, like to my current knowledge. Versus I’m spending this money, but at least every two weeks, there’s companies that are faster, at least every two weeks, I get the chance to apply whatever I’ve learned and make the outcome more optimal.

Jonas Neumann: And the thing that agile prioritizes is getting things done in two weeks, which means I will definitely have something after whatever period I look at, I will have something and I will have whatever I’ve prioritized.

Jonas Neumann: It might not be what I’ve planned six months ago, but hopefully I’ve learned something in those months and just be able to cost correct to do something better.

Bill Raymond: I had a client who wanted to get a fairly significant pitch deck completed. And I was helping them and we decided that it was going to take a few months, because we had to collect data from other sources, we had to pull people that we had to reach out to other folks that were not fully related to the project and bring them in.

Bill Raymond: So we generally knew it was going to be about three months, but we didn’t know what the final output would look like. Would it be a PowerPoint deck? Would be a website, would it be a video?

Bill Raymond: But when we started, you know, what we did was we just kept sharing with each other every week, here is the current result of what we have. And as opposed to sitting down and planning the whole thing out, I can tell you for sure that everyone started thinking that it was going to be a PowerPoint deck.

Bill Raymond: And it turned into a website with a training video and also supporting materials that would pitch what the new solution might look like. And it did take about three months, but what we delivered versus what those original requirements were, were two very different things. And we had to pull in different types of people.

Bill Raymond: You know, if I want to sit down and create a PowerPoint deck and put some circles and arrows, I can do that. And today, you know, with Google Docs and PowerPoint and all these other products, you can make them look really nice with just a few clicks of a button, maybe bring in some expert to polish it up.

Bill Raymond: But here now we had production people, animators, video people, was very different. But the end result is exactly what made this project successful.

Bill Raymond: And it wasn’t, and I use the word project, even though in the agile world we don’t always like to use those terms interchangeably. But my point here is that these values that you talked about, of thinking about quickly delivering something, understanding how you’re going to consume it, getting feedback on a regular basis, and having that rigor and the practice in place to make sure that you have some, I don’t want to say process, but some sort of a framework for doing that on a regular basis and changing when you need to, that makes the project that much more successful if people are open to this constant change.

Jonas Neumann: Yeah, absolutely agree.

Bill Raymond: And I guess that does kind of bring us to the conversation around value. You know, sometimes when we look at things, and of course you’re a consultant, so I know that you know, when people are talking about value with consultants, they’re like am I getting everything that I’m paying for out of this person?

Defining value

Bill Raymond: But if we look at it from an agile perspective and we think about how we define value, there’s so many ways that we could look at it. Are we making money? Are we delivering the quality that was expected? Does it have the right security practices in place? But I guess I’d be very curious to hear from your perspective, from a software developer that works with agile teams on a regular basis.

Bill Raymond: How do you define value?

Jonas Neumann: Very, very good question and very, very important. And I must say, my opinion, I see it differ a lot of times from other people’s, other developers. As a developer, when I spend three days coding, I have this beautiful looking piece of software, I have even written tests for it, it’s all automated, it’s great. I feel like I’ve done something that should be value, right? But I would say no.

Bill Raymond: Hm.

Jonas Neumann: Although it’s done to, in SCRUM we would call it, definition of done. When is something done? And to me, something is only done when the software is running in production and accessible by its users.

Jonas Neumann: And even then, is their value? Because value is many different things, but value is monetary value for the company, which might be an automation tool that frees up time from some specialists in my company and they can work on more value right there.

Jonas Neumann: It could be an app that connects people and they can collaborate, share things, and thereby improving psychological safety. There’s many different areas, but as a software developer, I feel like it’s my responsibility and I can only see value once I push it out the software and it can be used.

Jonas Neumann: To me, the analogy is a football team, I can bring the soccer ball all the way to near the goal of the opposing team. Whether or not I score is a lot harder, right?

Jonas Neumann: I can do my tactics and, and pass the ball and get it near, but getting it in is, is the last step. And that’s why we need the feedback.

Jonas Neumann: But that’s why value is a software running, accessible by its users. And that means in if I have two weeks sprints, that’s challenging. Yeah. I need a lot of automation.

Jonas Neumann: I need a lot of good practice to be able to push things out. Uh, And there’s a whole technical debate on whether releasing and pushing to production it’s the same thing. And of course, there’s features we want to hold back and stuff. All valid. But to me, it’s software that’s accessible by users is where it can create value.

Jonas Neumann: And whether it does is something, it’s the bad and the uncertainty we’re going to have to take.

Bill Raymond: Yeah. Well, and I’m guessing when you say that it’s accessible to the users, that you also mean that the users are happy with what you’ve developed and are pleased with that implementation.

Jonas Neumann: That’s the scored goal, right? I’ll have to bring it there and the rest is, hopefully there will be users that use the software. Maybe as a developer, that’s not too much I can influence, that’s obviously communications involved, marketing, PR in some cases and you asked to make that happen, but I can push it to where it can be used and then hopefully will make it.

Two-week sprint challenges

Bill Raymond: Now you said that, you know, it’s harder to do this over a two-week sprint. Do you have any examples of maybe a project you’ve been on where that was a challenge, and how did you address it?

Jonas Neumann: Many but yeah, I mean, let me pick one out. There was a project that I was on, where the context is an interesting one. So it was a huge transformation project. The company was revamping all of its sales processes and restructuring, doing another entity within in the firm, a huge project.

Jonas Neumann: And they realized that one interaction point between those new teams was an app that everyone knew they had to have, but totally forgot to plan. So me and my team were thrown into this and say, Hey, we have three months, I think three or four months. We need this app. We very precisely actually know what we need.

Jonas Neumann: Which is not typically the case because everyone thought about it, but no one had the responsibility to do it. But we were thrown into this messy, huge project with many, many different external parties and internal parties involved. And a lot of politics going on.

Jonas Neumann: What we ended up doing was like, okay, let’s do the things we know how to do. We know how to write code, we know how to play as a team and let’s just do the best we can. So very quickly we developed this software in a different language than was initially requested with a framework we weren’t very familiar with, but we just sort of gave it all we had and somehow people noticed that this team was not, you know, playing the political war. They’re actually delivering something and then that could have sparked fear, I guess. But it sparked enthusiasm in the surrounding teams. And we ended up getting thrown more and more stuff to deliver, which we ended up doing.

Jonas Neumann: So we got extended for another two months to build another small app there. And I guessthe lesson there was, following agile practices and getting things done, showing that helps you even in a scenario where politically, it might be a difficult scenario. If you have results to show, what are people going to say?

Bill Raymond: And, as a developer, as well as the people on the ground, it’s a lot more fun and encouraging to just be able to deliver something, to not have to think about too much of, what’s my surrounding, like which company I’m from? Are they checking very rigorously if my naming conventions and all these small, detailed things are in place, are not.

Jonas Neumann: And that, so that is really, really helpful.

Bill Raymond: That’s a great story. It sounds like what you were able to do is just say, you’ve given us the requirements, we will then go and implement them. And you started just chunking off pieces of it until you finally started delivering, but as along the way, every two weeks you were showing some value and they were starting to see the changes and that got a lot of excitement.

Jonas Neumann: Yes, exactly. So I mean, of course there was more an interaction. But it was hard in this political mess to grab the product owner and the business analyst associated. The good thing for us in that context was everyone was sort of, I believe before we came, everyone was trying to push back and forth who does this story.

Jonas Neumann: So there were, I think some stories had, I think 36 acceptance criteria, which is insane for a single story. But that’s the level of detailed plan that at least we could start with.

Jonas Neumann: Of course a lot of things changed because this thing was a year old. But at least we had something to work on and could sort of steer through the mess that way. Yeah.

The story

Bill Raymond: Right, right. Well, and you know, I think that’s kind of a testament to how this works, right? You start breaking down those requirements into smaller things, and those smaller things have some acceptance criteria, you use the term story.

Bill Raymond: So maybe you could just give a quick definition as to what that means and why the 36 acceptance criteria wasn’t necessarily the way to go.

Jonas Neumann: Right. Okay. So even, let me say, even in agile, we need to monitor our work. And the way we do it is from the user’s perspective. And the user’s perspective, we call it user story. So what does the user do? How does the user interact with the software we’re building? And from that perspective we write a story.

Jonas Neumann: I feel like one thing that not a lot of people mentioned that is quite important is, we do it to make work visible and to be able to prioritize work, but we do as little as possible of it.

Jonas Neumann: I think that’s, that’s one thing a lot of people don’t mention. And then one thing is to break the work into chunks so that single pieces of work can be prioritized and actually finished within two weeks.

Jonas Neumann: That’s why I was talking about the 36 acceptance criteria. So yeah, that story was not, we didn’t finish that in two weeks. I think we did it in four, the whole thing, which was quite good. But we, we broke it down into several um, sub-stories, if you will, that each contained their own interactions.

Jonas Neumann: let me make this a little more clearLet’s say we are building an e-commerce website and the user story might be from the product catalog, a user selects a product, put it into a shopping cart, and can see in a shopping cart, right?

Jonas Neumann: That’s, That’s something a user would do, but if someone who needs to implement, then they’re like, okay, how about, it’s a lot of things.

Jonas Neumann: Do I have a product page to have pagination? Can I sort things, are there pictures there, all these little things might actually take a while to implement. So that’s why we break it down into achievable stories. And then maybe at the end of a two-week sprint I can say, Hey, but here’s my product catalog.

Jonas Neumann: Here are the pictures, I remember I wanted to do sorting, this is the sorting, this is the paginations. So I only show 10 products on a page, maybe there’s a search bar, right? Instead of the entire thing. But I have something that I can show something that is, that my client can interact with and actually hands-on validate.

Jonas Neumann: Yeah,

Bill Raymond: Oh, that’s great. So it’s basically taking a stated requirement and then turning that into something that is actionable by the team, and also breaking that actionable thing down into smaller chunks if needed.

Jonas Neumann: Exactly. And that breaking down doesn’t have to be at the start. So, I think SCRUM doesn’t talk about that too much, but I know that Extreme Programming another, just another framework does. So they say the story in its initial state just has to have enough information that you can do a rough estimation.

Jonas Neumann: Is this too big or is this sort of achievable? That’s all. And then only when you decide together with your client that you’re actually going to work on it, are you going to fill in the details. that’s part of the where does the planning go? No, it just doesn’t have to be upfront and I don’t plan for work that I’m not actually going to do.

Jonas Neumann: Right. That’s the conversation and the plan is always current because it’s established and communicated at the time of when the work is done, or maybe at the start of the sprint, if I do backlog grooming. Yeah.

Bill Raymond: That’s a good example. Thank you. And one of the things that I’ve always been fascinated by is how software developers really do a good job of this?

Bill Raymond: And me as a business person maybe doesn’t do the best job of it, right? So I decided to start learning how to do some software development, create my own website, and I remember that I even created some user stories and I said, there’s going to be a homepage. And I had some designer put the page together to show what it looks like.

Bill Raymond: And I just said, you know, create this homepage. Well, the homepage had the logo on it, and I found out that if you really want to do your website right, you have to have this tiny little 16 inch by 16 inch icon that shows up in the tab of your browser. And that’s called the fave icon or favicon.

Bill Raymond: And then I found out that if someone stretches their browser and puts it on the desktop or on a small phone, you needed to have multiple versions of that. And I just remembered going, wow, my user story to create this webpage is taking me days just to get the logo right.

Jonas Neumann: There’s a lot of complexity we hide. Writing code is a creative process, but it’s interfered by at least six things. I have to constantly think, what does my user actually want? And part of it is, did he communicate well what he actually wants, right? Because if not, I have to rework and I don’t like that, and it’ll slow everybody down, right?

Jonas Neumann: That’s the whole communication part.

Jonas Neumann: Then there’s obviously my language and my framework that I have to know and deal with. Then there’s security. Am I building a vulnerability into the system right now? That’s very relevant. Then there’s performance. Am I writing it right now in a way that actually this thing is still usable, or am I slowing things down too much?

Jonas Neumann: Then there’s reliability. Like, have I thought of, what if the input is not what I expect and this thing breaks? How do I handle that? And there’s observability. What if there is a bug that I missed? Are we able to find out later on, how can I do that?

Jonas Neumann: Operatability. Do I build in the right knobs to make this, during the operational phase, to be able to change the things that I might have to or will it be a nightmare? And then there’s all sorts of quality aspects.

Jonas Neumann: There’s nothing, and I have all these requirements and all these things I need to think about and then I create something. That’s why I’m in it and that’s why most people are in it. We create something out of nothing. And there’s um, just, just the fact of that we do that, the creative part of it, is something that is very enjoyable.

Bill Raymond: Yeah, and I really appreciate that. I remember back in the day when I was working in an IT role, managing some software developers, I remembered one of my managers came up and and said, So do you see software development as a art or a science? And I emphatically, I mean, I was very, very firm about this, it is a science. And I can completely agree with you now that I was wrong. There is science behind what you do as a software developer, but there is a lot of creativity and uniqueness and different ways of approaching things. And it must feel great when you are developing something that’s brand new.

Bill Raymond: It just feels like you’ve invented something, I suppose.

Jonas Neumann: Yeah, that’s right.

Bill Raymond: That’s cool. I love it. well, we have defined how we’re going to do the work and we build a strong relationship with our customers so that hopefully we can be delivering value on a very quick basis.

Ideal working environment for agile teams

Bill Raymond: But now let’s talk a little bit about how exactly we can do that for teams. So what is an ideal working environment for agile teams to thrive?

Jonas Neumann: Yeah, I mean, if we specifically look at software development, our output is software. So the ideal setups should basically enable us to do this in the most efficient, fun, and best way. And a lot of that has to do with, is the team able to deliver these things on by themselves? That’s why in SCRUM we have the T-shaped developers, right?

Jonas Neumann: You have one areas of expertise, but you can actually do multiple things. You have a small team that is able to deliver software end to end. Like you mentioned, actually there’s a lot of things to know about and think about. Is it usable on different devices? Is it secure?

Jonas Neumann: And in a traditional IT setup that those might be four departments already and we’ve barely touched on anything. And when bringing in agile, we want our teams to deliver, be able to deliver end to end. if I have to coordinate six departments within two weeks, I won’t even find a meeting spot.

Jonas Neumann: Right? That’s how it is, yeah, we have endless cues waiting for another end. That’s not an environment where people can thrive. And as a software developer, if I want to be in a very productive state getting things done, I actually need multiple hours of consecutive high concentration work to get things done because I have to manage all these things that I just previously talked about.

Jonas Neumann: So the ideal setup is, a team is able to make decisions on all of these things. Like, I have someone who knows how to do UI and UX. I have someone who knows how to do with all the data stuff. I have people that can connect together and know about security. I have my business people right there who can help me with the requirements and the details that might not be specified.

Jonas Neumann: I have all these close contact collaboration to be able to deliver. So that’s the environment that management can do.

Jonas Neumann: And the book, Team Topologies goes into a lot of detail of what this would look like, and I read and was like, yes, yes, yes, please, yes. This is when it’s the most fun. really good there.

Jonas Neumann: So there’s what they called stream-aligned teams is what I was just mentioning. And as a developer, if I’m on one of those, I know that I can deliver, I know that I will deliver and it’s going to be fun.

Bill Raymond: Well, yeah. Absolutely. I completely agree with you. You know, Manuel Pais and Matthew Skelton, the authors of Team Topologies, were actually on the podcast. So if you want to go to the agileinaction.com podcast, you can go ahead and look up that conversation. I was so very intrigued by that book.

Bill Raymond: I couldn’t even, didn’t even get halfway before I asked them to please be on the podcast. Of course, I did finish it before we chatted and it was a great conversation. So I think what I’m hearing from you is, to allow an agile team to thrive you do need to be very close to the customer, but you also need to have the time and the space to get that work done.

Bill Raymond: Just putting a field on a screen or a button at the bottom of a page has a lot of work behind it, as you mentioned, with a lot of different types of resources, the people to get that done. And it is probably a lot more work than a lot of people think. And so giving that time and space for that to be thought out, it sounds like you also need to cut back on as many meetings as possible as well.

Jonas Neumann: That’s an interesting one. So I, I, I think it’s in_Accelerate_ the book by, I’m not sure if you’re aware of it, by Jean Kim and Nicole Foster and others.Developers need, I think it was about four hours of time in IDE. IDE is the tool we use to code, to be happy.

Jonas Neumann: So I guess the rest of it there is the collaboration part and it’s also not good and not fun to be too far apart from those people you collaborate with, so that you can actually make sure that you implement the things that you do.

Jonas Neumann: Because if we’re looking at it from a developer’s perspective, two weeks is a long time.

Jonas Neumann: If I have a question now, even if it’s as simple as, how big is this button going to be? I need someone to talk to. I will sort of need to do it today. It might block everything else that I’m doing. So there is a very close collaboration with people that can make these kinds of decisions. So in a SCRUM context, it can be the PO or you can put that responsibility on someone that helps, maybe a business analyst or maybe even the customer itself, if there’s a close communication, which is always, always helpful. Maybe not for the size of a button, for bigger things, but yeah.

Jonas Neumann: So there’s this time for collaboration, but there is definitely a balance andthought has to go into, I need to make sure that my developers have this uninterrupted time every day to actually work on things.

Bill Raymond: I guess to wrap this up, is there any way people might be able to reach out to you?

Jonas Neumann: Yeah, sure. I’m not on Twitter. I’m one of those few people, I’ve never been. So sorry about that.

Bill Raymond: Well, don’t worry, I don’t think it’s working anymore.

Jonas Neumann: We’ll see how that one goes. True, true. Absolutely. I’m on Medium and if not, I’m on on LinkedIn. Yeah. Name is, is Jonas Neumann. Happy to chat, happy to answer any questions you might have. I mean, if it’s for a specific topic, I guess the best way is, I probably have a Medium blog about it.

Jonas Neumann: You can leave a comment, there’s some interesting conversations there and some nice people that leave very interesting comments.

Bill Raymond: Yeah, absolutely. And, And that’s how we found you. You have a great Medium page with excellent content and we really appreciate that you are helping the community with that. We actually found out about you from the Medium article titled, The Fundamental Misunderstanding That is Destroying Agile.

Bill Raymond: And it was a great article and it covers many of the topics that we talked about here today. And I really appreciate the thoughtfulness that you put into this conversation today. And I’ll also make sure that your Medium and LinkedIn page are listed on the agileinaction.com website.

Bill Raymond: And if you’re listening in a podcast app right now, just scroll down to the show notes, in description, and you’ll see those links there.

Bill Raymond: I’ll also include a link to the Team Topologies conversation that we just mentioned, and also because we use the term SCRUM a lot, but didn’t define it here,

Bill Raymond: do look for our intro on SCRUM and that’s from Nader K Rad. where we have a two-part conversation, and I’ll make sure that is also in the show notes as well.

Bill Raymond: Jonas Neumann, this is a great conversation, I really appreciate your time today. Thank you so much.

Jonas Neumann: Thank you. Had a great time too.

Bill Raymond: