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 methodology 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.
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 ecommerce 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 ecommerce 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.
Autor José Angel Pérez
¿Alguna inquietud? Escríbeme a mi correo electrónico.
Contáctame en mis Redes Sociales. 
