Agile Project Management
From MIKE2.0 Methodology
-> You are here: Agile Project Management
This article on Agile Project Management explains
Big-bang, Waterfall-based projects typically culminate in a go-live or system activation date. As such, they require a great deal of:
Because of their iterative natures and as a general rule, however, Agile projects initially require lesser levels of each one. That is, design et. al are still important, but not nearly to the same extent as they are on Waterfall-based projects.
Old school project planning tools such as Microsoft Office are typically inadequate for Agile projects. Because a great deal of testing is taking place on very specific product features, speed and rapid deployment are paramount. No one wants to wait for a shared spreadsheet or static project management tool to be updated.
Rather, to be successful and support the overall goals of the project, Agile project management tools need to provide:
Managing Agile Project Teams
At a core level, managing Agile project teams is about three things:
To at least some extent, many Agile projects consist of throwing things against the wall to see if they'll stick. As a result, some degree of failure is to be expected and must be tolerated. (Of course, this is the trade-off with rapid deployment and end users' ability to "touch" the product sooner than under Waterfall-based methods).
Organizational culture and trust are paramount here. When people are crucified for making unforeseeable mistakes, they become unlikely to effectively utilize Agile frameworks and tools in the future. This defeats the purpose of Agile methods. While outright incompetence should not be tolerated, the benefits of Agile approaches hinge upon increased speed and decreased development and design times. In short, expect more failure but also expect to learn more from it.
Estimation, Scope, and Quality Management
Irrespective of software development methods, it is never easy to pinpoint the amount of time, number and type of resources, and budget required to successfully deploy a new application. Estimation can be quantified to some extent, most experienced and intelligent folks believe that estimates and approximations cannot be viewed with precision--especially before commencing such projects.
Scope is another key component here. A project's resources (both financial and human) typically increase exponentially. For example, doubling the scope of a project rarely if ever doubles the number of resources required. It may in fact cause a 400 percent increase in each. As projects develop, however, it becomes easier for people to refine their estimates around dates, resources, and budgets.
Like other software development and IM projects, scope is often a tricky animal. For example, to pay one employee or book one new sales account typically requires a great deal of work. Paying a second employee and booking a second account requires much less work. In fact, at some point, the marginal cost and effort of each gradually moves to zero. That is, it takes very little cost and effort to pay the thousandth employee or match the 500th invoice. This is the norm for these types of projects.
Quality management should also become more apparent as the product or project matures. Worrying about quality from day one might be a recipe for disaster. Remember that perfection cannot be expected as iterations propagate and tweaks are made. Refinements after core functionality is introduced can shore up quality, although "steps backward" can be expected because of newly discovered issues. Again, this is one of the drawbacks of Agile methods.
This article is a part of the 'Agile Business Transformation 'article.
Wiki asset search