A Deep Dive Into Agile Project Management

0:00:00 Speaker 1: This video on Agile project management is brought to you by TechTarget through a partnership with Global Knowledge.

0:00:08 Samuel Brown: Hello, my name is Samuel Brown, and I am going to work with you as we work our way through an overview of Agile project management.

0:00:27 SB: As I said, my name is Samuel Brown. I'm located in Raleigh, North Carolina. I've been with Global Knowledge for about 13 years now and have been in the field of project management and training for several decades and so look forward to working together as we work our way through all of this stuff. Our topic is Agile project management and our focus is on overview. So, the intent here is to give you a sense of what Agile is, what it's about and how it applies in project management.

0:01:19 SB: Our outline for this presentation has six sections in it. We're going to lay the groundwork upfront with an introduction to Agile basic concepts, basic ideas, and then sort of walk through, not really the lifecycle but the Agile cycle. And we'll talk about how we initiate Agile projects, how we plan a work cycle or iteration, what goes into building a product increment, and then how we wrap up a work cycle and do a review, and then how that review works for us, with us, to adapt to changes as we go.

0:02:23 SB: Well, I guess the first question that we need to answer is what is Agile? And Agile is a group of methodologies. It's not one methodology. There's a bunch of different examples but all of them share two things in common. They all value a pragmatic mindset and they all value and provide a flexible approach to meeting the expectations of our stakeholders. Agile developed out of software development and there's several flavors or methodologies, if you will, under the Agile umbrella. Some you are probably familiar with, Scrum being one of the most popular. But extreme programming (XP), Lean, Kanban, all are related under this Agile umbrella.

0:03:52 SB: When we talk about the pragmatic mindset, it's really the recognition that at the beginning, we don't know much. We know less than we need to know to effectively plan and so it doesn't make sense to try to do detailed planning upfront. As we do things, we learn. And not only do we learn but our customer learns. So, what our customer tells us they want upfront is what they want to the best of their knowledge and the best of their ability to describe it at that point in time. But as we start working with them, they're going to learn things, they're going to understand things they didn't understand before and that's going to change their way of seeing, their way of describing what they need in the end and that's going to help us. So, we need to, from an Agile point of view, think about projects as a partnership between us and the customer.

0:05:23 SB: And change is unpredictable. It cannot be controlled. So part of that pragmatic mindset is the recognition that we shouldn't be trying to control something that isn't controllable and so, shorten our horizon, focus on planning only what we know which means a few days, a few weeks, maybe a month or two or three into the future, but that's really all we can know with a high degree of confidence. Flexible approach means that we're focused on the customer, what the customer wants, what the customer needs. And as the customer's understanding of those needs evolves, we adjust with them that we need to adapt our approach. We need to adapt to those changes that are likely to happen through the customer's evolving understanding and so forth along the way, and that our teams will work better together, will work more efficiently when they're able to have some autonomy and some control in the way they work.

0:07:33 SB: So, when Agile was established back in 2001, it was established on the basis of a manifesto, and then from that manifesto 12 principles were developed. And so, let's take a look at those very basic elements that undergird all of these approaches to Agile. The Agile Manifesto says what you see on the screen, that we're uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value.

0:08:23 SB: Now, that's an important phrase we have come to value. The Agile Manifesto does not say this stuff on the right is bad and should be avoided or shouldn't be done. What they're saying is that in Agile, we value this stuff on the left more than we value the stuff on the right. Processes and tools are important but from an Agile perspective, individuals and interactions with those individuals is more important. Documentation is important but working functional software is more important. Contract negotiations, obviously, important but collaboration with the customer is more important. And being able to and following through on, responses to change is more important than sticking to a strict plan.

0:09:52 SB: Planning is important, planning is necessary but it's more important to be flexible and adaptable than it is to rigidly stick to a plan. From that, those 12 principles were developed. And this is a lot of text and I'm not going to read it to you, but I am going to call your attention to the stuff that has been bolded within each of the principles. Focuses on satisfying the customer; embracing change as we go on; delivering software incrementally that works; working with stakeholders to understand what they want, what they need, and how those needs evolve and change; to work with motivated individuals, motivated members of the team and getting them an environment that supports that kind of motivation; dealing with people face-to-face is more effective than dealing with them in a disconnected way. And that infers and is highly valued in Agile that to the greatest extent possible, we ought to be doing our Agile projects on a co-located basis. It's not always possible. Agile can work on a virtual basis but our principle is to do work together.

0:12:36 SB: That progress is measured by what we've delivered not by a calendar, that we should be promoting sustainable development and focus on excellence, good design, technical excellence to give us agility in adjusting to changes with our customer. And we value simplicity. Maximizing the amount of work not done. In other words, one of our principles is don't overcomplicate it. Implement the simplest solution in the simplest way that will meet the stakeholders' needs. And then that idea of motivated people. We also work from the principle that motivation comes from self-organization. So, we pull cross-functional folks together as a team, and we enable them to figure out the best way to work together for themselves based on the individuals that make up that team and what we're trying to accomplish. And then we need to look at what we've done, look at our opportunities to tweak the way we work, to fix things that didn't work as well. And so, not only do we need to do that in the end, we need to do it at regular intervals.

0:15:12 SB: Agile project management, then, is the way that we try to implement the manifesto and the 12 principles. This came out of software development, but its utility is not limited to software development. It works well in all kinds of environments, industries and projects. Agile PM should be pragmatic; recognize what we don't know, that we should always be learning; that change is not going to be predictable or controllable; and that Murphy's Law is alive and well and always at work. And we need to be flexible. We need to take things that we learn and look at how they can be applied to what we're doing and how we're doing it. And the goal from that adaptability, that flexibility is always focused on making sure that we are satisfying our customer. Now there are always limitations, so we can't ignore those, but our focus is on satisfying the customer to the greatest extent possible within those limitations that we cannot change.

0:17:32 SB: So, in Agile, there are some pretty common routine roles that we see in Agile environments and teams. One of those is the Scrum Master. Well, the Scrum Master's role is to act as the bulldozer, so to speak, staying out in front of the team but not too far in front and identifying things that might interfere with the team's ability to function, identifying organizational obstacles, and working to remove those obstacles and get them out of the team's way. The Agile coach, then, is exactly that. They work with the team. And they, like any coach, provide guidance, provide focus on developing folks within the team, mentoring them, and on ensuring good application of Agile practices.

0:19:21 SB: The product owner is sort of like what we have often thought of in traditional project management as project's sponsor. They're the ones who define what the need is that we're trying to meet, that define what they want in that future state that we're working toward. They're the ones that help make sure that as we do the work we stay on track with that vision. And then of course, the team and the members within that team are the ones that are taking the understanding of that vision and defining what needs to be done to implement it. Now, these are common but they're not exactly the same in every approach to Agile. But you notice what's missing in this is a project management role. It's not a typical or as we say it here, foundational Agile role.

0:21:09 SB: So what the project manager does, what's expected of them, how they fit into the Agile team varies from one implementation of Agile to another. But often, the project manager's role is a coordination role, acting as the coordinator between the Scrum Master, the coach, the product owner, and even the team, to ensure we don't duplicate, we're not redundant, and that we're able to function collaboratively as effectively and efficiently as possible.

0:22:26 SB: When we talk about the coach role, the Agile coach is coaching the team but they're also coaching other key stakeholders in the Agile project. They're collaborating with the team and the customer, make sure we understand what they want that we're adapting to it, that we can figure out how to technically accomplish what the customer wants, that we are focused on excellence as we do that, and that we do it within our Agile principles and practices. But we also need to coach the product owner what it means to be a product owner, what's expected of the product owner, what the relationship is between the product owner and the team and coaching them to understand that they are the spokesperson, the representative of the user community or the customers that the project is trying to deliver to.

0:24:10 SB: But the coach also needs to work with senior management to help senior management understand Agile principles and practices and to help manage the expectations from senior management around what Agile can and will deliver and how that delivery is going to occur. Communication is always key and it's key in Agile as well and it's one of the core functions of the Agile coach. The coach needs to take what the team is doing, how they're doing, where they are, and communicate that back to the product owner, senior management and other stakeholders in business terms, in terms of the value of what the team's doing for the larger organization. The coach needs to work to resolve resource conflicts, issues around availability, issues in coordination among those resources, and to be the cheerleader for the work that the team is doing, to talk it up, to highlight their successes, to highlight their accomplishments, and to then protect them from outside interference with what the team is trying to do.

0:26:43 SB: And we need to also coach our other stakeholders: SMEs, customers, et cetera, to understand where we are, what's happening, why it's happening, where we're going, and what they're going to get, what they can expect. So just a summary of what we've been talking about. The coach, just like on a sports team, ensures effectiveness, facilitates collaboration, removes obstacles and provides the interface from the project out to the organization. The team gets things done, collaborates among themselves, focuses on producing things that work and on being self-managed and self-directed. The product owner establishes the vision, defines that future state we're trying to accomplish, identifies, prioritizes our requirements, and then is the point of accountability in an Agile project.

0:28:50 SB: So, an Agile lifecycle starts with establishing that vision, high-level planning, identifying requirements. And in Agile, that set of requirements are high-level requirements and we refer to it as the product backlog. And it's made up of user stories, which we'll talk about in a couple of minutes. Once we've got the context, the high-level plan, then we're going to plan a cycle of work. That cycle of work is going to be short, depending on our project, one week to maybe four weeks. We're going to plan, out of this backlog, what we can get done in this time frame. And it's not a variable time frame; it's a fixed time frame. So, we're going to pick a one-week cycle, two, three, or four-week cycle but every iteration, then, will have that duration. So how much can we get done in the iteration?

0:30:26 SB: We're then going to develop based on what we said we can do in this iteration. And every single day, we're going to start the day out with a stand-up meeting to review what's been done and what needs to be done, what's left to do. We're going to update our artifacts, Scrum board, et cetera, and we're just going to keep doing that. At the end of the iteration we have something to deliver. It may take two or three iterations or more to have enough to have something we can release, but we're producing something measurable, meaningful out of every iteration, and it is at this end of the iteration that we're going to do our review, our retrospective. And that review and retrospective becomes the basis for adapting to change and planning the next iteration and then we do it again.

0:32:00 SB: So how do we get started? Well, we get started by defining vision. What do we want in the end? What do we need to get there? Why do we need that product in the end? What kind of constraints, resources, time, maybe money? Because you don't get resources if you don't pay for them. How much are we going to try to get done? And you notice here, rough, coarse-grained requirements, this is high-level stuff, not detailed stuff. And then based on that high-level, coarse-grained definition of scope, we need a high-level estimate. How long do we think it'll take to fulfill the vision? How many releases of functional results will we produce as we go that will then ultimately fit together to fulfill the vision?

0:33:40 SB: And that needs to be expressed succinctly. Think about it as an elevator speech, six components in that statement. Who are we doing this for? What do they need? What are we calling what we're working on? What are the benefits of it? What makes it different from what we've got? And what makes it different from other things we might have? For the engineering group who struggles to maintain all their research data, EngDat is a data warehousing system that simplifies managing data. Unlike their current simple file system, this product will tag their data for future retrieval. Who are we doing it for? The engineering group. What's their problem? They struggle with maintaining their research data. How are we going to solve that problem with this product? Its benefit is simplification.

0:35:41 SB: It's different from their current simple file system because it not only simplifies managing their data, but it tags their data so that data's easier to find and retrieve in the future. We develop this vision statement collaboratively with the team and the product owner. And then we need to figure out what's needed, what the requirements are, and those requirements are going to be basic user stories. And those user stories describe what the users need and INVEST is a technique for doing that. Stories need to be independent. I need to be able to see how I might implement this requirement separate from, independent of other requirements. Now, that's not always possible but that's what we're shooting for. It needs to be negotiable, which means when it's time to try to implement this story, we need to be able to, as a team, discuss it with the customer and figure out the details of what it takes to implement it.

0:37:42 SB: It needs to have value for the customer, and it needs to be value that can be communicated to the customer so that they can understand its value. And it needs to be estimable. We need to be able to estimate it, so the team needs to be able to look at the story and determine the level of effort it's going to take to get it done. And it needs to be small enough that it can be done in less than a single iteration. And finally, it needs to be testable. In other words, we need to be able to prove that we have, in fact, implemented the story and that the customer has reviewed it and accepted it.

0:39:08 SB: Well, we're going to end up with a whole bunch of user stories and they all can't be the same priority. So, we need to collect all those user stories and then prioritize our backlog. And the way we go about prioritizing the backlog is by looking at those user stories, by engaging our product owner and our team as we do this prioritization. And we need to consider the value of the story to the larger organization or business; the risk, technically, in trying to get it done and we need to consider minimum feature set. Remember our principle, keep it simple. So minimum feature set. You often hear the phrase in Agile -- minimum viable product.

0:40:46 SB: We don't need to do everything. What is the minimum that we can do to deliver something that works for the customer? And then we need to look at the dependencies between stories because try as we might, every user story isn't going to be completely independent. And so, we need to, as we prioritize, consider those dependencies and make sure that prerequisite stories for other features later get done first.

0:41:52 SB: Well, now that we've got a vision, we've got our backlog, we've got it prioritized, what are we going to do in this work iteration? So, the first step is to plan the goal. What do we want to accomplish in the next week, or two, or three, or four depending on the duration of our iterations? Once we've defined our goal, then we're going to select stories that will align with that goal and we're going to begin to break those stories down to identify what needs to be done. And the team's then going to self-select who does what. And those that own each task will estimate the effort in that task, and the team will then look to try to balance workload among themselves if they need to, to the extent they need to.

0:43:21 SB: Well, your iteration goal states what you want from this iteration. By the time we finish this work cycle, users should be able to enter and manage class information. That's our goal. Now we go to our backlog. What stories support that? And of those stories that support it, we want our high-priority stories in there, but we also want some of those low-priority stories. If everything goes great in the iteration, I don't want to run out of work for the team. The team doesn't want to run out of work. So, the high-priority stories are our focus, but we've got some just-in-case-we-have-time kinds of stories in the iteration as well.

0:44:42 SB: We're going to finalize that plan and we're going to finalize it by making sure that we are set to fulfill our goal, that our stories fit that goal, and that our estimates for all of those stories fit within our iteration, and that we've got a little bit extra just in case. The plan for what to get done in the iteration needs to push us. It needs to be aggressive. It needs to challenge us. It needs to give us enough to do that we can't sit around procrastinating or planning approach to things. Basically, the idea with the iteration plan being aggressive is that we want to avoid Parkinson's law. And bear with me one quick second here. There it is. Getting my text tool.

0:46:29 SB: Parkinson's law basically says work will always expand to fill the available time. Well, if I've got an aggressive plan, then Parkinson's not going to bother us much because there is no extra available time for work to expand into. That's the basic idea here. Now that we've got a plan for the iteration, we need to execute the plan, get the work done, develop the product increment. This is where we break our user stories down into detailed requirements. That's going to mean collaboration with our customer and that collaboration is going to be direct between the customer and the developers, those doing the work. We need to focus on quality. We need to make sure that we take a cross-functional approach and include all of the different disciplines, all of the different perspectives so that what we deliver, not only functions but it functions in production.

0:48:47 SB: And we need to know, establish with the team what done is. And make sure that as the team gets the work done, they meet that criteria. It's not a moving target. It's something we have identified, defined and agreed upon and now we have to meet it. And we're going to hold those daily stand-ups to review our status, to identify obstacles, to plan what's next. In those status stand-up meetings, status is our focus. They need to be short, they need to have a tight agenda and we need to stick to the agenda and stick to the purpose of the meeting.

0:50:02 SB: The team and the coach must be at every stand-up meeting. And often the team and the coach are the only ones that need to be at those stand-up meetings. If we need input from the product owner, if we want to inform or to ask questions of another stakeholder, then they can be there as well but it's a 15-minute meeting and it's focused on these three agenda items: What's been done? What are we going to do now? And what obstacles do we need to get out of the way? And if I face an obstacle then, what I will do today doesn't become this is what I'll do if the obstacle is removed. It becomes this is what I'm going to do while the obstacle is being removed.

0:51:37 SB: Self-directed teams means the coach is not assigning and directing the work of the team. The coach is enabling the team to figure it out for themselves to self-select work, to collaborate among themselves, and to then drive the accomplishment of what has been identified within each work increment. You notice the parenthetical note here, which usually involves command-and-control style of leadership, that's referencing traditional project management and traditional project teams. Servant leadership, servant-style leadership and collaborative engagement is what we want on our Agile teams. Servant-style leadership, hide levels of collaboration is what enables self-directed teams to be effective. And so, we've got the contrast here.

0:53:19 SB: Leader plans -- maybe with input from the team -- and dictates the plan to the team versus the team plans collaboratively with one another and the leader. Members select versus being assigned work to do. Members collaborate and share tasks versus the leader doing load balancing among members. Members report status among themselves, which rolls up to the leader, who then communicates back down to the team and out to the rest of the organization versus a bottom-up kind of reporting where the leader is always the point of contact for the rest of the management chain. And then when we need change, we need to fix problems. The team figures out together how to make that happen versus being told what to do from the leader. We keep track of our progress on our task board or Scrum board.

0:55:18 SB: The stuff we haven't addressed yet in our backlog, what we're working on, what things that we have selected are currently blocked and we're still trying to move that obstacle out of the way. What we've done but are waiting to prove, verify. And then what has been accomplished. When the iteration is, we need to do a review. And that's a review of the product and the team's involved, the customer's involved, the product owner is going to be involved. The team shows the product to the customer. The customer then evaluates it for whether or not it meets their need, it meets the requirement they had and they accept the product when it meets that requirement and need.

0:56:51 SB: And when it doesn't, they then identify what the shortcoming is and what needs to happen to make it acceptable. But part of this iteration review is also what we normally refer to as lessons learned. We need to look at what we did during that iteration and what worked, what didn't and what could be improved. And we're going to capture that and then that becomes input to planning the next iteration. So Agile aligns nicely with the idea of continuous improvement. We're doing short periods of work, we're identifying our strengths, our weaknesses, our growth edges out of each iteration and applying what we've learned in the next iteration so that we don't repeat our mistakes and we're getting better as we go. That review meeting has an agenda and is relatively short just like the stand-up, an hour or two.

0:58:36 SB: The team, the coach and the product owner are required attendees. The customer and other stakeholders can also be involved. And the agenda to demonstrate that each story selected was implemented. And to get feedback on how those stories were implemented, whether or not they meet the need, whether or not they are acceptable, to capture any additional information from that evolving understanding of what we want. And then if we need to do some kind of acceptance testing afterwards, that may be addressed and included as well.

0:59:41 SB: To get acceptance, if it's accepted, it goes to complete. If it's accepted but needs a little tweaking, polishing, it still goes to complete, but we create a new user story and add it to the backlog for those tweaks. If it's acceptable but it's made us realize there are other things that we wish we had, then it moves to complete and new user stories are created to address those ideas. If it's acceptable and we have gone beyond with a new user story then obviously, it moves to complete and the new story goes into the backlog. If, however, the story is rejected, we didn't quite hit the bulls-eye, then we work to rewrite the user story to better reflect what the customer needs and we put it back in the backlog. And so, you'll notice the pattern here, the story is rejected because what the story addressed turns out not to be something we really need, we delete it, and we add a new story to the backlog to back out that increment.

1:01:52 SB: And once we've done all of those adjustments to our backlog, we then reprioritize the backlog. And that's how we're adapting to change. We keep track of our pace of accomplishment through determination of velocity which is really how much have we done. This is the pace at which we plan to get things done. This is the pace at which we've done them so far. Overall, we track against our burn down chart. Our trend is the dotted line, our actual, the solid line. So, don't worry about the story points or ideal days, those are ways that we estimate our effort. And so, we're tracking burn down against total story points, or total ideal days over each iteration as we go. The reviews, retrospectives happen in between each iteration, not just at the end of the project.

1:03:40 SB: And they consider whether or not the lessons learned that we have applied have helped or hurt or made no difference at all. How we can adjust our practices or procedures, whether or not our estimates need to be revisited and refined and we need to consider how well we are collaborating and whether or not the team is communicating both effectively and efficiently as they work together. And change comes from all over the place. Most change is going to be driven by the team or the product owner. Now, the product owner is going to become aware of changes through changes in business conditions or priorities or needs and will then be the one who communicates those changes into the project via the backlog.

1:05:12 SB: The availability of the kind of resources we need is going to affect the team's ability to do the work. And those changes will also then be reflected through new estimates, revised estimates, revised stories, et cetera in our backlog, and in changes to the pace of our work. But because of our short work cycles, we're able then to accommodate these changes as we go through the project. And so, we adapt to change as we move from iteration to iteration to the next iteration. But we have to work within our limitations, and we do that by adjusting requirements, features and by focusing on the team's ability to be as productive as possible.

1:06:39 SB: The coach, the Scrum master removing those obstacles that interfere with team effort and reduce team productivity. And that's pretty much your overview of Agile project management and what's involved in it. Pragmatic approach, flexible approach, so that we can adapt to change throughout the project as both the team and the customer learn more and more over time. Thank you very much for your time and attention. I have enjoyed talking about Agile with you today.