What Is Agile Project Management?

Agile project management is the process by which projects can be managed and
implemented in small chunks of work. Agile projects deliver value to the business in
frequent small deliveries of product called features. And their traditional waterfall
methodology the requirements for the project would be documented up front. Then the
design of the whole solution would be completed. Followed by the development, testing
and finally, implementation of the product. If this whole process takes a year to
complete, the business does not see any tangible value until the very end of that project.
With agile projects, items are created by a small logical chunks of work called iterations
or sprints. Agile is a great technique to use when business needs are frequently
changing or when the business wants to receive product benefits earlier. With Agile you
can focus on what the business needs now and if that changes the new business needs
can be accommodated in the next iteration .Agile is frequently used to manage IT
projects, but can also used to manage non-IT projects.
Examples of non-IT projects that are suitable for Agile are facility moves, company
reorganizations, or changing business processes within a department. Just about any
project can utilize Agile if deliverables can be produced and implemented in a short
period of time, and can be expanded or added to with future capabilities. Just like
building blocks coming together, Agile projects buildcapabilities one piece or a few
pieces at a time. Let's talk next about the characteristics of successful Agile projects.
First, sprints or iterations are typically four to 12 weeks long. Face to face
communication is emphasized over documentation. We want to produce a product, not
product documentation.Business and technical team members are co-located or use
very rich virtual tools to simulate being together. In addition to these, a sponsor who is
100% committed to the Agile process is vital.
And lastly, requirement changes are anticipated and accommodated. There are other
items required for Agile projects to work that do not differ from traditional projects. These
include having a vision for the end game. Following a universally understood project
lifecycle. Your requirements must be understood. You should use a shared and
managed schedule. You have a dedicated team that is focused on getting the job
done. And lastly, communication with all stakeholders is critical.
Life cycle

Agile projects are managed in five stages, called the Agile Life Cycle. The stages are
Envision, Speculate, Explore, Adapt, and Close. Let's take a look at the highlights of
each of these stages. During the Envision stage, you and your customer will determine
what it is you are trying to build. You will also confirm who needs to be on your team and
determine the team values and norms you are going to use. You go through the
Envision stage of an Agile project once. At the end of the Envision stage, you should
have a documented project charter describing your scope and overall objectives and
your defined stakeholders for the project.
You should also have your team collaboration tools set up and working, and you
should've established team norms. Examples of team norms are your working hours
and how the team will work together to solve issues. You will then cycle through the next
three stages, Speculate, Explore and Adapt, to complete each Sprint. Speculate stage is
a planning exercise. Yes, Agile really does have planning. During the Speculate stage,
you will develop or revise the Feature Based Delivery plan, estimates for each feature,
and risks you need to manage.
A Feature is a piece of functionality or outcome that is valued by the client. One or more
features are completed as part of each sprint. At the end of the Speculate stage, you
should have a set of requirements for the Sprint and a list of features to be developed
based on those requirements. You will also create effort estimates for each feature, and
your risks will be identified or updated for the features you are working on. During the
Explore stage you actually develop the product.
Notice how quickly we went from Project Initiation, the Envision stage, to developing real
results. Activities during the Explore stage include your daily stand-up meetings and
frequent and brutally honest peer reviews of the features as they are developed. The
reviews come from daily or nearly daily interactions between business and technical
personnel and frequent and focus testing. Now that the features for this iteration
have been developed, it's time to pause and reflect. This is the purpose of the Adapt
stage.
A great benefit of Agile is you get feedback frequently. It's easy to remember what
worked and what did not, fix things quickly and move forward. Common activities during
the Adapt stage include a final review of the features by the customer and a
documented meeting of team members to reflect on their performance. From these,
lessons are captured and shared, and future sprint plans are reviewed and
adjusted. The Adapt stage can happen very quickly, often being completed in just one
day. The project will now loop through the Speculate, Explore and Adapt stages until all
sprints for the project are completed.
Once all the iterations are complete, our features are implemented, the Close stage can
occur. During this stage, you ensure all of your deliverables are completed, and a final
set of lessons learned are captured for the project. Now that you know what is supposed
to happen during each Agile stage, during the next set of videos, we will describe how to
make it all happen.

The Envision Phase

The envision phase is the first of 5 phases in the agile life cycle, and provides the
foundation for the project. At the end of the envision stage, you should have a
documented project charter. Describing your scope and overall objectives, and your
defined stakeholders for the project. You should also have your team collaboration tools
set up and working. And you should have established team norms. Let's go into the
details for each of these items. The project charter should contain the scope of the
project. The scope creates the overall boundaries for the project. Included in the scope,
should be the product vision, which is a summary statement about the final product.
This includes the target customer, key benefits, and purpose of the project such as cost
savings, or competitive advantage. In addition, the project charter should identify the
project sponsor and project manager responsibilities, authorize the project manager to
perform their responsibilities, and define the level authority given to the project
manager. Team collaboration tools are essential to ensure project communication is
easy and understood by all team members. These tools can track and report status,
facilitate joint feature development.
And push information out to team members. The key is having tools that are easy to
use. There are many collaboration tools on the market. The size of the project,
number of stakeholders, and the amount of collaboration desired will determine how
advanced you need to get with your collaboration tools. My suggestion is to start with a
small number of low complexity tools, and add other tools if and when they are
required. During the envision phase, all stakeholders will start working together on the
overall design of the project.
At this time, it's important to establish the team norms for how the team will work
together, including where they will physically work. As Agile projects involve close
collaboration, it isimportant the team understands how it will operate. That is the critical
element of team norms. Example team norms include, actively listen to what others
are saying. Attack the problem, not the person. Seek to understand first. Only
focus on "this" sprint and feature. If you see a problem, say something and make
suggestions for resolution.
Actively participate in the daily meetings. Be engaged. Solve conflict with the
other person when possible. If not achievable, both parties must come forward for
help from management . Email is a low touch communication vehicle, and should
not be used to solve problems. Don't respond to text messages during
meetings. Provide your full attention to the matter at hand. Be respectful of one
another.
Have the best interest of the project as your first priority. Share and respect the roles
and responsibilities of each team member. Agile teams are best if they have 15 or less
people. Larger teams are possible, but I recommend you split them into smaller sub-
teams to stay within the 15 or less guideline. Larger teams introduce risk, as the
coordination between larger numbers of people, and the features they produce is much
more difficult. Most of the risk with Agile Projects comes from having too ambitious a
schedule for feature production, or not having people on the team that can make
decisions, without waiting for management approval.
These situations should be avoided. With a proper project charter documented,
collaboration tools ready to use, and the team in place with minimal risk elements, the
project is now well positioned to commence the planning for the first iteration, in the first
speculate phase. We will discuss the details of that, in the next video.

The Speculate Phase

The primary purpose of the speculate phase is for the business and technical teams to
identify the features for this iteration. If this is not the first iteration, you should also need
to review past features that have not been completed. So, in the speculate stage, you
and the business need to consider. New features. Features from the backlog list, the list
of features on your to-do list, and features not completed from the prior iteration which
get added to the backlog list. Before we move forward, let's review the characteristics of
a feature.
A feature is similar to a requirement but instead focuses on a specific business need. A
feature is a small client valued function expressed in the form action result that allows
the user to satisfy a business objective need. To show you what I mean, here are some
examples of features. Calculate tax for supplies ordered, display the name and address
of buyer on the invoice, Display the shipping name and address on the invoice.
Enroll a student in a course, and track course completions. The typical and simple agile
approach is to write each feature on an index card, or a big sticky note. Using a physical
card that you can move from one category to another and back again, can make
organizing and prioritizing very easy. For larger projects, agile collaboration tools can
simulate the index card approach. Once you have a complete set of features, organize
them logically into groups.
You can then have the business review and prioritize features, with advice from the
technical team.During this process, business stake holders typically ask questions about
existing features, and add some features as well. This conversation about additional
features is great, and is part of the agile process, as is prioritizing all these good ideas. If
yours is like most agile projects, you will have discussions about features that have to
be considered in a future project. Because you'll run out ofmoney, time, or both.
Once the feature list has been reviewed prioritized, and agreed by the business and the
sponsor, you area ready to roll. Remember, you get to review the feature list at
the beginning of each iteration, so you're only done for now. Now that the features have
been agreed, you'll need to estimate the work effort required to complete each feature. If
this is your first iteration, you should do the estimates for all features. Make sure you
work with the team members and business subject matter experts to obtain accurate
estimates.
Once this is completed, you can now create your Iteration, Milestone and Release
Plan. The Iteration, Milestone and Release Plan will list all features to be completed,
when they will be completed, and when the features will be implemented for the
business. Typically, the Speculate Phase does not take a long time. For example, if your
iteration is eight weeks total, you should only be spending approximately five days or so
in the speculate phase. For any agile project, however, the first iteration of the speculate
phase will take longer as you'll need to identify and estimate the features for the whole
project, not just the first iteration.
The Speculate phase is about careful planning for each iteration, and re-prioritizing new
features along with the backlog. This considered planning helps you keep the next
stage, explore, sharp, and focused .

Explore phrase
phrase most people get excited about. We now get to produce the product.Fortunately,
with Agile, it doesn't take very long to go from the Envision and Speculate phases to the
Explore phase. This phase is all about collaboration between the business and technical
team members. The daily stand-up meetings, although run throughout all Agile project
stages, play their most substantial role during the Explore phase. Let's examine what
typical stand-ups are like. The meeting should be around 15 minutes long, 30 minutes
max.
Each team member shares what they achieved yesterday, what they plan to
achieve today, and they discuss anything they need help with to progress their
work. The stand-up meeting is not the place to resolve issues. If issues are identified,
they should be noted, addressed after the stand-up meeting, and reported back to the
group the next day. That's it. Nothing to document other than items you may want to
put into an issues register for the purpose of building lessons learned.
So what does the project manager do in these meetings? The project manager fulfills an
observer role, allowing the team to take the lead. As project manager, you should watch
for issues that are not being resolved and remove roadblocks for the team. Also, you
should ensure risks are decreasing over time, and after the stand-ups, communicate
status to key stakeholders, so they are informed of progress. Listen carefully during the
stand-up meetings. Your job during the Explore stage is to protect and enhance the
productivity of each team member by letting them get on with the job of building
and handle the organizational distractions that may slow them down.
The stand-up meetings help you understand how to do this by giving you a view to what
the team is facing on a daily basis. It also gives you the basis to maintain control of the
project. Tracking progress against the plan features for this sprint is your control
mechanism. Completed features are noted in the stand-ups, as well as on a feature
board, in the team room, so the team can see the progress that has been achieved. If
features are behind schedule, find out why. Make adjustments as quickly as possible
and take good notes, so lessons learned can be applied.
Similar to non-Agile projects, maintaining an issue register is necessary. What is
important is that issues are being resolved in a timely fashion. Your issues register will
provide the mechanism to determine if open issues are growing in volume. This could
be an indication that something is wrong and changes should be considered. It is easy
for teams to get so caught up in building the product that time gets away from
everyone. Timekeeping and sprint schedule tracking is essential. End each Explore
phase when the plan features for the sprint have been completed or when the time
allocated for this Explore phase has been consumed.
It's critical that you end the phase under one of these two conditions. If you plan to be in
the Explore phase for seven weeks and the plan features are not complete, stop the
phase according to your schedule and proceed to the Adapt phase. At that time, capture
and apply lessons learned. Ensure all team members understand the lessons learned
changes and set or adjust expectations with your stakeholders.

The Adapt And Close Phases

The adapt phase occurs at the end of each sprint immediately following the explore
phase. In each adapt phase, you will review with the team what has been delivered
compared to what was planned for this sprint, discuss what is and is not working,
and agree to any changes that will be applied. Its also wise to review the prior
adapt phase lessons learned to see if trends are occurring. The adapt phase is also
the time to review the product with the customer and confirm the features are
working as expected. Determine if anything has changed in the business that
reduces or changes the effectiveness of the features.

You'll also want to take the time to verify the features are producing the intended
business benefits. It is critical for you to facilitate a lessons-learned discussion in each
adapt phase for feedback to be openly shared. All input is valuable and should be
considered. You can then brainstorm ideas to resolve issues or eliminate potential
roadblocks to your team's success. You will find a number of typical adjustments result
from these adapt phase feedback sessions. These adjustments include: adding or
removing features, adjusting the estimates for features, or re-prioritize the features on
the back log list.
Modifying the daily stand-up meetings agenda to maximize effectiveness. Changing
team members based on project need, availability, and teaming effectiveness. Updating
the risk register, modifying or removing processes that are not effective. And lastly
adding processes, but only if they're essential to progress the project. It's important to let
all stake holders know about the changes that will be applied to future sprints along with
why those changes are being made.
If the team has been working especially hard, this is the perfect opportunity to celebrate
the successes of the prior sprints and acknowledge specific achievements. Some team
members may need a mental break before they start the next sprint. As project
manager, you'll need to ensure the team is ready for the next sprint and the morale is
positive and ready to go. For a longer project, I suggest occasionally giving team
members a holiday from a whole sprint to allow them to complete other work activities or
take vacation.
This allows them to return to the project rejuvenated. Assuming this is not the end of the
project, when you complete the Adapt phase, you'll proceed to the Speculate phase for
the next sprint. Remember, if the original agreed costs or schedule have been
consumed, it's now time to end the project and proceed to the Close phase. If this
happens to be your last sprint, the project is now ready to be closed. The close phase
now begins. The administrative activities and the close phase include: ensuring
vendors have been invoiced and payments received, reconciling any project financials.
Working with managers and team members to redeploy people to other projects or work
activities. Communicating the overall project results to the project team and other key
stakeholders. Now is the time to toot your horn. Next, ensure business benefits continue
to be monitored and achieve. It is important to transition this monitoring to the
customer. And last, if Agile project management in new to your company, provide
a special recap on why the Agile process worked and what lessons you learned.
You should skip the temptation to skip or shorten the close phase activities. Project
closure is important to ensure the project does not linger unnecessarily. That also gives
everyone the chance to appreciate the significance of what has been achieved.

2. Envisioning: Project Selection and Design

Selecting An Agile Project

One of the most important success factors for agile is the selection of the right project
for you to apply agile methods. Good agile project candidates share these
characteristics. First, you need to deliver a quality product quickly, but do not need to
deliver it all at once. Next, you expect the requirements to change or evolve. Also, your
organization is willing to free up very capable team members that can independently
make decisions about the product you're producing. And, you believe the product can
deliver business value in incremental pieces.
Let's look at a few examples of agile and non-agile projects to put this in
perspective. Let's say you want to implement an executive information system. You
have an agreed budget, strong executive buy-in, you have seven executives, each with
very different needs. They definitely want something delivered sooner versus later, and
they want the project done by the end of the year. This project has agile written all over
it. The requirements will undoubtedly change and evolve as the executives start to see
the possibilities.
You can easily break down the project into sprints, as you could categorize and
implement features by executive. Let's look at another example. You need to do a
business process refresh, replacingadministrative processes with updated ones to meet
greater customer demand. This is something your company does every three to
four years, with a proven set of steps and processes to follow.The budget is agreed, all
the scope must be completed, and you know what business areas and the number of
processes that must be updated.
This is not as good a candidate for agile. It does not serve a purpose to perform sprints,
and ask if there are new features required at the end of each sprint. The project's been
completed in the past using other methods, which have worked, and people are used
to. Could this project be implemented in sprint-like iterations? You bet. But just doing
something in iterations does not make it agile. That project life cycle is sometimes called
iterative, and can be a smart way to run a project. We also know all the processes must
be refreshed.
So it's not okay to time box the project, and only allow for some of the processes to be
refreshed based on a pre-agreed schedule, which could happen with an agile
project. Best to use the more traditional approach which has worked in the past. Not all
projects have to be implemented as just an agile, or non-agile project. It is possible to
implement a project as a hybrid, of agile and non-agile. Take an introduction in a new
product line in an existing business, for example.
I might use agile techniques to develop new marketing products and get done as much
as possible by the desired product delivery date. I would use a more traditional life
cycle for the reorganization of people into the new product department, as each person
must be evaluated, have their job responsibilities changed as required, and have their
new job created. I would apply the people changes first for a given area, and then the
business process changes could be made by the newly reassigned staff.

Using agile for the process changes is wise, as it forces the company to carefully
prioritize the work, and implement the most important features, business process
changes, first. Putting people into new positions is best done in a more traditional
project approach. In summary, agile can be applied to several different scenarios and be
implemented in different ways. It all depends on the project and organization you're
working in, and whether the characteristics of agile are the best way to create change
for your customer.

Scoping The Project

In the Envision stage, you created the project charter that describes the customer's
visions of the final product and overall boundaries for the project. What follows next is
the creation of the Product Data Sheet or PDS. This is a great planning document
and provides an executive summary of the project. A well written PDS provides more
detailed scoping for the project, and can become an easy to use communication tool for
the project. The PDS is typically created during the Envision phase prior to the first
sprint. The short and concise one to three page PDS includes the project description
and high level project scope, usually taken straight from your project charter along
with the project objectives, the business value you're going to provide.
You also should detail your timeline with milestones, the cost estimates for people's time
and estimates for other items you might need. Last, it includes the constraints, which are
sometimes called limitations, and the prioritization between the project scope,
resources, schedule, and level of quality needed. Let's take a look at the last two items,
constraint and prioritization, as they are vital for defining your Agile project. A constraint
is a restriction to the freedom you have in creating the project solution.
Constraints can be environmental, safety, economic, technical, or political, and
pertain to your project's schedule, team members, or to the product being
developed. Common constraints include, the project must be completed by such-and-
such a date. And certain technical standards must be followed, like electric product
safety codes. Other constraints include when the product can or cannot be
implemented. An example of this is avoiding peak times. It would be risky to change
cash register software at a retail store during the Christmas rush period.
Constraints can also pertain to your team. Like, certain people will be made available to
the project only at certain times. You may also have to detail limitations, such as using
existing infrastructure and equipment, and the budget will not exceed x
dollars. Balancing the constraints of the project depends upon the prioritization of project
scope, people, and other resources, schedule, and quality. Let's look at an example to
describe this. If the schedule is the highest priority, then Agileallows us to apply flexibility
to the scope and people.
You could reduce the number of features produced in a given sprint, or increase the
number of team members to ensure the sprint's completed on time. If product quality is
the lowest priority, then you have greater flexibility as you can focus on the schedule
and any product defects can be corrected in subsequent sprints. The client and the
team will participate in the completion of the PDS. The client should review the entire
PDS for accuracy, describe the business benefits, and confirm the resources they will
provide. Agile projects are known for minimal but vital planning, and that is a good thing.
The PDS is probably the most detailed planning document that exists in Agile, and it's
critical to the success of the project. If you resist the urge to dive into the first sprint and
spend time early in the project to create the PDS, and share it with stakeholders, your
project will likely run much more smoothly.

Designing Your Sprint Structure

Most sprint durations are from four to 12 weeks. This duration includes the speculate,
explore, and adapt phases. Determining the length of your sprints and the number of
features you'll try to build during each sprint is called the sprint structure. You'll want to
create a sprint structure that is appropriate for your specific project. So let's discuss
some hints and tips to determine your sprint structure. As a starting point, plan one
week for Speculate and one week for Adapt. Over time, you will learn what you
can accomplish in those time frames, and adjust as necessary.
The exception to this is the Speculate phase in the first sprint, as planning will be
necessary for the whole project, not just the sprint, so add a few more days. To
determine the best sprint structure, you'll need the complete list of features to be
developed along with size estimates. Then, create a logical grouping for the features so
you can assess the size of the sprints you want to use. Features can be grouped based
on, the business's prioritization of the features. The technicians you have available for a
given sprint, the business resources you will have available for a given sprint, or
grouped simply by business area.
Because sometimes it's easier to build features for a specific business area in a given
sprint. The size estimates for the features need not be detailed. You can use large,
medium and small with the expected number of hours for each category. For example a
large feature is assigned 80 hours, medium 40 hours and small 20 hours. As estimates
are refined during each Speculate phase you can adjust as needed.
Based on the number of people you have on your team, and the size of the features you
want to build in each sprint, you could determine the best size of your sprints. Pick a
size and stick with it. Keeping each sprint the same length. This helps your team
schedule themselves in a rhythm. Which is proven to be more productive over a number
of agile projects. Here's an example. Let's say your project is six months long and you
consume one month for the Envision phase. You now have five months left for the
remainder of the project. Based on the size and grouping of features,you decide on
three sprints of seven weeks each.
Of the seven weeks for each sprint, you have five weeks to perform the work. The
Explore phase. Based on the estimates and the available resources, you'll now be able
to confirm the features you can complete in a given sprint. If that does not align with the
features you want to build in a sprint, you could adjust your sprint length and the number
of sprints accordingly. I suggest building the highest priority features in the first sprint,
assuming you have the right technical and business resources available to work on
them. One final hint.
Many teams work best with short and focused sprints. Test this out to see if it works for
your team. Try things out during the first sprint and adjust accordingly. You can increase
or decrease the features planned in a given sprint to make things work better. Just keep
in mind, the overall duration of the sprints and the project should remain the same.

Deriving Your Risk Management Approach

As with traditional projects, risks should be assigned and assessed against specific
tasks in your plan or specific features in the agile environment. An agile project, the
other way to manage risk is through the features you assign to each sprint. If you have a
team that is new to agile, you canlower the project risk by making the first couple of
sprints easier. For example, let's say you have 50 features planned for the first six
sprints and you'll have a product ready for implementation at the end of the third
sprint. In that situation, you want to make the first sprint lower risk by working on easier,
less complex features.
Assuming the first sprint went really well, you can work on more difficult features in the
second sprint. If your team requires more practice at working in an agile environment,
then keep the features more simple. In this example, any features that require a lot of
cross department communications, advanced technical capabilities, or are extremely
intricate to produce, should be moved to a subsequent sprint. Allocating features to
sprints in this way reduces the overall risk to the project by providing an opportunity
for the team to get used to Agile Techniques to work on being a collaborative team and
to build their confidence.
Now let's say you have the same scenario, fifty features to complete over six
sprints. But this time you have team members that have Agile experience and they've
worked together in the past. In this scenario, the best risk approach is to handle the
most difficult features in the first sprint. You might as well complete the more difficult
features first, to ensure you know what you're up against for the project as a whole. You
can also learn from any difficulties you have, which should help you avoid surprises in
later sprints. So, your risk management approach needs to vary based on the
agile experience the team, or your company, has to apply to your project.
Another risk management approach is to adjust the number of features you intend to
produce in each sprint. It usually takes two to three sprints for an Agile team gets into a
good rhythm, and becomes fully productive. This is true, even for teams with
experienced Agile team members. Each team needs time to learn to best work
together. Based on this, you should reduce the quantity of features to be completed for
the initial sprints until the team is one hundred percent productive.And lastly, you should
always focus on risks specific to the business.
If the business is not used to agile technique, and receiving a product in many
implementations.This is something the business will need to get used to. When creating
the release plan and trying to mitigate risks, you'll need to work with the business to
determine the best sequence for implementing a given set of features. Business impact
is a critical thing for you to consider. This may change the priority of the feature
list. Sometimes the set of features that are the highest priority for the business might
also introduce the greatest amount of change and risk to the business.
It might be wise to move those features to subsequent sprint to allow the business time
to get used to implementing basic and simple features first. You can then look to create
and implement features that impact several departments or more radically change how
the business operates.

3. Speculating : Guiding the Agile Project

Collecting Requirements

Agile projects expect and are designed to accommodate change. Being able to identify
and document requirements throughout an agile project based on current business need
is a key ingredient to any agile project. During the speculate phase, we discussed
the use of index cards to document features. Now we'll discuss approaches and
techniques to document the features and requirements. A great technique is to have a
business analyst work ahead of the agile development team by one or two sprints. As a
sprint is being worked by the core team, the business analyst should be looking
ahead to ensure the set of features for the next sprint have been clearly defined with the
business.
In addition, if business needs have changed, the business analyst can work to define
new features that are desired or identify existing features in the back log that are no
longer necessary. There are several techniques to identify requirements. A common
technique is to utilize use cases. Use cases capture a diagram or picture to show the
relationship between an actor and the system or the process to achieve a specific
goal. An actor might be a person, a company or organization, a department, a computer
program, or a computer system.
Any entity that can make a decision. Use cases can be used to document requirements
for IT and non-IT projects. Here is an example of a high-level use case. The key
components of a use care are.The actor performing the event such as you going to
ATM, the system or process which the actor interacts with like the ATM, the overall box
which represents the boundaries for the requirement.
Anything outside of the box is out of scope. The inside of the box indicates the types of
things the actor can do with the system. Such as making a deposit, purchasing stamps,
checking your balance, and withdrawing money. The outside of the box shows the
various actors that can interact with the system. Such as an ATM maintenance person,
management who receive reporting information, and even a thief. Use case text can
also be used to describe the scenario in detail.
The use case process helps stakeholders imagine all the ways in which a requirement
will address their business needs via features. Another requirement's capture element is
the performance requirement card. These are similar to a feature card, but they describe
a requirement that is applicable to multiple features. For example, your accounting
department may have a performance requirement for the amount of time allowed to
process an incoming invoice.
For a help desk, the requirement could be each call will be answered within x minutes.
Shown here is a sample performance card. Each requirement will need to have a
unique identification, name or title along with a short description. The difficulty factor
assists the business in prioritizing the requirement compared to other requirements and
features. And lastly, the acceptance test section of the performance card describes how
to verify the requirement has been achieved once the product is developed.
Documenting requirements is essential for any project. With your agile project,
requirements will continually evolve. Having a business analyst work ahead of the core
team, will help you be ready for each sprint with just-in-time relevant features and
requirement information.

Designing And Running Your Stand-Up Meetings

The daily stand-up meetings are the heartbeat of an Agile project. This meeting is
crucial to the success of the project, as critical information should be shared to enable
roadblocks to be removed. The stand-up meetings should be about 15 minutes long,
sharp, and to the point. Having the attendees remain standing helps keep the meeting
short, upbeat, and active. All business and technical specialist team members should
attend along with the project manager, sometimes called the ScrumMaster. Ideally, the
project manger does not lead the meeting. Instead, team members will each provide
their update.
Have your team present their status in a different sequence each day. Having them
rotate who goes first adds energy to your meetings. Assign someone on the team to be
time keeper to keep the group focused. This may only be necessary until the group is
conditioned to the daily meeting format. 30 to 60 seconds per person should be
sufficient. The time keeper should be rotated for each sprint. Probably the hardest habit
to break is not to resolve issues during the meeting. Handle issues after the meeting,
ensuring only the necessary team members are part of the discussion.
Hold the meeting at the same time each day. Consistency is very important. Here are
some things for you to observe during the daily meetings. Is the team collaborating, or is
there tension in the air? Are risks surfacing that could impact future sprints? Is there a
common issue or problem that you can help resolve? After the meeting of course. Is the
list of issues growing? If Agile's a new concept to the team are some team members
struggling with the Agile process? As you can see there's a lot of valuable information
you can obtain from your stand-up meetings.
If you're paying attention, be alert and take action as needed. I suggest you always end
the meeting on a positive note. Have the team share any wins that were experienced
since the last meeting. For instance, did the business really like what they saw during
the product review? Did a technical team member work through a challenging problem
they're really proud of? Having team members share wins shows the team that progress
is being made and it keeps positive momentum going. If you have a small co-located
team and they're collaborating extensively throughout each day, you may find the daily
meetings less valuable as everyone's already aware of what's being shared.
In this situation, you could have the meeting less often. Maybe two or three times a
week, to ensure progress is being made, and to check the pulse of the team. On a
weekly basis, you may want to invite additional project stakeholders to the meeting. For
instance, business managers, technology managers and users of the product that are
not part of the core team could benefit from hearing how project is going and what
people are working on. The more engaged people are the better. I suggest you allow
five minutes of question time at the end of the meeting for the additional attendees.
It's amazing how important and valuable of 15 minute meeting can be. Concentrate on
making your stand-up meeting focused and valuable.

Controlling And Adjusting The Plan

Many people who don't understand Agile believe Agile Projects do not have control
mechanisms.That's actually far from the truth. There are Agile-specific techniques that
help you manage and monitor your Agile Projects. Scope is managed by the backlog
list. Scope is controlled by completing features to reduce the backlog list, and adding
new features as they are identified. The business in conjunction with the technical team
consistently reprioritizes to determine which features will be implemented during the
next sprint. These changes to the backlog list are common, however you
should remember the scope of the current sprint should always be locked down.
Once the list of features has been agreed for that sprint it should not change. Velocity is
the term used to describe how many functions the team is completing in the average
sprint. This can be calculated by examining previous sprints. Assuming the team
resources and sprint duration are kept the same. By understanding your normal velocity,
you can determine if your current sprint is tracking to that velocity rate. If you're not
tracking as expected, you'll need to start digging to determine why the velocity rate is
decreasing.
If the velocity rate needs to be adjusted downward for future sprints, you'll need to re-
plan and reduce the number of features to be completed in a given sprint. The benefit of
velocity is that it provides controls that allow you to understand what your production
rate is. And you can adjust your release plan or team resources accordingly. A
Burndown chart is a communication tool used to show the work left to complete in an
Agile Project. The Backlog chart compares features and the expected time to complete
them.
The X-axis represents the project timeline. The Y-axis is the work that needs to be
completed for the project or sprint. The time estimates for the work remaining will be
represented by this axis. The project start date is the farthest point to the left of the
chart. The project end is the point that is farthest to the right of the chart and occurs on
the predicted last day of the project or last sprint. At the start point the actual
work remaining is the total amount of work remaining.
As time progresses the Actual work completed line, here in red, can be tracked against
the Overall sprint plan, here in gold. So you can see if you're ahead or behind
schedule. You can then adjust the features to complete each sprint, extend the time and
cost, or re-plan the features you're going to produce to align the plan to your ability to
produce features. The Burndown chart clearly demonstrates if the project features are
being completed ahead or behind schedule, and when all features will be
completed. The key is using this information to continually monitor progress so you can
make adjustments, if required, to maximize team productivity.
If you use these simple control techniques, you'll have a very good handle on your Agile
Project progress.

Exploring : managing the building process

Controlling Without Interfering With The Build

The explore phase of the agile project life cycle is different from non-agile build life cycle
phases.Your role as a project manager is to observe and guide versus lead. You
actually take a back seat to the process and you lead via coaching. This can be one of
the more difficult adjustment for traditional project managers to make. You have to let go
of a bit of control. This is very different and difficult for some project managers. Rather
than seek control, your role is to clear roadblocks for the team. You can do this by
carefully listening during the daily stand-up meetings to identify issues.
You then take action after the meeting to follow up with people to move things
along. This allows the team to remain focused and productive on building the
product. Teams always need resources and I'm not necessarily referring to other
people. Teams need information and tools to perform their work, including access to
specialists and other things, like training. As the project manager, you need to ensure
the needs of each individual team member are being met so they can be productive.
One area where the team should always take the lead, is to prioritize the features and
estimate tasks. As project manager, it's your job to ensure these activities are
happening, and to assist team members only when they are struggling with this
activity. One of the most important ways to letthe team lead itself is to support their
decisions. Even if you disagree with a decision that has been made, sometimes it is best
to allow the decision to take its course, and learn from the outcomes that result. We
each learn a lot from our mistakes so allowing a few mistakes to happen causes great
growth opportunities.
With that being said, if you believe a decision will have a significant impact on the
project, it is best you discuss your concern with the team and alter their
decision. Sometimes, you have to support senior stake holders in addition to the team. If
Agile is new to the environment, you may need tospend additional time with
management to ensure they're adapting to Agile processes. Common problems to look
for are, is the customer not working with the development team on a daily basis for
effective collaboration, Has the customer been too busy to spend time with the core
team? Are managers confused about the iterative approach and concerned their
features won't be addressed? Spending some extra time with management can be
especially helpful during the first few sprints, and can calm concerns.
Concerns can also arise from the intensity of the agile approach. Productive agile teams
address this by adopting a rhythm or cadence. If a sprint is six weeks long, the work can
be very intensefrom weeks two to five as the product features are being developed. The
project manager should watch for stressors to ensure each team member is managing
their workload effectively. As project manager, ensure there are weeks that are less
intense, so the team can relax a bit, and get ready for the next sprint.
As you can see, the project manager is not the task master during the Explore
phase. Instead, they do everything possible To maximize the effectiveness of each team
member, so the team can be engaged and productive in a self-directed work team
manner.

Managing Constructive Collaboration

During the build stage, effective collaboration is essential for the sprint to be
successful. As project manager, you can do a lot to support the team during this phrase,
and ensure collaboration is working as desired. The plan, do, check, adjust, or PDCA
cycle is a great technique to foster collaborative behavior. Any time work is being
produced, team members should briefly plan the work with one another typically in
pairs. Complete the work, get it done, have the work verified by the other
person, checked, and if the result is not as expected take action to change it
immediately.
If, PDCA is practiced as each feature is being developed. There will be frequent
collaboration between the product developer and the customer. And, that is exactly what
you strive for. By design Agile Teams are intended to be co-located. However, the
reality is, that's not always feasible. If you're in the situation where core team members
are not co-located, you'll need to provide additional tools and techniques to ensure
collaboration is happening. In the envision phase video we discuss tools.
Make sure you provide tools that enable easy access to information for all core team
members. I've even set up a webcam in the team room which is fed to the other
locations, so the remote team members can always see what is going on. This helps
them feel part of the team as if they were there. Teams are more effective if they are co-
located, but good visual tools can assist with the lack of co-location. Make sure the team
meets face to face at least once to meet one another, ideally at the beginning of the
project as planning is commencing.
Another great approach is to work the first sprint together so the team really gets to
know one another. Core team members will make many decisions during the explore
phase. As project manager, you'll need to ensure team norms have been established
and agreed regarding how decisions will be made. It's best to establish a framework or
an approach for non-unanimous decision making. Here are some hints and tips. People
need to be encouraged to share ideas and be comfortable speaking up.
Each person has a responsibility to speak up and share their thoughts. Team members
need to listen carefully to the ideas being shared. As this could spawn other great ideas
and potential solutions. A decision can be made if a majority agrees. This stops the
group from going round and round endlessly. The rationale behind any decision needs
to be explained and understood by the team. Those who disagree with the decision
need to support the majority based decision.
Nobody has the authority to veto a decision. Unanimous decisions, though ideal, can
take longer to achieve. Taking that additional time might not be well-suited to the fast
pace of agile projects.You can agree that striving for unanimous decisions would be
allowed. But limit the debate time to ensure decisions are reached in a timely
manner. With this framework in place, the rules are known and the group can make
good decisions based on the information available.
As you can see, constructive collaboration doesn't happen by accident. It requires using
PDCA for daily interactions, effective visual communication tools, and agreed
team norms on how decisions will be made.
Managing Issues And Risks

All projects have to manage and deal with issues. The key is having the skills to handle
the problems as they surface. As project manager, you'll need to educate the team on
what to do when issues surface. Keep in mind that issue management is more about
relationships and how weinteract with one another as opposed to how we tactically deal
with issues. It's about building trust with one another, so that when issues do surface
you're comfortable having a direct and honest conversation about the
problem. Establishing techniques to have healthy conflict is very importantas issues can
then be resolved quickly using valid information.
Here are some good techniques to use for yourself and the team. Remind your team
members to attack the problem, not the person. Require team members to address
conflict with each other directly, in professional and respectful manner. Everyone should
bring facts to the table, not rumors, or hearsay. If your team members cannot come to
an agreement, ask them to present their scenario with well thought-out pros and
cons. Team members in conflict must then their information to you together, explaining
their counterparts' point of view.
This guideline is very effective, as many team members come to resolution on their own
as they're putting this presentation together. You should only make decisions when your
team has not been able to do so. When you do make a decision, make your decision
clear and provide the rationale behind your decision. Ask for their support, based on the
decision made. I like to post the top three project issues somewhere in the team room to
ensure the team is aware of the key project issues and to keep them focused on the
importance of resolving the problems.
Co-location is a key element of agile projects, however you also need to ensure the
team has the ability to complete some of their tasks in a quieter area. Issues can
surface if the team is co-located in one open space area where everybody hears
everything all the time. It could be hard to concentrate with lots of activities happening in
the team room. Provide cubicles, which can be used at times to complete intense work
activities, or allow team members to wear headphones inthe team room when they need
uninterrupted time.
When people have a good work environment they'll be more productive and better able
to address issues when they surface, as they'll be in a much better frame of mind. While
your team is working on their features, it is important for you to take a step back and
keep an eye on the overall progress and direction of the team. It's your job to look at
things strategically and ensure bigger issues are being addressed, and both new and
existing risks are evaluated and considered. If you have the space, post the top three
risks in the team room as well.
5. Adapting and closing: Fine Tuning to Deliver

Tracking Lessons Learned During Sprints

One of the best characteristics of agile project management, is the opportunity to obtain
feedback frequently and apply changes based on what the team has learned. The key is
asking the right questions, and using your project control tools, to ensure the project is
being reviewed with a critical eye. In the adapt and close phase, we discuss the things
that need to occur during the adapt phase. Here we will discuss some of the techniques
available to obtain solid feedback. The first trick, is to not wait until the adapt phase to
get feedback. In the team room, have an area where team members can jot down
lessons learned at any time.
Insure the information is complete, so you have the context. Keep in mind, you don't
need to know how you're going to resolve the issue. Just get the feedback written
down. Sample items include, it's taking longer to complete medium sized features than
planned. Daily stand up meetings are taking more than 15 minutes. I feel like I'm getting
nowhere as new features surface all the time.Then, when it's time to have the Lessons
Learned workshop at the end of the sprint, you'll have plenty of input to discuss.
Typically, your in-sprint list of items, will spawn other Lessons Learned ideas from the
workshop attendees.
Once you have all the lessons learned identified, prioritize the lessons learned
feedback, based on the impact of the project, and then determine how to address each
item. Focus on the team's high priority items. Here's an easy technique to prioritize the
feedback. Let's say there are 30 items to prioritize. Give each workshop attendee 10
votes, and have them vote for the items they believe are most important to the
project. They can spread their votes across several items, or put them all on one, if they
want.
The top priority items are the top vote-getters. Now that you've prioritized the list of
items that need correction, you'll need to identify the root cause of the problem, and how
to apply corrections. Sometimes the solution is painfully obvious. Other times, it could
be very difficult todetermine the best way to address the problem. Your facilitation skills
are needed at this time, to ensure everyone has a voice, and several good ideas are
collected from the team. It's best to allow ideas to flow, and encourage creativity.
Crazy ideas can sometimes become great solutions. If possible, have someone from
outside the team facilitate this workshop. This allows you to participate as a team
member. If you want to determine the level of enthusiasm surrounding a solution while
addressing lessons learned, I suggest you use the following technique, called the fist of
5. Each person votes using their fingers. 5 indicates they love the recommended
solution.
4 means they're happy with it. 3 means they could live with it. 2 indicates they have
reservations. And, 1 says they have grave misgivings. From there, you can can address
the 1's, and 2's to determine their concerns, and modify the solution until everybody
votes 3, 4, or 5. Whatever decisions are agreed, it is key for all project-related changes
to be communicated to the core team, and extended stakeholders to ensure any new
direction, is understood.

Accommodating Business Priority Changes

We know Agile is all about the business and adapting to their current needs as we cycle
through each sprint. However, there are things to consider when adapting to business
changes. Let's assume you have 100 features, and they have been prioritized by the
business, and you're planning to implement them over five sprints. From a technical
perspective, it might make sense to group the features differently between the
sprints. For instance, while features are being developed for reporting of billing
information, it might be easier and more efficient if you completed all reporting related
features in a given sprint.
However, if the business has deprioritized other reporting features, then the business
prioritization needs to be honored. It does mean, you need to ensure you have advised
the business about the impacts of their feature prioritization. You will have to re-estimate
the future reporting features, knowing the efficiencies have been lost from a technical or
resourcing perspective. For example, if all the reporting features were completed in the
same sprint, the work effort might take 100 hours.But with the reporting features spread
across several sprints, the work effort could be 115 hours, or 15% greater.
This is due to the amount of time it will take the resource to get their head around a
given topic each time they commence work on a feature. Here's another scenario to
consider. Let's say you were remodeling, carpeting, and painting the inside of a large
house. And let's think of each room as a sprint. The client has prioritized the sequence
in which the rooms are to be completed, along with the overall features for the
house. Air conditioning has been prioritized last as they don't know if they'll have the
budget for this feature.
And they live in an area where it's not warm very often. However, each room is
impacted by air conditioning as there are vents to be installed in each room. In this case,
it makes logical sense to do the air conditioning first. As project manager, you need to
inform the client regarding the impact. Usually in terms of costs or resources. If it will
cost 50% more to do the air conditioning last, they may decide to do it earlier, but it's up
to the client. In other situations, it may be mandatory to implement a given feature first,
as it is a prerequisite to other features.
Let's go back to the billing reporting feature discussed earlier. A prerequisite feature
would be theprocess for inputting billing related information. If the information is not
available in the system, then there would be nothing to report. And lastly, business
priority changes may cause a re-build of features. Due to the grouping of features, some
of the older features will need to be redesigned and changed to accommodate
the newer features that are being built and implemented. This is normal in Agile, it just
needs to be planned for.
When the release plan is created at the beginning of the first sprint, the subject matter
experts will need to review the sequence of the proposed features to determine design
and re-build impacts, to enable accurate estimates to be applied to the latter
sprints. With proper planning and foresight, you can maintain the key Agile principal of
the business controlling the priority of the features with a project team advising and
adapting the changes with each sprint.

Closing The Project

As you're closing the project, you start this phase with an overall focus to understand
and document lessons learned for the whole project. In agile terms, this is called a
retrospective. You may want to invite additional stakeholders to the retrospective, given
you are now looking at the project holistically. Once the project retrospective is
completed, you can now commence the final closeout for the project. You've reached
this point in the project based on one of the following conditions. All the desired features
have been implemented. Good for you. Or you've run out of time based on the original
agreed schedule Or you've run out of funds based on the original budget.
If you have exhausted your time or funds you'll have a few extra things to consider when
closing down the project. You need to review the backlog list and work with the business
to determine the importance of the remaining features. In addition, you'll need to find out
if there are new features the business would like to have implemented. If the set of
backlog features are important and there are additional new features to be considered,
it's possible a new project is warranted if the funds can be acquired. If the backlog
contains lower priority features, it is likely a new project will not be initiated.
In this situation, the backlog needs to be transitioned to someone who can impelemtn
thosechanges, if desired, gradually, versus via a project. Another approach the business
may want to take is, let's wait and see. If the backlog is important but they don't have a
lot of new features at this time the business may want to wait several months to
determine if new features surface and a new project is warranted. Regardless, it's very
important for the backlog list to be given back to the business so they can maintain the
list until future decisions are made.
In the adapt and close phase video, we discussed the administrative items that are
required to close out the project. Now we're going to focus on the human side of project
closeout. A team event is critical. Even if the project was not as successful as some had
hoped. End of project team events provide, closure for the core team members
and signify the project is over. Its a great opportunity to remind everyone why the project
was initiated, and to recognize what has been achieved.
If is new to the organization, its critical to discuss the benefits of what worked for
the team, and some of the sticking points that will need to be worked out for future
projects. People will need to be re-deployed to other projects, or return to their business
as usual operational positions. As project manager, it's important for you to work
with your core team members and their managers, to ensure each team member
understands when you no longer need them for the project activities, and what their next
assignment will be.
Keep in mind it could be an emotional time for team members as they transition from
your project to other activities. So they may be more distracted than normal. Project
closeout, can be easier for Agile projects given that retrospectives have been happening
after each of the sprints. You can focus on the overall effectiveness of the project,
versus all the details that occurred since the beginning of the project, and can reflect on
the improvements you have made, as individuals, and for the business.

Agile Tips and Tricks

Spotting Signs Of Trouble

Just like traditional projects, Agile projects can run into trouble now and then. Here are
some Agile specific techniques to look for potential trouble with your
project. Consistently check that the work completed matches the plan, and you do
not have leftover features added to the product backlog at the end of the sprint. This is
known as snowplowing. Snowplowing is likely at the end of the first and second sprint
when you are revising estimates to match team productivity. However, if this continues
you must meet with the team immediately to discuss and understand why this is
happening, and take appropriate action.
Another significant indicator of a problem is when the team frequently produces pieces
of a feature, then throws them away. This could be due to the development of features
that turn out to be a low priority, are not what was required or are incorrect, or need to
be revised based on receiving new information. Often the primary reasons for these
problems relate to the businessrepresentatives not asking the right questions to
understand the business problem.
Or the customer doesn't understand what you're trying to build, or you do not have
accurate information about the real business need. If you believe these are possibilities,
then you shouldconduct a product review with the customer to understand the root
cause of the problem. Based on the customer's input during this review, you should
revise the product backlog appropriately.Another focus item to avoid trouble is to
carefully watch team attendance at meetings. Are all your core team members present
and participating in daily team meetings and follow up activities?There could be valid
reasons for the occasional mental or physical absence by an individual, butrepeated
absences could be signs of a problem.
Core team member attendance at daily stand ups and retrospectives is critical for
effective communication and is a key to project success. You should speak to the
absentee core team member on a one on one basis. If they were the right choice to be a
core team member then a frank and open discussion and good leadership behavior on
your part usually leads to an effective resolution. Don't hesitate to bring the problem to
management if the absentee behavior persists.Another item to watch for is when you
use up the project buffers in your plan.
Doing this frequently can impact your release schedule and delivery date. The project
manager's role is to facilitate the flow of client valued functionality by managing any use
of the buffers. It is essential that all tasks are completed before the end of the sprint. So,
any issue that prevents task completion must be addressed quickly. The Issues Log is
an ideal tool for this. The log should record the date and description of any blockage,
and the reason for the blockage.
You can then review the size and number of issues in the log, and understand when and
how you are using buffers. The last item to think through when looking for Agile
trouble spots, are you the fixer of all the problems you see? Successful Agile teams are
self-organizing and self-governing. So you should have confidence and faith in the
team members, and leave some space for the self-governing to work. This means
resisting the temptation to be the fixer all the time. Agile approaches are powerful and
deliver great outcomes.
Careful monitoring of the common trouble spots can help ensure you will deliver
business values successfully.

Adjusting Management Technique

Let us imagine you have the perfect small pilot project where you could use agile
techniques. But it is the first time your organization will try using agile. If you tell
management everything will be different, they're going to be very nervous, so, rather than
create that nervousness Think about what is important to management and how you can
provide that within the agile process. This will enable you, bit by bit, to move managements
thinking from where they are now to where you want them to be. From my experience,
there are a few things that are priorities for management.

Solving the business problem with customer satisfaction. Maintaining control. For
instance, producing value within schedule and budget. And team morale. So let's look at
each of these, and how you can demonstrate them with agile approaches. Let's start
with solving the business problem with customer satisfaction. Before you start, make
sure the customer or product owner is committed to active participation throughout the
project. Without their input and collaboration and attendance at daily meetings, you'll
probably not succeed.
The customer defines the product back log and prioritizes features that solve their
business problem. As each feature is delivered or accepted by the customer, not only
are their business needs being met, but the organization is receiving the business
benefits faster, which should significantly impact customer satisfaction. Maintaining
control involves relationship management and talking to management. Understand what
reports and control measures they see as essential for them to feel comfortable.
Most executives care about the triple constraints of scope, time and cost
management. If necessary, you can use many of the reports and control measures that
are provided in traditional project management. With a slightly different format. For
example, in scope management, you can still demonstrate a defined scope, managed
with change control. However, instead of a change control board and documented
change requests, you will utilize the customer's input from product demonstrations
to add new items to the product backlog.
For time management, a tool such as MS Project is still useful for producing a Gantt
Chart with milestones. You can show the features within each sprint, the dependencies
between sprints for the entire project, and you can update this regularly for management
review. To provide confidence in your cost management, demonstrate that your agile
project has a fixed budget, limited to the availability of the people you have. Although
you will not track and report actual cost to budget in a typical S curve used in traditional
projects, you can show that both the customer and build team identify the cost of
each requested feature, and compare that to the value added to the business.
As features are delivered, you assess how much money is left in the budget, using
approved funds until nothing is left. Team morale with agile is often easy to
achieve. Good agile teams that have the right technical skills and are comfortable with
the concept of sharing project control. Typically operate as a high energy, supportive
team. Seeing agile approaches allow the team to deliver business value quickly, morale
usually is high early in the project.
Ongoing success at feature delivery continues to reinforce and enhance that
morale, and the team works more and more effectively as the project progresses. So, as
a project manager, if you take it slowly, and let the team learn as they go, most often,
motivation will be high, and the team will take great pride in their achievements.

Next Steps

The promise of agile projects is huge. As agile management techniques are relatively
new, you can probably increase your value in your organization with every agile project
you manage. What we've covered in this course is a typical approach to managing agile
projects. However, each project is unique. And being able to alter your approach with
each project, will help enhance your success.As they say, practice makes
perfect. Focus on helping your team to communicate with each other.And keep
management informed of the progress you are making.
And you will be on your way to project success. Overall, specific Agile techniques are
not as important as ensuring your whole team understand their roles, and your
expectations. As Agile is flexible, the techniques are flexible, and you should be flexible
too. Providing strong and consistent leadership for your team and management is key to
succeeding with your agile projects. Look for other opportunities to expand your
leadership capabilities. They will serve you well as you manage larger and more
complex agile projects.
Two great books that can help you are Agile Project Management by Jim Highsmith
and the art of Agile Practice by Bhuvan and Unhelkar. In those and other books you can
learn more about agile project management in detail along with how agile has been
rolled out in various environments. And one last reminder, there are a number of
organizations around the world that provide professional certifications for project
managers. Virtually all of them require information on thereal world project management
experience you have compiled.
So don't forget to record the approximate number of hours you have spent managing
projects, and be sure to include the project objective, project phase or phases you
worked on, along with a supervisor's name that can attest to the work you
performed. You may find that information handy at some point if you want to pursue
project management certification. I wish you the best as you manage your Agile
Projects. Each and every Agile Project that is delivered successfully helps all project
managers embrace these techniques.
Success breeds success, and I hope this course helps you and your team deliver
projects successfully beyond your expectations.