PMI-ACP Study Notes: Agile Fundamentals

[PMI-ACP® study notes] Unlike the traditional “waterfall” project management philosophy, Agile project management philosophy is geared to providing flexibility in response to the ever changing environment and requirements. Industries like software development and information technology are among the first to embrace Agile. This article outlines what makes Agile distinct from traditional project management approaches and how to implement Agile principles in projects. Knowing these would prepare you well for the PMI-ACP® journey.

Ten Agile Fundamental Principles

Below are ten fundamental principles common to all Agile frameworks or methods. These are the essences which make Agile different from waterfall project management.

1. Users Involvement
2. Team Empowerment
3. Fixed Time Box
4. Requirements At a High Level
5. Incremental Project Releases
6. Frequent Delivery
7. Finish Tasks One by One 
8. Pareto Principle
9. Testing – Early and Frequent 
10. Teamwork

1. Users Involvement

In Agile projects, users are actively involved in the project throughout itself development cycle. Inputs and feedback from the users are sought frequently to better understand the requirements of the users as the project evolves and circumstances change. This is among the most important principles of Agile.

The following are the advantages of users involvement:

• Reduces the reliance of detailed requirements documentation at the initiating stage of the project and thus eliminating the hassles of having to update the requirements documentation in details when circumstances change
• Allows the flexibility in adding / changing requirements fast and easily
• Better understanding of users requirements as the project grows and evolves with continual user input
• Detailed project status reports are not required as the team and users work collaboratively, the development progress is transparent to all parties. Users will be able to understand how the end product will look like and whether all their needs are fulfilled as the project progresses
• Users can help the Agile team to understand priorities of tasks and requirements
• Users become part of the project team and they are more likely to embrace the project outcome
• The Agile team and users work towards the same goal and share the responsibilities to make the project a success

Make this happen

• Make sure users are involved before the project starts
• [if possible] Pick a representative from the users that is a good communicator and flexible
• Co-location of project team and users for closer interaction or make use of collaboration tools / video conferencing
• If there is not a user representative (e.g. the users are your future customers), pick a member from your team to pretend to be the user as a whole

2. Team Empowerment

Three characteristics of empowered teams are:

• Self-sufficient – when forming the team, include all the team members necessary to perform all the required tasks and make decisions in a timely manner without any need to consult people outside. The users or the user representatives are integral part of the team.
• Collaborative – every member of the team works collaboratively to achieve the project goal as they are all entrusted with the authority to make decisions on the project. The success or failure of the project lies in whether everyone has contributed their best.
• Responsible – since the team is entrusted with taking care of the project, the team as a whole feel responsible for the scope of the project as well as the ultimate success of the final product, not individuals (e.g. functional managers or the CEO) outside of the team. Every member will perform their best to achieve overall success.

Make this happen

• Involve everyone in decision making right from the beginning
• Facilitate discussions among all team members to ensure everyone is always heard
• Determine whether team decision or individual decision is needed case by case
• Deal with team member conflicts or office politics proactively
• Form a trusting relationship with all team members by not micro-managing their tasks

3. Fixed Time Box

Unlike traditional project management processes in which the project managers would try to collect all the requirements from the very beginning and formulate a all-encompassing project schedule based on the available resources and the interdependencies of the project tasks, Agile does not make the assumption that requirements are clearly know at the start of the project. Agile embraces changes in requirements as a fact in the project life and believes that having a working software for the end users / customers to play with would help them to better understand their needs.

Therefore, Agile project teams work within a fixed time box. Tasks are assigned priorities with an estimated number of man-days. At the beginning of each “time box”, the team choose from among the list of top priority tasks a number of tasks to be finished by the end of the time box and work accordingly to give a working product at the end.

In normal projects, once an element of the “Triple Constraints” (i.e. time, cost and scope, aka “iron triangle”) is changed, the other two elements must also be changed in order to maintain the quality of the outcome. In Agile projects, only the “scope” from the triple constraints would be adjusted while the time and cost would be kept constant.

Make this happen

• Embrace changes (new requests, changed requirements, changed priority, etc.) and incorporate them with a change control process
• Assess new requests / requirements based on their priority in relation to the list of collected requirements and adjust the scope for each time box
• Fix the launch date of the deliverables so as to keep the team focusing on achieving the goal

4. Requirements At a High Level

Requirements for Agile projects are collected according to the following two ways:

At a high level

• Requirements are collected at a high level, just enough to give an idea of the required product for budget estimation purposes.
• Requirements are documented in the form of User Stories (showing how the users interact with the product) rather than detailed specifications.

On a just-in-time basis

• Since requirements may change along the progress of the project, requirements are gathered only when necessary for carrying out the tasks right away.
• Not to collect requirements for tasks several weeks away or more

Requirements are usually captured using visual methods (e.g. diagrams and storyboards) for better understanding across the team.  Storyboards shows how the users interact with the product with hand sketches, wireframes or annotated screenshots.

Make this happen

• Expect and prepare for changes in requirements.
• Only collect barely enough details for the requirements (can be in the form of documentation or storyboards) to estimate budget and carry out the work.
• Hold workshops to gather the whole team together to understand the requirements as a team effort.
• Record requirements in the form of deliverables (e.g. design the website is NOT a deliverable; interface design for the website is) and put each deliverable on a separate card so that the priorities can be easily changed when more requirements are added along the road.

5. Incremental Project Releases

“Incremental releases” means building on a previous release of the product / outcome. With incremental releases, not all the requirements of the users are to be met in a single release, only the top priority requirements as determined by the team and users. But with releases upon releases, all the requirements will be met ultimately.

The project runs through many iterations (cycles or sprint) of

1. getting requirements
2. development works
3. testing
4. releasing the product to users / market

The benefit of this approach is flexibility and ability to respond to actual needs instantly. Feedback can be sourced from actual users / market which can help adjust the direction of the project for new features / changes.

Also, the works and contributions of the project team can be appreciated by people outside the team as the many releases act like a progress report which in terms can boost the morale of the team. The organization can also benefits from the new features introduced instantly. Should there be any early termination of the project, there is aways something useful left.

Make this happen

• Establish the “core functions” (top priority requirements) to be included of the first and subsequent releases through discussion between the team collectively
• Make use of the MoSCoW analysis (Must have, Should have, Could have, Won’t have)
• Try to keep the number of core functions low (keep it simple rule) to enable delivery of next incremental release in a short timeframe (usually a week or two)
• Focus only on achieving the identified core functions in each iteration and finish all of them before the beginning the next iteration

6. Frequent Delivery

Make plans to enable the time between each incremental release to be short enough so that you can:

• realize value through early value delivery to reduce risks and attain stakeholder satisfaction (e.g. to gain organizational support)
• keep the momentum going by always focusing on the next shippable product
• get timely feedback from users / customers which will be gathered to adjust the project direction
• let users know the progress by a workable product release
• create competitive advantage as new features can be introduced real quick

Frequent delivery is especially suited for web-hosted services as there is little overhead for re-installation, upgrade or manage. The delivery schedule would range from a week to around 30 days for most Agile projects.

Make this happen

• Get feedback from users / customers (or through analytics) for timely input to help re-prioritizing the features to be included in the next release
• Plan a fixed release cycle so that the team has a common goal to work towards the deadline
• Let the whole company know the release plan so that they can work together to make the project a success (e.g. Marketing for press releases, Support for training materials)

7. Finish Tasks One by One

For the Agile tasks:

• Plan the reasonable amount of tasks for each iteration so that all tasks can be finished in each iteration.
• The tasks should meet the requirements of the “Definition of Done” which is established by the team.
• This enables frequent delivery of complete (ready for customer use) features.
• Completed tasks can act as a sign of progress check which keeps the team focused.

Make this happen

• Involve the users for testing
• Ask for sign-off of completed features from the customers
• Establish a standard procedure (e.g. develop – test – approve) for each iteration so that no steps are left out

8. Pareto Principle

• The Pareto Principle is also known as the 80/20 rule. It is a statistical principle that holds true for many things have a similar 80/20 distribution.
• In Agile development projects, the Pareto Principle applies to the fact that 80% of all development effort should be spent on the top 20% of the features that the customer actually ends up needing.
• Need to identify the top 20% of features that customers actually need and use most frequently.

Make this happen

• Educate end users and project stakeholders on the Pareto Principle.
• Prioritize the development efforts based on the Pareto Principle and try to identify the most beneficial and useful features.
• Work with the whole team for more accurate choice of features.
• Check the project scope with customers and stakeholders regularly to identify any changes in requirements.

9. Testing – Early and Frequent

• As each product release in an Agile project needs to be complete, each iteration needs to include a robust testing process to ensure the finished tasks are complete.
• The testing process is integral to the development cycle, there is no a distinct testing phase.
• Everyone in the Agile team is responsible for the testing of the product.
• Tests should be run time and again to ensure new feature would not break the functionality of existing features.
• The Agile tester should refer to the “Definition of Done” to guide the requirements of testing.

Make this happen

• Include automated tests for more robust and efficient testing.
• Include testing as a normal development routine.
• Involve the whole team to perform the testing.
• Integration tests are very important.

10. Teamwork

• Change is normal in Agile development, documentation is usually kept at a minimal.
• All the Agile team member should work together in a team so that any changes can be communicated with everyone.

Make this happen

• Collocation is one of the best tactic to ensure great teamwork.
• Use of a feature board / task board as a focus point / information radiator for the team.

Conclusion: Understand Agile for the PMI-ACP® Exam

These ten fundamentals of Agile project management philosophy form the basis of all Agile frameworks and methods. Though the PMI-ACP® certification exam would test you on different Agile implementations, like Scrum, XP, Kanban, etc., the above ten fundamentals are still valid no matter which implementation is selected.