 Welcome to Fluid Scaling Technology, when you want to go fast by Paige Watson. Paige Watson is a senior technical coach at Industrial Logic Washington. He has got three decades of experience as a developer and he has been a technical coach for five years. Without further delay, over to you Paige Watson. Good morning, let me share here. All right, thank you very much for joining. I know it's kind of earlier. I'm in Seattle, Washington in the United States who were about 12 hours difference. So just the opposite it's evening here, but I'm really glad to get this opportunity to talk with you. I'm going to give a little bit of a overview of what we did at a place called Primera Blue Cross. It's an insurance company here in Washington state. Using what came to be known as Fluid Scaling Technology. And yeah, first I want to do, I like to do three truths and a lie. So here's some some things. One of these things is a lie and and I'm going to go through. You know, when I was sorry. When a 5000 line basic file failed to render a picture of Farrah Fawcett when I was in high school, I decided to give up programming forever. You know, in 2000, I heard about XP development and asked a coworker to try pairing with me, but he he just laughed at me. I left a lucrative career in the adult entertainment industry to teach the world to build better software. I'm one of only two people in the world to attain the extremely hard to get certification of certified fast instructor. And I helped the singer Haroon to be the superstar that he is today and which one of those is the is the lie. Well, actually in 2000, a coworker came up to me and said, I have heard about this thing called XP development and pairing where like two developers work on the same computer and they share their knowledge and they write really good code. You want to try it? And I told him he was crazy and I laughed at him. And and now that's what I do. I teach I teach teams and companies to use better processes and better practices like pairing, mobbing, ensemble programming, you know, all those great things. So it's come back around. So I'm going to talk a lot about open space technology. Open space technology was created by Harrison Owen and you might know it from the conferences. You open space conferences, sometimes called unconferences. Open space technology has has four rules and one law is the way they put it, that the rules are whoever comes are the right people. Whenever it starts is the right time. When it's over, it's over. And whatever happens is the only thing that could happen. And there's one law and that's the law of personal mobility. And that sort of states that if you are in a session and you are not learning or helping others to learn, you have the option and sometimes it's almost the responsibility to go to another session where you can learn or you can help others learn, right? It's a really great way of holding a conference and having having great discussions around that. But I want to talk about that because here I'll give you some pictures. Here's an open space conference where they're starting out. You start out in a large group and the people that are there are the ones that self-selected into the conference. You'll notice there's papers and pens and stuff in the middle. After they open and welcome everyone, they actually will dynamically create a full day of conference in about 20 or 30 minutes. And they do that by writing the topic that they want to talk about or they want to hear about. And they'll put it on the wall on this grid and you'll see across the top, they've got the rooms. And down the left side, they've got the times, right? And the person who chooses to, they're not leading this topic. They're stewarding this topic. They're facilitating this topic. Maybe they're not the person with the most information about it, but they're the person who has interest in hearing about it, right? And then once the market places, this is called fills up, they'll split up and everybody will go to the places they want to see and the ones that are interesting and exciting to them, right? And so my friend Ron Cortell had this idea at an open space conference in 2014. He said, if 800 people can self-organize a conference in 20 minutes, why aren't we using open space technology to solve agile scaling? He thought, how can we use open space principles to allow teams to work in large scale? You know, there's got to be something there. And he thought about this idea for several years. In 2000, at Primera Blue Cross, which is that large insurance company that we worked at, we actually had the opportunity to try it out. And it wasn't called fast at the time or fluid scaling technology, but it is what became fluid scaling technology, right? We sat down, excuse me, and came up with a few sort of overview ideas of what we wanted fluid scaling technology to become. Now this went through a lot of iterations, right? We had part of our work was also learning to do processes better and experimenting on them. So we decided we wanted to bring everyone together to work as one collective. We want to visually represent the business goals on the wall, make it visible, make all the work visible, right? Let the collective self-organize into teams and break down and do the work. We actually called them tribes for a long time. The group of people was a tribe that made up our area. And I say that because we didn't really use the word team so much. We used tribe. And when I started there, we had about 20 people. When I left, we had over 50 in our collective. We started using collective as the word and kind of like that a little better. And then finally, on a short cadence, we would sink and repeat those above steps. And that's just kind of a high level overview of what we kind of thought we could accomplish, wanted to accomplish with this process. So we wrote those out and some other thoughts on giant stickies. And you're going to see we put these up all over, all around our work area. We have one that says fast rules, not really rules, probably standards. They weren't like, you have to do this. They were like, this is what we should do, right? Do the right thing for the release. Do the right thing to make the good code, to make the good release, right? Be a team player. Be a coach and be coachable. Strive for excellence in your craft. Those were simple enough, and yet they encompass these values that we wanted our collective to have. And then the other values, the things we valued about the way we work, face to face communication, code craftsmanship, pairing, mobbing, or ensemble work, test-driven development, a good CIECD pipeline. We valued self-organization, including trust and collaboration. This was really important to us. A shared vision, a single purpose and alignment. We, again, like I said, with these large post-its, we had them all over. And we continually went back to our vision and our alignment as a group. And then Kaizen, or that idea of continuous improvement, learning, growing, was really important to our collective. So we had several roles in the collective. I don't know if they were, I mean, they weren't really assigned to one person. One person would fill them. Sometimes you would fill more than one, right? We had a product manager. And this wasn't a role of authority over the team. But one of vision, the product manager role was to communicate the vision to the collective and interface with the business. They were to motivate everyone to, like, yeah, this is what we're going to do. It's so exciting. Here's how it matches with our vision. Let's go to it. And of course, they were there to answer questions that we had for the business. Most of the people on the team were just the collective members. We're part of the group. And we focused on growing and hiring in what we call T-shape. And you might have heard of that. But the whole idea is that each person has a highly, a broad set of valuable things that they are highly skilled at. We all know how to write code. We all know how to work on computers. We all know how to write tests, all these sort of things. We all know across the top. That's our flat bar across the top. But then alongside that, each would have an expertise or, excuse me, specialization. And that's that leg of the T that comes down. So some people would be strong in testing. Some people would be strong in data. Some people would be strong in ops or leadership or multiple areas. So when we put everyone together, we had a good, full-rounded team. Really interesting thing that came out of that. They asked us to sort of give our title so we could have our titles as part of our work, our name, our emails, and all that sort of thing. We talked about it quite a bit. And we actually came up with one title that everyone, no matter where you were in the group, everyone had the same title. And that was Solutions Developer. Because that's what we did. We didn't have developer one, developer two, senior, DVA, all that sort of thing. We were all solutions providers is what we were. Team Steward, the team Steward was very much like the facilitator in open space. Their job was to steward a chunk of work through a value cycle or an iteration. We tend to refer to them as value cycles because that's what they were. So they weren't necessarily the boss. They weren't necessarily the subject matter expert. They could be someone who has a connection and an interest in seeing that chunk of work get done. Or an interest in learning more about it. And so they're going to steward it through the process. That means that they weren't necessarily like in charge of fixing blockers. But their job was to make sure that someone was found that could work on those blockers. Or if we had to talk to another team, their job wasn't necessarily to go and talk to the other team and say, I'm the steward of this. Their job was to find someone that would talk to the other team and make that connection. So they more stewarded the work through the process. Maybe they were updating the reporting and that sort of thing. Finally, we have a market facilitator. And I put this on here. It's not really a role that we call out a lot. And it's a rotating role. And this person was just to run the fast meeting. And I'll show you that in a minute and why I put Kat Herder on here. Because their job was just to keep everybody on track or at least try to keep everybody on track. And people would usually take this role for a month or two and rotate wasn't a major one. So let's look at our fast meeting, right? We did this in small iterations. We actually did this every two days. We had one meeting and we did it every two days. So there's a very handsome market facilitator up there. And that job is just to clear off the board, get things ready. Here's all the people standing around. These are all the members of the team. Like I said, when I left, we had over 50 people. We probably have 30-ish there. Here's our product manager. Notice he's way in the back. His job is pretty much to hang out to answer questions. He doesn't have much, much input on, you know, he definitely doesn't assign work. His job is to be there to answer any questions for those of us that are going to steward the work. And I'll get into that a little more in some of the pictures. And then some of us sometimes, excuse me, we had guests. And guests, people that, would come from other teams because they'd heard of what we were doing. You know, other managers, the C, C level. People would come down to see what was going on. Sometimes we had guests actually come from outside of the company. Cause this was pretty amazing stuff that we were doing. And, and word got out. So let's actually look at what, what we were doing. And what we were doing, what we were doing, what we were doing, what we were doing, what we were doing, what we were doing. So let's actually look at what, what we were doing in this fast meeting. Right. So the fast meeting. Was. One, one meeting. That's all we had. It took about 30 minutes. Everyone attended. We would start out. The, the meeting with a group activity. You know, we would start out with a, a, an ice breaker sometimes. Usually announcements since we were all there. Sometimes a recap of process. If we had, like I said, the guests who kind of. Didn't know what was going on or we wanted to follow them. You know, excuse me, we wanted to show them. Get them. That knowledge of here's what we're going to do. And here's how, how, how we work type of thing. We're going to start out with a group activity. We're going to do a group activity here. Right. Here group activity. We're stretching together. We did that pretty regularly. Although I noticed our PM is in the middle and not doing it. So I don't know what that says, but I found that kind of funny. So. Following up. We would close the previous cycle. We would close that previous iteration. And then we would go and tell, and this wasn't a. This wasn't a demo, like, like your scrum type of demos. Maybe this was a sort of. A time to say what, what did we learn. In working on my chunk of work that I worked on this iteration. What did I learn that. Everybody else needs to know. What did I learn that. You know, that I need to communicate since everybody's here. Sometimes we would show, show demos, but not usually. We all sat together. We all were in the same area as you saw in that picture. And so. We didn't have to do that demo. Sort of separate meeting. Because our, our PM was there. We could show him at any time what we were doing, where we were at. After the demo. We did a thing called turn up the good. And if you know Woody Zool, he is kind of the, I don't know if you. I would call him that the sort of modern day founder of, of ensemble or mob programming, maybe. But he's a fabulous person who has great ideas. We had him come up and teach us several different subjects from mobbing to talking about how we work and how we track work. And that sort of thing. One of the things he taught us was this idea of turn up the good. Their ideas and processes that we value. And if we value them, let's do more of them. So we started out doing ensemble work mobbing. Just a small group of us and once or twice a week. And we decided at one point that like this was really good. We got a lot of work done. We, we tended to. We tended to really learn and really write good code. And so let's turn up the good. Let's try and experiment where we don't just do it once or twice a week. Let's try and experiment where we do it every day. And so we did, you know, and that's we, we tended to experiment with that with the things that worked well. Then we would plan our next iteration. Our PM would come up and set our direction. He would reiterate the vision of the team. He'd tell us like we're building this excellent thing. Here's where we're at. We're excited about it. He would then give us sort of not really a list of work that we would do for the, this iteration, but more. Work that he would like to see on the board for this, this next iteration. And when I say that we had five, the five work in progress slots for most of the time. That meant that the whole team, we would work on five things. And so the PM, his job was to supply us with eight, the top eight priority things. And then we would choose five of those things and work on them for this iteration, right? And this allowed him to, to change it up to, you know, to easily decide that priority changes and move to the next iteration. And then we would do a marketplace where stewards would step up, choose an item and they would say like, I want to work on this new user login. And I'm going to be in room one. And so just like we saw on that open space board, they would put their work into room one. They would put their name on the top of it. And they would say, maybe I need someone who knows the user database. And maybe someone who's worked with OAuth before since, since I don't really have that, that understanding. Right. They would kind of point out those things that they could, that they are going to need for that, that iteration. Once we filled up all those work in progress slots, then we would open the marketplace to everyone else and self organize. And everyone would go up and take their name and put it on what they were going to work on. Right. And we'll take a look at that. Here is a, here is one of the boards. I think this is kind of one of the break off teams. We had several teams throughout the time, throughout the time I was there. Sort of break off and work either separately for a while or, or separately, you know, they became a separate team. But sometimes they would be separate for a while, and then they would come back and join the rest of us. But let's work, look at this board very much like the open space board. We have work in progress lanes. We had five that was tended to be the, the like most of the teams that use this had five. We had magnets with our names on it. And you'll notice the people with their names at the top, those tend to be the shepherd or the, excuse me, the stewards. So they would put their name at the top. So it was really easy to kind of point out who that steward was for that story. Everyone else when they were, when they were ready to work on it, they would put their name on one of the, the stories that they wanted to work on. This team has a next up block. So this was a, not necessarily what was coming for the next iteration, but if they got to a point where they had finished working on this chunk of work that they had picked up for the iteration and they were needing work, they could come and look at the next up next in line box and maybe grab one of those things. We called out blocked work. We visualized it and put it right up front so that we were continually monitoring it. Right. We also use those red stickies on them. And then once they were unblocked, they moved to the main area and got picked up again. We also moved names of those people who were on vacation. So, so it was a really easy way to track of who was around and who wasn't. And this team, interestingly enough, also made a little section for offline time so that they could keep track of, you know, upcoming outages or something that would affect their work. Here's another view of the board. This is a, this one has a discovery tree on it, which is the, in the center there with the red and yellow stickies. The discovery trees were how we, how we found out the work that we needed to do. And that's, that's kind of a whole nother talk. I'll have some resources at the end. You can, you can either see the videos, read some blogs, or I'd be happy to talk with the, about those, you know, after this as well. So once we plan this whole iteration, the next step was to go forth and do all the things. And you'll notice here, for instance, we have two mobs here. We're working on two different things, but we were very close. And this allowed us to, to collaborate not only with the others in the mob, but the other people, you know, if, if that mob was working on something that we had interest or, or had a connection to, we could just turn to them and say, Hey, you guys, do you want to join us for a minute? Well, we talk about how we're going to, you know, architect this or how this is going to connect or, or whatnot. It was a fabulous way to work and, and it made the knowledge transfer quite easy. We also had a guild process guild. This process guild was really important in, in getting us to the fluid scaling technology model that we're, we use now in that the process guild would meet once a week to discuss processes and suggest experiments for improving how we did things. And that process guild would talk about the benefits of different changes maybe and then take that to the entire, the entire collective to talk about. We did experiments, our experiments had a start date and an end date and an expected outcome. We would do those experiments and at the end we would sort of retro on them and say, What did we learn? What can we do to change this experiment so that it has a, you know, is there something that we expected to get but didn't and how do we change that so that, so that we can continue this experiment or another experiment with the same expected outcomes. And this was really important because it allowed us to, to find ways of working better in, without actually making wholesale change of like, okay, we're going to throw out this entire process and do this. It's like, no, what's one little experiment we can run to try? Maybe we could try mobbing all, all the time instead of just twice a week. We'll do that for the next two weeks. I think it'll make our production better. At the end of two weeks we'll talk about it and see if that works. We learned discovery trees. This is how we, we, I talked about those a minute ago. This is how we tracked our work. Again, we, we have one on a window and one on a giant white board, but it made it very easy for everybody to kind of look at the work and what was done, what was in process and what, what hadn't been started. And again, probably another talk. Team agreements were really important. One of the things we often said around working this way is that you have to be an adult, which when I look back is kind of an odd way of saying it, but really a big part of, of the great work that we did was learning how to, to act together for the good of the team, for the good of the company, how to collaborate. And it's not easy. And it required us all to really do a lot of work. It's not just the team members, but the management as well. Right. We learned to, to value these agreements. And we took time. Two or three days, maybe even, it was maybe even a week in the beginning, out of our regular work schedule to sit down and sort of hammer out, have decision, you know, hammer out all our decisions around these agreements and get buy-in. We all agreed to, to the agreements we made about how we were going to organize, how we were going to, you know, promote natural leadership, how we were going to resolve conflicts. That was a really important one. Wasn't just like, okay, everybody run to the manager. Right. How do we resolve conflicts when you think one way and I think another? And, you know, we had to figure that out so that we could work. We could work together well. We talked about how we're going to experiment. We talked about our rules around code quality and collaboration. Are we going to have, you know, in the beginning, we decided everything had to be, had to have a pair to go into production. It had to be paired. In the end, by the time, you know, we had this large group, we were actually, everything had to be mobbed in production and had to, and had to be, we used a test driven development at the time had to be written with test driven development to go into production. That didn't mean we couldn't spike on things, but it couldn't go into production unless it had gone through them all. Right. And then we had rules or agreements around team growth and learning. How would we learn and grow? We actually decided we wanted to take time to learn. And we did. We took, in the beginning, we took like an hour a week. By the end, we had the first three hours on Monday morning was learning time where we did an open space event around learning. And someone would say, for instance, hey, I want to learn about Siri or Alexa skills today. And other people would put their names on that and they would go off and, and spend three hours learning about this. And they would come back and give us like, okay, here's what we learned. Here's how we can incorporate what we learned into our work. And there were some really great things that came out of that, that we were able to apply, not just, you know, about Alexa skills or whatever, but about process and about how we work that we, that we spent time learning about and applied to make our team better. And of course, we wrote all these agreements on a big poster and put it everywhere. We could see it. So what was really good about this? Right. If you're familiar with Daniel pinks book drive. He talks about motivation 3.0, which is the three things you need to really have a fabulously motivated team. And that is, you have to have the ability of mastery. You have to be able to get better at your job. You have to have autonomy, right? You don't want to be continually told what to do because you know how to do your job. And you have to have a purpose. And right, you, you don't. A job without purpose is, is, is boring really. You know, so once you get all three of those together, you get a fabulous time of performance and value creation. And, and we, we really achieved that well, we really enjoyed our work. And I don't think there was anybody there that, that really didn't. When was the last time you woke up on Monday morning and work cited that it was Monday and you got to go to work. That happened all the time for me. Because it was great stuff. I was doing great work with great people. And, and, you know, it was, it was amazing. We had this emergence of natural leadership. Right. This, the people that, that, not just because they've been there the longest, the, you know, but people that, that really wanted to do. Wanted to, to be part of that really kind of stood up. If someone would say, oh, we have to talk to, to security. And someone would go like, oh, I can do that. And they would stand up and say, yeah, I'll do it. We had a team ownership and team responsibility. And that was amazing. It wasn't just, it wasn't just my code. You know, it was all of our code. There wasn't just a bug that, that I'd written. Oh, Paige has written a bug. Look out, you know, he's got to go work on it. No, it was all of us. If there was a bug that got into production. It was all of us. It was all of our fault. Right. And we were all responsible for the work. We were all responsible and we own that. We were excited about that. We had a really good pride, amazing pride in our work. We learned, we learned as a team and grew as, as developers and, you know, people. And that was quite fabulous. And then we had, we made better software at a more rapid, but sustainable pace. And I, I bring that up. It always kind of seems like when I say, Oh, we made better software. It sounds kind of a, I don't know, maybe a little conceited, but it was because of our process. We really did make good software. We continually, and not only did we write test driven development, but with, with the mob or the ensemble group, the knowledge that spread around made the software better. We continuously and mercilessly refactored. So we were continuously cleaning up and making our software better. And I believe the last two years that I was there, we, I think we had two bugs that made it into production. And one of those bugs was due to load balancing that we didn't know about. And the other one actually was because someone had written code on their own and committed it and pushed it going totally against our, against our team agreement. And so it was kind of, kind of funny. Maybe it pointed out the fact, the reason why we had that agreement. But yeah, it was, it was pretty amazing. And the code was, was great. So there were some negative aspects. And, and I'll bring these up because it's important to know when you think about working in a way that, that is empowering for everyone. It's not collaborative work is hard and it's not for everyone. It is really hard. It requires this level of maturity that a lot of people aren't comfortable with at the office. Right. You have to be able to put yourself out there and say, I don't know, or, you know, this is wrong. Or you have to be able to be vulnerable. And a lot of people don't, don't like that, don't want that, don't want to work on that. And that's fine. I totally understand that, that it does require that work. So it's not for everyone. Right. We, we had several people that joined us. We always had an onboarding way of, of allowing people to, to join us. They knew what they got coming into it because we, you know, we, in the interview process, we actually had them be part of the work and they knew exactly what was coming, but there were times when the company merged other teams with ours. And there were people on those teams who, who weren't comfortable working in our, our processes and didn't want to be necessarily part of the collective. They, they wanted to just come to work and, you know, tell me what I need to do. Give me my story. I'm going to go work on it. I'm going to, you know, finish it. I'm going to go home and that's, that's fine. That's a, that's not an issue. It just isn't how we worked. And unfortunately, well, we had a, an onboarding process. We didn't necessarily have an off-boarding process where we could say, look, you're a great developer. You're a great person. There are other teams in this company that could use your, your amazing skills and, you know, how do we find that? Didn't exist. Maybe it's something that we, we could have thought about and come up with. If we'd had more time. And I, I use the past tense because of what I call the corporate immune system, very much like the immune system in our bodies. When something is different, it becomes attacked. Right. We were doing something that was radically different. We were, we were not doing scrum. We were not doing safe. We were doing this crazy thing where there wasn't a lot of, there wasn't any top down management telling us what to do. Right. And it requires a lot of trust from those outside of that collective. The business trusted us. We had to, we had to get them comfortable with it. They had to kind of learn as, as they went, just sort of like we did. But they, they, we gained that trust. But there were a lot of people that didn't trust us. A lot of other groups that, that didn't trust us from outside. Because it was different. Right. Management has to give up that power. Over feeling when, when you work this way. Management, it can't be a top down. You have to have that, that. Manager or management structure that lifts up the team that's there. Their job is not to tell them how to work and what to do, but their job is to make sure that they unblock all the, the blockers that they open up the. The channels that are not, the channels that are not. The managers that they open up the, the channels that are necessary. And they do the administrative things as well. The other thing that was interesting, we found other teams and managers. Sometimes felt really threatened by our team. There would be times when we would hear other managers come over and talk to us and say, you know, you, you guys are laughing too much. You know, and because we enjoyed our work, we did. Like there were times when we, when other teams were like, how come they get to spend time learning? Why can't we do that? Right. And, and I think that's one of those things that, that I don't know how to fix that. I don't know how we could have fixed it. We tried often to, to, you know, invite other teams, other people to come join us whenever we were learning. Anyone was welcome to join us. Whenever we had interaction with other teams, those teams, we would like, hey, come, come mob with us. Come be part of our collaborative effort as we solve this problem with our dependencies. Didn't, didn't work out unfortunately. So. Beach time check five minutes more. Okay. Thank you. I am, that's, I am right on schedule, which is excellent. Thank you. Thank you. So. A little about fast agile. I'm talking a lot about the fast meeting, but there are a lot of things that, that come around the outside of this fast meeting. The fast meeting is sort of the centralized glue that holds it all together. All of these things you can learn a little more about at, at fast agile IO. I've got the link on here and I'll have a resources slide at the end. So. So. Or use. Just by going to the. To the, the agile. Agile India 2022 site. And there's a link to all these slides there as well. But we had a thing called fast forecast. Excuse me. Fast forecasting, which was a wisdom of the ages. Wisdom of the crowd. Forecasting. So. It was, it was. When we needed to forecast, we didn't really estimate a whole lot. Once in a while we did, and we used fast forecasting. We use the opportunity and discovery mapping techniques that I was, that I was showing you. We, we think. That we could have scaled up to about 150 people, which is give or take a few is done bars number. We haven't tried it. And I actually haven't heard that it's gotten that high. It's gotten much higher. And some other teams that have tried this other companies that have tried this. We definitely found that mastery and reflection and improvement were a really important part of this as well, along with, with several other things. And again, you can go to the fast website and read about those. So just here's a little word cloud of kind of everything that I think I touched on. I'm more than welcome to talk about any of these with anyone. If you have questions. Yeah, my name is Paige Watson. I'm a senior technical coach from industrial logic. In the United States, and you're welcome to, to, to send me an email to contact me on Twitter. I love talking about this. And so I could go on for another four or five hours. Thank you very much. Thank you, Paige for sharing your information with us today. Thank you very much.