Transcript
Asgaut Mjlne Sderbom: We’re here to talk about continuous delivery, and that it’s not possible without pair programming. My name is Asgaut Mjølne Sderbom. I’m a senior developer in SpareBank 1, which is one of the biggest banks in Norway. I’ve been developing for 19 years, and I still love programming.
Ola Hast: My name is Ola Hast, also a developer at SpareBank 1. Yes, also love coding.
Starting Out (Career)
Asgaut Mjlne Sderbom: In October 2020, I started as a developer in SpareBank 1 Utvikling. I knew it was an agile company, focusing on people, culture, and everything, and they had this slogan, which is better together, it is bedre sammen in Norwegian. You never know how it is before you actually get to the company and start. After working there for about a month, I was in a meeting, and they said that you’re not allowed to do pair programming for the rest of the year. This was in November 2020. I was shocked. I was sitting back home back then. It was the pandemic, and my wife was working at home as well. She said she’d never seen me this angry in a work professional setting before. That’s when we decided to start to do something.
Ola Hast: At the same time, we had a survey on meeting culture. We like to measure things in SpareBank 1. It can get annoying sometimes, but it helps us keep a feel for the temperature in the company. We had a survey on meeting culture, and 82% of the respondents, I think it was about 600, they said that they felt that they were working in too much at the same time. The work in progress, or WIP, as we’ll refer to it, was very high. Seventy-two percent wanted 4 hours of uninterrupted focus time per day, but only 20% of us actually had it. Something was not right. What we did, we actually had a series of meetings and workshops about us having too many meetings. It didn’t quite solve the problem.
At the same time, we had visitors, breakfast visitors, from the Norwegian Welfare and Labor Administration. They are the ones who handle welfare and unemployment benefits, and so on, in Norway, which is about one-third of our national budget. The guys were Terje and Julian. They told us that they pair programmed everything. They put every commit straight into production. They have dropped all test environments, and they got rid of the pull requests. We thought, we’re a bank, we can’t do this. One-third of the national budget is nothing. By then we started thinking, maybe we should try something like this.
Asgaut Mjlne Sderbom: We are doing cooperation with someone called SINTEF Digital. They’re independent researchers or scientists sponsored by the government. This guy here, Nils Brede Moe, he’s the chief scientist, so we refer to him as the chief researcher. They are researching across the Nordic region, so they are in big companies around Norway, they are in Spotify, Ericsson, a lot of different places. They’re trying to see how we can have better, efficient teams. We will refer to him during this presentation and his findings, which will back up some of our experience.
Avoid Personal Focus, Increase Team Focus
Back to 2021, me and Ola, we were working in a team called the My Economy Team, which was responsible for all the expenses, showing like a forecast of what you’re going to use and how much you used on travel. It was a great team with the usual suspects, frontend, backend developers, designers, product leaders, IT coaches, everything.
Ola Hast: You were working, I was enjoying the benefits with the Norwegian Welfare and Administration.
Asgaut Mjlne Sderbom: Still in the team. We had some problems in this team. We were focusing on too much on the individuals and not as much on the team. This is normal questions that would arise on a standup, how is your task going? Can someone approve my pull request? It’s a lot of focus on the persons. Have you figured out the critical bug yet? Then, our favorite one, are we on track with your task?
Ola Hast: This is the team pretending that they actually care about you.
Asgaut Mjlne Sderbom: Then we have the researcher, Nils Brede Moe. He says, when he sees something like this, then this is not a team. This is just a group of individuals with their own goals, not caring about the team. It doesn’t smell like a team, he said. At this time, we had a great agile coach. She’s called Marthe Fleischer, and she saw this problem in the team. She said, we’re working in something called the radical focus model, which means we work in weekly cycles. We plan some stuff on Monday, and then we work during the week, and we have some ceremony on Friday. She said, this week, I want the team to only have three main tasks.
Even though we were six, seven developers, we were forced to work on fewer tasks. This made a difference. What happened after a while working like this, was we had a main task like this with some other tasks that are not that important, but these three are the main tasks for the week. Then these are just simple checklists. It’s not in any issue tracking system or something like that. Most important of all, there’s no assigned person to the task. There are not any tasks that are like, you are responsible for this task. It’s the team that is responsible to achieve these tasks during this week.
Let’s look at a classic setup with high WIP or work in progress. You have six different tasks, and then you have six developers. That’s perfect. This is a Monday, we’re planning for the week. Then we see that two of these tasks are not that big, so we add two more tasks. We have eight tasks for these six developers. Then we start working. On Tuesday morning, there are two other tasks coming, two bugs flying in. Then we have 10 tasks in progress for these 6 developers. Then the chaos starts because this team, they are trying to be a little bit modern, they slice tasks. They try to do rapid deployments to production, but that’s nearly impossible because all of these, since they are working with each their things, they have to interrupt each other because we have pull requests and we have code reviews. Then you have communication to solve your task and everything. It breaks down immediately. It’s not possible.
Ola Hast: The only person who is happy with this is the project manager.
Asgaut Mjlne Sderbom: The traditional project manager.
Ola Hast: Because everybody’s got more than enough to do. No one is idle.
Asgaut Mjlne Sderbom: It’s pretty easy to see because they also maybe require meetings. They have to communicate with other teams. Everything just breaks down. What happens then pretty fast is that they start to build bigger tasks. Everyone knows what happens when you build bigger tasks, you have bigger code reviews, the risk increases, and so forth. We have a solution. It’s called pair programming. If you put these guys into pairs, then the problem with the code reviews, with the interruption, everything is just solved immediately. The time used for pull requests are eliminated to zero because it’s done through the pairs when they’re working. Also, we have some rotation.
During the week, the pair maybe do some rotation, and then also knowledge is spread just as the way we are working. We don’t have to have any knowledge-sharing sessions, or meetings, or stuff like that. It’s just part of how we work. Then we create some time buffer because it’s always stuff coming along as we work during the week. As we said, this is continuous delivery with pair programming really coming into play.
Stop Starting, Start Finishing
Ola Hast: Another important thing, which comes from agile, is stop starting and start finishing. Everyone knows it’s a lot of fun to start things. Finishing things, however, is a lot more difficult. Anybody who’s done any renovation knows that getting the last bit of trim on never happens. What we saw after a while on our team was that instead of starting new tasks, people started asking, does someone have something going on that I can help with to finish? Then, Bard Kristian said, you can join me, and we can listen to Taylor Swift. What Nils Brede says about this is that this is the hallmark of a really good team. It smells like a good team, as he says. Because here, the team actually cares more about the goals of the team than their individual goals.
Asgaut Mjlne Sderbom: The research shows that the psychological safety in the teams, there’s no better way to build psychological safety than with pair programming. One other thing we recently saw as well was there was research about happiness, how happy people are in different countries in the world. Some of the main things that everyone should learn, like the kids and everything, is that you should have two things to do every day. You should thank someone, and you should ask someone for help. I think that fits really good into the agile thinking.
Back to this, Ola talked about NAV there, and this is rapid deployment to production and all test environments and stuff. We wanted to test this. Me and this guy, Geir Olav, he’s a full-stack developer. Me and Ola, we’re getting a bit old, so we don’t understand that they actually exist.
Ola Hast: No, we actually refer to them as unicorns.
Asgaut Mjlne Sderbom: He’s under 30 here, and he can do like everything. He can do React, and he can do Kotlin, and he can do SQL, and everything. It’s amazing. The task we were given, here you can see a transaction coming in, it’s from Adamogeva Jacob Aalls. That’s my hairdresser. Our clever machine learning doesn’t understand that that is a hairdresser. We want our customers to be able to choose the category so that could be visible on future transactions. Then they have to choose the main and subcategory. This is a perfect task. It involves everything, machine learning, frontend, Kotlin domain, SQL, whatever. It’s a perfect task for trying out this stuff.
We’re going to show a little bit how we started out. We have an API called api transactions, it’s the heart of the bank where all the transactions flow through. Then we have the frontend part of my economy going into a REST call into TransactionResource, the classic setup, TransactionService, hitting some adapters, hitting some backend systems. The classic way would maybe be to create the database to store these customer categories and build yourself up. Instead, we broke in in the middle of the heart of the API, and then we made a small service, and then we add a feature toggle. To this feature toggle, we said that if it’s me or it’s Geir Olav, then show this certain category in production because that’s what we wanted to test. We deployed this to production, and we could see it in production.
Ola Hast: Didn’t go quite according to plan, did it?
Asgaut Mjlne Sderbom: No, it actually didn’t go so well. What happened was that since we went into the heart of the TransactionService, we messed up the order of the transaction, so all our 1.2 million customers got incorrect orders of all the transactions. No one dies if transactions are in incorrect order. We got alarms on this, and it was easy to roll forward because the change was so small that we knew exactly where it should be. That’s a good example. If that was part of a big release, it could be difficult to find, but we didn’t even get nervous. We just fixed it.
Then we continued, did changes to the domain layer, changes to REST endpoints, design, we had feature toggles in the design. All of these were just deployments to production all the time, small deployments. Refactoring is a good point, actually, because usually when we worked before and we came to a major refactor, they said, we have to wait to the next pull request. We can’t do all this refactoring now. We have to wait.
Ola Hast: That means never.
Asgaut Mjlne Sderbom: That’s never.
Ola Hast: If anyone’s confused, that means never. It isn’t happening.
Asgaut Mjlne Sderbom: Yes, we forget as well. Since we are committing to main all the time and we’re in sync with main, then we can just step aside and then we can do the refactoring, and then we can go back again. Then we also have something that we like to do when we program, we have interfaces. Then, behind these interfaces, we just create implementations with just HashMaps and caching the domain objects. This puts us into a situation where we don’t have to care about the backend integrations at all. What do you usually say about that?
Ola Hast: This is actually a really nice architectural principle that you postpone the decision to the last responsible minute. We have had several instances where we thought that we needed a database, but when we came to the end and we’re going to decide on a storage mechanism, we saw that we could just use a cache, or the other way around, that we actually care about this data so we have to store them somewhere safely.
Asgaut Mjlne Sderbom: This also fits very well into this way of working. All the way in the end, we see we have a category with Postgres and we have some machine learning adapters. Then, we develop these and we test them so we get this separation of concerns principle as well coming in. Everything here fits into the continuous delivery way of working. In the end, we remove all the feature toggles and these cache implementations. This way of working, we saw it pretty fast. It’s not possible if you’re working alone. If you’re working alone and sitting doing all these small steps, then your decision will be, you have to take too many decisions yourself so you automatically build bigger stuff again. After a month doing this new feature, we had about 50 commits to this Jira task.
Then we saw another consequence of this working as well, that was that Jira or any issue tracking system was not necessary because we would have been using more time moving the tasks in Jira between state in progress, and done, and everything that we do on programming. Pretty quickly, we just added everything to this same task. Now after this, this was like the last time we used Jira issue tracking system. Now we don’t see any purpose with it anymore.
Ola Hast: We actually just stopped using it to see if anybody would notice. Nobody did.
Asgaut Mjlne Sderbom: The pull request part as well, it’s amazing because there are so many people using so much time on pull requests but we reduced it to zero. It was nothing. It was just a way of working. The only thing we wanted to try was to do small tasks and go rapid into production. All of the other parts, they just came as consequences of this way of working. It was not a goal to stop pull requests. It was never a goal to stop with test environments that you are going to talk a little bit about.
Ola Hast: Another consequence was how we worked with our environments. We like to do TDD, which means that we always have a good base of unit tests that helps us do changes and refactorings safely and confidently. What we used to do was that we usually had some scripts that started Docker Compose and had mocks of our backend systems, maybe some databases, and then we had some scripts on the top, like Postman or just some Java tests, but the feedback loop was just too long. We stopped doing it. It just didn’t make any sense.
Another thing was that since we had built so small things and had so good tests, then when we got to the test environment there was not really much to test. We still have a test environment because a lot of other teams are dependent on our APIs so we have a test environment but we don’t really use it ourselves. Another fun thing about our pipeline is that our production deployment has more resources so it’s usually deployed to production before it goes into tests since both are automatically. We used to have a pilot Q&A type environment but we solve all of that now with feature toggles. I don’t know how much wasted resources are around on environments that are dead most of the time, but I’m guessing it’s a lot.
Asgaut Mjlne Sderbom: We could say all the three boxes in the middle here are waste.
Ola Hast: What we ended up with was we had our local test environment and then we deployed to production, and everything in between just didn’t make sense anymore. It wasn’t part of some master plot but it just happened. We didn’t need it.
Asgaut Mjlne Sderbom: We love when things just happen as a way of working instead of someone else telling how to do it.
Focus, Flow, and Speed
Over to another part about focus, flow, and speed. This picture here is from the very northern part of Norway. It’s called the Lyngen Alps, just outside of Tromsø. Me and my wife, we went on this trip. We lived on a boat. Not that boat, but a bigger, better boat, and went around the fjord. We went with a guide up to the mountains and skied down again for a week. That was our flow that week, was powder skiing and having fun. Our flow in here looks more like this, but flow is an amazing state. When you come into flow you know what you’re doing. You know what your next step is. You’re just having a really good time developing.
Ola Hast: Can you approve my pull request?
Asgaut Mjlne Sderbom: Then that comes along. What our researcher Nils Brede says is that if you get interrupted with something that is not what you’re doing, then it takes around 15 minutes to get back into flow state. What happens if you get into flow state several times an hour?
Ola Hast: If you get interrupted, you don’t get any work done at all. If you get interrupted three or four times an hour then you spend 15 minutes each time, then you can just go home.
Asgaut Mjlne Sderbom: Yes, exactly. You get into something looking a little bit like this. In addition, if you have notifications on Slack, for example, many people use Slack, and then you click on this little icon because you attempt to click on it and you come into Slack and that lights up like a Christmas tree, with all the small dots and then you have the threads and then you get yourself lost into Slack.
Ola Hast: We love Slack.
Asgaut Mjlne Sderbom: We love Slack. We don’t want to go back to mail but you have to turn off the notifications if you’re working alone. Of course, we have a solution to this as well and that is pair programming. This is Ola and Stian working together. What our researchers say as well when we work together it’s like creating a buffer zone around the people who are working. They are not doing anything else than doing the stuff that relates to the task. That is pretty unique because we’re sitting alone, we get interrupted all the time, but if Ola here is starting to answer questions on Slack, then Stian is standing there idle.
That would be totally unnatural. It solves by itself. When you have two people going into flow with pair programming then you get significantly immeasurably higher quality than if you’re working alone as well. This is an important part also to think about when you’re comparing two people working in parallel and when there are two guys working together, because we sometimes get that question because the quality they create is so much higher so the rework afterwards are much less. We can see that when we have been working together doing continuous delivery and stuff like this, we have very few bugs and it’s easy to change the system afterwards.
Ola Hast: Another thing is that our team leader he said that when there’s two people working together it’s really scary to go over and interrupt them, but if someone’s sitting alone in the corner then you’re just free game. Another important thing is how you’re seated.
Asgaut Mjlne Sderbom: This is how we are seated.
Ola Hast: This is our little nook. The first thing we did when we moved in was that we moved the desks out so that we’re sitting with our backs to each other. Like everyone else, we have chairs with wheels so we can just spin around and work together and move around. Another thing is that we have whiteboards. We have whiteboards on both sides. As you can see, I don’t even have to get up out of my chair to write on the whiteboard.
Asgaut Mjlne Sderbom: We had lunch with the SINTEF guys, and there was one of the researchers from Spotify, and she said when they put in a whiteboard inside a team, the communication inside the team went up by 50% just by adding the whiteboard, because you get this innovative creative work immediately just drawing. That’s an important tip.
Ola Hast: Where we were seated before this, we had a whiteboard that was about 7-10 meters away, and it said, ‘Happy Easter’ in November. It has to be close. All of this, working like this can get really intense so it’s really important to take breaks. By taking breaks I mean really good breaks without any monitors or screens. Do like these guys, go for a walk. Get some air. Just do something else. The worst thing you can do is check Slack, or email, or something like that, because then you get sucked into something else completely, and when everybody else comes back from their coffee break or whatever then you’re even more tired than before the break.
Asgaut Mjlne Sderbom: This is also from the research from SINTEF. They say that this is one of the most common things is that people get very exhausted.
Ola Hast: It’s one of the main feedbacks we get that if people don’t rotate and take breaks your head gets like mush.
A Typical Day in the Life of Pair Programming
Let’s look at a day in our lives. Usually, we start at like 8:00 and 8:30, in the morning. Do some admin stuff. Then we have a few meetings during the day where I have a meeting, you have a meeting, we have lunch. One thing though is we Norwegians, we eat lunch at 11:00, which is super early for everyone else. What we see is that from 9:00 to lunch, we have a block where we can work. Then we can do some solo programming in between.
Then, we have a spot at the end of the day where we also can program together. You’re allowed to solo program but it gets really difficult after a while because you don’t have anyone to spar with or talk with so you start second guessing every single decision you take. What would Oscar think? The most important thing is that the task gets love all day. You don’t switch tasks when the other person is away. Preferably you’re a bigger team than just the two of us. We’re four now, so it’s not that much solo programming anymore. The task gets love all day, and no knowledge is lost. When this guy goes on his annual surfing trip to Morocco he can just leave. I know everything, the rest of the team knows everything. He has nothing he has to hand off. He has no pull requests to close, no long-lived branches that needs to be hiding.
Asgaut Mjlne Sderbom: I actually talked to another guy I know from another company and he said the complete opposite. When he leaves, he has to finish everything as Ola said. He could just sit on the plane and relax because he saw, nothing is left from him. I can just leave. This is of course nice when you go to Morocco for surfing, but that also applies for if you get sick or your children get sick, which happens way too often. Then, if we have other stuff going on which is the way, then the work just continues.
When I started in SpareBank, I knew it was the pandemic so I was sitting a lot from home. We had this 2:00 coffee on Teams where we were supposed to get to know each other, but I never got to know anyone in these 2:00 meetings. When I actually got to know people was when me and Vidar, when we were working together then we actually got to know each other. We can talk about other things than just programming as well, and I could ask all the questions and really got to know how this company works. This guy, Eivind, I worked with him for a year remotely and then I met him in JavaZone.
Then I noticed something weird and that was actually the first time I saw his legs. I’d never seen his legs. I felt I knew him. We’re still working a bit remotely, most at the office, but some hybrid and remote, and it works well. This guy here called Bard Kristian, he was onboarded in our team. We can start by saying what we’re not doing when we’re onboarding.
Ola Hast: We find a suitable task in the backlog.
Asgaut Mjlne Sderbom: That’s the worst thing you can do. You see this new guy coming in, then you try to measure his level, is he junior, senior? How good is he? Then you should find these tasks that are suitable for him, and he should do it. After he has done it, you should like, this new guy, he is a good developer. Instead, we do the complete opposite. We just put them directly into what we’re doing anyway. Then we switch every 15 minutes who is writing and who is looking, and they go into the task very quickly. We’ve done this a lot of times, and it works perfectly.
Ola Hast: Another thing is that he said that it was also a good place to ask all the stupid questions when you start somewhere. Like, where’s the good coffee? How do I find the HR systems, and all of that stuff? He doesn’t have to batch them up and hope he can interrupt someone later.
Asgaut Mjlne Sderbom: I think this is an important thing to do anyway. You just have to narrow down the scope of what you’re doing. As long as the new guys can do some if and else and Spring and stuff, they can be productive. He’s putting code into production from day one, then the motivation goes up. What Nils Brede said, a researcher, he said, if you work like this, there’s a much bigger chance that the people stick in the company for a longer time as well, and the team. There’s one thing that everyone has in common that you do every day, and that is that you waste time on non-valuable stuff. We call this the waste clock in our team, and we say that now we’re starting the waste clock. We’re doing that all the time. It can be just for starting a meeting and someone doesn’t, “Can you hear me now?” That happens.
Ola Hast: “Am I sharing the screen?”
Asgaut Mjlne Sderbom: Then, if you go to developers, developers are special because developers, for example, when I started, we had a build that took around two minutes to build. I was used to Quarkus, which is something really fast, and I asked, how can this build take two minutes? Then I got the answer that that’s just how the world is. I was saying this is how the world is, and the other was sitting there, and the other teams, and then suddenly these two minutes multiply up with all the developers in the whole company every day, and then it gets really expensive. When you’re pair programming and you’re sitting watching this two-minute build the first time, it’s like, we drink some coffee and it’s ok.
Ola Hast: The next time it gets awkward.
Asgaut Mjlne Sderbom: The next time it feels really weird, and then, yes, we have to fix this. We have to do something about it. That’s what happens all the time. We reduce waste all the time by working together instead of just sitting there, and it’s just how the world is.
Ola Hast: If you’re two or three people working together and things are going too slowly, then you start plotting, how can I fix this?
Asgaut Mjlne Sderbom: We also see it’s a little bit funny about leaders, because leaders, they don’t know what we’re doing. They’re just fine with all these slow builds. I think if you add up all this time that we use on non-valuable stuff waiting, that would be the top priority of the company, but sadly it’s not.
Pair/Mob Programming Interventions
I hope that you’re a little bit inspired to work like us, but we have seen, we can do some inspiration around, but when it all comes down to it, you have to start doing stuff. We came up, me and Ola, with something we called Pair or Mob Programming Interventions. It actually also now applies for other type of work than programming. First of all, to get people to come, we need cinnamon rolls. If you have cinnamon rolls, then developers will come. You need something to get them to come.
Then, we have given periods for three or four weeks that they have to test working together. There are two requirements. One requirement is they have to book a pair programming session in their calendar twice a week. Everyone has time for that if they book it. Then they have to rotate who’s writing and who is not every 15 minutes, because we’ve seen this, for example, a senior, he’s just showing a junior how to do it for 2 hours, and then they call it pair programming, but it’s not.
Ola Hast: Someone watching someone else program is not pair programming, it’s surveillance.
Asgaut Mjlne Sderbom: Then, we have SINTEF. SINTEF, they love this. They now also wrote a scientific article about this, introducing a way of working. They will do surveys and observations and everything. Then you have something social in the end. We have done this many times. We’ve done it on single teams, on areas, or tribes, or whatever you call it. It works very well.
Our newest, hottest way of introducing is called job shadowing. This guy, Magnus, he’s from another team. He’s invited into our team for a week, and then we just put him into what we’re doing for a week, and then we can really stress test the way we’re working, onboarding, and everything. We tested this, and it worked splendid. He came up to speed, he was delivering from day one. Then, he can go back to his team and maybe do something similar.
Ola Hast: We’re going to follow him back into his team and follow up and help them get started as well.
Summary
Asgaut Mjlne Sderbom: To summarize all this, this is our team. We’re now four people with Ole. We’re sitting doing test-driven development, domain-driven design, and really focusing on quick feedback. We do tiny changes, putting up to the CI server and get feedback if anything is broken. We do feature toggles in production. We do monitoring and we raise alarms if anything goes wrong.
Then we have a feedback loop on this whole circle. This whole circle is the scientific way of working, which we think brings the highest quality. Putting into production takes around five minutes, so we get super-fast feedback of how it’s actually working. Again, this gave a lot of consequences. There was never a goal, but we reduced waste. We don’t have any slow tests anymore. We worked a lot on that. We don’t use any time on pull requests. We have a pull request requirement, but we create the pull request and then we approve it in two seconds because it’s already done. We have a special thing, I think, with building branches.
Ola Hast: We stopped doing it because since the same tests that run on our machine are the same that runs on the branch, the branch build never failed, so why do it? We just stopped doing it.
Asgaut Mjlne Sderbom: This saves money on the cloud as well. The test environments, we don’t use test environments anymore. We also work with clients in the bank doing totally new features where they are sitting testing stuff in a production environment, which they also love because then they don’t have to care about setting up all the test data.
Testers as well, with that speed we have, I don’t know how we should fit in testers, but we have to test ourselves. Status meeting is reduced to one, because we’re talking to each other all the time when we rotate and everything. Knowledge-sharing sessions, definitely, that’s zero, because we share the knowledge when we work. End-to-end testing, the whole circle here is the end-to-end test. We don’t do any end-to-end tests more than that. Issue tracking tools are not used anymore, we just use simple Confluence or whatever tool to make checklists. Handoffs is something of the most important parts. When we see that we are dependent on other teams, then it just stops.
Ola Hast: The circle breaks down.
Asgaut Mjlne Sderbom: The DBAs are an example when we’re not allowed to do changes in the database. We moved everything so we can handle all those stuff ourself. Of course, this is not possible without working together. It would be impossible to do all these small steps sitting there alone. Me and Ola, we’re working in a team for the account part of SpareBank 1. We have 30 million requests every day from 1.2 million customers, which is a lot in Norway. It’s not a lot here, maybe. In Norway, that’s a lot. Still, though, I’m more worried when I’m sending out an Outlook invitation to 300 people internally if I’ve misspelled something, than I am when we’re putting things into production here, because I’m so convenient with the whole way we’ve been working. This gives some great quality as well. We can have one thing we can say that we achieved. What is that?
Ola Hast: I have no idea.
Asgaut Mjlne Sderbom: We were ranked as the number one mobile bank in 2024, so we have to do something. Back to where we started. Nils Brede, he’s talking to leaders across the company, and he said that the company is on a completely different level now. The leader’s now applauding. They want us to work more together. They want us to have interventions and all of that stuff. We’re at a better place. There was one other guy, a developer, who said that we have almost reached modern software nirvana in our team, and that may be cool, but that’s not completely true. We want to embrace change, and tomorrow, maybe AI is coming, and then we have to change. I think that’s the most important part that we are on the stage where we can change things. Maybe next year is about AI.
Status Reporting to Management
Ola Hast: How do we report our status to management?
Asgaut Mjlne Sderbom: On Mondays, we have this one status meeting that we need to have called Monday commitment, and then we’re talking with our team lead, and our team lead always knows what we are doing. She is looking after that. We’re doing the prioritized work.
Ola Hast: She’s also our product leader, so she coordinates with all the other product leaders and stuff like that. We have quarterly goals. That’s almost a different talk about OKRs and all that stuff. Basically, we have very loose goals from the top, and we just work within those bounds.
Questions and Answers
Participant 1: About the job shadowing, a person from the different team that joins your team, does he have enough functional knowledge of the team applications as well?
Ola Hast: Does he have functional knowledge about our team?
Participant 1: Yes.
Asgaut Mjlne Sderbom: Who?
Ola Hast: Magnus, the guy in the job shadowing.
Not really. He knows the domain since he also works in the bank, but that’s part of the point, that if what you’re working on is small enough, then the need for deep domain knowledge is limited.
Asgaut Mjlne Sderbom: I think this removes that part earlier when we had to use several months to get up to speed in a team. When you slice that down to a very minimum, they can be productive from the very beginning, then they just learn the domain and everything as they go, and it’s a much more motivating way of working, and they are productive, giving value from the beginning as well.
Ola Hast: Have you ever had that someone said that this is an unshareable task?
Not on our team, because we do pair programming, that’s part of our DNA. We have the discussion often, like, this task is too dumb to pair program.
Asgaut Mjlne Sderbom: We don’t discuss this in our team, but with other teams.
Ola Hast: If someone comes and say that this task is unshareable, then I would say he’s probably an information hoarder, and that’s not really a good way of working together, at least.
Asgaut Mjlne Sderbom: No, we work together on absolutely everything. If it’s looking at logs, if it’s analyzing, if it’s PowerPoint, if it’s just on task, everything. We work together on everything, because it’s not just a task, because it’s also the flow, and the knowledge sharing is super important.
Participant 2: What do you think about team size? You have four people in your team. How many do you think is a maximum to make this work, working on a product?
Asgaut Mjlne Sderbom: Nils and the researchers, they say small teams are the best. Four to five, I think, is the best size. I can say a little bit how we work as well. We are four, if everyone is present at work, we divide into two pairs. If one leaves, then they are three on one task. There’s never someone alone on that task, and that’s the way we’re working all the time. That works very well, I think.
Ola Hast: The bigger the team, the more coordination you need. I wouldn’t be more than five developers at least, or UX.
Asgaut Mjlne Sderbom: Four is perfect, I think.
Ola Hast: Because if you have more than four, then you need a fifth to manage everyone. It’s not very sound.
Participant 3: If this way, the fact that thanks to pair programming, which I think is good for any company, you were able to cut many meetings on sharing staff. This is something that you think that could scale up for bigger companies, or it’s more a way for smaller companies to cut overhead?
Ola Hast: Speaking of size, we’re about 300 developers now. The important thing is that the team can be autonomous. If your team has a lot of dependencies to other teams, then this is really difficult. Then, if you want to scale up, you should change your architecture or the way you work to be less dependent on other teams. Because then you get into the handover trap, where everything has to be thrown over a wall, and you have to coordinate with everyone. Then you don’t have independent services. Then you have a distributed monolith, or basically you’re working on the same thing.
Asgaut Mjlne Sderbom: I think the answer is that it totally scales. It’s just working in teams, small teams.
Participant 4: How did you persuade management that this is a good idea? Do you have some metrics that show that you actually got more efficient before and after?
Ola Hast: What they see is the quality.
Asgaut Mjlne Sderbom: They see what SINTEF is doing as well. SINTEF is reporting all the time, the researcher, how this is going. They can report that psychological safety actually went up. They do service before and after our interventions. They go and just see how people are working together inside different teams. They do a lot of stuff, so they see that this is affecting all the time. It’s coming back in service, when you said in the beginning, we’re doing this service all the time. It comes back as a point that’s really helping us out.
Ola Hast: Now there’s also a lot of literature in the industry, like the DORA reports that show that this is actually a good way of working.
Participant 4: Do you use DORA metrics?
Ola Hast: Not directly. We don’t use metrics per se. No.
Participant 5: Do you have any tips for convincing the team that is very against this idea? Like you’re the only one who wants to do this, and everyone else is very against it?
Ola Hast: If they’re very against it, then I would consider changing team.
Asgaut Mjlne Sderbom: If you’re in a team, and it’s just you are the only one who wants it, then it’s a problem.
Participant 5: I think they’re just scared.
Ola Hast: A more serious answer than changing teams is that when we started like five years ago, then everybody were introverts, and pair programming was not for me, and it was scary, and people are scary, and all that. What it really takes is a culture change in the company. If you can convince them to try a pair programming intervention, just get them to try it a few times a week, then it might be. If they’re really against it, then they’re probably a bit scared, and then you probably need to get a higher level of the psychological safety in the team.
Asgaut Mjlne Sderbom: It’s usually a very good idea to be at least two who wants it.
Participant 6: In your model of work, how do you deal with production support? What I mean by that is not know when your things catch fire, or you have to fix things, and you have monitoring for that. Let’s say the customer did not expect a certain feature to work a certain way. They didn’t find a category for the expense that they wanted to see. How do they report it? How do you review it? How do you act on it? How does it work?
Ola Hast: We have several channels, too many channels, actually. We have a customer call center with several levels. We monitor the app store. If you actually give us a bad rating in the app store and say why, then we usually explain it or fix it.
Asgaut Mjlne Sderbom: They have feedbacks in forums also in mobile bank for features like that, if that’s what you mean. Then, for alarms, we have guys who are watching more over the alarms than we are. Then we’re watching them ourselves, of course, as well. All in all, we see that when it comes to errors, when we work together after a while now, we see that we have very few errors, even in big rewritings and new features and everything. It’s very important, the rework, when you work together this way, it’s much less. It gets significantly higher value.
Ola Hast: When you’re working on a new feature as well, we start by starting small with maybe a feature toggle with just us. Then we take a small subset of maybe people who work in the bank and then a small subset of customers, before we roll it out to everyone. We try to get feedback all the time.
See more presentations with transcripts
