The best of agile project management

The Best of Agile Project Management
A selection of professional insights from the Blog archive

ProjectManager.com © 2013 All Rights Reserved

Since 2008 our project management professionals have been sharing knowledge,
experience and learning with online readers via the Project Manager Blog.

Their collective wisdom provides a wealth of how to, top tips and best practice
advice, for project managers, teams and businesses.

To make their writings more accessible we’ve created a series of “Best of” project
management topics available free to download and share.

Here is a collection of excerpts and insights from blog posts that discuss agile
project management and scrum development methodologies.

The principles and values of agile and scrum provide insights on successful project
management and software development, collaboration and more.

Enjoy!

Jason Westland CEO
ProjectManager.com

The 4 Values of Agile & Scrum ........................................................................................................ 3
The Benefits of the Scrum Methodology ........................................................................................ 5
The Pro’s and Con’s of Scrum ......................................................................................................... 7
An Iterative Approach to Agile Project Management .................................................................... 9
The Agile with Scrum Sprint Planning Process.............................................................................. 11
What is Agile Project Management Release Planning? ................................................................ 14
The Role of Scrum Master ............................................................................................................ 16
12 Principles of Agile Project Management.................................................................................. 19
30 Day Free Software Trial ............................................................................................................ 24

2

The 4 Values of Agile & Scrum

Agile software development is a way of developing software that has surfaced
over the past decade. It focuses on getting working software up and running
above an incessant and unnecessary amount of up front planning and
documentation that quickly becomes outdated.
One of the more popular methodologies of agile software development is scrum.
Scrum is a way that self-directed project teams can work in very short
development cycles, receive immediate feedback from end users, and continually
look for ways to improve the way they get things done.
There has been a considerable amount of information written about agile &
scrum software development. But, what are some of the underlying values that
are behind agile & scrum. The following is a list of four of these values:

Individuals and Interactions over Process and Tools
There are three things that are needed in any software development company to
deliver their products. These three things are People, Process, and Technology.
People are needed in order to get the work done. Processes must be in place in
order to provide a path to follow (similar to an assembly line) for the work to be
complete. Finally, Technology is what the people in the company will use to
create the software that is being put together on the assembly line.
In recent years process and technology
have taken precedence over people. This
has resulted in a “dumbing down” of
decisions that are being made because
everything is relegated to the realm of
process and technology.
Enter Agile & Scrum. Rather than an email
being sent out to 7 people, an agile team
member would get up and walk out of
their cube and go to another agile team
member and talk to them face-to-face.

3

They would lay out the situation; provide all the nuances of what is happening
and the concern about the impact that is going to have on the project. The second
person may not have the immediate answer but they get with another team
member, huddle up in a conference room for 30-minutes and get the problem
resolved.
That’s people over process or technology. The same principle applies to everyone
that needs to provide input be it management, a customer or another
department.

Working Software over Comprehensive
Documentation
A criticism sometimes leveled against agile & scrum is the
apparent lack of planning and documentation that is created.
However, it is really not the case as agile & scrum advocates
ongoing planning, not just at the beginning of a project.
Documentation creation is also ongoing in an agile & scrum
environment as well. It just appears in a different form than people are used to
with other methodologies. There are stories, charts, product backlogs, acceptance
tests, and the biggest piece of documentation of all…working software.
Rather than spending so much time up front on documentation that rarely gets
used, agile & scrum teams use just enough documentation to get them through
each sprint and through the next release of the software.

Customer Collaboration and Contract Negotiation
The underlying value and the spirit of agile & scrum development is to give the
client what they want - working software that helps solve their problem.
Agile & scrum encourage customer
collaboration and contract negotiation.
Customer involvement throughout the
software building process and iterative
reviews allow the customer to see where
the software solution is going.

4

It’s possible for customers to change their mind on the software functionality, if it
does not meet their needs, without derailing the entire project.
Software development service providers must negotiate a fair and profitable way
for this collaboration to occur. The best case scenario to enable such
collaboration is a time and materials based agreement, as opposed to a fixed fee
agreement. Any fixed contract could ultimately lead to your company losing
money as the needs of the client change over
time.

Respond to Change vs. Following a
Plan
Embracing change rather than just blindly
following a plan is a value inherent to agile &
scrum. Software development teams need to be
able to adapt to change rather than blindly
follow a plan that was set in place months or
possibly years before. Constantly inspect the
current situation and adapt to your environment accordingly.
Even if you have not fully embraced the agile methodology in your company you
can start following the principles above. Just having a different mindset and
approach to your next project will yield big results.

The Benefits of the Scrum Methodology

There has been a shift towards more agile project management methodologies in
recent years. This has opened up the door for more iterative releases and closed
the window of time between each next major release. The following are some of
the benefits of implementing a methodology such as the scrum methodology.
More Frequent Releases: The scrum methodology focuses on more frequent
releases with less functionality. Initially this may come across as being negative.
Who would want less functionality? Well, rather than wait 4-6 months for all the
functionality to be released at once, the scrum methodology enables releases to
be accelerated. In most cases functionality can be released every 4-6 weeks! The

5

development cycle is actually called a Sprint, which speaks to the abbreviated
nature of the scrum methodology.
Focus on Feature Set, Usability, and Value to the End
User: The iterative nature of the scrum methodology
lends itself toward a laser sharp focus on features,
usability, and value to the end user. Each release must
deliver value to the end user. At a certain level, it could be
viewed as a phased approach to the major releases.
Rather than waiting for everything to be done all at the
same time, functionality is released as it comes online.
Iterative Approach Allows for Changes and
Improvements: Agile project management methodologies such as the scrum
methodology embrace change. The waterfall method that is so common for major
releases is typically resistant to change. There are forms, meetings, approvals, and
other controls put in place for the purpose of preventing change with
conventional methodologies. The iterative nature of the scrum methodology
looks for perpetual feedback and then adjusts the plan and feature sets
accordingly.
Lends itself to SaaS: The Software as a Service (SaaS) model provides end users
an online service as needed via a monthly subscription. Part of the expectation
around the SaaS model is that there will be ongoing changes and improvements
to the software. This encourages subscribers to renew month after month. The
scrum methodology makes this easy to occur.
The days of waiting 4-6 months
between major releases are
over. People don’t have that
type of patience and there are
alternatives to having to wait
that long. Even if you don’t
adopt the scrum methodology in
its entirety, there are certain
principles and values you can
use that will allow your projects
to move along on the fast track.

6

The Pro’s and Con’s of Scrum

PRO Flexibility: The main benefit of using scrum for software development is its
flexibility. The very nature of scrum is designed to inspect and adapt. Small, bite-
size chunks of functionality and development work called ‘stories’ are defined and
selected to work on in short, iterative, and self-contained bursts of development.
This affords an incredible amount of flexibility for a number of reasons:
Feedback comes in fast and furious: At the end of each short development cycle
(called a sprint) the team shows everyone what has been accomplished and is
now ready for their feedback. The feedback will come back about what they like,
what didn’t work quite the way they expected, and input on some other areas
that may need attention based upon the changing needs of the business. This
feedback is then reviewed and, if appropriate, included in the next short sprint.
You Don’t Get Too Far off the Correct Path: Other development methodologies
can allow months and months to pass before anything is ever at the point of
being reviewed or demoed. The primary focus in the early stages of non-agile
methods concentrates on documentation and lots of it. By the time functionality
of the software is demoed, market conditions and business needs could have
changed so drastically that the initial solution that seemed like the right thing to
do is now way off the correct path.
In scrum, there are really not phases in the conventional sense of software
development. There is not a lot of upfront design, paperwork, and forms to be
filled out never to be looked at again. Rather, it focuses on development and
getting usable software to the internal or external customer. This allows the
software to not get too far off the beaten path or become irrelevant as a solution.
The scrum team selects what they will work on: There is a prioritized list of
functionality that is assembled by the product owner on the scrum team. The
team has the flexibility of choosing which areas of functionality they will work on
next that will be included in the next sprint.
The date of the completion of the sprint doesn’t change, however, what
functionality makes it into the next release of software may change depending
upon the work that was able to be accomplished.

7

An obvious upside of scrum is its flexibility. The amount of immediate feedback
and the ability for the team to turn on a dime really makes this methodology
great for many software companies.
CON Flexibility: One of the drawbacks from scrum is, yes, its flexibility. The very
quality that makes scrum so appealing to use is also the one area that needs to be
monitored very closely from a business perspective.
Here’s the scenario. The company that uses scrum sells a software application
that many clients use. The sales people and project managers at a company are
responsible for interfacing with these customers that purchase this software.
There are constant requests that come in from these customers for
enhancements and improvements.
These items are prioritized by the product owner on the scrum team and included
on a cumulative list of items to be worked on by the team called a product
backlog. The scrum team will then pick the items that make it into the next
development cycle and add these to the sprint backlog. It is this sprint backlog
that includes the new features and functionality that will be included in the next
release of software.
The clients want to know what is going to be included in this upcoming release.
You provide them with a high-level overview of the sprint backlog so they have an
idea of what will be coming down the pipe.
The scrum team begins working and find out that they run into technical issues
with a piece of functionality that takes longer to figure out than they had planned.
This means something gets bumped out of the sprint backlog and opens up a
potentially uncomfortable conversation with a client depending upon how critical
the functionality is in their eyes.
That’s part of the challenge. It is the team that makes the final decisions on what
will be included and what will not be included in the next release. At times this
decision may come across as arbitrary or not rooted in what is important in the
bigger picture of the application within the eyes of the customers.
True, this is a problem that surfaces with most development methodologies. It
just feels that due to the iterative and frequent number of releases with scrum
that this conversation has to be had on a regular basis.

8

Does scrum work? Absolutely! It has brought peace and averted many
contentious and disastrous situations using outdated methodologies. Just be
aware of the fact that it has the potential for being a two edged sword and you’ll
be pleased with the results.

An Iterative Approach to Agile Project Management

There is an increasing shift toward an iterative approach to project management.
This approach acknowledges the fact that it’s next to impossible to know
everything up front. The iterative approach is designed to figure out the details
along the way and then make the best decisions possible based upon the current
information available.

Why is the Iterative Approach to Agile Project Management
Necessary?
There used to be a time when project managers would delude themselves that all
of the requirements for a particular project would be known up-front so a
tremendous amount of time was spent gathering requirements and compiling all
kinds of design documentation. Reality then hit because there is really no way to
obtain and document everything you will need to know about a project, for a
number of reasons:
Users Are Not Sure What they Want: It is hard for clients to articulate exactly
what they want until they see it. This means a tremendous amount of time could
be spent in up-front planning only to find out it’s really not what the client had in
mind at all. That’s why an iterative approach to agile project management is a
must. It allows “baby steps” to be taken as the client uncovers and discovers
exactly what it is that they are looking for their project to accomplish.
Business Needs Change: Project durations can last anywhere from a couple of
weeks up to many years. During this time there are all sorts of pressures that can
be exerted on a company and the projects that are currently underway. A
competitor could have recently introduced a new product that is undermining
your customer base or, there may be financial pressures from within your
company that necessitate revising the scope of a project to make it more
affordable. Perhaps resource contentions with other departments make it

9

necessary to adjust the duration of the project. When discovered as a project is
underway, adjustments will need to be made to the project.
Technologies Change: The project could have started under the umbrella of one
technology, but it soon becomes apparent that a better technology has just
emerged. It is beneficial for the project to take advantage of this new technology,
but this will require some adjustments while the project is already underway.

Principles of Iterative Approach to Agile Project Management
Agility means that something or someone is quick, nimble, and able to respond to
the present circumstances at a moment’s notice. It is these qualities that agile
project management strives to embrace. In doing so, the following agile project
management principles will help an agile project manager keep up with change as
it occurs:
Deliver a Working Product Early and Often: One of the only ways that you will be
able to determine what a client really wants is to show them what you have. In
order for you to show them what you have sooner rather than later, you must use
the iterative approach to project management. Former times would have held
back the goods for the client to see until near the very end of the project. This
was many times met with disappointment as the results were nothing like the
client had imagined up front.
To prevent client disappointment, deliver small, bite-size pieces of working
software or project deliverables as they become available, for client feedback.
They may absolutely hate what is delivered yet at least at this point you can
readjust the plan or deliverable accordingly and get the project back on track
before its way too late.
Test Along the Way: Another important concept of the iterative approach to
agile project management is to test and fix bugs along the way. Development
methods such as the Waterfall Method would have all of the development work
complete before the testing group would ever lay their hands on the project. This
many times led to costly rework from a bug that had snaked its way through the
rest of the application.
Agile project management can discover and exterminated bugs early on in the
project with the understanding that a bug that is fixed as soon as it is found, is
much less costly to fix than one that has infiltrated an entire system.

1
0

Document What You Need: Team members will rarely reference everything that
has been written about a project instead referencing only what they need to get
the job done. The iterative approach to agile project management will provide
just enough information for that particular cycle of a project. More
documentation is provided once it is needed for the next cycle of the project. It’s
this approach that keeps the administrative burden to a minimum and at the
same time provides team members with exactly what they need to complete the
project.
Break Down Silos: A final concept around the iterative approach to agile project
management is that small groups of people from across disciplines are pulled
together to get the job done. This prevents just one group or team of people from
holding up the project, but rather allows others to work on the project
concurrently.
With dozens of people and countless activities to be managed across multiple
locations and environments conventional project management can quickly
become very challenging. With an iterative approach that focuses on
accomplishing just a few small steps at a time you’ll be surprised at how much
progress you can make.

The Agile with Scrum Sprint Planning Process

The sprint planning process used in the agile with scrum development consists of
two meetings. The first is to determine what will be done in the next sprint. The
second meeting is to determine how this agreed-upon work will be done.
You will end up with very powerful and long-lasting results once these two
meetings have occurred and the results are combined. If you have one meeting
without the other or never combine the results, chances are extraordinarily high
that nothing will happen. So here we discuss how to get the most out of this two
part planning process

Part I – What Will We Do?
The first agile with scrum sprint planning meeting focuses on what will be done
during the next sprint. The product owner is the driver and brings out a list of
stories important for the upcoming sprint.

1
1

Stories are what users want the software in development to accomplish. For
example, a user needs the software to sort and filter the final set of products
returned by the application or, the user needs to be able to select a product and
put it in their cart for purchase.
How does the product owner determine what products will make it into the
next sprint?
Carry-overs from the previous sprint: Typically, a handful of stories may not have
been finished in the previous sprint. These are good candidates for inclusion in
the current agile with scrum sprint. The product owner determines what stories
are still relevant, and includes and prioritizes them accordingly.
Feedback from the Users: The nature of the agile with scrum development
methodology is that it responds quickly to feedback from the user. Additionally,
agile methodology believes in releasing smaller sets of functionality more
frequently rather than waiting on massive amounts of functionality released
infrequently. This allows users to assess the newest release and say what they like
or don’t like about the functionality. This feedback becomes part of the product
owner’s prioritization process.
A Changing Marketplace: A third area that provides stories to be included in the
next release is what the marketplace is doing. Competitors may have come up
with a new feature that you need to include in your software. Or, there may be an
opportunity to optimize software with new functionality.
Once the product owner determines the list of stories to be included, she will
discuss it with the team. They will vet out each story based on their current
understanding with questions, ideas, and clarifications. The team then determines
whether or not to include it in the next agile with scrum sprint.
They will already have an idea of how long
each story will take to implement as the
estimating work has been done prior to this
meeting. It’s now a matter of filling up the
development cart with the number of hours
allocated for the next sprint.
For example, it may be a two week sprint
with four resources working full-time at a

1
2

75% utilization rate, which allows for 240 hours to be applied toward these
stories. The team picks those stories that add up to this number of hours.
A word of caution for teams that are new to the scrum sprint planning process: be
careful to not over-commit. It’s easy to be optimistic early on, but when the team
realizes that they won’t be able to meet their commitment, it only leads to
disappointment and frustration. It’s better to under-commit and over-deliver than
the other way around.
Notice the delineation of responsibility that is also occurring at this point in the
agile with scrum sprint planning process. The product owner determines the
prioritization of what will be worked on, whereas the development team focuses
on the viability of that selection and further hones that list.
You now have the first part of the agile with scrum sprint planning process; a
prioritized and agreed upon list of activity that will make it into the next sprint.
You’re now ready to move into the second part, which is deciding how the work
will be done.

Part II – How Will We Do It?
The development team now gets their hands on the list of stories that everyone
has agreed to undertake for the next sprint. They begin breaking the stories down
into tasks and activities and doling them out to the team. There is a give and take
as ‘progressive elaboration’ occurs. Team members begin working on their tasks.
However, software development falls into the realm of ‘you don’t know what you
don’t know.’ Once more information is uncovered about the task it may need
more hours to complete. This is discussed with the team and ultimately product
owner as it may jostle some of the other high priority stories on the list.
The team will get better at estimating durations over time. They may even
consider using some of the alternate estimating measurements below:
Number of Hours: This is the most common and easy to understand concept of
estimating. The team calculates the number of hours it will take to complete the
stories against the actual number of hours available.
Number of Points: Points can be assigned to various tasks based upon their level
of complexity. Points are then tallied up until the maximum number for the
current sprint has been reached.

1
3

Number of Tasks: Tasks can be counted if they are similar in size for the sprint.
Tasks are added to the sprint until it has reached its allotted number.
Determining WHAT you will do does no good unless you know HOW you will do it.
Knowing HOW you will do something but being unsure of WHAT you are going to
do is also not good. Both elements carry equal weight when trying to get the most
work out of your team and fully utilizing the agile with scrum sprint planning
process.

What is Agile Project Management Release Planning?

Agile project management release
planning is as its name implies: flexible.
Agile project management is designed
to be able to turn on a dime and pivot
in real-time as needs and
circumstances change.
This is predicated on the fact that smaller releases executed over smaller time
frames will ideally not change much. Then, as that release cycle is underway,
feedback and adjustments can be made that will move into the next release.
Agile project management carries with it a number of benefits, such as smaller
releases providing for new functionality faster and the end-users feedback
constantly incorporated into the end product. This allows it to align closer with
their final expectations.
Understanding what agile project management release planning requires carries
some inherent risks that are not typically present in conventional software
development methodologies, such as the Waterfall Method.
The very flexibility that makes an agile project management plan so appealing can
also be the nemesis of project managers who are used to working with more
structured and formal methodologies.

Two Views of Agile Project Management Release Planning
There are two distinct views on how agile project management release planning is
accomplished.

1
4

Fixed Date: The fixed date approach draws a
line in the sand when it comes to the date the
project must be complete. There is no
negotiation when it comes to the date being
met, for example a project to support a trade
show where a new product is being
introduced
The Challenge: with a fixed data approach the scope of the project may have
some flexibility. The team can commit to a particular date, but they may not be
able to commit to 100% of the functionality being requested to be complete. The
goal should be to get as much as can possibly be done by the fixed date, and then
roll whatever is left into the next development cycle. What should not be
orphaned for the next development cycle, however, are large pieces of critical
functionality that must be complete in order for the product to provide value.
Fixed Scope: The fixed scope approach draws a line in the sand when it comes to
the features and functionality that must be in the product. There is no negotiation
when it comes to what is included, but there may be some flexibility around the
time that the project is complete. This may be the case when there are only a
handful, or one, new feature being introduced and releasing the product without
that functionality would be meaningless.
The Challenge: Flexibility in the timing of the project needs to remain reasonable.
For example, a 6-8 week development cycle that drags on another 6-8 weeks has
totally missed the mark. With agile development teams it’s understood that
schedules may slip days or a week on short development cycles, but it shouldn’t
be much longer than that.

Devil’s Advocate “But, I have a fixed date and a fixed scope”
Welcome to one of the biggest challenges of project management - working
within the triple constraint of scope, cost and time. It’s at this point that hard
decisions and trade-offs will need to be made. You want to be as accommodating
as you can as a project manager, but when requests become unreasonable and
untenable then you need to raise your hand and say no.

1
5

The Role of Scrum Master

Below are some of the functions the Scrum Master serves:

Coach
One word that can be used to describe what the
scrum master does is to be a coach. This can be
correlated to what a sports coach does for their
team. They guide, admonish, strengthen, and
push their team to perform their very best.
This is typically somebody who has a deep
understanding, love, and appreciation for the
sport and wants to share this experience with
others on the team.
It is similar with the scrum master. This person is typically very knowledgeable
about how the scrum methodology works and is passionate about its success. This
excitement is then shared with others on the team in their various roles. The goal
of the scrum master as coach is to push their team to always work better
together, self-organize, and increase their performance.

Peer
Despite the term ‘master’ that is used in scrum master, the scrum master is not
the ‘boss’ or manager of the team. This may be hard to understand for
conventional project managers who have come from a hierarchical, top-down
approach to managing people on their team
The scrum master is not higher in rank than anyone else on the team. It is their
responsibilities that give them this name and separate them from other team
members. The scrum master has certain functions that they are responsible for
fulfilling and this is done in their capacity as an equal peer with the rest of the
team.

1
6

Scrum Expert
… the Scrum Master will typically serve as the scrum expert on the team. This
means they are responsible for helping the team optimize the use of scrum as the
methodology they have chosen to build their software.
This expert role is implemented in a number of ways. This can range from the
scrum master facilitating meetings, making sure team members understand their
respective roles on the team, to helping others use and understand the various
scrum artifacts that are necessary to keep a team running smoothly.
One thing the scrum master should be careful to stay away from and that is
constantly pointing out to their team members when they are “doing scrum
wrong”. This is counterproductive and does not fit into the description of what
the scrum master should be doing. Rather, the scrum master should catch people
doing things right, and then, in the spirit of a coach show them how things can be
done better.

Remover of Obstacles
This is part of the role of scrum
master that is comparable to that of a
project manager. They need to be
able to remove obstacles and
impediments out of the way of their
team mates.
An obstacle or impediment may be
anything that slows the team down from getting their work done. This could
include unnecessary approval processes, slow responsiveness from other
departments, or maybe even updating outdated hardware or systems.
The team should be able to count on the scrum master to clear the path ahead of
them. This will allow them to focus on the work that is currently on their plate to
accomplish and get it done as efficiently and effectively as possible.

Dispenser of Information
Another big role that the scrum master plays is to constantly dispense
information to project stakeholders about where the current sprint and

1
7

development effort stand. This can be done via the various artifacts of scrum (i.e.
backlogs to burn down charts) and just common-sense communication efforts.

Facilitator
‘Facilitate’ is a great word and sums up what a scrum master should do for their
team. Facilitate means “to make easier or less difficult, help forward”. The goal of
a scrum master is to make the tasks, activities, and day of each of their team
members easier and less difficult. This can be done by doing each of the items
above and keeping the attitude of being a peer at the forefront.

Is the Scrum Master a Dedicated Role?
There is some discussion about how involved the
scrum master should be when it comes to the actual
development work that is underway. One school of
thought is that the scrum master should be
exclusively dedicated to their role described above
and not get buried in the day to day pressures,
deadlines, and constraints that come from actually
having to do the work themselves. Others feel as if
the role described above may not consume 100% of
the time that is available and any leftover time can
be devoted to toward development work.
There are pros and cons to each approach. If a scrum master is involved in
development activities they could find themselves in the critical path of a project
that is underway. This means that when the going gets tough or deadlines are
looming they will most likely default to getting their own work done. This is
understandable based upon the pressure that is put upon their particular
deliverable. But, it could also let the team suffer during a time that they especially
need someone filling the role of scrum master.
The upside of a scrum master filling both roles is that the company may feel as if
they are getting more for their money by not having to invest in two people to fill
the roles.
On the other hand, a person that is a 100% dedicated scrum master focuses
exclusively on the activities mentioned above. They are the person that constantly

1
8

has the big picture in mind and is always looking around the corner for what could
be in the way of the project moving forward, or what opportunities could be
taken advantage of to bring the sprint to a more expeditious completion.
The downside of this approach is that there may need to be more resources
applied to the project from a technical perspective and may cost the company
additional money.
Is the scrum master some mysterious super-being that wields their mysterious
power over their minions? Absolutely not! Rather, a scrum master is just one part
of a highly effective team that is focused on getting the right features into each
product release. The end result is a working piece of software that brings the
greatest amount of satisfaction to the end user.

12 Principles of Agile Project Management

There has been much written on the subject of agile software development and
by extension agile project management.
To go back to the source of this knowledge you can spend a little bit of time at
AgileManifesto.org to get an idea of where this all started, the values this
methodology holds dear, along with the 12 guiding principles the original team
espoused.
The 12 principles of agile project management follow along with commentary on
how and why each of these principles is beneficial in the rough and tumble world
of software development.

Principle 1: Our highest priority is
to satisfy the customer through
early and continuous delivery of
valuable software.
The competitive advantage of a customer
centric focus is many times lost in the
shuffle of corporate politics and
bureaucracy. The first principle of agile

1
9

project management serves to principle reminds us that software is built to be for
an end user. Created to help people do their job more efficiently and effectively
or, to enable end users to perform tasks that previously were out of their reach.

Principle 2: Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
Conventional and linear software development and project management
methodologies cringe at the idea of change. However, you can almost be assured
that there is not one software project in existence that made it from beginning to
end without changes. Agile project management methodologies and software
development embrace this fact. They view it as an opportunity for the end
product to end up being closer to what the client or end user wanted and thus
increases its usability and satisfaction.

Principle 3: Deliver working software frequently, from a
couple of weeks to a couple of months, with a preference to
the shorter timescale.
Previous methods of developing software would concentrate on an incredible
amount of documentation up front under the guise of vetting out 100% of the
requirements that were needed for a particular project. The reality is that after a
couple of months what you ended up with is a whole bunch of very nice and very
thick documentation but no working software to show for it. Agile project
management concentrates on creating and implementing working software
frequently.

Principle 4: Business people and developers must work
together daily throughout the
project.
Business people and developers must work
together daily throughout the project as such
collaboration helps maintain the agility of

2
0

software and the ability for it to change in order to keep up with the changing
marketplace.
This is a foreign concept to many that have worked in software development yet
not worked within the parameters of agile project management. This principle
needs to be taught, learned, and reinforced because it’s not something that will
come naturally to most people.

Principle 5: Build projects around motivated individuals. Give
them the environment and support they need, and trust them
to get the job done.
In other words, there’s no need to micromanage teams that is following agile
project management methodologies. There’s no one that knows better what
needs to be done and how it needs to be done than these self-directed teams.
Allow teams to figure things out, make their own decisions, and move the project
forward. An agile project manager (scrum master) is there to support and enable
them to get their work done.

Principle 6: The most efficient and effective method of
conveying information to and within a development team is
face-to-face conversation.
Much has been lost in the art of communication due ironically, to technology.
Technology allows developers and business people to make it throughout their
entire day without talking to anyone, if they so choose. The use of email, instant
messages, text and other forms of communication have displaced face-to-face
communication. While these technologies have their place, keep in mind that
there is nothing better than face-to-face communication if you really want to
understand someone or be understood yourself.

Principle 7: Working software is the primary measure of
progress.
Simple, right? Think about all of the other measures of progress that have been
used in the past. Number of open bugs, number of closed bugs, velocity of bugs

2
1

being fixed, and hours spent on a project, hours remaining on a project, budget
consumed, budget yet to go, etc. These are important measurements, but, they
are really all the overhead that is necessary to get the software working correctly.
That’s what needs to be measured.

Principle 8: Agile processes promote
sustainable development. The
sponsors, developers, and users
should be able to maintain a constant
pace indefinitely
It used to be very cool back in the early days of
software development and not-so agile project management methodologies to
get down to crunch-time at the end of a project schedule. This is when there was
only 2-3 days left before the software was to be delivered and there was 2-3
weeks of work left to go. Everyone would hunker down, pizzas would be ordered,
cots would be set up and the all-nighters would begin. Great times, maybe.
Sustainable? No way. This type of crunch-time schedules became a normal way of
working for many developers and created all kinds of issues ranging from burnout
to health problems.

Principle 9: Continuous attention to technical excellence and
good design enhances agility.
This means take pride in your work. Agile teams aren’t just a bunch of hacks that
are throwing code together to get a shoddy product out the door. They take the
time to review their solution, determine the best approach and then implement
with far-sighted vision on where the product is going in the future.

Principle 10: Simplicity--the art of maximizing the amount of
work not done--is essential.
Simplicity is genius. The ability to take something extremely complicated and then
make it easy to understand for everyone involved with the project is a true art
form. A goal of agile project management is to make this possible more often
than not. This many times flies in the face of corporate culture and what

2
2

managers are looking for in their employees. They want to see busy-ness…even if
they are working on things that are unnecessary and non value-add.

Principle 11: The best architectures, requirements, and
designs emerge from self-organizing teams.
Teams that practice agile project management are strongest when they are self-
directing. There is an aversion to a top-down, know-it-all, hierarchical approach
and more of a “we’re all contributors to the solution” approach. Everyone is free
to offer suggestions on the best implementation ideas, architectures,
requirements and other aspects about the project to make it the best result
possible.

Principle 12: At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its behavior
accordingly.
Inspect and adapt is an overarching principle of agile project management. Just
because something is written down somewhere or this is the way something has
been done for years does not mean that it needs to stay that way. The team
should always be asking if a particular way is the best way of doing things. If it’s
not then adjustments can be made and the new way can be implemented going
forward.
The 12 twelve principles above seem to make perfect sense when you look at
them in the context of agile project management. However, these were
revolutionary principles when they were first introduced. Many have taken these
principles and made them their own for the benefit of themselves, their teams,
their companies, and ultimately the users of their working software!

2
3

30 Day Free Software Trial
There are two key differences between ProjectManager.com and its competitors.

The first is that we give you all of the features you need to plan, track and report on
projects efficiently. The second key difference is that our competitors charge a high
upfront price as well as annual maintenance fees for new releases.

Here at ProjectManager.com we offer you all of the features you need to manage
projects, at a small monthly price of just $25 per user. That simple! When you sign up to
ProjectManager.com, you also get for free:

Unlimited Projects
3 Gigs of Document Storage
Client Login
Free Upgrade to New Releases

Take Action, Sign-Up for a 30 Day Free Trial Today!
Take a Free Trial
Create your own Projects
Sign up to boost your project success

Any questions? Email support@ProjectManager.com and
one of our friendly support staff will be happy to help. We
also recommend a visit our resource library if you would
like access to further:-
 project management tips
 video tutorials
 project management templates

2
4

The best of agile project management

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

The best of agile project management