 315 on that screen. And by 315, it should say 215. I just didn't change my computer clock. You can press play. You're not going to drive. Oh, sure. Probably do that, huh? OK, welcome. Hi, everyone. We are at DrupalCon Nashville 2018, and you are currently in the session. It's all in the dysfunctional family. If you did not intend to be in the session titled, it's all in the dysfunctional family. You can sit awkwardly for the next 24 and a half minutes, or you can gracefully get up now and quietly make your exit. We will not take it personally. We will take it personally. We'll all just avert our heads while you leave. So today, it's Lee and myself, David, are presenting this. And I want to begin with a quote from the book that's sort of inspired and gave us the, led us into the experience we had that we're going to relate to you today. And it's by Patrick Lancioni. It's the five dysfunctions of team. People here have heard of this book, maybe read it. Nice. It comes with a companion workbook. And if you get a chance, if this is something you want to be trying with your teams, I really recommend getting that companion workbook. Because while the book itself is interesting and tells a great story. Come on in. We just started. You haven't missed anything. It doesn't tell you how to implement the ideas. And the workbook is what you need to do that. So I just want to begin. Not finance, not strategy, not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and it's so rare. There you go. Just a little food for thought as we kick this off. So here's what we're going to be going through today. We're going to do brief introductions of David and myself. So you have a sense of where we come from and why we are speaking on this topic. And then we're going to discuss the problem. We're going to use actually an example that David himself experienced on a team he was a part of, to sort of set up a problem and give you an example. And then we'll go through the model that's established in the book to give you a sense of how his team at that time worked through the problems they were facing. And we'll relate it back to sort of our experience more broadly. And then we actually are not going to do the example workshop today, because we're not going to have enough time. But we'll give you a couple of tips of things you can try on your own time. And then we'll have some time for a Q&A at the end. So I'll start with the intro. I'm Lee Bryant. I'm the content manager at MyPlanet. MyPlanet is a software studio up in Toronto. We've got people co-located all around the world. And my experience in terms of team development and teamwork, I've had about 36 jobs in less than 15 years. I averaged more than two a year for a while there. But I've been at MyPlanet for a few years now. And a lot of my jobs were in spaces like camp counseling and support work and working with sort of dynamic groups and people who had a lot of really strong personalities or a lot of difficulty dealing with other people's emotions and other people's individual identities, I guess. So it was a big part of my early career trajectory was establishing those things in my career now is focused on content, yes, but a lot of also community building and establishing networks and groups of people and bringing people together in sort of trusting relationships. So that's where I come from on that stuff. And currently I'm at MyPlanet as well. I'm a customer success manager there. And previous roles I've had there have involved me being a scrum master on a team and a product owner on another team. And working with my teammates to try to do the best work we could and try to get better at how we get our work done. And the experience I'm going to relate to you comes out of that motivation on one team in particular. My background originally was in manufacturing, printing, the old printing industry back in the early 70s is when I started in that and here I am still going, but in the digital world. And I made the move to digital publishing in the early 90s and through various paths I ended up five years ago joining MyPlanet and I'm very happy there. But I'd like to bring some of the work I've done focusing on team building to your attention. So first I'm going to describe the problem we had. And this may be a problem that some of you have experienced on your teams or see on other teams. And what we were failing to do was to deliver value. And value has a number of meanings but in this case with a development team is we weren't delivering the code we were supposed to be delivering, the functionality we were supposed to be delivering on time. And what are the symptoms of this? Well, we failed to meet our commitments. We were a scrum team, we were running sprints and we weren't meeting our sprint commitments. We'd make them week in, week out, set ourselves challenges and goals and we would not make those. Some of the things slowing our progress, technical debt, defects in our work. And we were doing the scrum practice, the agile practice of retrospectives. Does everyone here understand what a retrospective is? Don't have to explain that, good. But instead of discussing our problems as a team and discussing what we could do to actually meet our commitments, we were discussing things like the amount of light we would have in our room during the day where the lights would be on or off or which set of lights would go. How smelly your food could be. We were discussing anything, it's typical bike shedding, right? We were just discussing anything but our actual problems. But these anything seemed like insurmountable problems to us in the discussions. These are symptoms of a problem with a team failing to deliver. So some of the familiar symptoms, and Lee and I are gonna go through these, are in attention to details. The retro's not able to talk about what actually was going on, the defects. Those are in attention to details. In attention during meetings. So a lot of people on their laptops are looking at their phones and scrolling through stuff or taking calls in the middle of meetings, all those kinds of things. I mean, it runs the gamut from just twiddling your thumbs to some truly egregious behavior, but not being present in the actual meeting and listening to what your colleagues are saying is a pretty good sign. It's the best with someone falling asleep in a team meeting. Who else has experienced that at a curiosity? Yeah, there's a lot. It's not uncommon, unfortunately. But these are symptoms. And these are things we can either as observers or as part of a team go, oh, wait a minute. We also had people weren't asking for help. We were creating code that had defects in it, but people weren't asking each other for help. There was silence during our meetings. No one asking questions. No one asking questions. I'm willing to risk that level of vulnerability to say I don't understand or I'm curious about this or what if we tried it this way? And I've mentioned the defects that we kept putting into our code sprint by sprint. And there were others. Anyone here have an example they wanna share pile on here or not? Piling on would be a really good example actually. Piling on's another great one. Anyway, there are obviously a lot, anytime your meeting is kind of derailing or your teams are not producing to the degree that you know they should be able to do, there's probably gonna be a lot of signs and symptoms of what's going on. So it's a good time for some self-examination. And in David's case with the team, the realization that they came to was that the solution to the problem actually had to begin with David and a few of the other sort of key core players on the team. So I'll let him speak to that. Yeah, so initially as we tried to, the people were motivated to see the team improve, tried to seek improvement in our retros. We were looking for the wrong things as well. We were trying to focus on who was making the mistakes or non-route causes of the problem, why we weren't working together and collaborating. And finally, we just weren't working in a vacuum and trying to solve this. We were, all of us, doing a lot of reading, at least those in the group, the three of us who were trying to get the team moving again. And we stumbled across Patrick Lake, like Gionni's book, and we realized that improvement in the team had to start with improvement with those of us who were in the role of a leader of some sort on the team. And that we had to begin the process by changing ourselves and how we related to the team. And as someone who came from the traditional manufacturing and traditional corporate world, having people in a leadership position recognize that they might be the problem was an entirely new concept. One that I'd been aware of when I was in that world, but I'd never actually applied to myself. So that's where we started working and looking at ways to work with the team to improve. One more quotation, do you wanna take this one? Success comes only for those groups that overcome the all too human behavioral tendencies that corrupt teams and breed dysfunctional politics within them, lots of heavy words to parse out there. So these are the five dysfunctions of a team. You can see it's something of a pyramid building its way up. It starts with absence of trust, which is an unwillingness to be vulnerable within the group. And one of the things that's really highlighted in Lynch Gionni's book is how much you cannot really do anything if that core component of trust is missing. If people don't feel safe to speak up and raise a real issue, you're never gonna be able to address the issues in a meaningful, absolutely constructive way because they're not even being brought to the fore. So that absence of trust is a huge, huge, huge cornerstone of how to solve the problems to begin with. Fear of conflict. Conflict isn't necessarily a bad thing. Conflict is how we exchange, in this instance, means an exchange of ideas, some of which may not be compatible. There may be two ways to solve a problem or three ways to solve a problem. Which paths should we take? That's a conflict that a team has to be able to discuss and resolve. If you don't trust each other, you can't have that discussion because you're not gonna open up, you're not going to, have you ever heard someone say after a problem stopped the team and you had to go back? Well, I knew that wasn't gonna work. Oh, well, why didn't you talk to us about that in our decision-making process? So without trust, you can't have those conversations around conflicted ideas. And without having that conversation, you can't get to the best resolution to whatever problem you're trying to solve. So the next tier, lack of commitment. That one's an interesting one. It's sort of a feigning buy-in for group decisions which creates some ambiguity. And it creates some ambiguity sort of throughout the whole organization. If you don't have the kind of passion and commitment to the situation at hand and you're just going along with it, sort of to what David was alluding to with that fear of conflict, they're quite closely connected. If you're not willing to speak up and raise the conflicting opinions and you'll just go with it because it's easier, then you're not actually trying to find the best solution. You're not actually trying to create the thing that's gonna work the best. And it creates a real structural mismatch and you're gonna end up on a lot of different roads. You shouldn't have been on in the first place just because everyone was going with the flow in a really kind of negative way. So the next to last one is avoidance of accountability. And when we're on a team together and I'm a big fan of some other business thought which says that motivational rewards should go to the entire team, not be individualized. But there are times when individuals on a team need to take accountability for what they've done. And a team where people won't take accountability for their individual actions is a team that will allow mistakes to be passed through and the defects entered through the code that won't support each other and that won't step up and take the actions necessary to see the project succeed. And the final one, inattention to results. So focusing on personal success or status and ego before team success. And this is, I would say the other thing Lincioni really highlights as one of the key bits. If there's no trust, a lot of what's happening is people are really caught up in their own ego and their own agendas and they're really feeling that vulnerability anytime they're exposed for having made an error in the code or for having a thought that actually doesn't pan out an idea that's just not gonna come to fruition. So that inattention to results stemming from putting their own ego and their own desire to be the unicorn that's the best in the room and is a 10X dev or whatever it is. I'm not a developer, I probably misused all of those references. That's a real problem creator, that's a really big issue. And so once you've got all those building blocks you can still find it completely toppling off because people are still so attached to that thing and that they don't care about the end result as long as they look good. That's a really big issue. So remember teamwork begins by building trust and the only way to do that is to overcome our need for invulnerability. And what does invulnerability do for us? Well if we're invulnerable we don't need to ask for help. So one way that a team can not make its sprint target is because people are not asking for help spend a day, two days working on a problem which if they had raised the issue with their teammates might have had a solution inside a half an hour or an hour. So that team eventually came to, was able to say to themselves, they got to the point where they could say hey look if you've got a problem we're going to ask for help within two hours of having the problem and not being able to solve it. Previously the team, the members of the team would go the entire week without asking for helping a problem and their ticket would never be done. So the sense of invulnerability that you can't make a mistake or you can't be shown to be weak is the thing that stops people from trusting you. And without that trust at that very bottom level you can't achieve any of the other points along that pyramid. So how did we do it? Well it's hard and it takes time and we had a lot of tentative steps forward that ended up with us starting back at the beginning again. And it comes back to that invulnerability piece and the trust and back to that previous slide where I mentioned that it was a decision by the three people with leadership responsibilities and accountability on the team who got together and realized that we had to start showing the change and be the change ourselves. And when we finally succeeded in doing that the first time that you show invulnerability to someone they'll go, oh that's interesting. I wonder what that was about. Maybe it was an interesting lunch or something. So one example of invulnerability to your teammates isn't enough to make this work. You have to do it consistently day in, day out over a course of a number of weeks. So working with the workbook in our retro from the five dysfunctions it probably took us six to eight weeks to get to the point where we could actually feel that trust was starting to happen with everyone. That we stopped protecting ourselves from each other and that allowed us to move on to a countable, not sorry, what's the next one after? Countability after... After trust? Yeah, I just turned 65. I have some problems. Fair combat. That's when we could start having conversations that were passionate about what our solutions could be to a particular story, but also a conflict in them without the conversation breaking down into, well I don't think you know what you're talking about or well I told you so. So once we crack those two bottom pieces everything else seemed like a snap because those two bottom pieces are the ones that allow the other three to actually occur. Because the other three can't happen without trust and without the ability to have passionate discussion with opposing ideas. The results. The results. It was a team that excelled. David's team turned around I think like you said it took six or eight weeks for them to get from that really kind of horrifying state of super inefficiency frankly. They were really underperforming to a team that was phenomenal producing beyond expectations several weeks out of the many that followed those first six to eight, which is a huge deal. They went from missing deadlines, from not being able to make commitments from being hugely, hugely, hugely in technical debt and increasingly kind of budgetary debt a little bit to meeting and surpassing the goals and overcoming it entirely. Which is obviously very, very important especially that budget stuff from a business perspective. But more importantly the team was just functioning. They were getting along. They were helping each other. They were improving individually and as a group. Those are all really, really important things. And one of the kind of best benefits that came out of it was that the team itself had some new innovations that came out of it that they were able to then proactively bring to the client and offer up new opportunities that otherwise, I mean, not only would they never have surfaced those opportunities, they were gonna miss the ones that were already present and we were gonna lose a lot of stuff. So they went from not being able to meet current expectations to exceeding them and getting new expectations put on them that they were also able to meet. Yeah, I just wanted to talk to that point. And it's in hindsight I recognize the great job our product owner was doing because the client wasn't happy with some of our delivery, a lot of our delivery. But he managed to maintain a good relationship with the client that when the team changed and did begin to deliver, the client's trustness also grew. So it's not just internal trust you can garner by being following this sort of process, it's external trust that you will gain as well. And we've got so much trust with the client that we were eight weeks into a project for them. And one of our team members in a team meeting said, you know what, I don't think this solution that we've jumped on at the beginning is actually the best solution and it's actually going to scale to do what the client needs. And we went back, our product owner went back to the client and said, we've got another idea. Will you pay us to work for two weeks on this other idea to do a prototype? And they said yes, and the prototype worked. And then we said, will you allow us to throw out these eight weeks of work and tack another eight weeks on to the end of the project and we're gonna do it this new way. And they went yes. From the business point of view, those opportunities and those innovations never would have happened if the team had not have improved their collaboration, improved their trust, and gone through that hard work they did going through the Five Disfunctions workbook. And it showed a result on our bottom line and it showed a result in a solution architecture that we were able to leverage on several other projects as well. So as David just said, hard one trust in each other resulted in deep trust from the client. So if this were a longer session, right now is where we would do this sample trust exercise but instead we'll just quickly talk through it because we wanna leave a little bit of time for questions and we're starting to get down to that point. We are. So a sample trust exercise, one of those sort of quick easy wins you can do a short workshop is to divide the group into smaller groups or if you've only got say a team of five or six, that's probably small enough. You wouldn't wanna go much beyond five or six people. I think that's probably the upper limit, David, you agree? And then you wanna explain three things. Where you grew up, how many kids were in your family, and what was the most difficult or important challenge of your childhood? Not your inner childhood, not like a hugely traumatic, horrifying revelatory incident, but something that's a little bit personal, something that says a little bit about how you came to be the person you are. Just kind of the most important challenge of being a kid and the most important challenge of being a kid, keep in mind is often like, I was always, I'm the youngest and so I got the smallest portion at dinner and that's like, fine, you're probably fine, but it probably informs a little bit how you feel about trusting other people to give you your fair share of things and how you feel ownership over things and that kind of stuff. And you can change out these questions and adapt them as necessary, but an exercise that just gets three really quick, reasonably straightforward pieces of information out into the group, shared among the group is a great starting point in terms of exercises. And if I can give you a tip about this, it's, we're not Dr. Freud, we're not psychoanalyzing each other. Thank God. And try not to get into the negative things, try to frame the questions and the discussions around the good things that happen in people's lives. Those things can still inform us and provide us with insights into each other, but it means someone doesn't have the feeling, particularly at the early stage, when they may not have the trust in the process yet, the feeling of being arm twisted into revealing things that they wouldn't reveal to people normally. So you get people to reveal things that they would tell over a drink in a pub or something like that. What was their proudest moment in high school or what was the name of their grade school teacher and talk about that, but don't talk about how many times did you get strapped when you were in kindergarten? No, so that you don't want to go there. That is very grim. Hope you're enjoying this talk, everyone. I was waiting for the other student to drop, David. I need an example. Yeah. So that is it in terms of what we've got prepared for you, but if you've got questions now is the ideal time to bring them up. Anybody have any questions? Come on up to the mic. Yeah, please. I was wondering about if you could give a specific example of a conversation someone in leadership or on your team would, you know, being vulnerable, like what that would look like. Yeah, absolutely. So the question, I don't know if that mic is recorded, so I'm just gonna repeat it, was could we provide an example of someone in the leadership position sort of role modeling or giving an example of their own vulnerability in order to sort of prompt it with the group? I mean, even just in that last workshop example, being the first one to share what that challenge was is a great first step towards that or being willing to say, you know, last week I had a client meeting and I said this one thing, I promised we could deliver on it and I hadn't actually checked with our technical leadership team and I spoke out of turn, we weren't gonna be, I messed up, I made that mistake. I oversold our capacity. Owning that mistake is a really great example of your own vulnerability. One of the other members of the leadership group with that team is in the room we would often, without setting it up too much, would work together, so I would admit a mistake that I had made and his response would be to accept that, to make a suggestion to prevent that from happening in the future, but I would not be scolded or reprimanded so people got the idea that, oh, it's okay to admit to a mistake. You're not going to be in trouble because you admit to making a mistake, so we often would, it wasn't role playing because it's an actual mistake I've made but we would make sure that the conversation happened where it could be heard by other people so that we could expose my vulnerability and we could also expose that inside the team as long as you were working towards improvement that being able to say you made a mistake and identify it and identify corrective action kind of got almost rewarded without there being a cooking involved but there was a way that there was nothing bad happening because of this sequence of events. And if you don't have that sort of natural partner in crime to bounce that off of, then you can facilitate it yourself. I made this mistake, can anyone give me, I would love if you've got an idea of how I could have avoided that in the future. Ask for that help, that's a great. Asking for help, honestly, everyone in this room forever regardless of what you're doing, just ask for help. People want to give help, they feel so good when you give them the chance to help. You seem like so much less of a little tight hummingbird that is so fraught, it's just the greatest thing. You feel good when you get the help, everything about it is great. My number one recommendation to all people. Questions, sorry, before I go off on a help tangent. This is recorded in fact. Oh great, fantastic, I will not repeat it. So I'm gonna start by just asking, in your example, David, you had your three leaders who kind of banded together to begin the sort of introspection and improvement process and I'm gonna just start by asking, I know your role, but what were the roles of the three? And the second part of the question is, how did the three of you kick this off? How did, what was it like to talk to each other and begin that conversation and saying, this is rotten, what can we do to lead the team to improvement? So it was a scrum team, I was the scrum master. We had a tech lead on the team and we had a product owner on the team and we were the three that put our heads together and had been looking for ways, particularly the tech lead on myself, who had been looking for ways to get this team out of the rut it was in. And we were really good on this scrum ritual so we were having our regular retrospectives, they just were pretty ineffective and we just brought it up in a retrospective and said, look, we've come across this book, here it is and we shared some stuff from it and what do you think about giving this a try? Because there were developers, some of the, many of the developers in the team wanted to see this problem solved but they didn't have the tools to solve it and so this workbook gave us a way to put ourselves on a railroad track, so to speak and find a solution because it was a known method for finding a solution and particularly with devs, I mean, what better way to frame a solution to a human problem but to say, look, we've found this path that isn't too, you know, funny and it's kind of engineering-like. Let's give it a try and we got buy-in. It took, it still took a lot of time for that initial first rung to be crossed. I'm gonna cut us off now because there's another group in here afterwards but there are more questions we'll be just outside and thank you so much and feel free to send your information, take the survey, et cetera and join the sprints or whatever that other slide was that we're supposed to pick up and I forgot to do and have a great rest of DrupalCon, guys, bye, thank you. Sorry for running a little long there.