Agile is a good approach to use for many projects, not just in IT. Many marketing teams, for example, are using Agile in their production planning. In this video, Devin Deen gives you an overview of Agile project management in just 3 minutes—after, that is, he offers up the history of the Agile approach. (Okay, so, it’s really more like 8 minutes. Grab some popcorn.)
In Review: Agile Project Management
In this video, Devin talked about the fact that Agile isn’t suitable for all projects. It works best where:
- Users don’t know exactly what they want;
- There are variable and changing priorities;
- You have a cross-functional team who can work well together; and
- The team is co-located (although this isn’t essential).
Devin explained the roots of Agile project management and some of the major terminology including:
- Story: the use case that describes what the deliverables will do for the user;
- Backlog: the set of requirements;
- Sprint: the time-boxed effort where you focus your work on delivering the prioritized requirements;
- Scrum: the team of people working on the project; and
- Burndown chart: a way of tracking progress against the tasks planned for that sprint.
During the execution stages of an Agile project Devin explained that the Scrum team get together for a daily Scrum meeting to discuss the work plan for the day, what they achieved yesterday and what they plan to do tomorrow. This is normally written up on a board.
At the end of the sprint, Devin explained that you hold a sprint review to demonstrate the functionality delivered in that sprint.
Pro Tip: Agile project management teams rely on good communication and teamwork for fast response times and efficient delivery. Good collaboration tools can speed tasks and help your team work better together.
Thanks for watching!
Hi. I’m Devin Deen, Content Director here at projectmanager.com. Hi. In today’s whiteboard session, I’m going to cover Agile project management in about 180 seconds, so let’s get stuck in.
Now, first thing you need to know is that Agile project management is not an approach for every single project. It’s only good for projects where the end user may not know exactly what they want. You have kind of also the constant variable changing priorities and you have access to a cross functional team of people who can collaboratively work together at the same time, ideally co-located. If you’ve got those ingredients, then you certainly have everything, at least at the starting point where you might want to try and approach the project using Agile project management.
Now, Agile project management came about in 1986-ish, a couple of Japanese fellows by the name of Nanaka and Takeuchi, studying the manufacturing process and the supply chain in restaurants oddly enough, came up with the idea that a rugby team type project team approach was the best way to get those projects delivered. The metaphor was that you have a rugby team who takes the ball across the line, passing it back and forth until they get against the try line. When they observed and studied projects that had that cross-functional project team working together to get that project across, they found that they had a higher degree of success rate than, let’s say, a bunch of individuals working asynchronously to achieve that same objective with that project.
Ten years later in the United States, a couple of fellows by the name of Sutherland and Schwab presented a paper on that topic on what they call the rugby method, but Sutherland and Schwab renamed that and called that Agile project management and that was delivered in Texas. I think it was a Business Objects Conference (Editor’s note: it was called the OOPSLA Business Object Design and Implementation Workshop and was held in Fort Worth, Texas in 1995).
Now, what you need to know about Agile project management is your project is organized into a story of backlog and task. The story is the use case, it’s what you want to achieve out of that particular project, the overall project might be, for example, an e-commerce website and, just following my train of thought, the story would be wanting your customer to be able to log in a series of shirts or clothes and purchase them through your e-commerce website. That’s your story. That’s your use case.
The backlog is the set of requirements that go into filling up that story. You might say a user in Idaho can access your website, that’s a requirement, or they can pay with a credit card, a Visa card or a MasterCard or their own personal banking card or do a fast check, a direct deposit to pay for that. That’s part of your backlog. The list of requirements that sort of comprise your story is what’s called your backlog.
Your project team, when they get together, they look at that backlog, they then decompose the backlog or the requirements into different tasks and those are quite simply tasks, so that’s easy enough. When you’re trying to achieve the story, you get your list of backlogs and you organize the achievement or the production of that backlog into what’s called a sprint. They’re time-boxed sort of mini projects if you will anywhere between a week to probably four weeks. Four weeks is your absolute maximum and one week is your absolute minimum. Anywhere between one to four weeks, you’ll time box your effort, you’ll time box what you’re going to deliver in those requirements in your backlog and that’s called your sprint.
Your project team, your cross-functional team is organized into what’s called a scrum. The scrum is a collection of people who get together in that particular sprint. They’re locked ideally in the same area working together to achieve your backlog. Sprint planning is a meeting that you have half a day with your end users. You go over the story, you take them through the list of backlog and you get them to prioritize the requirements or the functionality that they want you to deliver in that particular sprint. It’s really important that the users own that prioritized as a backlog. That’s the first half of the day.
The second half of the day, you bring your scrum together, get them to look into the backlog, get your scrum to sign up to which of those items on the backlog they can actually deliver in your period of time, in your sprint time frame. Let’s say you’re going to do a sprint in 21 days. Get your project team together, get that scrum together and they’ll look at the backlog and they’ll say, “Yeah, we can do this one. Yeah, we can do this one. We can get the functionality so they can drag that shirt into their shopping basket. We can get the functionality to actually make that credit card payment.” They’re the ones who are signing off on which items in their backlog they’re actually going to deliver.
When you’re in execution, you have a scrum meeting. Those happen everyday, generally in the morning, no longer than five minutes across your cross-functional team. Three things that team members talk about, they talk about what they did yesterday, they talk about what they’re going to do today, and they’re talking about what they’re going to do tomorrow. A lot of Agile project managers put the list of task that need to be accomplished on a board somewhere, organized by person or organized by functionality. It’s really up to you about how you organize that, but it’s important that the team keeps a constant focus on what they’re doing and they’re thinking about what they need to achieve, what might go in their way. In that scrum meeting, that’s when they sort of talk about obstacles and who can help whom and they do that coordination.
A sprint review is the demo that you have at the end of the sprint. It’s what you’re actually showing to your end users, demonstrating the number of items in that backlog that you’re actually able to achieve in that particular sprint. A sprint retrospective is at the end of that sprint, after you do your sprint review meeting, you get the scrum together, you talk about what you did well, you talk about what you didn’t do so well and then you also look at that backlog of items. It’s assumed that you won’t be able to achieve all the backlog, so those backlog items that you didn’t achieve in that particular sprint go into the next sprint and they form the starting task of your next sprint.
Now, how do you manage this as a project manager? How do you manage these sprints? Do you just turn up everyday at the sprint meeting and make sure nobody gets into fisticuffs? Let them go for it and just assume the team’s going to achieve what they said they’re going to achieve? No, you don’t do that. There are ways to track, manage and monitor and control that sprint once it’s on the way. The most popular way to do it is using what’s called a burn down chart.
Let me just quickly describe this burn down chart for you. Burn down chart is really easy. It’s the number of days on your sprint on the bottom. In this case, zero to 21 days. On the left-hand side, we’ve got the total number of hours in effort required to achieve that backlog and that’s based on the task that the scrum has put together and then again on the right-hand side, we’ve got the list of tasks. These are the tasks that the scrum when they look at the backlog, they broke that backlog into different tasks and you had a quantity of task, in this case, 30 tasks.
For this particular sprint of 21 days, I’ve got about 300 hours worth of effort to achieve a backlog that I’ve agreed across 30 different tasks. On a day by day basis, as a project manager, you need to be recording how much effort has been expended by that scrum and how many tasks they’ve completed. What you should be seeing along the way in your sprint is that the list of hours obviously left to go sort of whittled down. You start at 300 hours in your hopper and you basically subtract the number of hours per day the team is working and you’re also counting down the number of task left to do to achieve the backlog.
Depending upon where they get is an indication of how successful that scrum work together in that particular sprint. Along the way, if you’re seeing lots of issues crop up, certainly as a project manager, take control, get in there, make some suggestions on how to clear up those problems or maybe it’s an indication that you need to revise your sprint and think about which items need to go in that backlog and manage your stakeholders’ expectations.
This is just a top level view about Agile project management. Certainly, after this whiteboard session, don’t go out there and say you’re an Agile expert. Go out there and read the material from Schwaber and from Sutherland or Takeuchi and Nanaka. Read up on the Agile project management method. There are many different flavors depending upon if you’re doing project development or software development. Pick the one that works for you, but most of all get out there and try it. Give it a go.
For more project management whiteboard sessions and all your project manager needs, come see us at ProjectManager.com.