12 Principles of Agile Project Management and How it Adds Value

Though Agile came into existence in the 90s, it only gained in popularity only in the last half a decade due to its increased adoption in enterprises across the globe. In today’s service-based environment where everything and anything is a project, PMI ACP Training has certainly become one of the most trusted ways to develop a project.
It was in February 2001 that 17 project practitioners from across the globe came together to address new ways to develop software. Though participants did not agree on many things, then they found consensus around 4 main values and 12 basic principles which were known as the “Agile Manifesto”.

4 Main Values of Agile

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change by following a plan

12 Basic Principles of Agile Project Management and How it Adds Value

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software:

On many occasions while developing software, the main priority behind why the software is being developed is forgotten. So as an organization, how are you able to relate to this principle?

As an enterprise, you can reduce the gap between requirements gathering and customer feedback by incorporating only a few changes at a time. This ensures that you have a better opportunity to provide a satisfactory product that meets the customers’ requirements.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage:

Previously we used to wait for ages to make changes. Agile prescribes you do not have to wait for the next system redesign to implement changes. You can shorten the time between understanding and implementing an important change. Moreover, do not get scared if you have to change something late in the development process, just go ahead and do it.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale:

Previously in traditional project approaches, it was all about documentation under the pretense of completing the requirements. But, then at the end of the project, there was nothing to show but just documentation. Agile clearly focuses on reducing the distance between planning and deliverables. The focus is more on creating the software than just planning for it which helps to improve the efficiency of project teams.

4. Business people and developers must work together daily throughout the project:

Agile is all about collaboration, where there are cross-functional teams working on a project to deliver the software to the customer that meets new market demands. This is a crucial process and this does not come naturally to the enterprise workforce. One can also use communication tools to work along with remote workers who are at different locations.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done:

Today, more and more project teams are being micromanaged which is detrimental. Project teams should know their responsibilities and be self-reliant. Ensure you assemble a proper team that can get the job done. Give them a couple of sprints to come together and let them on their own with minimal supervision to achieve the project’s objectives.

6. The most efficient and effective method of conveying information to and within a development team is the face-to-face conversation:

Put simply, you want to shorten the time between a question and its answer. This is another reason why co-location or remote work during the same hours is key in agile project management. When teams work together under the same (virtual) roof, it’s much easier to ask questions, make suggestions, and communicate.

7. Working software is the primary measure of progress:

Working software is one of the crucial metrics for an Agile project development team. It doesn’t depend on how much coding you have done, bugs you fixed or the efforts you have put in. As a good project team, you should be able to show working software in the end. If you can do that, then all other metrics become irrelevant.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely:

Project teams feel the major brunt of burnout when they work on a project for a very long time and this is a common problem in enterprises across the globe. To avoid this, Agile suggests the work be done in short sprints/iterations as excessive work can be detrimental and affects the overall quality of the project. Senior project members or scrum masters should first identify the right pace for team members to be more effective.

9. Continuous attention to technical excellence and good design enhances agility:

Development teams wait for an eternity to clean up their codes which are either redundant or confusing. Coding should get better at each sprint and teams can use scrum tools to review their code to find the best possible solutions. When you clean up your codes during the project, it saves a lot of time for your project.

10. Simplicity — the art of maximizing the amount of work not done — is essential:

As an enterprise, you have to keep things short and simple during a project. Be it project kick-off meetings, daily stand-ups, sprints, etc, can be kept short to achieve better efficiency. Avoid things that are mundane and keep track of your team by using the latest project management tools like Trello, Mashable, Basecamp, InVision, and more.

11. The best architectures, requirements, and designs emerge from self-organizing teams:

Some of the best attributes of a good Agile team are a team that takes its own direction; where team members are not constantly reminded of what needs to be done; a team that attacks problems and finds solutions. As a project manager or a scrum master if you are micromanaging them then that should be a straight red flag of a serious problem in the team.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly:

The term ‘looking over your shoulders holds true with Agile project management where you inspect and adapt all along. You will always find resistance to change. Just because you have done things in a certain fashion all these years does not mean that is the best way to do it. If there are better ways to move ahead in a project, the team should implement certain adjustments throughout the project lifecycle.

Agile methodology has all the right tools and techniques which cater to a project in this ever-changing complex business environment. By ensuring the project sticks to the 12 guidelines, Agile is basically helping your team and the project to remain on its due course.

Previous articleTop 10 Mistakes Made by Newly Formed Agile Teams
Next articleHow Lean Six Sigma Maximizes ROI of an Enterprise
Billie Keita is known for her exemplary skills in implementing project management methodologies and best practices for business critical projects. She possesses 10+ years of experience in handling complex software development projects across Europe and African region. She also conducts many webinars and podcasts where she talks about her own experiences in implementing Agile techniques. She is a Certified ScrumMaster (CSM) and PMI Project Management Professional (PMP)®, and has published many articles across various websites.

3 COMMENTS

  1. I’m working in SW industry for some 20 years. Worked as developer, tester, project manager, … I did not recognize that we worked for other reason than to satisfy customer? Before agile came in, sometime we used using pure waterfall process, sometimes using iterative process, depending of the customer needs and wishes, but mail goal always was to satisfy the customer.
    Change requests also existing for a long time, and it is always better to incorporate changes sooner than later.
    Deliver working software often, I agree completely. Quite often I worked with a customers that wanted one release so they can make acceptance and run the implemented software – telecom companies, for example. You cannot implement some RFC partially. Well, you can, but no value for the company to deploy such software. Of course you can demonstrate that you implemented some part, if customer wants it.
    Build projects around motivated individuals. I though this is preferred way, not for every methodology, but for every business?
    Face to face conversation is nice and encouraged in every project. Usually project manager, or someone other business responsible, want to have those decision in written format.
    And regarding simplicity and about to keeping things short and simple – I would say it is general, regardless the methodology used. Would say the similar about other stuff – micromanaging, attention to technical excellence …
    Don’t get me wrong. I love agile, I love prioritized backlog, I love product owner which is involved in the process from the begging, I love retrospectives (by the way we had project experience workshops also long time ago) … just have impression that agile is preached as a silver bullet which, only by using it, solve all the issues we had/have …

LEAVE A REPLY

Please enter your comment!
Please enter your name here