047 Agile Team

[00:00:00] Hello and welcome to the bottom Mount skills podcast. I might pass since I'm the CEO of quality science and we are at the last part of the people in teams, chapter of agile software development. And in this episode, we're going to talk about the development team. And previously we've talked about scrum master and the product owner.

Now we're going to talk about the team. This is the mighty engine. Of all that great work that's going to happen in your brand new software or digital product. And I think what is most important when you think about asking the question, what is a good agile team? There is really only one answer and that is that teams should be multi disciplined multidisciplined that they should come in.

It should [00:01:00] be like the 18, you know, it should be a cast of characters, springing different skills so that you can have a really diverse point of view. And that will help you really come up with some really innovative approach approaches to some simple problems or tackling the big overall pains and gains of your users.

Now as diverse as they might be in skills, what will bring them all together as a shared vision and commitment to the project. And, um, that's really essential when you have a multi discipline team, all gotta be excited, motivated. Fired up about the vision of what you're going to build committed to the project.

So let's uncover how you can span everything from deep work to collaboration in an agile team. Setting. All right. So yeah, let's talk about this team. Um, what's in the team [00:02:00] and like, what does multidisciplined look like? And, you know, the thing, when I think about all the different projects, um, an agile team is, can be anything from hardcore, uh, engineering.

Design, um, user experience. Um, I tell you what great BAS business analysts, uh, dev ops copywriting design and art delivery members. Um, I mean, Oh my gosh, there are so many different roles that can be inside different skills that could be, uh, in. This team and you could call upon experts. So let's say you're building a product, that's all about workouts.

So you get health and fitness [00:03:00] experts. You get physiotherapists, nutritionalists you name it, bring all of those people together. Now the trick in bringing them all together is to have this really come and go. So. You need, do need to make sure that they're actually excited around the idea of the product.

Like hello. Like it doesn't matter whether or not in the case of creating like a workout app, whether they're workout boffins, but if they're genuinely interested and compelled by the notion of Lexmark, let's make people more healthy fit and, well, that's really important because without a doubt, yes, we will go to what we call.

The Valley of darkness. And that is where you're not sure what you're going to build. The timeline's creeping up. Everyone's for real King out. And it's. This bond around a common goal that will kind of bring you altogether. [00:04:00] So I think that, you know, you need to make sure that, you know, whilst you bring that diverse cast of characters together, you have to ensure there's a common goal.

Now, some of the other really important things is. You got to communicate like crazy. And at the start of that is sharing what you're working on. Not only in the daily scrums, but making sure that people in other disciplines really have a sense of what you're doing and what you're contributing. And on the other side of that, I think as a receiver of these messages, you have to be genuinely interested in the work that others are doing.

Because if you understand the various disciplines that are contributing. To one single product. I think you're in a better place to integrate them, to bring, uh, the whole product together. So that is elegant, seamless, and just insanely intuitive rather than being really [00:05:00] clunky. And obviously, you know, A force fit between all those things.

So there's a bunch of things going on. There's this cast of characters fired up about a goal. They're all connecting and working in a similar way. And I wanted to take a moment to. Reflect on two ideas that I think drawing Mave the performance of a team. Now, if you are interested in, um, how agile teams work, uh, both in a detailed view and on a kind of a metal level, you should jump over to bottom up.io, where you can check out the full masterclass that we have.

It's it's all free. Well, you can sign up and, um, go really deep on some of these topics. But for this episode of the podcast, I really just want to share with you two ideas is around, uh, an agile development team and the people that build the product. Okay. First [00:06:00] idea. It's all about finding balance and this it's really common sense and it sounds really easy.

Yeah. When you talk about you, you know, how you think about your time, but finding the balance is actually really hard in a fast moving agile project. And this balance that I'm talking about, let's say you're a team member in an agile project. The balance that I'm talking about is between doing your deep work.

Your expert work either individually on a very small team and then your collaborative work, where you're often doing work sessions with other people from other disciplines in the project. And this harmony between deep work and collaborative work indicates. So much of whether a team is going to build a great product, because sometimes you see, let's say the archetypical [00:07:00] developer who doesn't really want to work with anybody else because they're too busy writing the code.

So they're just maxing out on deep work, but they might be spending time thinking about problems that if they maybe went and found a BA a UX or UI designer, uh, maybe even a dev ops person, Maybe just sharing the problem might half of the problem. Um, so sometimes there's a tendency to do a deep work and that makes it very challenging because you really do have the team operating as all these really small silos.

On the other hand. Sometimes there's just too many work sessions, too many meetings. There's no time for the work. So when I talk about the success of an agile team finding balance between deep work and collaborative work is. It is so important because if you can go do some deep work and then you bring it back to your colleagues, you jam [00:08:00] on it, you discuss it, get some feedback.

You go back, do some deep work, come back again from another working session. If you can build that, that cadence you'll find that you just fly, but there's an under 10 unintended consequence to the balance. Here is not only is your deep work thoughtful. But your collaborative work gives all the other team members a really good sense of what you're working on.

So it means their work will fit better with yours. So that's the first thing, finding the balance. It's a really fundamental challenge to a good team. So make sure you strive for finding that balance between deep and collaborative work and the last thought I have for you. Is to connect. And I mean, this from a point of view of be connected, um, during [00:09:00] the day, uh, be connected for your demos, for your retrospectives or common practices in an agile project, you should be doing your standups daily.

Um, but the other thing is you really need to make sure. That you are all talking the same language and let's say I'm working on. A feature and I give it a particular name, which has certain assumptions, certain user stories attached to it. If I'm not constantly connecting with others, like if I'm the designer, I need to talk to the developers.

And if I go too off on a tangent and I created a let's call it the headquarters a feature, and they're all cal...