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