What is Agile?

Agile project management is a method of project management that focuses on taking small, iterative
actions to complete tasks. Short-term development cycles are used to complete the incremental
elements of a project. Instead of top-down administration and sticking to a defined strategy, the
approach emphasises speedy delivery, adaptability, and cooperation.

Continuous feedback is provided in Agile procedures, allowing team members to respond to

difficulties as they arise and stakeholders to communicate regularly. The Agile technique, which was
originally developed for software development, is now widely employed in the execution of a wide
range of projects and in the management of companies.

Compare this to more standard project management methods. In most cases, traditional project
management follows a linear path. After the previous stage is completed, the next step is moved on
to planning, designing, implementing, and closing.
Planning, Monitoring and Adapting:
Agile Planning Stages:

1. Product Vision – [revised once a year] a document created by product owner describing
what the product is, who will and why use it, and how the product supports company
strategy
2. Product Roadmap – [revised twice a year] a document created by product owner describing
the high-level product requirements, timeframes for deliverables, prioritization and
estimations, it is a visual overview of all the releases and major components
 can be in the form of story maps – a diagram indicating the sequences of
backbone, walking skeleton and optional features to be released over time
 then the features to be release in the 1st, 2nd, 3rd, etc. releases can be
mapped out
3. Release Plan – [revised twice / four times a year] a document created by product owner
describing the high-level timeline for product releases (features with higher values are given
higher priority in the releases)
4. Sprint Plan / Iteration Plan – [revised once a month / an iteration] a document created by
product owner, scrum master and development team describing sprint goals and
requirements and how those requirements will be completed
5. Daily Stand-up / Daily Scrum – [daily for 15 minutes] a meeting to be attended by project
team and stakeholders to discuss on what was completed yesterday, what will be done
today, and any roadblocks found
6. Sprint Review – [monthly, at least an hour, for scrum] a meeting at the end of each sprint to
demonstrate the working product/deliverable to stakeholders for feedback/acceptance
7. Sprint Retrospective – [monthly, at least an hour, for scrum] a meeting at the end of each
sprint to discuss on product and process improvements, at least one area is picked to focus
on continuous improvement

Agile Monitoring:

1. Unlike the “monitoring and control” of traditional project management to avoid deviation
from the plan, Agile monitoring is more about inspection for values and processes for the
project, every release, every sprint and every day
2. Agile monitoring involves Agile metrics/measurements, variances, and burn-up and burn-
down charts, change management, forecasting, continuous improvements, retrospectives,
quality control, frequent validation and verifications and other related activities

Agile Adapting:

1. Agile adapting is essentially making changes to the project, product and processes for
implementing changes which customers value most
2. Agile adapting involves process tailoring, continuous integration, adaptive leadership, soft
skills negotiations, delivering business value, revised vendor management, change
management

Planning, Monitoring, And Adapting knowledge includes retrospectives, task/Kanban boards,

timeboxing, iteration and release planning, WIP limits, burn-down/up charts, cumulative flow
diagrams and process tailoring.
Retrospective:

 an Agile process for self-evaluation (like a “post-mortem” meeting or “lessons learned”

meeting in traditional project management) by the Agile development team only to analyse,
adapt and improve the entire Agile development performance – a learning opportunity for
the Agile team and the project
 improve productivity, capability, quality and capacity
 lessons learned are to be implemented by the Agile team right in the next iteration for
instant improvements – a continuous process improvement for timely implementation
 to be performed at the end of each iteration (usually once per month, or every week or two)
with all development team members only for up to 1 hour
 focus on what went well, what went wrong and how the team can improve in next iteration
and beyond without finger-pointing
 set the stage – get people comfortable to speak and outline the topics for discussion
 check-in – everyone expresses in 1 or 2 words about the expectation of the
retrospective
 focus on / focus off – which side to focus on (e.g., dialogue vs debate)
 ESVP – choose 1 from among “explorers, shoppers, vacationers and prisoners” that
describes their feeling anonymously
 working agreements – work on different topics in small groups first
 gather data
 generate insights
 decide what to do – identify the high priority items to devise an action plan
 close the retrospective – express appreciation and feelings
 Plus / Delta – what should be done more / what should be changed
 Helped, Hindered, Hypothesis – three flip charts for participants to add ideas on
 the chosen improvement stories will be put in the non-functional backlog to be carried out
by the whole team to improve Agile processes
 support the growth of the self-directed team for enhanced performance
 Retrospective Meeting vs Review Meeting
 Retrospective meeting is for the development team only with the primary aim for
process improvement
 Review meeting is for demonstration / getting acceptance of deliverables with
management, product owner and stakeholders, backlog item(s) may be identified for the
next iteration
 Retrospective Meeting vs Lessons Learned Meeting
 Retrospective meeting is carried out once per iteration and identifies one area for
improvement
 Lessons Learned meeting is carried out at the end of the project / phrase as the project
closure activity and all the lessons learned are to be identified and documented
(according to PMBOK® Guide)

Task / Kanban Boards:

 Kanban literally means “visual signals”

 Kanban Boards are boards placed in highly visible location with vital project information on
project progress displayed, acting as an information radiator
 adapted from the Lean Manufacturing Process and as a by-product of just-in-time (JIT)
process
  the development states (e.g., Backlog, Analysis, Development, Test, Deploy, Done) would be
identified as columns on the board with units of shippable products written on color-coded
index cards to be put in various stages of the development
 each index card would need to go from “Backlog” all the way to “Done” (called “flow”)
 the emphasis is continuous development (i.e., flow)
 Kanban is a pull-based system where team members “pull” the work from the backlog
 WIP Limits
 WIP means “Work in Progress” – a work that has been started but not yet reach “done”
 WIP should be limited because
 WIP represents investments but no value has been achieved yet
 WIP represents risks in the form of potential rework as the work has not been
accepted
 WIP represents bottlenecks / inefficiencies in processes, etc.
 WIP Limits are used in Kanban to limit the number of performing work in order to optimize
the flow, once the WIP limit has been reached, no more new tasks are to be added to the
‘state’ and the team will work together to move current tasks forward
 WIP = 5 means the team can only allow 5 tasks for a state (however the WIP limit should not
be too low to realize the benefits)
 aim to achieve efficiency through focusing on a limited number of tasks so that the team will
work together as a whole to move the WIP onto completion
 can be used to identify and clear bottlenecks and manage expectations
 Little’s Law – the cycle time is proportional to the size of queue (WIP)
 cycle time – the time required to wait for the benefits
 more time is needed if the WIP is larger

Cumulative Flow Diagram (CFD)

 used in Kanban to visualizes and identify trends and bottlenecks / waste of the project
 plot the features (completed, WIP and total) against time
 visualize the Little’s Law in the WIP portion
 CFD can be plotted in more details by plotting the activities completed by individuals / teams
 the slope indicates the rate of progress
 a declining slope indicates bottleneck (below the widening band)

Theory of Constrains (TOC)

 changes to most of the variables in an organization usually have only small impacts on global
performance
 need to find out the few variables that bring about significant changes
 question 3 of daily stand up / daily Scrum addresses this theory by asking for any roadblocks
that impediment progress

Time-boxing

 Time-boxing is a concept for time management by treating time as fixed blocks

 once the allotted time is up, the work must be stopped regardless of the progress
 with fixed start time, fixed end time and fixed duration for the activity to control the risk
and progress – the control in the chaos
 focuses on the essentials and reduces wastes
 especially suit to projects with high unknown factors
  e.g., fixed iteration review demo sessions (usually once a week) in XP marks the end of the
iteration, architectural spikes, daily stand-ups, etc.

Release Planning

 release planning is the meeting to plan the project schedule at a strategic level for delivering
an increment of product value to the customers (can be date driven or feature driven)
 consists of multiple iterations
 make use of team velocity and story maps (group user stories into backbone, walking
skeleton and additional elements) to plan the release

Iteration Planning

 is the meeting to plan and commit which user stories / backlog (usually with highest priority)
to be turned into potentially shippable working software for the iteration based on the
velocity of the team
 iteration 0 is the work before the actual development work begins
 technical and architectural setup
 gathering initial requirements into the backlog, etc.
 iteration H is the hardening iteration to test and prepare the software for launch
 Steps of the Iteration Planning meeting
 Customer to pick product backlog items with highest priority (or the team to select
backlog items from among the release backlog thru discussion with customer – the
Product Owner has the final say in Scrum)
 Development Team to determine the tasks needed (as sprint backlog in Scrum)
 Team Members to choose the tasks through self-organization and estimate the time
needed to compete the tasks (select the tasks themselves)
 Repeat until the capacities of all Team Members are full
 Typical Agenda for Iteration Planning
 Opening
 Product Vision and Roadmap
 Development status, state of architecture, results of previous iterations
 Iteration name and theme
 Velocity in previous iterations / estimated velocity
 Iteration time-box (dates, working days)
 Team capacity
 Issues and concerns
 Review and update definition of Done
 Stories / items from the backlog to consider
 Tasking out
 New issues and concerns
 Dependencies and assumptions
 Commit
 Communication and logistics plan
 Parking Lot
 Action Items / Plan
 Retrospect the meeting
 Closing
 Iteration Planning vs Release Planning
  Iteration planning involves schedule development at lower/detail level about tasks and
time
 Release planning involves schedule development at high level about features and
iterations

Burn down Chart

 a graphical representation of “work remaining” vs “time remaining”

 make project events (e.g., fluctuating team velocity, new stories added, etc.) visible for
expectation management
 a major way to report Agile metrics
 a burn-down chart show:
 How much work has been done?
 How much work remains?
 The team’s velocity (the slope of the chart)

Burn up Chart

 a graphical representation of “work finished” vs “time remaining”

 a line at the top indicating the project scope (the level can be changed when work is added /
removed)
 burn up vs burn down chart: burn down chart is simpler than burn up chart; yet if the project
scope is evolving, burn up chart can offer a more realistic view of the progress of the project
(scope changes/creeps are hidden in the burn down chart)
 may use of Cumulative Flow Diagram to also show the WIP in addition to the total scope and
work done shown by burn up charts

Process Tailoring

 amend the Agile methodology to better fit the project environment since every project is
different in terms of team size, nature, resources, criticality, etc.
 e.g., at the end of each iteration, review meetings will be done to understand what can be
improved by doing things differently. We can try to implement the changes in the next
iteration to test.
 Kanban is tailoring-friendly while Scrum is not
 as a rule of thumb, it is recommended to implement the Agile methodologies out-of-the-box
for the first few iterations before making changes / process tailoring so that the values of
standard Agile methods are better understood before making changes.
 relationship between different processes for Agile methodologies must be thoroughly
understood before attempting to make changes

Shu-Ha-Ri model (by Alistar Cockburn) – originates from Japanese Noh theatre

 Obeying the rules (Shu)

 Consciously moving away from the rules (Ha)
 Unconsciously finding an individual path (Ri)
Agile Estimation

Agile estimation is about evaluating the effort required to complete each work item listed in the
prioritized backlog, which, in turn, helps improve sprint planning. Estimates can be hard to grasp.
How should a company know the amount of time it will take to complete a product backlog item so
far in advance? How can they account for unforeseen impediments that arise? This is where Agile
estimation techniques come to the rescue.

From Agile project cost estimations to how long it will take to deliver, estimations are part of the
daily grind. The project is likely to go off track without accurate estimations in terms of budget and
time.

If a business does not spend time conducting accurate estimations, their product would get delayed
exponentially, which, in turn, can increase the chances of them getting outcompeted.

A rule of thumb for making accurate estimations is to put effort into strategizing around the right
Agile estimation techniques rather than making random guesses. Therefore, familiarizing themselves
with agile story estimation techniques should be a top priority of a business looking to develop a
new product. 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.

Why Run Agile Estimations?

Agile estimations are essential for:

 Making teams accountable for deliverables

 Inducing discipline across the Agile team
 Predicting the approximate time, it will take to finish a project
 Enabling better sprint management
 Improving team productivity
7 Steps of Agile System Analysis Process
1. Identify System Users

This is the most important question. If you miss with users, you will build the wrong solution. All
further analyses will rely on defined user roles, so be very careful with this first step.

Typical questions:

 Who will use the system?

2. Define Main Users Goals

Each user in the system has specific goals. One user role will use system not very frequently to solve
just a few problems, while another user role will use system about 2 hours per day and resolve many
complex problems. Why will user use this system? What problems will it solve?

Typical questions:

 What I (as a user ___) want to achieve with help of the system?

3. Define System Usage Patterns

Each user has common behavioural patterns. For example, Manager comes at work and start
checking yesterday results. Or Frequent Flyer wants to optimize travel expenses for the next month.
Or Salesperson having a call with existing unhappy customer. Or Resource Manager handles requests
on additional developers for 3 projects simultaneously. All these are typical usage patterns. This is
the best starting point for functional solution. You clearly see the real problems, you understand
them well, you have all you need to be creative and invent simple, effective and elegant solution.

Typical questions:

 What are the typical user behaviours (daily, specific situations, etc.)?

4. Invent Functional Solution to Meet Users Goals and Usage Patterns

This is just a logical continuation of previous step, but maybe the most complex step. Here you think
how to solve exact problem, discuss the solution, jump to steps 5-6, refine the solution, write down
it and move to the next usage pattern.

Typical questions:

 What is the best way to satisfy usage pattern?

5. Define Main Navigation Paths

This and next steps usually performed together with step 4. Usually, it is hard to invent great
solution without tracking user paths and sketching some UI (User Interface) areas. In fact, it is better
to stay off UI as far as you can. In discussions replace all phrases like “Then User clicks Leads link in
the top menu and sees leads list” with “Then User sees leads list.” Concentrate on information user
need on each step, not on links and clicks. Good navigation path looks like this:

User:

 Quickly add new lead into the system

 See leads list
  Find leads added yesterday
 See additional details for each yesterday lead

There is no UI in the list above, just information.

Typical questions:

 What functional areas/action should user execute to complete usage pattern?

 How many areas required to complete user goal in specific pattern?

6. Create UI Mock-ups

UI mock-ups are great to have a quick look at possible users/system interaction. Dashboard sketches
are perfect. Forget about cool tools like Visio, Dreamweaver or any other UI prototyping tool.
Dashboard sketches are the fastest, easiest and exciting thing to work with. You will group around
dashboard with markers in hands and discuss where to place system settings link with great
enthusiasm. Everyone can draw with a marker, but it is just not possible with computer. With marker
in hand everyone feels that s/he can improve this UI and bring in cool ideas. Here is the place where
team spirit rises! Draw UI sketch, take a photo on digital camera and put all photos in a single shared
space.

7. Polish UI Elements

There is always a possibility to make things better, to improve something here and there. It is a good
attitude. You should think about UI details of most important features that will be implemented right
after the project start. But be careful, don’t spend much time on UI perfection, likely it will change
during development anyway. And never polish UI for features that will be implemented in 3+
months ahead of current date, with great possibility it will be a waste of time.

Typical questions:

 Can we improve UI to reduce clicks, provide better visibility, etc?

Agile and Soft skills negotiation

Key soft skills negotiation qualities for the effective implementation and practice of agile are
emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution,
servant leadership. 

Soft skills negotiation:

 Emotional intelligence: Having a high emotional intelligence means self-awareness, control

over your own emotions, and being attentive to other team members’ emotions. A high
emotional intelligence allows team members to collaborate effectively.
 Collaboration: Collaboration is a key soft skill negotiation skill. It involves working in groups
to create ideas, solve problems, and produce solutions. Pair programming is an effective
method for improving team collaboration.
 Adaptive leadership: Being agile includes focusing on cornerstones of agile project
management, like incremental delivery, continuous integration, and adapting to changing
requirements. Doing agile includes several activities that an agile leader must do less; speed-
to-value, quality, and engage and inspire.
  Negotiation: Key soft skills negotiation qualities for the effective implementation and
practice of agile are emotional intelligence, collaboration, adaptive leadership, negotiation,
conflict resolution, servant leadership.
 Conflict resolution: Conflicts are unavoidable in the project environment. Conflict resolution
must not focus on personalities and past events. The people who are in conflict are first
responsible for resolving it. Conflict resolution is a key soft skill negotiation skill. It involves
applying proper leadership techniques to resolve and diffuse any conflict between team
members or other stakeholders.
 Servant leadership: Servant leader is an expected leadership style from Scrum master. In
high performance teams, leaders manage the principles and principles manage the teams.

Agile Approach to Quality:

Value-based Prioritization in Agile
Prioritizing can be defined as determining the order and separating what must be done now, from
what needs to be done later.

Scrum uses Value-based Prioritization as one of the core principles that drives the structure and
functionality of the entire Scrum framework. It benefits projects through adaptability and iterative
development of the product or service. More significantly, Scrum aims at delivering a valuable
product or service to the customer on an early and continuous basis.

Once the Product Owner has received the business requirements from the customer and written
these down in the form of workable User Stories, he or she works with the customer and sponsor to
understand which business requirements provide maximum business value. The Product Owner
must understand what the customer wants and values in order to arrange the Prioritized Product
Backlog Items (User Stories) by relative importance. Sometimes, a customer may mandate all User
Stories to be of high priority. While this might be true, even a list of high-priority User Stories needs
to be prioritized within the list itself. Prioritizing a backlog involves determining the criticality of each
User Story. High-value requirements are identified and moved to the top of the Prioritized Product
Backlog. The processes in which the principle of Value-based Prioritization is put into practice are
Create Prioritized Product Backlog and Groom Prioritized Product Backlog.

Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks
and uncertainty as they may have negative consequences associated with them. This should be
considered while prioritizing User Stories on a value-based approach (refer to the Risk chapter for
more information). The Scrum Team also alerts the Product Owner of any dependencies that arise
out of implementation. These dependencies must be considered during prioritization. Prioritization
may be based on a subjective estimate of the projected business value or profitability, or it can be
based on results and analysis of the market using tools including, but not limited to, customer
interviews, surveys, and financial models and analytical techniques.

The Product Owner must translate the inputs and needs of the project stakeholders to create the
Prioritized Product Backlog. Hence, while prioritizing the User Stories in the Prioritized Product
Backlog, the following three factors are considered: -

1. Value

2. Risk or uncertainty

3. Dependencies

Thus, prioritization results in deliverable’s that satisfies the requirements of the customer with the
objective of delivering the maximum business value in the least amount of time.
Risk Management in Agile
A risk is defined as any factor that could impact outcome of a project positively or negatively and risk
management is the practice of identifying them and taking precautionary steps to manage them

In traditional software development methodology, risk management is an important process,

especially in planning function. However, when it comes to Agile there is a common stereotype that
an Agile project is totally unplanned and risk management is not applicable. However, this is far from
correct. Poor risk management is the major contributor to the failure of any project and hence risk
must be managed in a project, irrespective of the software development methodology.

The main difference is that in agile projects, risk management is done throughout the project
lifecycle as opposed to traditional models where a major portion of risk management is done
upfront.

In Agile projects, the team must be trained in the risk management and build-in focus on thinking
about risks in all the Agile/Scrum ceremonies:

1.Product Backlog - Product owner need to consider risk as a consideration for prioritizing user
stories and breaking down the ones over a certain size into smaller stories

2. Sprint planning - Team can only accept the work they are confident about delivering

Below are the ways and approaches to incorporate risk monitoring and control in Agile projects:

3. Daily stand-up meeting - This can become a forum of raising issues and risks as the team can think
about the question on what is blocking or likely to block their planned deliverable

4. Sprint Reviews – Regular product demos ensures less risk of delivering the wrong product. In
Sprint reviews, stakeholders can be informed of possible blockers and opportunity to highlight
mitigation activities

5. Sprint retrospective – Focus on what can be done better, and the idea of continual improvement
will ensure risks are unveiled

In general, risk management in an Agile approach offers more mitigation options than traditional
waterfall model:

1. Schedule variation which generally is the biggest risk in projects is managed in Agile by way of
having feedback loops

2. Frequent changes in requirements or scope creep is an integral part of the agile scrum process
and the changes go into product backlog for prioritization
3. Team and customer are synchronized on the need and constant exposure to customer minimizes
the risk of not building the product to the need