High-uncertainty projects have high rates of change, complexity, and risk. These characteristics can present problems for traditional predictive approaches that aim to determine the bulk of the requirements upfront and control changes through a change request process. Instead, agile approaches were created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback.
Agile History
Today, agile methodologies are popular project management approaches that focus on flexibility. However, agile project management is a fairly new concept born out of the increasing speed of technological advances.
By the early 1990s, a small group of software industry leaders began developing and promoting innovative approaches to software development life cycle (SDLC) which embraced quickly reacting and adapting to changing requirements and technologies.
Rapid Application Development (RAD), Rational Unified Process (RUP), Scrum, and Extreme Programming (XP) became the new, highly responsive, and flexible software development methodologies used.
In the early 2000s, a small group of software industry leaders met in Snowbird, UT, to discuss these new methodologies. The term agile project management was coined in 2001 to describe the flexible nature of software developed in iterative stages and became a blanket term for the new methodologies. To distinguish agile software development from the traditional methodologies, the leaders at Snowbird, UT, came up with a set of values for using agile, called the Agile Manifesto.
What is Agile Project Management?
Definable work projects are characterized by clear procedures that have proved successful on similar projects in the past. Processes involved are usually well understood and there are typically low levels of execution uncertainty and risk.
High-uncertainty projects have high rates of change, complexity, and risk. Characteristics of high-uncertainty projects present problems for traditional predictive approaches that aim to determine the bulk of the requirements upfront and control changes through a change request process. Agile approach was created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback.
Agile project management is defined as a mindset defined by the Agile manifesto values, guided by the Agile manifesto principles, and enabled by various practices, the approaches and techniques being used by project teams today existed before the Agile manifesto by many years.
Agile approaches and methods are umbrella terms that cover a variety of frameworks and methods. Any kind of approach, technique, framework, method, or practice that fulfills the values and principles of the Agile Manifesto.
Agile Vs. Traditional Project Management
Regardless of the methodologies you choose, in both Agile and Waterfall types of project management, the goal is to produce a result that meets specifications and customer requirements. Another way of looking at the differences between Agile and Waterfall, is to examine the differences between knowledge work and industrial work. Industrial work uses defined processes, while knowledge work relies on empirical processes.
In a defined process, we can define the constituent steps in advance, and most industrial projects can be planned and managed using a defined approach. When faced with uncertainty or a new process, you will use trial and experiment to check what works, and the resulting process will be iterative and incremental, with frequent reviews and adaptation. The result is an empirical process, in other words, you will follow an Agile approach for this type of project.
Waterfall project management requires detailed planning at the outset, each stage is completed in full before moving to the next stage. Agile project management methodology employs short, iterative build and release cycles.
Agile Project Management Principles
The Agile Manifesto was designed to be a set of lightweight and guiding principles rather than set rules and formal processes. The Agile Manifesto forms the basis for the most methods currently in use today, including Scrum, extreme Programming, Lean, Crystal Methods, and others. The 12 agile project management principles of the Manifesto are the guiding force for all methodologies I am covering below:
Principle 1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. All Agile methodologies are looking for ways to bring value to the customer on a regular basis by communication and adaption. Customer satisfaction is the aim!
Principle 2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer’s advantage. This allows for some flexibility in the design rather pre pre-planning and going through a formal change control system every time there is an update to the scope of work. The aim is to Welcome Change.
Principle 3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. The goal is to produce something usable early and often. Frequent Delivery is about producing a usable increment in a short time span that the customer finds valuable.
Principle 4 - Business people and developers must work together daily throughout the project. In Agile project management, it is about having collocated teams, even if you are managing remote or virtual teams, the best practice is to Collocate them for at least one iteration if possible.
Principle 5 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. In Agile project management, teams are self-managed and self-organizing, and they are there because they want to be there.
Principle 6 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face to face contact is the best way to communicate. It ties into collocation as well as open and honest communication across the team dynamic.
Principle 7 - Working software is the primary measure of progress. Focus is on a usable increment that works, and not spending a lot of time on a software that doesn't work. The aim is a Working Software.
Principle 8 - Agile processes promote sustainable development. Sponsors, developers, and users should be able to maintain a constant pace indefinitely. In agile projects, to achieve a 40-hour work week and no overtime is possible. The aim is to have a Sustainable Pace.
Principle 9 - Continuous attention to technical excellence and good design enhances agility. In Agile project management, the entire team looks for ways to improve quality, the design, and the overall process on a regular basis. The aim is Continued Attention.
Principle 10 - Simplicity—the art of maximizing the amount of work not done—is essential. You need to keep it simple, no need to add extra features if they are not necessary.
Principle 11 - The best architectures, requirements, and designs emerge from self-organizing teams. The team decides for itself what it can and cannot do, and it works together on solutions. The aim here is to have Self-Organization.
Principle 12 - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. In agile project management, the team should have a constant focus on looking back to move forward. The aim is to have regular reflection.
Agile Planning
Agile projects call for adaptive planning. An adaptive approach acknowledges that planning is an ongoing process and provides multiple mechanisms to proactively update the plan. This is what distinguishes agile planning from a more predictive, static approach in which most of the plan is created upfront and re-planning is done primarily in response to exceptions to the plan and change requests.
In agile, planning is not a one-time standalone activity, iterative planning efforts continue throughout the development process, even done to the teams daily check in meetings. Agile methods are value-driven – they aim to maximize the delivery of business value.
This is why the product backlog used in agile project management is prioritized with high-business-value items at the top and why releases aim to maximize the value of the functionality being delivered. Agile planning differs from traditional planning in three key ways:
- Trial and demonstration uncover the true requirements, which then require re-planning. Instead of creating very detailed specifications and plans, agile projects build a prototype to better understand the domain and use this prototype as the basis for further planning and elaboration.
- Agile planning is less of an up-front effort, and is instead done throughout the project. Agile methods recognize that the level of risk and uncertainty on knowledge work projects makes extensive up-front planning problematic, so they distribute the planning effort throughout the project’s lifecycle.
- Midcourse adjustments are the norm. The product the business wants may be transformed by late-breaking change requests that are triggered by changes in the business environment. To stay on target, agile project management uses sophisticated adaption systems to gather feedback and make adjustments to the backlog and plans as the project work is being done.
Agile Teams
Agile teams focus on rapid product development so they can obtain feedback. In practice, the most effective agile teams tend to range in size from three to nine members. Ideally, agile teams are collocated in a team space.
Agile project management encourages self-managing teams, where team members decide who will perform the work within the next period’s defined scope. Agile teams thrive with servant leadership. The leaders support the teams’ approach to their work.
Team members in successful agile projects work to collaborate in various ways (such as pairing, swarming, and mobbing) so they do not fall into the trap of mini-waterfalls instead of collaborative work. Mini-waterfalls occur when the team addresses all of the requirements in a given period, then attempts to do all of the design, then moves on to do all of the building.
In agile project management, three common roles are used: Cross functional team members, product owner, and team facilitator.
- Cross-functional teams consist of team members with all the skills necessary to produce a working product. In software development, cross-functional teams are typically composed of designers, developers, testers, and any other required roles. The cross-functional development teams in agile projects consist of professionals who deliver potentially releasable products on a regular cadence. Cross-functional teams are critical because they can deliver finished work in the shortest possible time, with higher quality, without external dependencies.
- The product owner is responsible for guiding the direction of the product. Product owners rank the work based on its business value. Product owners work with their teams daily by providing product feedback and setting direction on the next piece of functionality to be developed/delivered. That means the work is small, often small enough to be described on one index card.
- The third role typically seen on agile teams is of a team facilitator, a servant leader. This role may be called a project manager, scrum master, project team lead, team coach, or team facilitator. All agile teams need servant leadership on the team. People need time to build their servant leadership skills of facilitation, coaching, and impediment removal.
Agile Project Management Tools and Techniques
Agile tools and techniques lend themselves most appropriately to systems and projects in which accurate estimates, stable plans, and predictions are often difficult to attain in the early project stages. Agile project management favors an adaptive, iterative and evolutionary development approach.
Using agile tools and techniques can help to: Self-organize and plan, communicate (within the team and with the rest of your organization), continuously improve the way you work, and get support from management.
Below I am listing some of the common agile tools and techniques that teams use. Others can be used depending on the project and team. Agile teams may also adopt unique combinations of techniques to support their framework and methodology. Examples include: Prioritization techniques, interpersonal skills, sizing and estimating techniques, planning techniques, information radiators, risk management techniques, collaboration games, and software engineering techniques.
- Remember the Future
This is a facilitated exercise that asks project stakeholders to imagine that an upcoming release or iteration has been successfully completed. They are asked to “look back” and describe what happened to allow the iteration or release to be successful.
Let’s assume we are planning a release six months out. We gather the project stakeholders, including the development team, users, and sponsors, and ask them to imagine that it is now six months plus two weeks from the current date. (The reason we ask them to imagine two weeks after the release date is because that is often how much it takes for the acceptance and implementation).
In the first part of the exercise, the stakeholders will look individually to write a report for their boss about how the release went, so the first 20 minutes, participants work alone to come up with their lists, recording each item on a sticky note.
In the first part of the exercise, the stakeholders will look individually to write a report for their boss about how the release went, so the first 20 minutes, participants work alone to come up with their lists, recording each item on a sticky note.
Then everyone transfers their sticky notes to a wall. Then as a team, they work together to group the sticky notes into associated clusters and remove any duplicates, this step can take another 20 minutes, the team will create headings to identify each group of items.
In agile projects, people struggle to generate a complete list of features and interim steps. Using this game, we will try to better understand the stakeholder’s definition of success and how we can achieve that successful item.
- Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the final product of the project, in other words parts of the expected final product. All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder. Every requirement and every change in the project will be reflected in the Product Backlog.
The Product Backlog is dynamically changing and improving; it is never complete. We do not wait until the Product Backlog is complete to start delivering the items; the first iteration can be started as soon as the Product Backlog is showing the near future.
The Product Owner sets a number of factors to determine the value of each item for the business; return on investment is usually one of the factors. All these factors will be summarized into one value (importance) and this is shown with each item.
The Product Backlog items will then be ordered based on their value, in a way that the higher an item is, the sooner it will be delivered by the Development Team. As the items located at top of the Product Backlog will be delivered sooner, they will also be more detailed and clear compared to the lower items.
Each Product Backlog item also has a work estimate. These estimates are solely done by the Development Team, and are used in comparison to the capacity of the development team in a single iteration, to determine the number of items that will be selected for that certain Sprint. Many additional information might be added to each item to help the agile team take control.
- Wideband Delphi
Delphi Method is a structured communication technique, originally developed as a systematic, interactive forecasting method which relies on a panel of experts. The experts answer questionnaires in two or more rounds.
After each round, a facilitator provides an anonymous summary of the experts’ forecasts from the previous round with the reasons for their judgments. Experts are then encouraged to revise their earlier answers in light of the replies of other members of the panel.
It is believed that during this process the range of answers will decrease, and the group will converge towards the "correct" answer. Finally, the process is stopped after a predefined stop criterion (e.g. number of rounds, achievement of consensus, and stability of results) and the mean or median scores of the final rounds determine the results.
In Wideband Delphi agile technique, the estimation team comprises the agile coach, moderator, experts, and representatives from the development team, constituting a 3-7-member team. There are two meetings: Kick-off meeting, and estimation meeting.
- Planning Poker
Once the team has a prioritized list of user stories to get started with, they need to figure out how much effort it will take to build them. They usually estimate the story points needed to build each story out as part of the iteration planning meeting at the start of each iteration.
Most often the team knows which stories are the highest priority by looking at the backlog, so they try to commit to as many high priority stories as they can in each iteration. One way the team does this is planning poker.
Most teams will hold a Planning Poker session shortly after an initial product backlog is written. This session (which may be spread over multiple days) is used to create initial estimates useful in scoping or sizing the project.
Because product backlog items will continue to be added throughout the project, most teams will find it helpful to conduct subsequent estimating and planning sessions once per sprint. Usually this is done a few days before the end of the iteration and immediately following a daily stand-up, since the whole team is together at that time anyway.
Planning poker is a very effective agile technique, in part because it is collaborative. When the team estimates effort for an item, each team member estimates the whole effort, not just his or her part of it. So even if you are not doing the work, you are estimating it… and that helps everyone on the team to get a better understanding of the whole project.
- Story Mapping
A story map is a high-level agile planning tool that agile stakeholders can use to map out the project priorities early in the planning process, based on the information available at that point. A story map is essentially a prioritized matrix of the features and user stories for the product that is being built.
Once it is created, it can be easily adapted to serve as a Product Roadmap that shows when the features will be delivered and what will be included in each release.
To create a story map, we start by listing a group of features for the product horizontally across the top of the matrix, from left to right. Down the columns, we arrange the user story cards in each feature in descending order of priority.
The first two rows of user stories at the top of the diagram are especially important, and they have special names. On the top row we place the stories that describe the essential functions needed for the system to work. This line is called the backbone.
On the next row, we place the stories that describe the smallest version of the system that will meet the customer's most basic needs. This line is called the walking skeleton. Unlike the items in the backbone, which are simply required, the items in the walking skeleton will depend on what the customer considers to be a minimum viable product.
- Variance Analysis
Variance is a measure of how far apart things are, or how much they vary from each other. Once the work has been executed, there will be a variance between closest estimate and the actual results. Much variance is normal and should be expected – we just want to keep it within acceptable limits.
When evaluating performance or tracking results, we should understand that there will always be a certain amount of variance due to the normal fluctuation. Variances can be classified into common cause variation and special cause variation.
Common cause variation refers to the average day-to-day differences of doing work, and special cause variation refers to the greater degrees of variance that are caused by special or new factors. In agile projects, the main point is that we should simply accept common cause variations on our projects, we need to only take action in the case of special cause variation.
- Trend Analysis
Trend Analysis is a particularly important agile tool for detecting problems because it provides insights into future issues before they have occurred. Although measurements like the amount of budget consumed, for example, are still important, such measurements are lagging metrics, in other words, they provide a view of something that has already happened.
Lagging metrics provide a view of the past that might be exciting for the accountants, leading metrics provide a view into the future, and they are more exciting to agile leaders. This is because leading metrics provide information about what is occurring now or maybe starting to happen on the project.
This early identification of a potential problem is more useful than lagging metrics, since it helps the team adapt and re-plan appropriately. Keep in mind that identifying trends is more important than analyzing the actual data values.
- Pair Programming
Pair Programming is about quality in the first place. It’s certainly not about the opportunity to always work with one's best friend. And pair programming is also not about 2 people writing the same code. Much of the success of pair programming, in how we have experienced it, lies in the roles and the rotation of pairs.
Iteration Backlog is made up of forecasted functionality and its decomposition in development work. A good practice we use is to have team members take the ‘lead’ in seeing a Product Backlog item being created end-to-end.
At the start of the day the pairs are formed, holding that the leads look for the right ‘partner’ to work with on the development work that lies right ahead. After lunch the pairs are rotated. The lead once again looks for the right ‘partner’ to work with during the second half of the day. This rotation offers team members the opportunity to get the best possible help for any given problem every half day.
Within the half day that a pair works together, they take up a second set of roles. The person holding the keyboard and mouse is called the ‘driver’. The second person is the ‘navigator’. The driver focuses on writing code, while the navigator minds respect for the overall direction and design.
Within the half day that the pair works together, the roles of driver and navigator are switched frequently. The control over mouse and screen frequently goes from one to the other, and back. It depends on the specific code being written, whether either of them has done this already before, whether someone has a great idea, etc.
The separation of driver and navigator assures that activities that a single programmer would do in a sequential way anyhow are performed in a parallel way (write code, compile, sit back and check, read again, verify coding standards, check naming conventions, consider the design).
The person minding the road, writing code, gets immediate feedback, even while the writing is happening, by the navigator who is minding the overview, the overall direction
As a conclusion, agile project management leverages both the aspects of iterative and incremental characteristics. When teams use agile project management methodology, they iterate over the product to create finished deliverables.
The team gains early feedback and provides customer visibility, confidence, and control of the product. Because the team can release earlier, the project may provide an earlier return on investment because the team delivers the highest value work first. Agile life cycles are those that fulfill the principles of the Agile Manifesto.
In particular, customer satisfaction increases with early and continuous delivery of valuable products.
