Forming The Agile Team - Agile Training Series Part 2

1. Forming the Agile Team Introduction: Hi, I'm Teresa Bennett, and this is part two of the Agile course training series for business analysts. And this part of the series, we're going to look at forming the Agile team. There are four topics that we'll cover in this training. The first is the units of the team. We're going to talk about the business unit and the development unit, and what areas of the organization fall into each of those units. When we're talking about our team and putting the people together that are going to be a part of that Agile team. Then we're going to look at team member roles and look at what roles are performed by the people on those two units. Then we'll move into best practices for the team. What is it that we need to do consistently to ensure that our team is successful? For every sprint and every project that we complete. Then we'll talk about your team, your role on your Agile team, and what mindset shifts you might need to make an order to be successful on an Agile team. And what flexibility means to you when you're working in an agile environment. So join me in the next video and let's get started. 2. Units of the Agile Team: Two units form the Agile team. First, we have the client facing unit, which you can also think of as the business unit. The people that form that team are, first of all, the client, which is the sponsor of the project. You also have the marketing team, which is your company's marketing team or the company the product is for. If your company is a consulting firm and has been brought in to assist on a project at another organization than it would be the marketing team of that organization. The product manager is the person that manages the operations of the product. And they are also part of the client-facing unit. And then of course we have the executives which I would consider to be anybody at director level or above. We also have the CMMI, which are subject matter experts. Those are the people that work with AND OR support the product. So they're the ones that really are working with it day in and day out and really know all of the nuts and bolts of the product. So they're able to answer your questions on how do you do this? What happens if a customer asks for? How do you go through this process? They should be able to answer those kind of questions. We also have stakeholders as part of the client-facing unit. Those are people or groups that have something to gain or lose from your project's outcome. The reason I'm mentioning something to lose here is think about it in terms of when you're making an update to a process, there are sometimes things that are removed from the process as we're making things more efficient. And that can take out steps that a particular group of people were doing or take out a process altogether that are group was doing. So a stake holder that is losing something could be a group that is no longer going to have to perform a function because the changes that are being made are making things more efficient and that function is no longer needed. And then of course, there could be other people involved depending on what the project is. So you might need to consider customer service reps, sales staff, maybe receptionists. If, for example, the software is maybe a hotel reservation system. So you would have front desk workers, any of those kind of people that you might have to think about that could be included either smooth or another group of people that might need to be involved in the project and then other product managers and stakeholders. So who else might be involved besides the stakeholders that you've already thought of? Are there other people that may be affected? Now let's take a look at who's included in the development unit. We have, of course the developers, right? Those are the people that are coding. They're developing the application. They're making changes to the actual software, the business analyst. So this is the person detailing the stories during the grooming sessions with the business unit. So if you are the business analyst, then. This is where the bulk of your work is going to be done on the Agile team. Qa is also involved in the development unit. So the QA team are the people that are doing software testing, procedure testing, process flow testing, anything other than the unit testing, which is typically done by the developers because they're testing their own code before they're turning it over. So unit testing is not included in QA, that's part of the developer function. But any other testing that's happening is typically included in the QA food chin and then the project manager. The project manager can be separate from the Scrum Master. Or the project manager can also be discriminant. Or I've seen this both ways in different organizations I've worked in. So it just depends on how your organization is set up and how they are defining roles and responsibilities within their organization. So you may have a combined role where the project manager and the scrum master or the same person, or were they are separate roles performed by two different individuals. Next, we have the technical writers and or training manual writers. They are responsible for creating technical documentation and training documentation. Training documentation may be done by the client unit. So somebody from the business unit may be assigned to do the writing of the training manual. Again, it just depends on how the organization is set up at the company that you're working at. So I have worked in organizations where they have not had a dedicated training manual writer. So the technical team that did the technical writing also create the training materials. And I've also worked at organizations where the business unit, right, the client facing unit had a training team and is somebody to write the training materials. So it just depends on how they're set up. If they do have a person to create the training materials as part of the client-facing unit, then they would be included in that area rather than in the development unit. Then we have our UX and design creative people. So they are the people that are defining the look and feel of the application and the user experience. Then we have the architecture people that are also included in the development unit because we're talking about system architecture, database architecture. It's more of the technical architecture rather than anything that would be business-related. And then we have another kind of other category, right? So any other IT or I S staff that is necessary to the success of the project. And again, that is dependent on how your organization is set up and what that particular project is for as to what other units might be involved in that particular project. 3. Team Roles: Next, let's take a look at team roles. So we're going to talk about who is responsible for what on both of those units that we just talked about, the client-facing unit and the development unit. Each of those people have certain responsibilities within the team. So for the client facing unit, they're responsible for the product vision and roadmap. They're also responsible for managing the Product Backlog, which is the scope, but think of it as the scope of the project. What are we doing for this project? They are expected to be prepared with details at the appropriate time. So at any point that the project team needs specific details related to anything for the business functions of the project. They need to be prepared to be able to answer those questions. They need to set clear expectations for acceptance, meaning they need to make sure that the entire team understands what their expectation is for when they will say that the what has been developed and built meets their expectations. So they need to tell us up front what those expectations are so that we are building to meet those expectations. That the hope is by the time we get to the point where we're demoing a product to them. They're saying yes, that is how I expected it to be. And they are of course, very much involved in communication throughout the team with not just defining and helping the team understand what it is that they want, but also in communicating any changes and their feedback to what is being created and built for them. The development unit is responsible for estimating, meaning that they need to have a good handle on estimating the time that it is going to take them to complete everything that is within the scope of the project. They're responsible for planning and committing for the iteration. So an iteration is also known as a sprint in the Agile world. And a Sprints are typically two weeks, maybe three weeks. I have seen some organizations do four-week sprints. However, I caution against those because you start moving into more of a waterfall mindset when you get into a sprint that is four weeks long or even longer than that. So the better timeframe for a sprint is two weeks or three weeks, man. And during that sprint, or what could be known as an iteration, the expectation is that the development unit is able to plan what they're going to do during that iteration and commit to that, and then come out of the other end of it with those things completed. Obviously, they're going to need to execute the iteration, right? So after they've planned and committed to what they're going to do, then they need to be able to execute on that and complete the tasks that need to be done. And then after that, that's where the demo comes in that I mentioned before when I was talking about the business unit. So the development team is going to do a demo at the end that to sprint to show what was completed during that timeframe. And if communication has happened well, and everybody has had the same understanding than what they're seeing in the demo should be what they expected to see. And therefore, they should say, yes, I accept this because it was built in the way that we expected it to be. And of course, they are expected to provide clear communication during each of the sprints through completion of the project. 4. Best Practices and Your Team: Now let's talk about team best practices. We want to start as a team and finish as a team. What we mean by that is when you first start on a project to everybody's very excited about it. Gunpowder like yes, we're going to do this thing where onboard with this, we don't want to get into a cycle where we're excited about things. And then we get into an iteration and we start working through it and problems come up. And by the time we finished that iteration in that two week or three week time period. And we get to the end, Everybody's pointing fingers and saying, well, we didn't do this because this wasn't clear. And we didn't get this done because this person didn't do this. We want to start as a team and finished as a team. And what that means is that during that entire two to three week period, we are working together, collaborating together. We're bringing up issues that come up and we're resolving them together so that we complete that sprint. Always together as a team and we're not splintering. And having those things happen that can break this apart and cause the ill will during a team. So the communication is key there during the entire process in order for the team to stay cohesive and work together. And part of that is number two, which is open and honest communication. If you're missing something, if you're having a roadblock that's keeping you from getting something done. We have to be able to talk about those things and come up with solutions to those things. Number three is inspect and adapt. So what this best-practice means is that we're always looking at what we're doing, thinking about how we can do it better, and then adapting and making those changes moving forward. Which brings us to number four, which is incremental improvement in product and process. In order for us to improve the product, meaning what we're delivering, we always have to be improving our processes as well. So during that open and honest communication and the inspecting and adapting, we want to improve our processes so that we're improving the product that we're delivering your team. So let's talk about your expectations. What expectations do you have when you are working on an Agile team? What shifts and mindset need to be made when you're moving from waterfall to an agile approach. One of the things for me, probably the biggest thing for me was understanding and being okay with the fact that I'm not going to know every thing at one time. So when you're working with, in a waterfall environment, you are completing all of the requirements. So you may be working in the analysis phase of a project. Four. Certainly for weeks at a time, sometimes months at a time, depending on how big the project is. And by the time you get to the end of the analysis phase, you know that product inside now. You have been working on it for so long that you've now become a CMMI to the product. And with Agile, you're not going to be there at the end of an iteration, at the end of a sprint, right? All you are going to really be comfortable with and know about are the requirements, meaning the stories that were completed and worked on during that sprint. So you're building your knowledge at the same time, the development team is building their knowledge. And that was probably the biggest shift that I had to make in my mindset was being okay with the fact that I wasn't going to know everything that I was going to be learning along the way, along with everybody else. The other thing that you have to be comfortable with is flexibility. So jumping in where you're needed. One of the things that really works well in an agile environment that we don't get a lot of opportunity to do in a waterfall environment is jumping in and helping out in other areas. Because in a waterfall environment you are so focused on getting everything done in one set of time. Your finishing out all of the requirements, you're doing, all of your documentation. So you're having all of your requirements sessions. You're creating all of your requirements. You're creating all of your process flows. You're creating all of your data flow diagrams, any kind of documentation that you have to do it use cases, whatever it is, you're doing the whole thing. So you're very much focused on all of that. What has to get done in that world. And you have blinders on because you have to, in order to get through all of that. However, in an agile world, you have a little bit more flexibility because you're only focused on a certain chunk of work at a time. And that leaves you with the ability to kind of open up your eyes and be able to see what's going on around you and what the rest of the team is focused on and hearing what challenges are having and maybe understanding like they are having a roadblock or challenge with this thing. Even though that's not part of my day-to-day tasks, I know how to help with this. I can help them overcome this roadblock. And you can speak up and say, you know what, I can help you out with that. So being flexible and taking that into consideration and taking those steps to kind of jump in and help your teammates is another thing that you are learning how to do and getting comfortable with in an agile world. Your project for this class is to document what expectations you have for working on an Agile project and what shifts and mindset you think you personally would need to make if you were moving from a waterfall environment to an agile approach or if you are new to Agile and have not worked on Waterfall previously. So you don't necessarily have a shift to make. Then list three things that you feel are necessary for a successful mindset, for an Agile work environment.