Agile Project Management Key Graph

Features or Deliverables: As a Project Management method, Agile focuses on delivering Features or Deliverables as often as possible. As part of the definition, the Deliverable must be Completed, Tested, Debugged and Usable. Iterations: Core to any Agile method are Iterations. Iterations are fixed-length periods of time, of 1 to 4 weeks (usually 2) during which we try to accomplish a list of things or deliver certain features. The idea behind iterations is to give the team a short term objective that creates both a sense of emergency and a feeling of accomplishment once it is completed an addictive cocktail. Shortterm, achievable objectives help to keep morale high. Releases: Releases are a part of the Grander Scheme of things. A release usually consists of a few iterations, where many Features or Deliverables are sent to the client or put into production. Stories: Agile is highly customer-driven. Therefore, features are usually translated into User-Stories. A Story explains how a feature is to be used and gives it context. A proper way to write Stories is to start by: As a User I want to have access to my data online

As a Client I want to have a billboard printed in Times Square Backlog: The Product Backlog regroups all the remaining Stories for a given project. The Product Backlog is meant to be properly maintained and prioritized. Once an Iteration is completed, stories are selected from the Backlog, based on Priorities and are sent to the new Iteration. Prioritization: There are many ways to organize the Backlog: Business Value, Point value and relative Importance are the most frequently used systems. Business Value indicates the $ value of releasing a particular Story, Point Value is an indicator of the relative difficulty of delivering the feature and Importance is a measure of how critical a feature is to the overall project. Put together, these indicators allow for a Cost/benefit analysis that facilitate the Prioritization process. Agile Roles: There are 4 typical roles in Agile. Product Owner, Project Manager, Worker and Stakeholder. The Stakeholder is usually the instigator of the project or the investor. The Product Owner is the Stakeholders representative. He is in charge of prioritizing the Backlog and Writing the Stories. The Project Manager (or Scrum Master in the Scrum method) is a facilitator to the team. He organizes the team, removes impediments, oversees the process, manages the Sprint backlog and the overall progress of the project. The Workers are the ones getting things done. They estimate the stories in points and the tasks in hours. If the stories are estimated to be too big for a sprint, they can request the stories to be broken down by the Product Owner. Sprints: The Sprint is the name given to the current Iteration the workers are involved in. Cross-functional teams:

In Agile, teams are meant to be cross-functional. Here are a few examples: Software: Website: Marketing: Hardware: SEO: Developper, Tester, UI dev, Designer Copy Writer, Developer, Designer, Content Manager PR, Designer, Copy, Event Manager. Engineer, Industrial Designer, Tester, Supply manager Copy writer, On-site Optimizer, Backlinker, SEM manager.

Self-Organization: Teams are asked to organize themselves by creating the tasks related to the stories and estimating them, whether it be by Estimated Hours or Value Points. They subsequently assign tasks among each other and launch the iteration. PMBOK vs Agile: In Project Management, there are always 3 aspects that are considered: Budget, Scope and deadline. In traditional Project management, the Scope is fixed and Budget and deadline may vary. In Agile, the Deadline is fixed, but the budget and Scope may vary. Essentially Agile allows you to adapt to changing priorities and to prioritize what has the most value. Benefits of Agile. Quicker Time-to-Market Reduced Risk by Managing Uncertainty Increased reactivity to changing priorities Superior Productivity & Software Quality Healthier Customer-relationship Better Team Morale

In essence, Agile is NOT that different from traditional Project Management. It just builds on it and improves elements that were found to be inefficient or problematic, such as managing risk and dealing with changing priorities.

Difference between Agile and Normal Project Management PMBOK vs Agile: In Project Management, there are always 3 aspects that are considered: Budget, Scope and deadline. In traditional Project management, the Scope is fixed and Budget and deadline may vary. In Agile, the Deadline is fixed, but the budget and Scope may vary. Essentially Agile allows you to adapt to changing priorities and to prioritize what has the most value.

A fundamental difference between agile project planning and traditional project planning is that agile project planning is very collaborative in nature: the team is responsible for planning, not just the project manager. People should choose their work, they shouldn't be assigned it

Why Agile Programming?

Agile programming gives teams repeated opportunities to assess the direction of a project throughout the entire development lifecycle. These chances for evaluation are built into the natural workflow of agile programming through regular cadences of work, known as sprints or iterations. At the end of every sprint, the team presents a functioning piece of software to the Product Owner for review. This emphasis on a shippable product ensures that the team doesnt get bogged down with gathering

requirements. Because sprints repeat and the product continually adds increments of functionality, agile programming is described as iterative and incremental. In waterfall, development teams have a single shot at getting each part of a project right. Not so in agile programming, in which every aspect of development is revisited throughout the lifecycle. Theres virtually no chance that a project will follow the wrong direction for very long. Because the team reassesses the direction of a project regularly, theres always time to change course. Perhaps the effects of this inspect-and-adapt strategy are obvious: Namely, they significantly reduce both development costs and time to market. Because teams can gather requirements while coding, exhaustive requirements gathering cant prevent a team from making progress. And because agile teams develop within the short, repeatable work cycles, stakeholders have ongoing opportunities to ensure that the product being created matches the customers vision. In essence, it could be said that agile programming helps companies build products their customers want. Instead of committing to market a piece of unwritten, sub-optimized software, agile programming empowers teams to build the best software possible. In the end, agile programming protects a products market relevance and prevents a teams work from winding up on a shelf, unreleased, which is an option that makes both stakeholders and developers happy.

many times, when a waterfall project wraps, a team that built software based on customer specifications finds out that its not actually what the customer wanted

. If youre a developer, then you know that its infinitely easier for a customer to describe his or her vision when there is functional software to interact with and respond to.

But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didnt provide the concrete processes that development teams depend on when deadlines and stakeholders start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and Ive found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders