Agile and flow with Staffan Noteberg

Join Murray Robinson and Shane Gibson as they chat with Staffan Noteberg about Agile and Flow. Learn how Agile is about adapting to unexpected change and why coaches should be practitioners to effectively guide teams.

Key takeaways include:
🔸 Speeding up the feedback loop
🔸 Encouraging monotasking and reducing interruptions
🔸 Starting small and scaling out
🔸 Addressing the issues with SAFe
🔸 Focusing on interactions between people and informal networks
🔸 Using tools to build networks while working remotely

Tune in to explore the value of Agile and Flow, and discover how to optimise team performance by emphasising interpersonal connections, setting clear goals, and promoting mono-tasking.

Read along you will

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

Murray: and I’m Murray Robinson. 

Staffan: And I’m Staffan Noetberg 

Murray: Hi, Staffan. Thanks for coming on. So we wanted to talk to you about lean and agile today. But why don’t we start by getting you to tell people a bit about yourself. 

Staffan: So I’ve been into it for a long time. Since the nineties I worked as software developer and then got into complexity in the late nineties and even more for the last 20 years about teams and deliveries and cooperation and products and things like that. This term agile that has changed very much in the mid nineties, it was about virtual companies and then came to agile manifesto and then agile was very much about scrum. And now agile is more the opposite of what it was from the beginning for some people, at least. But taking big deliveries that someone ordered a long time ago and we didn’t know why, but we need to deliver this thing. I also written some books about personal productivity. 

Murray: Monotasking? Was there another one? 

Staffan: One called pomodoro technique illustrated.

Murray: it’s interesting. How many people have been software developers. Our view is that you have to have done the work to be able to really, advise people on how to do it better and how to reform. But you do get these people coming out of the executive coaching community to coach people these days.

Staffan: I think it is an advantage to understand the domain, but it’s not it itself that the customers are looking for. It’s something else. So maybe in the future, we will see ethno graphs and other people also participate in this.

Shane: Should a coach have played the game before to be a good coach. It’s interesting the number of coaches who have come from a software engineering background and a product background. So do people who have played the game before make better coaches or not?

Staffan: I think the approach you should have is that I need to learn more about this domain and also need to learn more about domains around this. If you’re a software developer, then maybe you need to learn more about psychology or about products or markets or ecosystems. But if you come from somewhere else, maybe you need to learn more about software development. Otherwise you won’t understand what the real problems are.

Murray: You’ve been writing about lean and agile recently. So what is the connection between lean and agile? 

Staffan: Agile is a very overloaded term. So it means very different things to different people. I think about it as an ability to adapt to unexpected changes. So you set up your system so you’re more prepared to adapt and influence the new situation. So it’s not like you are just adapting. It’s also that you should be active in the new situation and take advantage of the change. 

Staffan: For example, if you have more diversity, maybe it’s easier to adapt compared to if you’re more specialized, if you have more feedback loops, if you have shorter iterations, these things creates this ability to adapt if something happens.

Murray: But what about lean though? I asked Alistair Coburn about this a few years ago and he said, We didn’t know anything about lean when we were writing the agile manifesto, but it feels to me that quite a few of the ideas have got in there and it’s certainly become much more important, as it’s got bigger and people have been expanding agile to lots of other areas. So tell me about how you see lean and agile together. 

Staffan: My analysis is that scrum is very influenced by lean and especially by flu. So I think the scrum has, two parts. So one part is the agility, which it comes from John Boyd, the UDA And the other part is lean that you should try to improve in small steps and refine everything you do, and be better and better at things. I think that what people are referred to as agile now is very influenced by that moment, by the Toyota thing.

Murray: I did some consulting with a large automotive company. And I found that in the office, they weren’t using lean ideas or agile ideas at all. It was very much traditional American top down command and control management. But in the factory, it was all lean, CanBan everything, and, small groups working together to solve problems. But for some reason the ideas hadn’t made it into the office until agile and the agile movement . Do you have any thoughts on that? Why would that be.

Staffan: I think that things change faster and faster, especially markets and customer demands. There was a time before when we thought that this is the way we are going to do things. The jobs to be done will be the same for a long time. And this way of thinking has changed. So now you think that this is temporary, there’s a new product. It helps me right now. I will buy it, but I will probably not use it 10 years from now. And that’s why product development has become so important compared to manufacturing. The factories were early with this because in factories that’s where it’s easy to just deduce things, to just make calculations and say, How you do things, but there were movements in the 20th century that really improved this way of thinking to try to find the real problem and change that instead of just fixing what you see.

Shane: Do you think that the reason that lean was founded in factories was because the work being done was visible?

Staffan: I think that it’s easy to struggle when you can’t see things. In development you don’t know if you did the right thing because you could have done hundreds of millions of other things. And maybe that would have been better. When you’re manufacturing things, maybe you can calculate and see that this was the best. Also something that is crucial is where the money is. The used to be a lot of money in manufacturing and not so much in development. And nowadays when things could faster and faster, there’s a lot of money in development. People are more keen there to optimize and get better processes and methods.

Murray: I see scrum as creating batches of work. When you look at teams, they’re preparing things for their sprint. They’re doing things in their sprint, and they’re trying to finish their plan by the end of the sprint. So you get batches that disrupts the flow of work. Sometimes I advise teams to go to CanBan or to use scrum ban. I quite often say to teams. Don’t worry about finishing everything, in your sprint, if you can finish it at the start of next sprint, that’s good. Cuz then you won’t have a bottleneck in, some of your team members. So what do you think does scrum cause batching of work, which disrupts your flow?

Staffan: If you think of scrum, As mini fall. So we have a plan for two weeks. We are going to do these tasks and they should be completed. And the successful sprint is if we have completed all these things then you will get these batches where you just do things just because you have planned them. And you don’t think about the product or the value that it’s creating. I think it’s good to have some cadence where you say , or these things, the things that we really should continue with or are the other things that are more important?

Staffan: My experience with teams that say, we don’t want to do scrum, we want to do CanBan is that they’re not concerned about this. So they say, we don’t want those scrum. We want to do Kaban. And what they really want is to get rid of all these meetings and stick to some task for weeks and weeks or months and months. And then they forget about is this thing that they are doing, is this really the best way of spending their time? Maybe they should do something else. 

Murray: I get my Canman teams to have all the same meetings anyway. So I get them to have a weekly planning meeting with their clients or their product owner. So I think the combination of scrum and CanBan works better than either one of them on their own. 

Murray: Now you wrote a book called monotasking and I haven’t heard about that before, so I’d love you to tell us about it. What is monotask.

Staffan: The word monotasking is the opposite of multitasking. Its pay attention to one thing at a time. if you have a team you are not having a sprint backlog, but you have a sprint goal. Instead of saying what deadlines do we have? You say, this is our sprint. goal Let’s get together and see how we can contribute. On the personal level. Monotasking is you focus on the most important thing.

Staffan: Monotasking is not only about deep focusing it’s also about setting up an environment where you really can monotask. I found six areas that are important for being able to monotask. One of these is to cut down on your backlog, or your to-do list. Cause if you have a lot of things, even though you haven’t started with them yet, they are disturbing you. And it’s very hard to prioritize when you have so many things crying for attention.

Staffan: Monotasking is personal, but if you have a scrum team, you should have 10 things in your product backlog, not hundreds of things or years and years of work because they will disturb you. You will think about these things because you have in some way, committed to them, even though you haven’t started with them yet. There’s a lot of research showing that if you have things that you’re thinking that you will do in the future, they will disturb you and slow you down. 

Staffan: And the second thing was about procrastination. One thing is to notice when you are procrastinate. There are methods that could help you. One thing is if you think that you should end your task before you go home in the afternoon. But if you think in the other way and think that I should have something started before I go home, then you will be eager in the morning to start with that one research says, but of course it’s in individual. So it doesn’t work for everyone, but for many people it works like that. 

Staffan: Let’s say that the scrum team, instead of stopping doing things in the end of the sprint, and then start with new things instead started with new things in the middle of the sprint. And when they started the sprint they should be more eager in the first day of the sprint to continue with these things. 

Murray: So you’ve done a lot of work with big enterprises coaching them on agility. What are the main challenges you see when you are going out there and, trying to help people adopt these new ways of working?

Staffan: One thing is that there’s higher trust in structures than maybe it should be. When you’re working with product development and software development ideas and development is bouncing around in a network. In that case, it’s very important who you trust in the organization. And I think that many organization can do more to nudge the informal network to help people to new things. So it’s making lot of connections inside a company to have when you need to know something. 

Staffan: Many people say that we are struggling with dependencies. Some people say that we need to manage the dependencies and some say that we need to get rid of dependencies. But the third thing might be that you strengthen the informal network across the silo borders and then it’s easier to get the information or give the information when you need it.

Murray: So, If you were scaling, agile within an organization, let’s say that you’re working with a hundred people what approach would you use?

Staffan: I would start very small with one thing. Usually what I’ve seen in agile transformations, you get these bunch of people and they create some playbook or they say, we should do SAFE for scrum. And then you have whole book of rules and everybody should follow this. And I think you should be very careful. We are putting these rigid constraints and saying that this is the rule. Everybody needs to follow. So you should start as small as possible. Some things you need to have the same rules for all people, because you’re cooperating in some way that it doesn’t work. If something does another way, but a lot of things could be decided by the team themselves. So then maybe you should inspire the teams and say that this is the way you could do, but you decide yourself. But a few important things that is crucial to organizations maybe you should say, this are mandatory. This is the way you have to do this. If you have 10 of these things, maybe you should start with one of them and see when this works. We could take on the second one or the third one, instead of saying, now we have a big transformation, it costs a hundred million dollars and we will do it for two years or one year, and then we’re done, then we’re agile. 

Shane: I definitely agree that scaling with hundreds or thousands of people from a standing start is just ridiculous. To me, it seems like it’s a set up for failure. 

Staffan: One addition. I wouldn’t even call it an agile transformation because one thing is that agile is so overloaded, so it’ll mean different things to different people. And the other thing is that agility is not the best thing everywhere. When something is very mature, it could be better to just optimize resources. And other cases, it’s better to think about flu and removing waste and not about agility. So instead of saying, now we’re being agile should try to pinpoint where do we need more agility where dont we need more agility. 

Murray: What is most important to you when you are doing this work?

Staffan: To me personally, it is to get organizations aware of the complexity and that everything can’t be planned. You need to try things and learn along the way that’s something that I think is important. Try different things, not just making a pilot and then say this concept works and scale it, but try different things at the same time. 

Murray: So then how do you get them to understand and embrace uncertainty and experimentation? 

Staffan: It’s very dependent on the specific situation and that’s why it’s very hard to make a recipe on it and say, this is the way that you should do experimentation. As an agile coach or product coach, you need to have a broad repertoire and really understand what is going on right here in this company. What could they try and how could they try this? I learned a lot from reading books and listening to things and talking to people that are in some other field, for example the ecology in the forest, how the fungus is supporting the trees. It gives me many ideas of how maybe you could do something in an organization.

Murray: In your article, you talked a bit about tailorism. Frederick Taylor says the work of every workman is fully planned out by the management. Not only what is to be done, but how it is to be done and the exact time allowed for doing it.

Murray: I don’t know about you, but I still see a lot of that thinking in senior management that, you have to define your processes centrally and then make everybody follow them. And that would seem to be a major barrier to innovation and experimentation in teams. What do you think? 

Staffan: So I think that sometimes people that have the mandate things that for example, when they’re making an agile transformation that this is just a new machine that we are bought and there is one best way to use this machine. So we need the training, how to manage this machine. What bottoms to press and what place to look at and what we should do in different situations. But when you have hundreds or thousands of people that should cooperate, it’s totally different. Things are happening and things are changing and its path dependent. So when something happened this will influence the future for all time. You can’t reset everything like in a machine and then you need very different methods. Some people don’t think about this. So they spend a lot of money on centralizing, finding the best practice and implementing that best practice, even though it won’t help them because they need something that is more generic. That could be changed and they need to have processes to emerge and change as time is going because we learn more and the environment changes.

Murray: I think that it’s managerial thinking in organizations, which people learn as they go up the ranks through big organizations. There’s this assumption that you have to be in control and be seen to be in control. You have to know what’s going to happen and, be able to develop a plan and then achieve the plan. That’s what it takes to be a good manager. And you have to be certain about things. And you have to have a lot of influence and power and that’s how you get promoted because you are seen to have all of these attributes and people who try and do that, tend to think in this very old fashioned way, that everything is predictable, that everything’s plantable that the way to do something effectively is to break it down into little parts and then do each part in its cheapest possible way. You may have heard me talking about how I worked for a place it took 12 weeks to get a firewall rule change, cuz they broke it into tiny little bits and then tried to do each bit as cheaply as possible.

Murray: I’m increasingly thinking that agile is part of a movement that’s quite similar to the change from Newtonian thinking to quantum mechanical thinking. Cause it’s all about an acceptance of uncertainty and change. In, quantum physics and in maths there was this enormous realization that a lot of things were uncertain. And even now we’re battling with managers to try and get them to accept that things are uncertain because a lot of them still don’t cuz they don’t want to. Do see it that way that agile is part of this big paradigm shift in thinking. 

Staffan: I think regardless if it would be called agile or not there is a change in that direction like you say, Murray. And one reason for that is that the market doesn’t accept companies that only exploit and try to make things in the same way and try to just optimize the resources. They will be punished by the market. It goes much faster now than when we have software and we can digitalize things that could be companies with 10 people that takes a lot of market from old companies that have tens of thousands of people. That wasn’t possible before, because then you needed resources, like a lot of money. You needed a lot of factories and raw material and things like that. But now can be much faster. So, that is certainly the case, but I think that maybe it won’t be called agile because I seeing more and more that agile is becoming commodity and the term agile is used by the other way of thinking.

Staffan: And maybe it will be called something else or maybe it is already called something else. But I think that in the early 21st century, the agile movement, helped this a lot but maybe not as much anymore.

Murray: I don’t think agile is dead. But I do worry about safe. I feel like safe accepts dependencies and hierarchy. It weaves it all in to whatever it is, which is definitely not agile in my view.

Shane: We had a podcast a while ago where people were talking about adoption curves and I’ve been ruminating on that. Murray and I have been very clear that we are not a fan of safe for a whole bunch of reasons. And every now and again, I get a message saying, Hey, stop bashing safe. And I’m like, I don’t agree with it. I’m not gonna agree with it. And that’s okay. But I was thinking about it more and more. And if we think about agile as an adoption curve whenever we adopt something new, the people that adopted are the people that are comfortable with uncertainty.

Shane: And so if we think about the early days of agile, there was a lot of uncertainty . This was a different way of working. You had to be an early adopter. You had to be comfortable with UNC. And we’re at the stage now, with agile where the late majority is starting to adopt it and they want certainty. And safe gives them a sense of certainty to adopt this new, agile way of working. So all the consulting companies are selling it to make money but I think customers buying it because it gives them certainty and the late majority want certainty cuz they’re following the crowd.

Staffan: Yeah, I agree with you, Shane. I also think that some of these processes have an outside in view. In scrum, there are lot of feedback. Scrum is very based on inspect and adapt. So you should look at what do we have right now? How could we change both in process and in product?

Staffan: But I think this big processes that become popular right now there, the feedback loop is from the outside in. If you look at these methods, it seems like they have no feedback loops. They replaced review with Demo. So I’m from the outside, I’m requesting something. And then I want to Demo that’s my feedback, but in scrum, it’s the other way around you start from the team and say, we are doing something we’re inviting people to come here and review what we have done so we can get feedback. 

Murray: Yeah. I agree. It certainly feels like safe is a push system. People outside. Push work into the teams and, if the teams wanna change the way they’re working they’re not allowed to. So it’s not very agile. And I think I tend to a greasy Shane what’s happening now is that people who don’t really want to follow the agile values and principles are adopting agile because they feel they have to be competitive, but they wanna keep all of their old ideas at the same time. And there’s, quite a big consulting market for that. 

Murray: So, Staffan, you’ve been doing this for quite a long time. I’m wondering what interesting things have you learnt along the way? 

Staffan: It’s very popular to think of humans as computers. So they have some memory and you can teach them, you should say, this is the mindset that you are going to have. Then we will get the right culture, but maybe should think in the other way that the way people think is coming from what they are doing. Instead of thinking that we should reprogram their brains. We should say that this is the mindset that you need to have, and then they will do the right thing. So it’s more about interactions, in the agile manifest as interactions, over processes and tools. And I think this interaction is something that has been played down in the agile movement interactions between people. Maybe if we could connect a lot of people, so they have a lot of interactions, maybe now you’ll behave in the right way because you have the right mindset.

Murray: So this is going back to what you were talking about before with the fungi that connect trees together. This reminds me of what’s called loose connections in social network theory. And I was reading a paper the other day that said that at Microsoft, when they went to remote working, the biggest issue that the researchers saw was that there was quite a decrease in spontaneous connections and loose connections and getting to know people outside of your area. Personally, I think remote working is really good and we were wrong about the necessity for face to face meetings and face to face work in agile. But, there is a price to be paid in those looser more spontaneous connections across groups. Is that what youre talking about? 

Staffan: I think that it’s still very new that we working remotely and that we connect in this very formal way with each other, but there will probably come better methods of helping these things. So if you work in the old way that we did in the office, when we overheard things from our colleagues that was sitting, in the same room but we go home and sit at the computers and only have meetings that are in our calendars, then we’ll miss a lot of things. I think we will see in the future new processes that helps people to have these spontaneous collaboration during the Workday in some other way. For example, let’s say that you have open space for the whole organization one hour every week, maybe you will get a lot of new connections, but also new insights. And that could be, done remotely. 

Murray: I like that idea a lot. I’ve been involved in a few open space events and I thought they were fantastic. And you could do them online because you could use boards to come up with things to talk about, and you could create meeting rooms based on topics with facilitators, and then everybody in the company could go into them. As you said, that’s a really interesting idea.

Shane: I think remote working’s gonna be the crisis that changes the way we work. I was working with an organization and we were very focused around slack as a way of communicating across the teams. And there was an add-in for slack, which was donut meetups. You opted in and it would randomly send you an invite, a meeting request with somebody else. So you could have a 15 minute chat to them and just randomly connect to somebody else in the organization that you’d never met. It was like bumping somebody in the water cooler or as you went down the stairs. But then I’ve seen, that idea gets forced and so people don’t opt in. So there’s a balance. I think taking the ways of working that we had when we were in person and trying to apply them in a remote paradigm is not gonna work. We are gonna have to find new ways of working that work, where we don’t share food, we don’t bump into people. We don’t build our culture in person. 

Murray: Have you come across anything else that helps people with those impromptu or loose connections when you’re working online? 

Staffan: One thing I tried in the big organization was buddy system. Every second month you were randomly connected to one person in the organization could be the janitor and the CEO, for example, that was connected. You were connected to one person. And then you were supposed to have a meeting every second week during these two months, there’s roughly four meetings 30 minutes. And the agenda was like explain to the other person what you work with right now. So you need to explain it in a way that person understands and it makes lot of discussions come up and you get connections and you get more understanding of what people are working with in other parts of the organization. Some of these connections were never used, but some became very important.

Shane: So I, think of scrum ceremonies as a forcing function. We have daily standups to force the team, to talk to each other, at least once a day. So think about the things we’ve lost by not been in together. And then what are the forcing functions we need to introduce to bring that capability back.

Staffan: I think, that’s a very good point. You should be very careful before you implement a lot of these things because they will cost you energy. They will take time to do these things. But you should try. It’s very hard to understand upfront if it will go to be a good investment or not. So maybe you have to try it, but if you don’t like it, you can skip it. 

Murray: That’s the thing I’m missing out on in the team I’m working with at the moment. I started off by going and talking to the developers and I haven’t talked to many of the developers for quite a while. Now I’ve got into talking to, project managers and people like that. So I need something to force me to connect with developers and testers and some of the people in Vietnam and things like that. we should wrap up. So what are your thoughts, Shane? 

Shane: So we started out with this idea that for you, Agile’s about adapting to unexpected change. So we can’t plan for it, but we can get ready. And I liked your idea that we should focus on breadth of skill over specialization. We should focus on more feedback loops. We should focus on shorter iterations for delivering things. We should focus on setting the goal for the team and letting them get on with the work. If we do those things, then we have a better chance of dealing with that unexpected change when it hits us. And we all know that, change is gonna hit us regardless. And that’s a common theme we’ve had across the podcast on a regular basis from our guests, especially the setting, the goal. That’s coming through for me really strongly for a long time now is set the goal, let the team get on with it.

Shane: Monotasking . Notice when you are procrastinating. One of my failings is procrastination and I try many techniques for it. So that idea of work on one thing at a time don’t multitask. Set up the environment to reduce interruptions. The developers want time where they’re in that zone. They’re working and getting something done. That’s important. So how do you manage those interruptions? Especially in the remote world?

Shane: I like the idea that developments like bouncing around within a network. And because of that, it’s not about hierarchies. It’s about this network we’re bouncing around. So we need to foster informal networks. There is always a dependency in a large organization and successful teams I’ve worked with have managed those dependencies through their informal networks nine times outta 10. 

Shane: From a scaling point of view? I think about start as small as possible and then get some things working and then start to scale out. As we scale rules of engagement or ways of working are important. But set those when we need them and only when we need them and then expect and adapt them when we need to. And the last one for me was, this concept of inside out versus outside in. I like this idea about inside out as we’re inviting people in so we can help them. We’re not having work from the outside, throwing at us. 

Staffan: My point there is who getting the feedback. Is it the outside getting feedback on the request, the requirements, or is it the inside getting feedback on the work? 

Shane: I like that concept. Murray. What have you got.

Murray: I do think of agile as very much a feedback mechanism and I certainly think a lot about how change is more effective when it comes from the bottom up, you’ve gotta have a goal leaders should set the goal, but then how you do the work. It’s the people doing the work who can best come up with how to improve doing the work if they know the goal you’re trying to get to. I do find it interesting though, to think that there are some ways of working where you don’t get the feedback, it’s just somebody outside, some manager who pushes stuff in and then finds out whether they’re gonna get it or not. That’s more of a traditional way of working.

Murray: We talked about a lot of things. We talked about coaching. We talked about, models of management thinking. We talked a lot about flow to start with the most interesting part of it for me though, was this discussion we were having at the end about impromptu connections and how we have been losing those working remotely.

Murray: If you’re working in a team on a floor, for example, you’re gonna bump into people and talk to them. If they’re part of your broader group, but if you are spending all day on teams or zoom or whatever it is, you’re gonna be very focused. And unless you make a particular effort, you’re not going to be talking to people in your broader group, and that is going to affect your understanding of what’s going on . And that is the first thing in the agile manifesto. Isn’t it people and interactions over processes and tools. I wonder these days, if most people think that the agile manifesto actually says processes and tools are more important than people in interactions. Cause that’s way it’s often implemented. so that’s what I got out of it. 

Murray: So Staffan, how can people find you? Do you write, do you blog you consult? Don’t choose. So what’s the best way for people to find you?

Staffan: it’s probably LinkedIn. I write blog post at medium.com and do some trainings also. Just Google my name and then you will get to monitoring.com or something like that. But also connect with me in LinkedIn.

Murray: And do you do public training or do you just do corporate training?

Staffan: I do public training in monotasking. So I will have some, this AU both removed also both uh, remote and also here in Stockholm

Murray: okay. Great. All right. Well, thanks very much for coming on. We appreciate it.

Staffan: Yeah, thanks for having me. It was the interesting conversation.

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