What 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.