Agile Project Management Simplified

2013
Jaiveer Singh
7/21/2013
Agile Project Management

www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com
Contents
Traditional vs. Agile Project Management ................................................................................................................3
Agile Philosophy.........................................................................................................................................................4
Agile Manifesto......................................................................................................................................................4
Agile Principles.......................................................................................................................................................4
Principles of System Thinking (Complex Adaptive Systems) ......................................................................................5
Building High Performance Agile...............................................................................................................................5
Emotional Intelligence and its role in project management......................................................................................6
Agile Teams Communication & Collaboration...........................................................................................................7
Servant & Adaptive Leadership Styles .......................................................................................................................8
Introduction to Agile Methodologies.........................................................................................................................9
Scrum.....................................................................................................................................................................9
XP Programming....................................................................................................................................................9
Kanban...................................................................................................................................................................9
Agile Estimations .....................................................................................................................................................10
Relative Sizing, Story Points.................................................................................................................................10
Wide band Delphi Estimation Technique.............................................................................................................11
Planning poker (Scrum poker) Estimation Technique..........................................................................................11
Affinity Estimation Technique..............................................................................................................................11
User Stories..........................................................................................................................................................12
Agile Planning, Monitoring & Adapting...................................................................................................................12
Product in a Box...................................................................................................................................................12
Iteration & Release Planning, Time Boxing..........................................................................................................13
Information Radiators .........................................................................................................................................14
Kanban Board , WIP Limits ..................................................................................................................................14
Cumulative Flow Diagrams, Burn down charts....................................................................................................15
Retrospective .......................................................................................................................................................16
Agile Analysis & Design............................................................................................................................................16
Product Roadmap, Backlogs................................................................................................................................16
Progressive Elaboration.......................................................................................................................................16
Personas ..............................................................................................................................................................17
Product Quality........................................................................................................................................................17
Pair Programming................................................................................................................................................17

Definition of Done................................................................................................................................................17
Continuous Integration........................................................................................................................................18
Agile Management & Development Tools...............................................................................................................18
Agile Management Adoption...................................................................................................................................18

Traditional vs. Agile Project Management
Project management is the discipline of planning, organizing, motivating, and controlling
resources to achieve specific goals. A project is a temporary endeavor with a defined beginning
and end (usually time-constrained, and often constrained by funding or deliverable) undertaken
to meet unique goals and objectives.
A traditional phased approach identifies a sequence of steps to be completed. In the "traditional
approach", five developmental components of a project can be distinguished (four stages plus
control):
Typical development phases of an engineering project
1. initiation
2. planning and design
3. execution and construction
4. monitoring and controlling systems
5. completion
In software development, this approach is often known as the waterfall model, i.e., one series of
tasks after another in linear sequence.
Agile project management approaches based on the principles of human interaction management
are founded on a process view of human collaboration. It is "most typically used in software,
website, technology, creative and marketing industries.” This contrasts sharply with the
traditional approach.
In the agile software development or flexible product development approach, the project is seen
as a series of relatively small tasks conceived and executed as the situation demands in an
adaptive manner, rather than as a completely pre-planned process. It is the most consistent
project management technique since it involves frequent testing of the project under
development.
It is the only technique in which the client will be actively involved in the project development.
But the only disadvantage with this technique is that it should be used only if the client has
enough time to be actively involved in the project every now and then.

Agile Philosophy
Agile Manifesto
The agile manifesto is the most important statement which really pitch forked this methodology to a different level.
It proclaims
“We are uncovering better ways of developing software by doing it and helping others to do it. Through this work
we have come to value”
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
“While there is value in the items on the right, We Value the items on the left more”
Agile Principles
1. Satisfy customer through early and continuous delivery
2. Welcome changing requirements, even late in development
3. Deliver working software frequently
4. Business and developers must work together daily
5. Build projects around motivated individuals
6. Face-to-face conversation is the most efficient and effective method of collaboration
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development
9. Continuous attention to technical excellence and good design enhances agility
10. Maximizing the amount of work not done
11. The best results emerge from self-organizing teams
12. At regular intervals, the team reflects and adjusts its behavior accordingly

Principles of System Thinking (Complex Adaptive Systems)
Systems thinking are a management discipline that concerns an understanding of a system by
examining the linkages and interactions between the components that comprise the entirety of
that defined system. The whole system is a systems thinking view of the complete organisation
in relation to its environment. It provides a means of understanding, analysing and talking about
the design and construction of the organisation as an integrated, complex composition of many
interconnected systems (human and non-human) that need to work together for the whole to
function successfully.
Complex adaptive systems are special cases of complex systems, often defined as a 'complex
macroscopic collection' of relatively 'similar and partially connected micro-structures' – formed
in order to adapt to the changing environment, and increase its survivability as a macro-structure.
They are complex in that they are dynamic networks of interactions, and their relationships are
not aggregations of the individual static entities. They are adaptive; in that the individual and
collective behavior mutate and self-organize corresponding to the change-initiating micro-event
or collection of events.
Building High Performance Agile
A high performance Agile team is a committed team that has the right people, has been
effectively empowered, has established trust, adheres to an effective process, works at a
sustainable pace to deliver quality software of a quantity that reflects a consistent high velocity
and factors in influences like capacity and support.
Agile teams are the building block to any successful agile transformation. Without strong, self-
sustaining agile teams, any change as a result of an agile transformation is very likely temporary.
An agile team (preferably 6-9 team members) is:
• Cross-functional - the team includes all roles necessary to deliver the work (at minimum
Dev and QA), and dependencies outside the team (e.g. UX) are understood and available
as needed
• Dedicated - team members are dedicated, with any non-sprint work transparently tracked
on the task board and the potential impact (decreased priority) agreed with non-sprint
stakeholders
• Co-located (preferably) - defined as sitting in the same space. Where distributed teams
are necessary, ensure strong ties are created through virtual tooling and regular
communication

• Working from a single backlog - the team has a single product backlog, containing
items prioritized by the business and ready for the team to work on, from which to pull
work
• Managing unplanned work - agree with the PO an agreed contingency or bug capacity
to be removed from the sprint; manage this contingency to avoid impacting the sprint
commitment
Three stages of an agile team
Stage 1 - Predictable Delivery
Start by creating a habit of finishing work requests within the team. Many teams or
developers working in a traditional environment quickly lose the habit of finishing a
feature completely, perhaps as a result of silo’d delivery or high interruption levels.
Quickly reintroduce this habit, before focusing on other agile behaviors. Without the
habit of getting to done, a team will never progress.
Stage 2 - Build Quality In
Once a team has the habit of predictable delivery, the team turns their attention to quality.
While learning to deliver predictably, the team has become more and more aware of
technical ownership.
Stage 3 - Sustainable Delivery
Finally, once a team has mastered completing the stories they commit to while building
quality in, they turn their attention to improving throughput. This is a delicate step
because a traditional mindset might set velocity goals to increase productivity. But
velocity is a lagging indicator, telling a team after they have reached a sustainable pace,
rather than a leading indicator telling the team what more needs to be done.
Emotional Intelligence and its role in project management
Many studies have shown that emotional intelligence is a key determinant of success in the workplace.
Working well with people—direct reports, peers, customers and management—is just as crucial to
success. Emotional intelligence may indeed be the reason that some project managers are more skilled at
managing relationships in projects.
Emotional intelligence (EI) is the ability to identify, assess, and control the emotions of oneself, of others,
and of groups.
It is the ability to identify and manage your own emotions and the emotions of others. It is generally said
to include three skills:
1. Emotional awareness, including the ability to identify your own emotions and those of others;

2. The ability to harness emotions and apply them to tasks like thinking and problems solving;
3. The ability to manage emotions, including the ability to regulate your own emotions, and the
ability to cheer up or calm down another person.
Agile Teams Communication & Collaboration
Effective communication is a fundamental requirement for agile modeling. Teams that pair
together stay together.
Face-to-face conversations are the heart and soul of agile projects. Agile meetings provide a
format for communicating in a face-to-face environment. Meetings on agile projects have a
specific purpose and a specific amount of time in order to allow the development team the time
to work, rather than spend time in meetings. Agile artifacts provide a format for written
communication that is structured, but not cumbersome or unnecessary.
The table provides a view of the different communication channels on an agile project.
Agile Project Communication Channels
Channel Type Role in Communication
Project planning,
release planning, and
sprint planning
Meetings Communicate the details of the project, the release, and
the sprint to the scrum team.
Product vision
statement
Artifact Communicates the end goal of the project to the project
team and the organization.
Product roadmap Artifact Communicates a long-term view of the features that
support the product vision and are likely to be part of the
project.
Product backlog Artifact Communicates the scope of the project as a whole to the
project team.
Release plan Artifact Communicates the goals for a specific release.
Sprint backlog Artifact Updated daily, it provides immediate sprint and project
status to anyone who needs that information. The
burndown chart on the sprint backlog provides a quick
visual of the sprint status.
Task board Artifact Visually radiates out status of the current sprint or
release to anyone who walks by the scrum team's work
area.

Daily scrum Meeting Provides the scrum team with a verbal, face-to-face
opportunity to coordinate the priorities of the day and
identify any challenges.
Face-to-face
conversations
Informal The most important mode of communication on an agile
project.
Sprint review Meeting The embodiment of the “show, don't tell” philosophy.
Displaying working product to the entire project team
conveys project progress in a more meaningful way than
a report ever could.
Sprint retrospective Meeting Allows the scrum team to communicate with one another
specifically for improvement.
Meeting notes Informal These are an optional, informal communication method.
Meeting notes can capture action items from a meeting
to ensure people on the scrum team remember them for
later.
Notes from a sprint review can record new features for
the product backlog.
Notes from a sprint retrospective can remind the scrum
team of commitments for improvement.
Collaborative solutions Informal White boards, sticky notes, and electronic collaboration
tools all help the scrum team communicate. Ensure that
these tools augment, rather than replace, face-to-face
conversations.
Servant & Adaptive Leadership Styles
Servant leadership is a philosophy and set of practices that enriches the lives of individuals,
builds better organizations and ultimately creates a more just and caring world. While servant
leadership is a timeless concept, the phrase “servant leadership” was coined by Robert K.
Greenleaf.
A servant-leader focuses primarily on the growth and well-being of people and the communities
to which they belong. While traditional leadership generally involves the accumulation and
exercise of power by one at the “top of the pyramid,” servant leadership is different. The
servant-leader shares power, puts the needs of others first and helps people develop and
perform as highly as possible.

Adaptive LeadershipTM, described by Ron Heifetz in his classic book Leadership Without Easy
Answers, is a set of strategies and practices that can help organizations and the people in them
break through gridlocks, accomplish deep change and develop the adaptability to thrive in
complex, competitive, and challenging environments. Leadership like this can be learned. And
anyone, anywhere within the organization, can do it.
Adaptive leadership recognizes there are basically two kinds of problems that people confuse
when trying to find solutions. First, there are “technical problems” where an adequate response
has been developed; there are one or more experts with general credibility and an established
procedure will suffice. The second kind of problems are “adaptive problems” where there are no
set procedures, no recognized experts, and no adequate responses developed.
When problem definition is not clear cut and technical fixes are unavailable. It calls for adaptive
leadership where the leader does not have the answers. Instead, the leader has to orient people
to their places and roles, control conflict, and establish and maintain norms in order to
orchestrate people working together to find new solutions that will succeed.
Introduction to Agile Methodologies
Scrum
Scrum project management is a software agile development process. Scrum models
allow projects to progress via a series of iterations called agile sprints. Each sprint is typically
two to four weeks, and sprint planning in the agile methodology and Scrum process is essential.
While the agile Scrum methodology can be used for managing any project, the Scrum agile
process is ideally suited for projects with rapidly changing or highly emergent requirements like
software.
The agile sprint itself is the main activity of Scrum project management. The agile methodology
and Scrum process is iterative and incremental, so the project is split into a series of
consecutive sprints. Each is timeboxed, usually to between one week and a calendar month.
XP Programming
Extreme Programming is a discipline of software development based on values of simplicity,
communication, feedback, and courage. It works by bringing the whole team together in the
presence of simple practices, with enough feedback to enable the team to see where they are
and to tune the practices to their unique situation. In Extreme Programming, every contributor to
the project is an integral part of the “Whole Team“. The team forms around a business
representative called “the Customer”, who sits with the team and works with them daily.
Kanban

Kanban is a new technique for managing a software development process in a highly efficient
way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing
software is a creative activity and therefore different to mass-producing cars, the underlying
mechanism for managing the production line can still be applied. In Japanese, the word “Kan”
means "visual" and "ban" means "card," so Kanban refers to visual cards. Lean uses visual
cards as a signaling system that triggers an action to supply the process with its needs either
from an external supplier or from a warehouse.
A software development process can be thought of as a pipeline with feature requests entering
one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad
hoc process to a highly formal phased process. In this article, we'll assume a simple phased
process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.
A pull system is where processes are based on customer demand. The concept is that each
process manufactures each component in line with another department to build a final part to
the exact expectation of delivery from the customer. Because your production process is
designed to produce only what is deliverable, your business becomes leaner as a result of not
holding excessive stock levels of raw, partly-finished, or finished materials.
Just-in-time is a “pull” system of production, so actual orders provide a signal for when a product
should be manufactured. Next stage of software development can pull next batch of work once
they have capacity to process more.
Agile Estimations
There are three main concepts you need to understand to do agile estimation.
1. Estimation of Size gives a high-level estimate for the work item, typically measured using a
neutral unit such as points
2. Velocity tells us how many points this project team can deliver within an iteration;
3. Estimation of Effort translates the size (measured in points) to a detailed estimate of effort
typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how
long it will take the team member(s) to complete the assigned work item(s).
Relative Sizing, Story Points
Relative estimation applies the principle that ‘comparing’ is much quicker and more accurate
than ‘breaking down’. Relative story point estimation is a type of delphi estimation method that
is applied at the product backlog level. In a nutshell, this means that it relies on the simultaneous
input of a cross-functional team to ‘triangulate’ in on a common estimate for a user story, or
other product backlog item.

Unlike traditional estimation units such as ‘ideal days’, the measurement unit utilized during
relative estimation is not time based but rather, size based. Size in this case does not have a direct
relationship to a specific time duration but instead, it is a function of three factors: effort,
complexity and risk.
These sizes are measured in units that we call ‘story points’ and typically, a slightly altered
Fibonacci sequence is used as the point system:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
The reason for using the Fibonacci sequence is to reflect the inherent uncertainty when
estimating larger items.
The team ‘velocity’ metric is then used to determine how many points can be completed on
average per sprint and this value is then applied to the product backlog to determine how long
the entire backlog will take.
Wide band Delphi Estimation Technique
• It is a consensus based estimation approach wherein the team agrees on a final number
after few deliberations
• A moderator is identified. A team of 3-7 good estimators are selected and provide them
the work item to estimate.
• A kickoff meeting is called wherein team first creates work break structure (WBS) of the
tasks/activities involved and discuss the assumptions.
• After which each team member provides their individual estimates separately and a
second meeting is called to arrive at the consensus on the differing items.
• The final number submitted is reviewed by the Project manager and agreed as basis for
baseline plan.
• This method is for detailed effort estimates
Planning poker (Scrum poker) Estimation Technique
• It is a consensus based estimation approach and it is a variant of wide band Delphi
• After a moderator or Product manager explains the story, the team discusses the
assumptions or risks and gets clarifications
• They select a number from a deck of cards given to them and simultaneously turn up their
number to indicate their number.
• People with the lower and higher estimates are given a soap box to offer their estimation.
• The discussion continues until consensus is reached
• This method avoid anchorage by the influential members of the team
Affinity Estimation Technique
Affinity Estimating is a technique many Agile teams use to quickly and easily estimate a large
number of user stories in story points.

• This is a great technique if you’re just starting a project and have a backlog that hasn’t
been estimated yet, or in preparation for release planning.
• In this technique stories are read out to the whole team and then the team is asked to
arrange the stories on horizontally on a wall in order of size, without talking.
• Present a set of reference stories the team has done in the past, i.e. good examples of a
point 1, 2, 3, 5, 8, etc. stories.
• It is a high level estimating technique
User Stories
In agile development, the user story is a lightweight and more nimble substitute for what has
been our traditional means of specifying software requirements - software requirements
specifications, use case specifications, and the like.
Indeed, an argument can be made that the user story is the most important artifact in agile
development, because it is the container that primarily carries the value stream to the user and
agile development is all about rapid value delivery.
User Story
• A High-level definition of a requirement, containing enough information for estimation
and implementation.
• Focus on “What” not on “How”
• Well-written user story to follow INVEST
(Independent, Negotiable, Valuable, Estimable, Small, Testable) model.
Mike Cohn suggests a more formal approach to writing user stories. He suggests the format:
As a (role) I want (something) so that (benefit). Formal
• Theme: Theme is collection of User stories
• Epic: Epics are larger user stories, typically ones which are too big to implement in a
single iteration and therefore they need to be disaggregated into smaller user stories at
some point.
Agile Planning, Monitoring & Adapting
Product in a Box

Before you begin, focus on the end. In this exercise, teams create the physical “box” that sells
their idea—whether that idea will ultimately become a tangible product or not. By imagining the
package for their idea, the teams make decisions about important features and other aspects of
their vision that are more difficult to articulate.
This game is popular among software developers when setting out to capture the customer’s
view of a new application, but its use doesn’t stop there. The game can help facilitate any vision-
oriented discussion, and has been used to describe topics ranging from “our future methodology”
to “the ideal hire.”
Iteration & Release Planning, Time Boxing
Product Roadmap
It is a high level understanding of the increments (themes) that you're going to take on in the next few
releases to accomplish those strategies. These themes are very high level (giving you plenty of room to
react to what you learn along the way). It gives your customers a feel for what you're about and where
you're going.
Release Planning
Release planning is all about understanding what you're going to do towards those themes in the next
release. It is setting a common understanding amongst the teams on what the release will likely look like.
It is not a commitment, rather a projection. It helps to establish a common baseline across the teams.
Iteration Planning
This is the first level where you actually commit (at the team level). You plan out what you're going to
accomplish in the next iteration (a matter of weeks). You get a clear understanding on what done is
(acceptance criteria).
Daily Stand-up
This is the level at which individuals commit to what they're going to get done in the next day. It helps to
ensure that the team is communicating. It encourages collaboration and highlights issues which are
blocking the team.
Time boxing

• The time boxing is the method where the time is fixed for an iteration, say 1-4 weeks and the
story points /stories will be fitted into the iteration based on the velocity of the team or capacity to
deliver.
• The time boxing duration is decided by the stage of the project and the type of the project and the
experience of the team.
• The thumb rule is to fix one week as the iteration during the beginning so that team will slowly
pickup speed and once after 2-3 iterations when velocity is stable, switch to a typical 2-3 weeks
mode.
• Time boxing applies for release also and it varies from 1-3 months in duration.
• Fundamentally, it is designed to establish a sense of urgency and coerce the team to focus their
effort on getting something done.
Information Radiators
Information radiator
• Information Radiator is popular term invented by Alistair Cockburn.
• It is publicly posted displays that shows anyone walking about an idea of what’s going on in the
team. It will be mostly the Big visible charts, Graphs, Release/Iteration plans or “stick it” index or
story cards.
• What information needs to be displayed is entirely up to the project team and they also decide
how often this information need to be tracked or updated.
• Information radiator are also good ways to remind team of critical items, risks, issues that need to
be addressed.
Kanban Board , WIP Limits
Task/Kanban boards
• Kanban is a scheduling system that helps to determine what to produce, when to produce and how
much produce.
• A new card is “pulled” into the system only when “in progress” card is complete.
• This will give a clear idea of where the bottleneck is their in an iteration if the WIP items/cards
are getting increased.
WIP limits

• One of the goal in agile process is to reduce Work in progress (WIP) items as much as possible in
an iteration so that wastage and bottlenecks are avoided. WIP limit is a way of eliminating
bottlenecks and the subsequent wastage/issues.
• This is applicable to a task/story in an iteration
• WIP limit does not allow more cards into a development queue unless there is a capacity to limit
the WIP of stories. Typical limit is 2-3 cards
• Some agile processes in manufacturing like Just in time (JIT) will strive to reduce WIP as low as
possible so that wastage is eliminated e.g. Toyota
Cumulative Flow Diagrams, Burn down charts
Cumulative Flow Diagram – CFD
A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a
product, version, or sprint. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates
cards (issues). Each coloured area of the chart equates to a workflow status (i.e. a column on your board).
A CFD can be useful for identifying bottlenecks. If your chart contains an area that is widening vertically
over time, the column that equates to the widening area will generally be a bottleneck.
Burn down Charts
• Burn-down chart tracks how much work remains on the project against the iteration.
• At the end of each iteration mark the progress and you can project forward to see whether or not
you’ll hit your target end date
• A sudden increase or decrease in the number of story points in a graph is clear indication that
customer requirement changed.
Burn down Charts
• Burn-up chart tracks how much work is done.
• It shows more information than burn-down chart as it indicates a line showing how much work in
the project is planned.
• In Burn-up chart bottom line is the work done and top line is the scope.

Retrospective
Retrospectives
• This is a post iteration demo/review meeting to discuss and understand what went right, wrong
and needs improvement in an iteration/sprint on each story
• It is a lessons learnt meeting to understand the issues, analyze root cause and to learn from that.
The idea is to come up with proper preventive measures in future
• This session also helps to understand any changes in scope during the iteration (any stories
added/modified or deleted from the list) and what is the impact of that on the system and future
iterations.
• Without the participation from all team members, Preparation and commitment the retrospective
will not be successful
Agile Analysis & Design
Product Roadmap, Backlogs
In general the product roadmap is a long term business planning and communication tool, however in
agile world it is used in short term product planning perspective, but it is still required. It is usually
maintained by Agile Product managers
In roadmap the approximate release dates are calculated based on the product backlog and the team’s
velocity.
It is the output from release planning process and consists of a series of planned release dates including
the theme and prioritized feature set. In commitment on schedule beyond next release and so roadmap is a
plan of intent.
Progressive Elaboration
This concept focus on detailing upcoming requirement/ next scheduled items as one moves forward in
time while more details gets available with better clarity.
Progressive Elaboration means that over time we elaborate the work packages in greater detail.
Progressive Elaboration refers to the fact that as the weeks and months pass we have planned to provide
that missing, more elaborated detail for the work packages as they now appear on the horizon.
Generally in development projects the scope progressively elaborates, this poses a great risk to
schedule/cost as the estimation is usually done during the start of the project and not all elaborations are
considered as changes.

Personas
Personas define an archetypical user of a system. They are fictitious people which are based on your
knowledge of real users of the system.
Personas are incredibly useful when you don’t have easy access to real users because they act as “user
stand-ins”, helping to guide your decisions about functionality and design.
Personas are formed based on the stakeholder analysis and the knowledge of key users, their behavior and
expectations. A system can have one or many personas. The main persona is the primary persona and we
may have negative persona also.
Product Quality
Pair Programming
Pair programming is an agile software development technique in which two programmers work together
at one workstation.
One, the driver, writes code while the other, the observer (or navigator), reviews each line of code as it is
typed in. The two programmers switch roles frequently.
Definition of Done
Definition of done
• The definition of done is important as each team/team member, customer may have different
understanding and interpretation of done.
• A proper definition of done will avoid half tested, half documented, half optimized, half
refactored and eventually half ready software to be released.
• A typical “Done Done” means implemented, reviewed, unit tested, but not necessarily
documented.
• Make definition of done more comprehensive to build high value, high quality software and to
avoid future technical debt.
• A potentially shippable product may or may not have adhered to proper done definition.

Continuous Integration
Continuous integration
Continuous integration (CI) is the practice, in software engineering, of merging all developer working
copies with a shared mainline several times a day. It was first named and proposed as part of extreme
programming (XP). Continuous integration (CI) is used to improve the quality of software and reduce
time taken to deliver it.
Principles of continuous integration include
• Maintain a code repository in a proper version control tool
• Automate the build (Make, Ant, Maven, MS build, IBM rational build forge)
• Make build self testing
• All commits to baseline everyday
• Every commit should be built
• Keep the build fast (10 minute builds)
• Test in a clone of production environment (Integration server)
• Make the builds available to customers and testers on timely basis
• Automate deployment(Installation)
Agile Management & Development Tools
Agile Tools used
The most common software tools used continue to be standard office productivity tools such as Excel
(61%), Version one (37%), Microsoft Project (36%) and JIRA (35%). Few other widely used tools for
continuous integration are CruiseControl & Jenkins.
Agile Management Adoption
According to the 2012 CHAOS report, Agile succeeds three times more often than waterfall.
Because the use of Agile methodologies helps companies work more efficiently and deliver winning
results, Agile adoption is constantly increasing.
Ahmed Sidky and James D. Arthur has developed an Agile Adoption Framework providing a structured,
repeatable framework for adopting Agile processes in a development organization.
The framework uses a four staged approach for assessing the organization's ability to adopt agile

practices, cascading down through project suitability and aims to reconcile the findings in a set of agile
processes to adopt:
Sidky Agile Measurement Index (SAMI), which proposes the agile potential (i.e., the degree to which
that entity can adopt agile practices). This consists of four components:
1. Agile Levels - a set of agile practices that are related and, when adopted collectively, would make
significant improvements in the software development process, thereby leading to the realization
of a core value of agility.
2. Agile Principles - guidelines that need to be employed to ensure that the development process is
agile.
3. Agile Practices and Concepts - concrete activities and practical techniques used to develop and
manage software projects in a manner consistent with the agile principles.
4. Indicators - questions the assessor uses to assess certain characteristics of an organization or
project, such as its people, culture, and environment, in order to determine assess the readiness of
the organization or project to adopt an agile practice.
Web References for further study on Agile Management.
• www.AgileAlliance.org
• www.AgileManifesto.org
• www.AgileBok.org
• www.AgileModeling.com
• www.Agile-Process.org
• http://www.mountaingoatsoftware.com
Useful Books on this subject
• Agile Development by James Shore
• Agile Estimating & Planning by Mike Cohn
• Agile Retrospectives by Esther Derby
• Managing Agile Projects by Sanjiv Augustine
• The Software Project Managers’ Bridge to Agility
• Disciplined Agile Delivery by Scott W. Ambler

Agile Project Management Simplified

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (20)

Similar a Agile Project Management Simplified

Similar a Agile Project Management Simplified (20)

Más de Jaiveer Singh

Más de Jaiveer Singh (16)

Último

Último (20)

Agile Project Management Simplified