Sign up to save your podcasts
Or
Share Agile Practices: When do we get people together?
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Agile Practices: When do we get people together?
Episode 50: Agile Practices: When do we get people together?
Hello, and welcome to the bottom up skills podcast and Mike Parsons, the CEO of . And today I got to say, we're getting to the wait for it. The second last part about agile software development series. And today we're going to be talking about when we get everybody together and you know, this idea of the let's get everyone together and talk about the product is fantastic.
I mean, look, let's just get people aligned. Let's get people going in the right direction, but these projects can very quickly, uh, involve a lot of people. And the real emphasis to success of bringing people together is all about when and how you get them together. [00:01:00] And I've had to do a pro agile projects with huge mega brands like Coca Cola, a Nike I Kia, and lots of really cool startups like radio up in San Francisco.
Um, and. I've learned. So, so very much, uh, about how to best divide up these moments. So people can have not only the time to understand, but it's also about the chance for them to contribute. And that is, um, I mean, that's a win, win. If people really are aligned, there'll be able to offer all sorts of help, uh, on your project.
And if you're building a first generation product, a business, a new service, you name it, you're going to need some help. So if we can get the most out of bringing people together, chances are you're more likely. [00:02:00] Okay. So let's dive into this and we're going to talk about. Four concepts. The first one is scrum.
The second is a demo. The third is a showcase and the fourth is a brains trust. Okay. So these are different vehicles that have different purposes that occurred different times. They go for different amounts of time, but they also have this purpose of getting people aligned, getting them on board with what's happening because the core team is going to be going like crazy.
They're going to be sprinting all the time, so they're going to catch people up. Uh, and that's really important if you want help, if you want support, uh, then people have got to have some. You know, rudimentary understanding of what's happening, otherwise it's just guessing. Okay. So let's go and jump into the first of these concepts.
The scrum said differently. This is your daily [00:03:00] standup. And as we talked about in a couple of the previous episodes, this is a fast daily session for the core team. That a good one is 15 minutes. I start to get worried if they go for 30 minutes, because then I think you're actually, you've, you've made the classic mistake in a scrum is that you start talking in detail about a thing when that should be handled offline in a separate session.
The scrum it's purpose is to understand. Are you on track? It's amazing message from you to the rest of the team. Hey guys, I promised at the end of the sprint, I deliver this and I can tell you I'm feeling good about where I'm at. And today I'm going to be working on this new feature and I don't have any blockers.
That would be the perfect contribution stand up and [00:04:00] sometimes, and it's okay if you have to say, you know what, I thought that this feature. That I have a dependency on would be ready tomorrow, but I've just realized it's not. So I'm not sure about what I should do for the back half of the week. That's a blocker.
Great. We can tackle that. So the scrum is asking, are you on track and the scrum master, it's their job to go out and help each individuals solve those, uh, blockers that they do have if they come up. So the scrum is only attended by the core team. Um, that would usually be. Somewhere from six to 12 people, um, depending on the scope of the product you're building, I mean, I've got, uh, projects running at the moment that have doubled that number of people in it.
Uh, but they're, they're pretty significant projects. I also have some projects running just on five or six people, so it really does vary, but I [00:05:00] mean, once you're building core application, You've got data specialists, application developers, UX folks. You're going to have quite a lot of people. Paul you've got scrum master BAS client binders, a whole bunch of people running around.
So that scrum is just so essential for, um, making sure you're on track. Okay. So that's the first part of getting people together and what we start to do. In the demo is we go beyond the core team. We might go to some executive sponsors and bring them into the demo. Um, we may even bring, um, some experts in, uh, we might bring, um, client partners, uh, clients, you name it.
Now the demo doesn't happen. Of course, every day it happens usually every two weeks and it's usually a perfect way to wrap up a sprint. And, um, I think you are [00:06:00] showing your progress as a team. But I think if you only share that, then you're leaving a little bit on the field there. Um, I think you can also contribute, and this is a high form of alignment to what you are learning, how your better understanding uses the nuances in how the application needs to work in order for people to be delighted, that kind of stuff that really gets you inspired, but also.
In a capacity to contribute. If you understand, not only what the team are doing and the progress they're making, but you understand that the sort of learning that, the wisdom they're building about this product and how it serves its customers. Now, unlike the scrum, the demo can go for quite a while. And I would say it the list of 90 minute thing, and you want to open it up and make it conversational.
I think from my experience, the biggest [00:07:00] temptation in the demo. To make a presentation where two or three people on the project talk at the others. The best demos I've been in, uh, are aware the product owners are bringing you into the conversation about the progress they've made, um, the ups and the downs and what they're learning.
And it should be so compelling that people are. Volunteering contributions, help assistance and support. Um, that for me is it's a great demo. It's not judging jury situation. And you know, you can, you can change the vibe by how you present your demos, how you set them up, how you orchestrate them. But I would just avoid like a super polished thing, because then you're just spending lots of time in your keynote deck and not enough time on your product, if I'm really honest, Okay.
So we've got scrum and demo scrum [00:08:00] core team daily demo, every two weeks core team and extended members. Um, we'll get to the brain stress in a moment, but they're often people you can bring along. But now let's talk about the third one. Now the third and fourth one and not formal parts of agile and scrum methodology.
These are classic Mike Parsons out on, and I can tell you that they help. So very much. Now the showcase there should be a monthly, um, uh, opportunity. It should be something where you demonstrate. The achievements of the team. And very few of the team need to be in the showcase, maybe the product owner and the scrum master exec sponsor.
And you're presenting to folks not only in your brainstorm, um, direct, uh, executive sponsors, but you can also have it as a [00:09:00] fantastic knowledge sharing, uh, opportunity between folks who are. Not related to this project at all. Now, what I tend to find is that, um, there are others in the organization really keen at my clients who are really keen to learn about agile, and they might not be involved in the project at all.
We use the showcase as a, as a chance to, you know, maybe get the CEO, um, uh, involved with what we've achieved. Maybe get someone from a, like, if we're working with the retail team, maybe we'll go over to a team ...
View all episodes
By Mike Parsons
4.5
22 ratings
Episode 50: Agile Practices: When do we get people together?
Hello, and welcome to the bottom up skills podcast and Mike Parsons, the CEO of . And today I got to say, we're getting to the wait for it. The second last part about agile software development series. And today we're going to be talking about when we get everybody together and you know, this idea of the let's get everyone together and talk about the product is fantastic.
I mean, look, let's just get people aligned. Let's get people going in the right direction, but these projects can very quickly, uh, involve a lot of people. And the real emphasis to success of bringing people together is all about when and how you get them together. [00:01:00] And I've had to do a pro agile projects with huge mega brands like Coca Cola, a Nike I Kia, and lots of really cool startups like radio up in San Francisco.
Um, and. I've learned. So, so very much, uh, about how to best divide up these moments. So people can have not only the time to understand, but it's also about the chance for them to contribute. And that is, um, I mean, that's a win, win. If people really are aligned, there'll be able to offer all sorts of help, uh, on your project.
And if you're building a first generation product, a business, a new service, you name it, you're going to need some help. So if we can get the most out of bringing people together, chances are you're more likely. [00:02:00] Okay. So let's dive into this and we're going to talk about. Four concepts. The first one is scrum.
The second is a demo. The third is a showcase and the fourth is a brains trust. Okay. So these are different vehicles that have different purposes that occurred different times. They go for different amounts of time, but they also have this purpose of getting people aligned, getting them on board with what's happening because the core team is going to be going like crazy.
They're going to be sprinting all the time, so they're going to catch people up. Uh, and that's really important if you want help, if you want support, uh, then people have got to have some. You know, rudimentary understanding of what's happening, otherwise it's just guessing. Okay. So let's go and jump into the first of these concepts.
The scrum said differently. This is your daily [00:03:00] standup. And as we talked about in a couple of the previous episodes, this is a fast daily session for the core team. That a good one is 15 minutes. I start to get worried if they go for 30 minutes, because then I think you're actually, you've, you've made the classic mistake in a scrum is that you start talking in detail about a thing when that should be handled offline in a separate session.
The scrum it's purpose is to understand. Are you on track? It's amazing message from you to the rest of the team. Hey guys, I promised at the end of the sprint, I deliver this and I can tell you I'm feeling good about where I'm at. And today I'm going to be working on this new feature and I don't have any blockers.
That would be the perfect contribution stand up and [00:04:00] sometimes, and it's okay if you have to say, you know what, I thought that this feature. That I have a dependency on would be ready tomorrow, but I've just realized it's not. So I'm not sure about what I should do for the back half of the week. That's a blocker.
Great. We can tackle that. So the scrum is asking, are you on track and the scrum master, it's their job to go out and help each individuals solve those, uh, blockers that they do have if they come up. So the scrum is only attended by the core team. Um, that would usually be. Somewhere from six to 12 people, um, depending on the scope of the product you're building, I mean, I've got, uh, projects running at the moment that have doubled that number of people in it.
Uh, but they're, they're pretty significant projects. I also have some projects running just on five or six people, so it really does vary, but I [00:05:00] mean, once you're building core application, You've got data specialists, application developers, UX folks. You're going to have quite a lot of people. Paul you've got scrum master BAS client binders, a whole bunch of people running around.
So that scrum is just so essential for, um, making sure you're on track. Okay. So that's the first part of getting people together and what we start to do. In the demo is we go beyond the core team. We might go to some executive sponsors and bring them into the demo. Um, we may even bring, um, some experts in, uh, we might bring, um, client partners, uh, clients, you name it.
Now the demo doesn't happen. Of course, every day it happens usually every two weeks and it's usually a perfect way to wrap up a sprint. And, um, I think you are [00:06:00] showing your progress as a team. But I think if you only share that, then you're leaving a little bit on the field there. Um, I think you can also contribute, and this is a high form of alignment to what you are learning, how your better understanding uses the nuances in how the application needs to work in order for people to be delighted, that kind of stuff that really gets you inspired, but also.
In a capacity to contribute. If you understand, not only what the team are doing and the progress they're making, but you understand that the sort of learning that, the wisdom they're building about this product and how it serves its customers. Now, unlike the scrum, the demo can go for quite a while. And I would say it the list of 90 minute thing, and you want to open it up and make it conversational.
I think from my experience, the biggest [00:07:00] temptation in the demo. To make a presentation where two or three people on the project talk at the others. The best demos I've been in, uh, are aware the product owners are bringing you into the conversation about the progress they've made, um, the ups and the downs and what they're learning.
And it should be so compelling that people are. Volunteering contributions, help assistance and support. Um, that for me is it's a great demo. It's not judging jury situation. And you know, you can, you can change the vibe by how you present your demos, how you set them up, how you orchestrate them. But I would just avoid like a super polished thing, because then you're just spending lots of time in your keynote deck and not enough time on your product, if I'm really honest, Okay.
So we've got scrum and demo scrum [00:08:00] core team daily demo, every two weeks core team and extended members. Um, we'll get to the brain stress in a moment, but they're often people you can bring along. But now let's talk about the third one. Now the third and fourth one and not formal parts of agile and scrum methodology.
These are classic Mike Parsons out on, and I can tell you that they help. So very much. Now the showcase there should be a monthly, um, uh, opportunity. It should be something where you demonstrate. The achievements of the team. And very few of the team need to be in the showcase, maybe the product owner and the scrum master exec sponsor.
And you're presenting to folks not only in your brainstorm, um, direct, uh, executive sponsors, but you can also have it as a [00:09:00] fantastic knowledge sharing, uh, opportunity between folks who are. Not related to this project at all. Now, what I tend to find is that, um, there are others in the organization really keen at my clients who are really keen to learn about agile, and they might not be involved in the project at all.
We use the showcase as a, as a chance to, you know, maybe get the CEO, um, uh, involved with what we've achieved. Maybe get someone from a, like, if we're working with the retail team, maybe we'll go over to a team ...