Agile Project Management
Posted by Brad EgelandWhat does Agile Project Management mean to you? Wikipedia doesn’t truly define it – it creates a definition from the concept of Agile Software Development stating that it then applies the practice to management in general. Let’s look at the definition of Agile Software Development then.
Wikipedia defines Agile Software Development as a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Ok…that last statement is lofty, but if you can hit that target, not too much can go wrong. In general, though, I’d like to focus on the concept of following an iterative process where the requirements and solutions evolve through collaboration. I can buy into this. I’ve never managed a project where the initially stated customer requirements are exactly what the final product turned out to be. The Project Manager, as well as the customer team and sponsor, must remain open to change to the original scope as it best fits the project and the intended solution and many times those changes come with impact to timeframe, schedule, resources and cost/budget.
Sprint Planning
One concept sometimes applied to agile project management is the idea of organizing your project plan into a series of ‘sprints.’ What this means is the tasks of the project plan are divided into a series of common-length time periods – often two weeks in duration. Everything is planned around what is to be accomplished in each sprint.
At the start of each sprint, the team gathers briefly and plans for exactly what will be accomplished in the sprint. Each member – on both sides (customer and delivery) is aware of what is expected of them in the current sprint and looking at the schedule in these series of two week events helps everyone to focus and remain on a tighter schedule with specific accountability.
Daily Focus
Often, with this method, daily meetings are incorporated while the formal weekly status meeting is abandoned. I believe in continuing accountability to a weekly formal status report complete with issues, risks, and budget information so the customer and the delivery team has formal status information documented and in front of them on a weekly basis while they are working heads-down on the current sprint tasks.
Formal Reviews
At the end of each sprint, a formal review – thus basically replacing the weekly formal status meeting or call – is held to go over each task of the sprint and the status of each task is presented by the assigned resource who owns that task. The concept is basically to break the tasks into these short bursts so that the team manages itself and owns the tasks at a more detailed level. With the focus being on shorter bursts of task activity, it’s easier for the non-PM participants to see the impacts of their efforts, self-manage their work, and be accountable for it without the extreme risk of running far off schedule, budget or both.
Summary
I’ve personally only used this method once and it was focused on corrective action on a project that had gone south and I was called in to help get things back on track. I can’t speak to its use over the long haul of a project. I still prefer the more traditional practices of project management, but I could definitely see this being a useful process – especially with the proper makeup of resources and project tasks.
As always, I’d like to hear your feedback – especially if you have significant experience with what you would refer to as agile project management. Let me know what has worked for you.
Related posts:
Ferrix Hovi says:
When I close my eyes, I can hear the roar of a giant waterfall. As a scrum practitioner, I feel there is little justification for a project manager role doing the specified things.
First of all, teams should be self-organizing and direct customer contact is encouraged. In sprint planning, I see no point of having a role called a project manager anywhere near. Accountability comes with the commitment, no project manager there either. Also, the two week sprint is a bit short according to my experience. It is enough to make big and efficient changes and short enough to be dynamic.
In daily scrum, only team members are allowed to talk. Anyone can come though, as long as they shut up. Most people are not interested in seeing that. During the sprint the team is accountable only to themselves. Peer pressure is actually more efficient than a superior making sure everything gets done. Information is shared through the scrum of scrums. A memo is usually sent to all scrums so that everyone has the rough idea of progress.
The most important part of sprint review is the informal retrospective where the team looks back and evaluates their progress and decides on new things to try. After that, the customer should be available for demo and planning. Going through all tasks is hardly ever necessary because they have been discussed in the dailies. A demo to the customer is usually more efficient. The tasks undone are a different thing though.
I am offended whenever I am referred to as a resource where the word person could be appropriate. Respect is baked into agile methods, hence people should be treated as people and even more: adults. Empowering people makes them responsible and accountability is automatic.
If you ask me to place project managers into scrum, I won’t know. Product owners or scrum masters, maybe. The truth is that there are fewer managers in a working agile environment. Authority and accountability still exist but they come from the developers themselves among themselves.
Donna Burgess says:
I watched a project run without a PM for 4 months, wasting a lot of money, and creating wasteful code. This caused frustration for the customers as well as the developers.
The development manager also couldn’t see a place on the Agile team for a PM.
When I, a PM, was asked to step in, everyone without fail said they felt a sense of relief. This was echoed at the final project retro.
‘Self-managing’ teams still need a leader, a protector, a decision maker, a planner, a shield, a guide, a problem solver. Someone to fight their corner and rally morale when things are going pear-shaped.
Sadly, many Agile evangelists will only understand the value of a PM when they don’t have one. Notably on a large project.
Brad Egeland says:
Donna- I agree with you. I don’t necessarily agree with the Agile approach, but thought it would be interesting to present this angle on it. PM leadership and PM principles still need to be in place, in my opinion. Otherwise, only luck will allow for a successful solution on projects of any significant size. (I’m sure there are others out there who would disagree with that statement, though.)
Luca says:
Agile doesn’t mean no management, means just in time, just enough management. Lack of management is chaos.
PMBOK-style project management though is very well designed for projects like building a bridge, but ignores the realities of software development. Big plan upfront simply DOESN’T WORK in software of any kind of complexities since so many aspects of what’s a success cannot be defined with precision from the beginning.
Most software development success condition is “we’ll know it when we get there”, and in that situation the best thing a PM can do is a LOT of risk management.
Agile is in the end process that focuses on keeping risk low, and allowing you to develop your requirements over time.
It’s TOUGH to do it right, but it’s also the only good way to go about it.