Unit -5 Agile Project Management

Predictive Versus Empirical Management

One can look at processes as predictive or empirical. In a predictive model we can define a stable
process However, as volatility increases our predictions loose value.

In a process with much volatility we have an empirical process. To control an empirical process one
would use a form of empirical model of process control.

The empirical model of process control provides and exercises control through frequent inspection and
adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable
outputs.

The empirical model of process control is constituted of three parts: visibility, inspection, and
adaptation.

1. Visibility: transparency or visibility means that any aspects of the process that affects the outcome
must be visible and known to everybody involved in the project process. The collection of those
involved with the project is referred to as stakeholders.

2. Inspection: inspection requires that various aspects of the process be inspected frequently enough so
that unacceptable variances in the process can be detected.

3. Adaptation: adaptation requires that the inspector should adjust the process if one or more aspects of
the process are in an unacceptable range

One of the big areas of volatility in software development is requirements. This one area alone tends to
push a project from one where you can use a predictive model of process control to one that requires an
empirical model of process control.

An interesting study, "Influence of Process Models on Requirement Volatility, and Strategies for its
Management", was done on the relationship of software development model to requirements volatility.

It is an interesting read. It shows that agile methods tend to handle requirements volatility better than
other methods. If you Google Agile you will see the empirical model of process control discussed along
with three key elements.

Comparison between Non Agile and Agile Project:

Compare Non-Agile and Agile Project Methodology.

What are non-agile and agile software development methodologies?"

Non-agile:
Non-agile, also known as the Waterfall or linear, is a traditional method for creating software. It splits
the software development lifecycle (SDLC) into 6 different stages where you tackle challenges one
stage at the time. You can only proceed to the next stage when the current stage is 100% done.

These are the usual stages:

Planning

Requirements

System and software design

Implementation

Testing

Deployment

Maintenance/Updates

Due to its rigid structure, older software developers tend to call this methodology a "plan-driven
process".

To successfully use the Waterfall methodology, you need to have a clear plan when certain things are
done, how they are done, and of course - why they are done.

The Waterfall works best for bigger teams that have clear goals, requirements, and a solid
understanding of the scope of the work that needs to be done before and after the initial kick-off.

Agile:

Agile is an incremental, iterative approach to software development. Unlike the Waterfall approach that
has a rigid structure and demands that you complete your product one phase at a time, agile is a lot
more loose and open to changes.

This methodology revolves around the idea of breaking down project requirements into smaller bits of
user functionalities, which are called "user stories". These are then prioritized and delivered
continuously in short cycles which are called "iterations".

Absolute customer satisfaction is always the end goal of the agile approach. This means that the focus
of each iteration should be built around the idea of providing a higher quality solution for the customer.

In order for the agile approach to actually bring results, cross-functional teams work in so-called
"sprints" of 2 weeks to 2 months. The goal of every sprint is to build usable software which they can
give to the customers to test. Once the customer provides feedback, the devs take the comments to
mind and use them to develop a plan for the future iteration of the product. The work is organized into
a backlog that is prioritized based on business or customer value.

Unlike the Waterfall methodology which is a reliable "by the book" process filed with concrete steps
and phases, agile is more about being light on your feet and moving fast, releasing usable products as
often as possible, and responding to actual customer needs. Everything revolves around effective
leadership, teamwork, accountability, and quick face-to-face communication.
Working in agile means that you frequently have to pivot and go against your initial plan. That's why
making a full list of requirements and a complete SOW before starting work is often a huge waste of
time.

In agile, you learn on the go and frequently "tweak" your plan in accordance with what the business
stakeholders and customers are saying. That's why retaining as much flexibility as possible throughout
the development cycle is very important in agile.

Depending on the project and team that's in charge of the development, this can be both an advantage
and disadvantage.

Because reprioritizing tasks is a big part of agile. Keeping track of all the delivery dates and making
sure that the team completes everything that you agreed with a client can easily become your worst
nightmare.

If you're constantly changing the priority of specific activities and adding additional sprints, it's quite
possible that certain things will be lost in the noise. Since agile is so flexible, implementing frequent
iterations based on the evolving customer feedback can lead to the delivery of a significantly different
product than initially agreed with the client.

With the Waterfall, things are quite different. First of all, progress is easily measured because the full
scope of the work is known in advance. Even though the management part is easier with the Waterfall
approach since everything is done "by the book" based on quality documentation, this model also has
its disadvantages.

Lack of flexibility is the biggest downside of this approach. Because The Waterfall is a sequential
model, you can't bounce between phases and introduce changes whenever you want. Only when you're
truly done with a specific phase can you go back and tweak what needs to be tweaked.

Without a sufficient plan and a strong, data-driven business case, using non-agile methodologies can
backfire. For example, end users might not react to the product as expected once it gets launched.

If the documentation was wrong and the product turns out to be not competitive enough, the client will
certainly ask for revisions and require additional work. Alas, fixing the problem at such a late stage will
require additional time and unplanned project expenses.

Non-Agile or Agile: How to Choose the Right Methodology?

Since we made it clear that both non-agile and agile methodologies are two quite different processes
that are used in different organizations for different types of products, there is a number of factors that
developers consider before opting for one of these models:

Plan and documentation

Project scope and size

Business environment

The need for creativity and innovation

Team size and capabilities Available resources (costs, time frames, etc.)
This might be a good time to underline the fact that none of the two methodologies is per se better than
the other one.

Generally, the agile model works better where there are a lot of uncertainties at play. Naturally, in these
cases, the development approach needs to provide flexibility and enable a lot of 'testing on the go' in
order to create a valuable product, i.e. a product which addresses the exact pain points it was intended
for.

The non-agile model works well for situations where the budget is tight and so is the schedule. Here,
there is not much room or need for creativity and innovation. Predictability of costs is a priority.

Three Fundamental Stages of Agile Project:

Stage 1: Prioritization of the project purposes

This is the initial part of the work, when the development team, project, and product managers come
together and make work planning. All the professionals decide how the project will look, write user
stories about the features of the project that should be added to its structure and functionality.

It is necessary to use the following methods during this stage of work:

Work planning begins with a proper allocation of roles in the development process: it is necessary to
make sure every team member is responsible for a certain area where he is absolutely well-grounded
and has enough experience.

In order to build a consistent workflow without any problems and loses, use different prioritizing
techniques and calculate the importance and necessity of every feature you would like to implement
into the work.

it is unnecessary to plan the entire work at once long-term Agile planning is possible, but it is not so
important to practice it with each project. Calculate your project activities and tasks for the initial sprint
and follow your plan.

Stage 2: Development and technical iterations

There is the main and the most essential part of the Agile methodology project development: a team of
developers, QA engineers, designers, in the lead of a project manager, creates the internal and external
components of the project and checks and tests them all. Every iteration (or sprint) has its special
needs, goals and proposed results, so it is necessary to achieve them in order to meet a project schedule.

There you do not need to make something unique - you should not make some typical mistakes, as
follows:

it is useless to run over schedule - it may seem strange but it is so. Even if you have done your work
scope earlier than it is expected, it does not make any sense because the project development is like a
united system where every process depends on each other. But if you are always in perfect timing, you
can help your colleague with his work!

Do not forget about the project documentation writing! Agile really appreciate turnkey projects which
are easy to be monitored and supported in future, so do not ignore such a part of the development.
Stage 3: Product releases

When the project has its certain completed part that can function by itself, it is the time to make a
release. The whole team and all the specialists and stakeholders. involved in the project creation,
present their product to the customers and tell them how it works.

During this stage, the main thing is to make everything on time and not to miss all the necessary
requirements of the project received from the customer. Indeed, the company is waiting for their
completed product - and they definitely want to see it as the dream comes true. So do not get your
customers down with their expectations

Estimation in Agile
Q. What is Estimation in Agile?

Agile estimation is the process for estimating the effort required to complete a prioritized task in the
product backlog. This effort is usually measured with respect to the time it will take to complete that
task, which, in turn, leads to accurate sprint planning.

What is a Sprint? A sprint is a time-boxed interval that defines the time allocated to complete a task.

Note: No matter how accurately a business estimates the effort required completing a user story in
Agile, an estimate is still an estimate. Do not strive to achieve perfect accuracy because requirements
can change at any time. There are also agile anti patterns and other emerging realities that change the
course of development.

Agile teams also make estimations with reference to story points. A story point is used in Agile
Development projects to estimate the difficulty of implementing a given user story. This is measured in
relative units assigned to different user stories that require estimation.

In a nutshell, a story point is a number that helps estimate the difficulty of building a user story
successfully. This difficulty could be anything related to the complexities, risks, and efforts involved.
Agile project estimation also helps to build strong coordination. If project X is dependent on project Y,
agile project estimation provides an overview of the wait time.

Q. Why Run Agile Estimations?

Agile estimations are essential for:

1. Making teams accountable for deliverables

2. Inducing discipline across the Agile team

3. Predicting the approximate time it will take to finish a project

4. Enabling better sprint management

5. Improving team productivity

Q. Why do Teams Estimate in Agile?

Overestimating and underestimating are both common for Agile development teams which leads to
varying development and launch times.

Though the process is complicated, considering Agile estimation in the initial stages can assist with
accurate user story estimations and helps the team stick to the timely deliverables.

Some of the to-the-point benefits of Agile Estimation

Techniques include:

1. Improved Decision-Making

With accurate, agile estimation, the development team will be able to conduct effective backlog
grooming sessions, which will further help in precise sprint planning. When they make informed
decisions and plan well, their user story delivery time will improve.

2. Better Coordination

Let's say that the estimated effort for user story A is two weeks. On the other hand, the estimation effort
for user story B is four weeks. Now, suppose both the user stories depend on each other and are
connected. In that case, the team needs to prioritize work so that both user stories get completed
simultaneously, thus leading to better coordination among teams.

3. Better Risk Management

Software projects often suffer from exceeding budgets and timelines. To lessen this risk, Agile project
estimation is an ideal solution. Agile product estimation helps estimate story points and stick to
budgets, estimates, and the project's scope. The more accurate the estimates, the better the chances of
on-time, quality delivery.
Agility Principles (Not In Syllabus)
Q. Explain principles of Agile Methodology.

Q. Describe and discuss characteristics of Agile Process Model.

The Manifesto for Agile Software based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development. Working software is delivered

frequently (weeks rather than months).

3. Working software is delivered frequently (weeks rather than months).

4. Close, daily cooperation between business people and developers.

5. Projects are built around motivated individuals, who should be trusted.

6. Face-to-face conversation is the best form of communication (co-location).

7. Working software is the primary measure of progress.

8. Sustainable development, able to maintain a constant pace.

9. Continuous attention to technical excellence and good design.

10. Simplicity is essential.

11. Best architectures, requirements, and designs emerge from self-organizing teams.

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

Advantages of Agile Process

Q. What are Advantages of Agile Processes?

1. Stakeholder Engagement,

2. Transparency,

3. Early and Predictable Delivery,

4. Predictable Costs and Schedule,

5. Allows for Change,

6. Focuses on Business Value,

7. Focuses on Users,

8. Improves Quality
Scope management in agile project
What is the scope?

The scope is a domain activity that the project team will work for. The scope can be divided into two
types-

1. Product scope: the feature and functions that characterize a product, service, or result.

2. Project scope: The work performed to deliver a product, service, or result with the specified
features and functions. The term “project scope” is sometimes viewed as including product scope.

Scope management in Agile

Scope management in Agile is different from traditional waterfall management as Agile flexibly
manage scope while waterfall fixes it. The reason why Agile keeps scope flexible is that it is not easy to
fix all scope at the initiation as the business environment and customer‟s requirements frequently
change in the global age. And, Agile is intrinsically designed to flexibly adjust to uncertain business
requirements with time-fixed iteration (1 to 4 weeks duration) and constant reviews (Sprint Review and
Daily Scrum).

Key Factors

 The scope must be managed flexibly in an Agile project. Resources and time are basically fixed.

 When you change something in the project, remember the first element considered is scope.

 The scope is a living artifact that should be flexible and adjustable to the uncertain business
environment.

Product Scope
In the Agile project, the product scope is defined as the Product Backlog that is an ordered list of
everything that needs to be implemented in the product. The Product Backlog is the core artifact that
keeps evolving as the business environment and product’s requirements change, and all people
involved in the project can see in order to keep transparency in the project.
Input

 Project Charter: the formal document containing comprehensive information about the project.

 Product Vision: Vision of the product describing the purpose and achievement of the product.
Usually incorporated into the project charter.

Output

 Product Backlog: Items describes all features, functions, and services of the product.

Project scope
The project scope is a more comprehensive concept that contains product scope and describes all
activities of what the project team does and does not do. Although the software project is to develop a
software product, the project team occasionally gets involved to other activities such as customer
support or sales activities.

Input

 Enterprise environmental factors

 Project Charter

 Product Vision

 Product Scope

Output

 Project scope document or revised Project charter.

“The Product Owner takes final responsibility for the scope management.”
Roles and Responsibilities of Agile Project Manager
Management expects Agile Project Managers to perform several different roles effectively. We can
break down these roles into three categories: team-level roles, enterprise-level roles, and hybrid Agile
roles.

Team-Level Roles

 Agile Project Managers can assume two distinct roles in the project process.

 Act as a consultant, allocating the right personnel, processes, and resources to bolster team
effectiveness and efficiency.

 Assume the role of a coach, advising team members how to optimize their efficiency within the
project team best.

Enterprise-Level Roles

 This level of roles poses more significant challenges for Agile Project Managers by virtue of their
sheer scope.

 Act as a director, managing multiple Agile teams and integrating their work with activities outside
their scope.

 Assume the role of leader and manager in charge of massive, enterprise-level, complex projects.

Hybrid Agile Roles

 The Hybrid Agile process combines Agile methods with non-Agile techniques, such as the Waterfall
method.

 Create a sound project management approach that fits best in planning and managing the work.
Filling a Hybrid Agile role is challenging, as the APM must factor in the traditional techniques
alongside the Agile methodology.

 Meet the project‟s goals within the designated limitations of the project.

Responsibilities of an Agile Project Manager

It (also called an APM) plans, leads, organizes and motivates Agile project teams. The manager has a
vast range of responsibilities:

 Helping the team achieve a high level of performance and quality, holding teams accountable for
their work, removing obstacles, and mentoring less experienced team members.

 Defining the project‟s schedule and scope while balancing this with timely and regular value
deliveries, and organizing and leading working and project status meetings.

 Delivering Agile projects that offer outstanding business value to the users.
 Supporting the product owner in managing communications with stakeholders, managing
customer‟s expectations for deliverables, and implementing an effective project governance system.

 Promote team empowerment through team-building techniques, ensuring each team member is
making a meaningful contribution and fully engaged in the project.

APMs work strategically with management teams to best define the product‟s epics. Note: an “epic” is
a large piece of work that has a single shared objective. Epics can be a business requirement, customer
request, or a desired feature. Epics often require more than one Sprint to finish.

The Differences between a Traditional Project Manager and an APM

Traditional Project Managers Agile Project Managers

Define the target/objective Create the vision

Aim your resources at the target Initiate the project in a broad direction

Launch the project Adjust and adapt to accommodate change

Hope the target doesn‟t move (e.g., the project

Hit the target incrementally
doesn‟t change)

Scheduling and Tracking

Kanban and Scrum are two frameworks or systems that help teams adhere to Agile principles. Though
they are both different methodologies, there are some similarities between them. They generally work
with three categories: work to be done, work in progress and work that has been completed. This
is where Agile management software can be a real asset for project scheduling. Here are a few general
steps a project manager may take when creating a project schedule:

 Divide the project into workable tasks and define the sprints’ length: An Agile project starts
with a list of features to be implemented and several iterations to implement those features. A
project manager should identify these tasks, priorities them with the help of their team and input
them into the schedule. Each feature will have a timeframe to be mapped to iteration. Each feature
and sprint will also require a status e.g. not started, in progress or completed.
 Add the tasks that should be completed as part of the sprint: Agile management software can
help project managers and their teams view the tasks to be completed and mark them as „done‟
when they‟re ready. Applications like Jira, Trello, Monday Sprints are just a few examples of
Agile management software.

 Define the estimated time for each issue in the sprint: Each section or iteration is reviewed by
the project team, which should include some of the project‟s various stakeholders. Insights gained
from the feedback are used to determine the next steps.

Tracking projects based on Agile Methodology

 Progress Report
The manual progress report makes it possible for the project manager to create a record that
indicates the progress observed (% completed), as well as the evaluation (list of configurable
values), a description, and a date.
This is useful when the progress of the project is not only represented by the consumption of tasks,
but by the achievement of the deliverables of the project.

 Tasks by Type
This chart represents the percentage of tasks in each status present in the project at this time.
The standard status types are 1.“To Do”, 2. “In Progress” and 3. “Completed.” It is independent of
the number of columns that the Agile board has because each column will be based on one of
these three types.

 Tracking Charts/Diagrams

 This section provides two options: Burndown chart and Cumulative Flow diagram (CFD).
 Both share the same filtering block which allows you to customize the displayed information
according to your preferences.

 Burndown Chart
Represents the dynamics of tasks completed.

 Cumulative Flow Diagram (CFD)

A Cumulative Flow diagram is a stacked area chart that shows, in each time interval, the number of
tasks per status.