June 15, 2018 | Net Health

3 Minute Read

Scrum.org Features Net Health Case Study: Net Health Used Team Self-Selection to Reorganize Their Scaling Initiative

Valerie Pierce, Senior Software Architect, and Nic Easton, Nexus Scrum Master and Software Engineer III, talked with Scrum.org to prepare a case study on how Net Health overcame scaling challenges since adopting Scrum in 2014. It started by moving from a number of unassociated Scrum Teams to a collection of Scrum Teams within a single Nexus. As quoted by Scrum.org, “they believed self-organization and bottom-up intelligence gave them the greatest chance to successfully deliver on Net Health’s business objectives.

Net Health found success in implementing the Nexus framework from Scrum.org. According to Chris Hayes, CTO and Board Director, “Because our teams were already familiar with Scrum, and we are big believers in self-organization, Nexus was our best option for successfully delivering on Net Health’s business objectives.” We’ve continued to have teams coming together producing integrated increments around one to three per Sprint.

Take a moment and see what Valerie and Nic covered with Scrum below:

 

Want to read more about Net Health’s case study with Scrum.org? Click here.

View Video Transcript

Good morning, good afternoon, good evening, everyone. This is Patricia Kong, from scrum.org, welcoming you to this month’s Scrum Pulse where I am joined by Nic Easton and Valerie Pearce from Net Health. Today what we’re going to actually be talking about is how they used team self-selection to reorganize their scaling initiative. So Nic Easton and Valerie Pearce were implementing a Nexus at Net Health, and this is a really interesting exercise that they did where they took all their team and said, “Hey, let’s reorganize. Let’s use self-selection to match our scaling initiative.”

So I asked them to share their experience because I’ve been having a lot of conversations with different organizations who are looking to learn from why an organization would do this. And not only just why, but how they would facilitate something like that. So today I’m going to be your moderator, giving the introduction, and Nic will talk about some of the reasoning behind their scaling initiative and then Valerie’s going to actually walk through the details.

So if we can get to the next slide please. So just some quick guidelines. Your microphones will be muted throughout, but feel free to put in some questions. We’re going to taking some question during the Scrum Pulse. And you can put that into the question panel. There’s also a chat panel if you’d like to chat there. You can tweet your questions to at Scrum.org and also use #ScrumPulse.

Next slide please. A little bit about scrum.org, scrum.org is the home of Scrum. I’m seating in our headquarters today, in Burlington, Massachusets. We are mission-based company working to improve the profession of software delivery, and we do that really through a few different ways through training, education, and assessments. We have a community of profession Scrum trainers. I think around 215 of them now around the world who train our courses around professional Scrum. We have certifications and assessments to validate learning, and a lot of resources for you to help you improve the profession of software delivery also.

One of the ways we do that is through the Scrum Pulse. So this is a free webinar by scrum.org and that’s generally I think run about monthly right now and there’s a lot of different themes. I’ve participated in a few and giving content around topics like Nexus, which is the scaling Scrum framework around evidence-based management, around women in management. But you can see there are several other themes that we have maybe around empiricism and agility, building trust and respect between business and IT.

So you can plug in, see different videos on our resources page. We also have a YouTube channel. And we would love, love to get requests for future sessions and what ideas and things that you’re thinking about. So you can always tweet that to us with, again, the #ScrumPulse or at Scrum.org.

Next please. So today’s presenters, yours truly. I’m moderating today. My name’s Patricia Kong, I’m the product owner of Enterprise Solutions, so I think about what we do outside of the team, so we can get that goodness into the enterprise. I’d like to introduce you to Nic Easton and Valerie Pearce. So Nic Easton, he actually serves as the agile coach. He is the Scrum master on the Nexus integration team, which Net Health calls the Nexus Scrum Master. He launched the community practices and introduced evidence-based management at Nexus, especially during their scaling initiative, which in my opinion shows that he really liked to put some skin in the game. By trade, he’s a software engineer, but like I said right now, he’s serving as the Nexus Scrum Master.

Valerie Pearce, who in my opinion has one of the best accessory games in the industry, she’s always wearing the best earrings and things like that. But she is on a mission to become as T-shaped as possible. I’ve talked to her about actually being pie shaped because she’s showing some very special skills. She’s the senior software architect at Net Health, but spend most of her time in 2016 to 2017 leading the professional Scrum transformation at Net Health and implementing Nexus. These are both great people who walk the walk in terms of Scrum values.

I got the pleasure of meeting them probably about I think in 2017 as I started to implement the Nexus at Net Health. And it was actually through one of our public classes in Burlington for SPS and I remember it very vividly because I remember we have a lot of people in the classes, but I remember Valeria and her colleague Kim during a break, staring at the Nexus poster and having a very serious discussion about it. And it caused me to ask them, “How are you doing? What are you thinking?” And they had talked about their story of sharing an implementation of Nexus.

So let me do a quick introduction of Net Health, if you could click to the next, Valerie. There you go. So Net Health, they’re based in Pittsburgh, Pennsylvania. They offer software solutions for healthcare professionals. They’re known for specialized outpatient care and offer an end-to-end solution for their clients. They serve 98% of the nation’s largest nonprofit and for-profit hospital chains. So what they’re doing is very important in terms of reaching out to that industry.

And because of that, they have this motto and this mission of the art of the right fit. And that’s the foundation of a platform that they’ve built to serve the people in the healthcare industry. So Net Health has 300 employees. They’re working across different offices, and also work from home employees. They’ll be able to share more, around how they did this team self-selection with that dynamic.

I am going to today, kick it over to Nic and Valerie. They’re going to be giving most of the content. Again, Nic is going to lay down the foundation of the scaling journey and the reason behind the team reorganization through self-selection at Net Health. And then again, Valerie is going to share the details of the event as she facilitated it and walk through that process. So please feel free to chime in with your questions today. We’ll be monitoring them throughout the presentation, and we left enough time for you guys to participate in a Q&A at the end. So over to you, Nic.

Thank you, Patricia. Can you hear me okay?

Hear you perfectly.

Great. So I’d like to start off with a little bit of background information on why Net Health implemented Scrum and then moved on Nexus. So we first adopted Scrum in 2014 because organizational leadership had a large new initiative and couldn’t afford not to start the work right away. So we couldn’t really wait for an exhausted requirement phases as we had done previously. We had little to no agile experience as an organization and I think we, to some degree underestimated the amount of change required that we needed to get the value from an agile way for working.

And slowly but steadily we started to move towards an agile way of working and we scaled from two Scrum teams to five. I think the biggest challenge there was that we were still operating in both in agile ish and a waterfall mode at the same time.

If you fast forward a couple of years, we had teams operating in silos not really communicating with each other very well or very often. We weren’t regularly integrating code even though we were working from the same code base. We sometimes built conflicting features. And we were really just unable to scale any of the meaningful conversations we were having. We were also in a scenario where business analysts weren’t on Scrum Teams. There were several people in a product owner role also not on Scrum Teams. So we implemented the Nexus framework, and several months in, we realized through inspection that we needed to adapt our teams. We need to change our teams. And having been through scrum.org scale, professional Scrum, the Nexus training, we decided to put our money where our mouth was and we decided to do a team formation.

So Nic, one of the questions that always comes up in a scaling conversation and you brought it up here is around the product owner role. So one of the things that the audience is wondering about is what did that structure look like for your product ownership at this point for Net Health?

Yeah. So we had a VP of product, we also had three or four product managers who each had a product owner reporting to them. And we also had a product owner that was on the Nexus integration team. That was essentially the structure.

So a lot of people wearing some sort of product hat? Okay, got it.

Yes.

Thank you.

Could you go to the next slide, please. So what’s the thought process around a team formation? Imagine, like we’re showing here, you have three knobs. You can adjust to optimize your outcomes. You can adjust the teams, you can adjust the work, and you can adjust the architecture. We knew that adjusting the architecture was just going to be too expensive. We knew that the work was pretty well defined. So we knew what we wanted to work on. And so we believed that it only made sense to adjust the teams.

Next slide please. So why self-selection though, in general? We believe that Scrum advocates for self-organization and as practitioners of Scrum and Nexus, we believed that self-organization gave us the greatest chance for successfully delivering on Net Health’s business objectives. So we wanted to allow each individual to choose his or her Scrum Team.

Nic just, who is the we here, when we’re looking at this?

So the organization really, on top of that has always valued highly engaged and highly satisfied team members. So we’ve put all that together and thought that all of those things are going to lead to highly satisfied team members which will only increase productivity and efficiency.

Thank you.

So to dig into a little bit more about why, we had teams, roles and product needs that had just changed over time. And we used these needs to drive our constraints for the team formation. We knew, like we said, before, we wanted a business analyst to be on Scrum Teams. We wanted to spread out the knowledge and expertise that was concentrated to only one Scrum Team to the rest of the Nexus, to the rest of the Scrum Teams. But moreover, we wanted to support a greater investment across the Nexus in building our platform and increased flexibility across the teams to support any future platform strategies.

So to dig into what the actual constraints were, about a month before the team formation, functional managers and other stakeholders of the Nexus got together to develop constraints for the teams to organize around. And this was a great opportunity for the organization at large to discuss the pros and cons and gray areas about when self-organization is appropriate, and to what extent. Because self-organization was a complexly new concept for us. But given our experience with the principles of agile, we took a small step in separating out the what and the how.

So we attempted to focus on stakeholders defining what we were trying to accomplish with the new teams. And then for the Nexus members to figure out how to accomplish it. So again, separating out the what and the how. So this is where we landed, you can see it on the screen here is that we wanted one business analyst per team. We wanted at least one senior software engineer per team. We wanted at least one junior or mid-level software engineer per team. We wanted a software to QA engineer ratio, no greater than three to one. This time we had software and QA team leads. And we wanted no more of them, or sorry, no more than one of them per team. We wanted at least three of the current Scrum Masters to stay honest Scrum Masters, to keep that consistency and continuity. And there was a very specific constraint, lastly, that three team members that were experts in one of our products had to stay together to carry on that knowledge. And to talk about what we actually did next, I’m going to hand it over to Valerie.

All right. So how did we actually conduct our team formation workshop? First, we did lots of preparation. I was the Nexus Scrum Master on the Nexus integration team at the time. And as Nic said, I worked with stakeholders to articulate what we were trying to accomplish, that you’ve seen as constraints. We held Q&A sessions for any participant who was interested in learning more about what to expect. The hardest part was finding a day about a month out where there was no PTO. So we scheduled the event for that day, we reserved the biggest room in our headquarters building. And we encourage participants who were in one of our remote offices to travel to our headquarters office.

We invited functional managers to observe, but asked them not to interfere with individuals selecting their teams. We did this to build competence in this concept of self-organization. And then on the day of the workshop, which was June 28th, we started with an overview of logistics, which I’m going to run through now.

So the whole goal of the workshop was for each participant selecting their team to stick a card they would be given, a Nexus member card onto one of five team boards. Seems pretty straightforward. And at the same time have all stakeholder identified constraints met across all five teams. And you’ll notice, I’m going to talk a lot about stakeholder constraints. They were front and center throughout the workshop.

So each participant would receive a Nexus member card. And these were five by seven inch stickable, re-stickable really sturdy cards so that they would survive the day. They had print, a font large enough to see from a distance. And on the cards themselves, there was any information about the individual that was relevant to the stakeholder constraints. So in addition to the person’s name, there was their title. As you recall, Nic talked about a couple of constraints that were based on senior software engineer or junior mid-level engineer.

We included whether this individual had a team constraint. And this only applied to three individuals to keep the knowledge together on one team. And an individual’s Scrum Master status. Had they been a Scrum Master, were they currently a Scrum Master? And each team member would also receive voting cards. And we came up with this idea because we wanted a really quick mechanism throughout the workshop to poll the group on how they felt about what we were doing. And we wound up using the cards for a variety of topics that came up throughout the workshop.

Valerie, we have a couple of questions coming in, right here. So the first one is when you were talking about title, what do you guys define as a team lead?

Sure. At Net Health, our software engineering team leads and QA leads are individuals who have a technical leadership as well as a people manager role.

Okay. And then, why the Scrum Master status, please?

Yeah. So if you recall, one of the constraints that our stakeholders identified is that we really wanted three current Scrum Masters to continue to be Scrum Masters for continuity. So we just wanted that information to be very transparent on the Nexus member cards.

Excellent. Thank you.

All right. In the room, this really, really big room that we had reserved, we set up five large empty team boards around the perimeter. And we wanted to make sure there was enough space between them for people to walk through the room, gather around the team boards. And next to each team board, we hung up the list of constraints as a checklist. We wanted our goal, what we were trying to accomplish, to be front and center.

We were going to allow or allot a 10 minute time box for individuals to walk through the room and add their card to the desired team board. And we really encouraged individuals assembling at each board to talk about the emerging team makeup, whether or not constraints were met. And people knew whether it was appropriate. They knew whether the constraints were being met and whether they should think about staying on that team or possibly moving to a different team.

So after this 10 minute time box, each team was asked to speak to whether or not they were meeting the constraints. And if the team wasn’t meeting constraints, we talked as the Nexus about what we would need to do to meet them. Then we did a vote of confidence after each team had talked to the constraints. Green meant, “I’m really confident about these teams we formed.” Yellow, “I have some concerns that we should discuss, but we might be okay.” And red meant, “I have major concerns about these teams.”

And we found that red was a good indicator that constraints clearly weren’t being met and we had to try something different. So after we had started the workshop with that logistics overview, we got started. Individuals found their card, they were color-coded by each department or by role. Blue for business analysts, green for quality assurance engineers, yellow for software engineers. You can see a nice picture of the actual workshop there. It was nice to be able to see visually, what is our team makeup in terms of skills. Participants were given the choice, when they got their member card, to indicate if they were interested in becoming a Scrum Master. Again, we wanted that transparency about, is there at least someone on this team who would like to be a Scrum Master? We made sure there were extras of everything just in case. We had a couple of promotions, staffing changes even in the week leading up to it. We wanted to make sure we were all set and good to go.

Hey, Valerie, we’re getting a couple of questions around the Scrum Master role here. So in your model the way that your Nexus functions, were your Scrum masters also development team members, or were there dedicated Scrum Masters to the team? Or is that something you were looking to transition to?

Sure. At the time, we had only part time Scrum Masters. They were a member of the development team and also served as a Scrum Master. We’ve moved a bit, experimented a bit beyond that as of late, but at the time, that’s what we had. And we want-

And you, at that time were the Scrum Master? You were solely serving as Scrum Master?

Yep, that’s right.

At the Nexus? Mm-hmm (affirmative).

Yep.

Thanks.

And we wanted, with the right innovatility we wanted people to have the opportunity to grow and really indicate that they wanted to grow into a Scrum Master role.

Excellent. Yep.

So we started with a practice round. And the reason we did that practice round is we wanted people to get comfortable with the format, be able to experiment freely with what it would be like to have 50 people in a room, pick the team, they want to be in and also satisfy all the constraints. That practice round, turned out to be pretty useful. We learned that it’s going to be hard. So it gave people a heads up about the real team formation and what challenges we’d have to collectively solve.

And following the practice rounds, we were prepared to rinse and repeat up to four times. So why four times? We didn’t assume it was going to be easy to meet constraints. And this repetition or thread of repetition had an impact on the collective problem solving. Our challenges became clear after the practice rounds, and after each round that we conducted and it encouraged people who didn’t want to spend their entire day doing this to actually get down to business and solve the constraint problems.

So one of the things, especially as this is the first time that you guys were doing this and really taking a chance, I think from all the teams in the Nexus and just even as an organization, so safety can be an issue. Where we talk about things and you’re giving this ability to use red cards. So then actually, did anybody ever use a red card to say, “Hey, we have a major concern about this? We don’t like this. We would prefer…” And you can see some scenarios behind there where it’s just because everybody would prefer to stay in their own team. Can you talk us through some of the setup there?

Sure. We definitely saw red votes in the first round and in the practice round. And they were primarily, “We’re definitely not meeting constraints.” So those red cards became a trigger for us to say, “Either we’re going to solve this, or we’re going to go into another round, to reset everything and dive into a fresh round.”

And how many rounds did it end up taking? They’re wondering.

Yeah. In addition to the practice round, we spent two rounds until we got to teams that worked. And that constraint check and vote of confidence at the end of that last round, it still wasn’t perfect. It wasn’t perfect in terms of voting. We still had people concerned. We still had red cards and we talked through them and people moved collaboratively to find something to… We eliminated all the red votes and got to almost all green votes.

Okay, great. Thank you.

Sure. So we closed the workshop by building consensus on a couple of things. We wanted to figure out a timeframe for teams to self-organize their Scrum Master. Since for us the Scrum Masters were key in coordinating communication across teams. We wanted teams to come up with some new team names. And as it turned out, we self-organized a theme, it just emerged of team names that were a combination of an animal and a natural disaster. So we wound up with names like Alpaca Lips, and Narwhal King. So that was fun.

We wanted to figure out at this point, we were in the middle of a sprint, we wanted to figure out the timeline for when the new teams would take effect. Some people wanted to really plan out carefully, we have teams who had refinement runway on their work. How do we transition, that refinement to the new teams? How do we transition that targeted work to new teams? Others really wanted to rip off the band aid and say, “Hey, we’re in the middle of a sprint. Let’s change teams at the beginning of the next sprint.” And it turns out that we chose that latter option. We ripped off the band aid, because during this wrap up part of the workshop, people talked about a creative way to transition work targeted to the old teams onto the new teams.

So did you do a mid sprint or did you [crosstalk 00:26:39]?

So the workshop was mid sprint. The new teams took effect on day one of the following sprint. We wanted to figure out our NIT representation. So how would each of the new teams be represented on the Nexus integration team? And as a Nexus, at Net Health, we triage our production products. So we wanted to figure out a way to share the load, share the work and production triaging. And during this wrap up period of the workshop teams figured out how to share the production triaging fairly.

All right. So that’s how we actually conducted the workshop from front to end. Now I’m going to turn it back over to Nic, and we’re going to get into some of the things that we learned by forming new teams through self-selection.

Thanks Valerie. So the first thing we learned, and we may have learned this before, we actually did the thing was that teams didn’t want to be reorganized. They felt conflicted about reorganization from top down. People were conflicted about the constraints. So for example, we had constraints based on title, not skills necessarily. And I think going forward, we’ll probably care less about whether or not you’re a senior software engineer and more about the skills that you bring to the table. We also added BA’s to Scrum Teams. And then they got to pick the teams that they wanted to be on, whatever made sense for them and for the work that we were going to be doing next.

And we also found that several people really welcomed the opportunity to switch teams, they appreciated that they could choose what team they were on. This was something new for us. They wanted to learn new things and work with different people. And on the flip side, some individuals chose their team because they really didn’t want to change teams, but constraints were met. And this was fine.

We also found that people moved teams for the benefit of the entire Nexus. So in these rounds of team formation, when we saw lots of red cards, someone may have really wanted to be on a team, but they saw that by them moving, they could solve the constraint problem. And so they did it. Individuals really stepped up for the good of the whole Nexus.

This whole workshop and this whole process leading up to it really built trust between teams, and between leadership and teams. Teams showed leadership, that given some clear constraints, they could successfully figure out how to meet them and self-organize into new teams. And leadership showed teams that they were willing to try something they’ve never done before. Define the what, but not the how. What traits do we want to have on each team and enable self-organization to make those traits emerge?

And I also learned that facilitating and coordinating this workshop across 60 to 70 people was a real significant undertaking. And I think though, it was really important for its success.

Well, congratulations. So thank you to both of you and to Net Health for being so open and sharing this experience and especially even on this side to sharing some of the conflict. So I have some follow up questions, but we certainly have several questions coming in that are around what you learned, but also just a little bit more detail around what’s going on.

So one of the questions is really about the concern around reforming teams. So what’s interesting is you’re talking about, when you talked about the formation, when we talk about Scrum Teams, it’s not about the individual, it’s about the benefit and how do we deliver as a team. And then when we talk about Nexus, when we’re scaling we’re saying, “Okay, how do we think about the Nexus where several teams are working together to build something? And how do we operate at the benefit of the entire Nexus?” So we’re looking at something that benefits as an entire system, not just as the parts and the ebb and flow. But one of the things that we talk about is that when you’re reforming a team, you’re potentially hurting the ability of the individuals to gel as a team. And you might be getting a hit on velocity. What did you guys see there? Was that a concern for anybody, when you were thinking about this?

Yeah, I think it was a real concern. We really wanted predictability as an organization into our velocity. We thought we really valued that. Individuals were really, really concerned about that reforming, “How am I going to learn to work, and build new communication patterns with my team?” But what we found was that the Nexus framework enabled us to think of these concerns more as a Nexus, it brought the whole question of team cohesion up to a Nexus level. And because we were all in this together a Nexus, it made this new forming of Scrum Teams within the Nexus, it made it more seamless.

That’s great. And there are some really good questions that are following up on that. So what executive buy-in did you guys have from this? And you showed the stakeholders which, I’m assuming you as the management and the executives. But how did you guys handle executive buy-in? How did that whole process work? And let’s imagine that new leadership comes in. Do you guys think that this model would stay in place? So at what level of sponsorship did this come from? For either of you.

That’s a really great question. So the sponsorship for at the time of the team formation came at the leadership of all of product development in Net Health. And I think there were key functional managers all the way up through executives who were involved in really deciding, “Yeah, we want to do this information,” and supporting it and coming up with the constraints for it. I think at this point, the Nexus framework is baked into our culture. I mean, it fits. So if there were a leadership, I think transition, I think you stated, I think it would work well. I don’t really have any concerns.

And it’s so important, and I think that question really gets to the heart of, when we talk about, Nic explained how you guys started using Scrum. And then I remember the story of the reason you came to Nexus is because someone said, “We have a scaling problem. Let’s visit this. This is the Nexus guide.” And then having that bottom up initiative, and then the top down support is really something that’s necessary to have agility thrive in an organization.

Some more questions, if I may. So there’s Teresa Shine, you have great questions. So do you think there’s a sustainable cadence to repeat this activity? Or have you guys set the teams for life?

I think there is definitely always room to evaluate and reevaluate the composition of your team. And I think that you don’t necessarily have to wait for an event or a formation like this to make sure your team is composed in a way that allows you to be successful. As for cadence, if you feel like you regularly look to the future, maybe twice a year or something, from a roadmap perspective, maybe you could use a cadence like that. But I don’t know that there’s any one particular hard and fast rule for any of this.

So that leads to this follow up, so you talked about, hey, we’re looking at our roadmap, and you showed some stakeholder identified constraints earlier, Nic. Do you guys still consider those to be… Did you consider those constraints to really be successful and useful after the teams were formed? What experiences would you say, “Hey, we might do this to think about the constraints.” What could you inspect and adapt for next time in terms of those constraints? What would the conversations look like with the stakeholders?

Right. So I think with any of this, this was the first time that we had done this. So there was definitely a learning curve. And I think that the constraints were successful because we learned from them. And like I had alluded to before, I don’t know that we’ll necessarily focus so much on title. So not software engineer three or whatever. But more about I have skills in this particular area. I like to work on this type of thing and organize around that. There might be a, we want to look at team sizes to make sure that they’re not too big or too small, but I think that we would focus again more on skills and less on title.

So since you’ve done this workshop, I know that Net Health has grown in size. What do you think is the limit that you’d be comfortable facilitating this for? When we talk about a Nexus, we talk about somewhere between three to nine teams, let’s say up to 100 people, do you think this could be done for more than the 60 to 70 people? Could it be done at 100, 150, 200? What do you think would have gone on?

I think you could definitely do it 100 people, let’s say. So if you had, I don’t know, nine people on each team or something like that, maybe a little bit less than 100. But I don’t know how we would go honestly, above that. I do put a lot of faith in self-organization, I’ve put a lot of faith in people’s ability to step up and be a hero type of thing. So I do think it might be a little bit more challenging, the more people you have, the more dependencies potentially. So you might need to add another step or two in there. But I do think it would be possible.

Right. And I would chime in that. I think this took, you mentioned about a half a day. So when you think about just the size, it’s about clearing those calendars and seeing what can happen. But the other thing is really having that support of, if we’re going to do this and having some clear constraints and boundaries of how many rounds you’re going to take or when you’re going to conclude that you are done. And also just saying, “Hey, do we have the management support, of whatever happens with these 50, 100, 150 people, that we’re going to support this for a little while?” So getting back to the questions. This is an interesting one, how did you handle, because we’re talking about the constraints and the composition of the teams, how did you handle UX design? Were they embedded in the teams?

That’s a great question. We do have UX design skills, but we don’t have enough individuals who really specialize in that to have a constraint per team, that each team has those skills. So we approach UX skills as a Nexus to how do we share the people with those skills?

And there was one here then. So if you have the new teams that were formed, how did you manage rapid response types of work where a particular person, let’s say you have an expert that needs to work on a specific issue?

I think we wanted to consider that when we did the formation in looking at what our work was going to be for the next several months and making sure that we didn’t put ourselves in a scenario in which we were creating external dependencies or maybe not even external dependencies, just dependencies with another team. We were trying to do everything we could to make sure the teams were aligned to the constraints, but also that we weren’t creating a bunch of dependencies as well.

Something else I think, we really like about our Nexus is that if there’s an individual with skills that another team needs, we don’t hold hard and fast that these are our teams. We might say, teams might coordinate, “Hey, person X, can you join our team for the sprint to help us with this particular skill?” So that’s been really helpful and fluid sense of where skills need to be for a sprint.

And that’s a lot around self-organization. And we’ve had a lot of conversations I think, from this, between Net Health and scrum.org about how this is really called out self-organization and the bottom of intelligence at Net Health has really been looking at. Okay, so you guys have been growing. So how have you been weaving in new hires into these teams?

So usually, a person will come in and then we take it to the Nexus, essentially. So take it to the Scrum Team, take it to the Nexus. What do you guys want to do? Would you like to have some rotation thing? Would you like to go a different route? And we essentially allow the Nexus to figure it out. If somebody feels like they need to add a person or whatever, they can do so, but we try to make it smooth, but also let the Nexus decide really how it goes.

Okay. That’s a great thing to hear. It’s interesting, because we’re going back, there’s a lot of questions around the constraints. So this is a two-part question. So let’s think about it this way, so did you know your constraints beforehand? Or was it discovered through the process, I guess of your scaling initiative? Did you guys write down the constraints and meet up as a stakeholder group beforehand? How did those constraints come to be?

So yeah, we had scaled in Scrum, in effect by starting to use the Nexus Framework several months before we did this team formation workshop. And in probably six or so weeks ahead of time, we had worked with the stakeholder group to have these clearly identified constraints. So everybody knew what the constraints were at least a month in advance of the workshop.

Oh, okay. That’s very interesting. So and one of the constraints that you had identified was saying, “Hey, we have business analysts in one team we’d like them to spread up throughout.” Someone’s asking here, can you describe the roles or responsibilities, and let’s say at Net Health of your BA’s, product owners and product managers? And has that, I’m going to add, has that changed since your implementation of Nexus in this reorg?

Sure. So it’s definitely has changed. We have since moved away to one product owner, who works with the product managers. And the product owner essentially has a team of business analysts that she works with, to make sure that anything that she needs we’re doing from a business perspective, from a product perspective. All of the business analysts are now on Scrum Teams now, and no longer report to two separate product managers.

Excellent. And so one of the things that they’re wondering as a follow up here, the listeners are, did you have, and for how long if you did, have a Nexus before this exercise, this workshop?

Yeah. As far as the timeline, we had started looking into Nexus about a year before this workshop started. Our Nexus Sprint one, probably about six months before this workshop. And we started with our existing Scrum Teams to just scaling using Nexus.

Excellent. So you’re starting with your existing Scrum Teams, and you’re scaling into a Nexus. And one of the things that you talked about was, “Not only are we doing this reorg workshop, but hey, when we change, we go through different sprints. Sometimes, somebody might join a different team and this is for the benefit of the Nexus.” A question here is if a person switches a team per sprint, and they put Scrum Master, but how do you consider capacity changes? Or your impacts of the roadmap? And what are the hits, again, that you’re getting? And how do you report on that when you have these changes in the teams?

Yeah. So we talk about changes like that pretty openly, in an environment where anyone can join in listening. And it’s very transparent. And usually we are making the switch because we don’t have what we need to do what we need to do. And like most other things, we were focusing on the most valuable thing we can do at the time. So the offset is again, talked about and if it’s a calculated risk, it’s a calculated risk, but everybody knows about it. As for capacity, you can take into account that a new person is going to be joining your team and a person may be leaving your team. But numbers only get you so far. I think at the end of the day, it’s a gut check about what the team thinks that they can do and when.

And then at the end of that, we talk about value. So if we’re looking at capacity, but we’re balancing that with value with all the evidence-based management work you’re doing with the Nexus, Nic, right?

That’s exactly right.

So here’s an interesting question around personnel. And I promise I’m only going to give you a couple of more questions. One of the things that you talked about was the no more than one team lead per group. Was there a structure before where, was the team was reporting into that team lead and if you changed that, did it cause any sort of personnel issues? And do you feel that having a team lead in general is counter to self-organization or the empowered self-organizing team?

That’s a great, great question. And I think it’s something we’re actively inspecting and adapting. Back at the time when we did the team formation last year, it was common for our software engineering team leads to be on the Scrum Team and all the individuals on the team reported to that person. We really strategically wanted to break that tie. We didn’t want to have to, if an individual moved from one team to another, we didn’t want them to change who they reported to. And for our quality assurance team leads, they typically weren’t on Scrum Teams. So what we’ve learned and what we’re experimenting with, is how to really leverage people managers and how to leverage technical leadership without a reporting structure on a Scrum Team.

That will be an interesting experience to share back with the group, I think.

Sure.

Yeah. So in terms of constraints, so did you guys consider location then as something? So if we’re talking about these different structures, is location, that was something that was this constraint? Because you talked about you have four regional offices, you have certain remote people. And if it is a constraint, will you continue to have that as a constraint or not?

Sure. For us that wasn’t a constraint. We have a reality that we’re not going to have a co-located Nexus. So we try to approach a lot of what we do in remote friendly ways. Nic, do you have anything to add?

Yeah. I think at the time, we did things like have a liaison during the actual formation, that you could be on the phone with if you weren’t in the room, which was super helpful. But looking how we’re doing things now, and then going back to what I said before, very recently, there were individuals that weren’t, or that were in the same location, but were working with teams that weren’t in the same location. And just organically they said, “Hey, we think that it would be better if we co-located,” and they split off and started their own team. So we do value that and if people think that that’s the best thing for them to do, that they should make it happen.

Yeah. And location is a conversation that always comes up in terms of scaling. That’s a big conversation, how you deal with that, how an organization deals with that will vary. But as long as you’re inclusive, that’s a right way forward. So last question here. And Valerie, you actually just spoke about this at a conference. But why did Net Health choose Nexus over other scaling frameworks? So why over SAFe? Why over LeSS? Why over DA? And that’s the last I’ll do in terms of promotion of other scaling frameworks.

Sure. I can start with that. And Nic, I’m curious if you want to add anything. But we were familiar with Scrum. We looked into what options were out there. And knowing what our… At the time of scaling, we thought our biggest pain point was that we had five teams operating in silos, and then code integration was really challenging. It was at the time of code integration, that we learned about feature conflicts and sometimes we were getting to package up a release or merging code, when we found that we build a feature that conflicted with another feature in the same sprint. So at the time, we thought Nexus was… It’s Scrum. It’s just scaled Scrum focused on this relationship or connection between people or things. And it really made sense to us to solve that problem. We didn’t know that it was actually going to really help us with so many other things. We did look into other frameworks, and I think we wanted simplicity. We wanted that focus on collaboration that we found in the Nexus Framework.

Yeah. I would just add to that and say, yeah, Nexus is still Scrum. It’s Scaled Scrum. And we were comfortable with Scrum for the majority of the organization. And the other thing I wanted to add there is, it came from the bottom, which I think meant a lot. So one of our Scrum Masters at the time had found the framework, raised it, and we made it happen. And I think that that was a huge part of it.

Excellent. Thank you for sharing that part of your journey. I mean, it’s just so interesting and refreshing sometimes to say, “Hey, we have a problem. And as a team, as a group, for the betterment of this organization to serve our customers, let’s just look for an easy solution. And let’s not break our back doing it.” And that’s what I hear.

So in closing, let’s see if we can get to that. So, Valerie, if you can transfer to me and I’ll show the closing sides. Just even based off of all these detailed questions, what we know is that there are people out there who are listening to this. So that are thinking about doing something like this, who will benefit for maybe just having the details of how they could do this, or they might consider how they could host this or facilitate this. So they might be using this to conduct a similar exercise as if needed.

I think the other things that we’ve learned today is that when we’re working and we’re thinking about self-organization, let’s consider what’s a benefit for the whole Nexus, rather than just individually. And what are our politics gesture. So you guys have shared a really great story, and I hope other people can learn from that.

But we have other things here. So you can see that you can connect with the scrum.org community. If you have more questions, you can participate on the Scrum forums, that’s where practitioners like Nic and Valerie can answer your questions, engage in a conversation but also with our professional Scrum trainers.

This is only one of many webcasts. So there are tons that you can go back and replay on our resources page. I’ve certainly conducted a few around what is Nexus? An introduction to what is this Nexus? Why would we be even forming a Nexus? What does a Nexus in action look like? You can see here, what is Scrum? That’s an important one to share with teams too. So learn from a variety of different people, including our trainers.

If you don’t like to watch webcasts, then read a blog. So we are putting out all this information to help with our mission of improving the profession of software delivery. So we’re always putting information out there and writing about different topics. So you’ll find some different things in our blog. And at the end of the day, I’d really like to thank you guys for taking an hour out of your days to participate, Nic and Valerie, to give this experience and share this experience that you’ve had but also to our listeners who are participating. So a big thank you and Scrum on. Thanks, everyone.

Share this post

Subscribe and See More