Agile Project Management

What Is Agile Project Management?

Agile is new norm of the industry and everyone in the tech industry is moving to agile. These set of tutorials and templates will help a scrum master or project manager to adopt agile. Agile is a methodology for the management of software project development. In contrast to a traditional sequential approach to software development, Agile focuses on the development of a series of incremental iterations of the product, each of which is functional and potentially can be deployed.

 

Agile projects typically involve small teams working in short bursts, with each of the bursts followed by a review process with the client stakeholders hence Agile is different from Waterfall model in a few ways.

Agile And Scrum

• The Agile approach is only a philosophy of development and does not, in itself, provide a specific, detailed framework for project management.

• The Scrum framework is a specific set of organizational structures, methods, and procedures that allows the Agile philosophy to be applied to projects.

• Scrum clearly defines roles of team members and lays out a concrete plan for both the work of the team and the interaction between team and client.

• Scrum includes three participant roles: Product Owner, Scrum Master, and Team.

• The Product Owner is the liaison between the development team and the other client stakeholders. This role is responsible for communicating project goals and requirements to the team and is involved in the process throughout the project.

• The Scrum Master facilitates communication between the Product Owner and the Team and ensures that the Team has what it needs to get its job done.

• The Scrum Master is responsible for stakeholder management, in that he or she ensures that the goals set by stakeholders are achievable by the Team.

• The Team consists of a small group developers that works independently, managing its own processes and organization.

• Scrum meetings are the essential part of the agile culture. 

Roles And Responsibilities In An Agile Scrum Project

Agile project management is not just another buzzword, and it’s not a superficial paradigm shift teams should make simply for the sake of doing so. Rather, agile project management allows for maximum productivity throughout a project’s lifespan, and keeps teams working to their highest potential at all times keeping project documentation to minimum.

Agile Project Team Members

Of the many differences between traditional and agile project management, perhaps most obvious are the shift in responsibilities members of the development team have in the completion of projects.

This section will describe the responsibilities of each of the following team members:

• Product Owners

• Scrum Masters

• Development Team

Keep in mind that, while each of these individuals or groups of workers have their own set of responsibilities, agile project management dictates they interact with each other throughout the process.

Product Owner

• In a traditional setting, Product Owners would generally provide information upfront to a development team, then allow them to take over entirely and is the owner of product backlog.

• The next time the Product Owner became involved would be after the project was completed.

• With agile project development, the Product Owner stays in touch with the rest of the team throughout the entire process.

• He provides frequent feedback regarding how the project being built matches his vision, and provides insight into what his overall goal for creating the product is.

• In doing so, he helps the team prioritize features and functions, allowing them to focus on what’s most important.

• Product Owners should no longer expect to hire development teams to take complete control of a project. Of course, this might not be so easy to swallow for Product Owners who are used to throwing money at a problem until someone else solves it.

• However, Product Owners need to understand that the new way is much less of a gamble than traditional project development. By becoming more involved in development, they’re much less likely to be unpleasantly surprised by a shoddy final product.

• Since the Product Owner is much more involved in the process of agile project management, he must be able to:

• Communicate his vision effectively
• Manage priorities according to his mission
• Make informed decisions on the fly

ScrumMaster

• Though it sounds like some sort of rugby-karate hybrid title, the ScrumMaster is simply an agile project manager (specifically relating to Scrum project management - a subset of agile).

• Unlike in traditional project management(Waterfall model), the ScrumMaster is less of a boss and more of a leader.

• Rather than providing his team members with explicit instructions as if from a movie script - and then micromanaging them throughout the process - the ScrumMaster gives his team an overview of the agile project at hand, then allows them to take control.

• He will conduct daily meetings with his team to discuss progress, changes, and surprises - and work with the other members to create a tentative plan for the next steps.

The ScrumMaster cannot simply sit back and ask his team to “tell him when they’re finished.” Instead, he must:

The ScrumMaster is most likely a former “boss” who has been looking for a way to manage his team more effectively but hasn’t been sure of the best way to do so. With an open mind and proper training, the right leader can become a top-notch ScrumMaster and lead his team to true success.

The Project Team

• In traditional project management, the team was essentially nothing more than worker bees doing their bidding for the queen (or boss, if you will).

• Though members of the team are still responsible for the “on-the-ground” work relating to projects, agile project management provides them with much more autonomy and freedom to complete tasks in the most efficient ways possible.

• Rather than being given specific roles by a boss-like figure, agile project teams communicate with each other to decide who is best-suited for each task that needs be done.

• In turn, team members take ownership of their work, knowing not only that their team members are relying on them, but also that they have been voted the best person for the job.

In addition to being able to complete their specified tasks efficiently, members of agile project managed teams also need to be able to:

For most developers, becoming members of an agile team is a dream come true. Rather than having to robotically go through the motions day in, day out - only to see their “boss” get credit for a job well done - agile team members can approach each project prepared to do their best work possible.

Agile vs Waterfall Differences

The Waterfall and Agile models for software development project management each offer advantages and disadvantages, and the best model for a given project depends on project goals, client priorities, and the strengths of the project manager and team. The differences in the models' structures lead to some significant differences in the way the projects run and the kind of final products they produce.

 

Basics

• The Waterfall model lays out a rigid plan for the project, beginning with conception and moving through design, construction, testing, and deployment.

• Int the Waterfall model requirements for the final product are clearly and inflexibly set during the conception phase, and each successive phase of the project must be completed before work can begin on the next phase.

• The Agile model moves through a series of iterations of the product, with testing and client approval being a part of each iteration using a product backlog.

• At the conclusion of each iteration, project goals are reassessed, and new goals are incorporated into the next iteration or sprint of the agile project.

Flexibility

• The Agile project management model is, by design, more flexible than the Waterfall model.

• Agile project goals can be adjusted during each iteration, and the project can more easily adapt to unforeseen challenges and opportunities.

• Waterfall projects do not allow for goal adjustments during the process, and unexpected obstacles can threaten the success of the entire project.

Client Involvement

• Agile and Waterfall projects differ considerably in the extent and timing of client involvement.

• In general, Agile projects require much more client involvement throughout the project than do Waterfall projects.

• With Waterfall project management, the client is involved during the conception stage of the project but need not be involved again until the deployment phase.

• In an Agile project, the client is involved throughout the process. This gives the client a measure of control through the entire process, but it also gives rise to the potential for unexpected revisions of the project plans, which can lead to schedule overruns and new obstacles.

Team Involvement

• Agile project teams are typically small, and team members are often versatile in their skill sets.

• Team members are also typically involved with the project throughout its duration. Waterfall project team members may only be involved with the project during the distinct phase for which they are responsible, allowing them to work on other projects when their involvement is not required.

Speed Of Deployment

• Because Agile projects are tested and approved at each iteration, there's the possibility that an acceptable version of the product could be deployed relatively early in the process.

• Waterfall projects are deployed only at the end of the process, and there is no room for schedule flexibility.

Project Coherence

• The Waterfall model creates an extremely well-defined project process, with a beginning, middle and end, as well as a clearly marked path for getting from one end to the other and a clearly delineated picture of what the final product will look like.

• An Agile project, because it may be developed in discreet stages, has a tendency to be less coherent.

• As the project moves through successive iterations, project goals may change, and the final product may end up looking substantially different from the initial conception.

• While often an advantage of the model, this lack of a clear pathway also brings the danger of schedule overruns and discreet project components that do not work well together.

The two models lie at either end of a spectrum with predictability at one end and flexibility at the other. The correct model to choose for a given project depends on where on the spectrum the project's priorities fall.