Webinar
The early Agile Alliance drafted a series of “principles” which would guide Agile product development. These principles have always left room for interpretation (since no two projects are the same) and since we’re looking at Agile from the perspective of project management, we have reframed some of the principles accordingly.
For example, principles #3 “deliver working software frequently” is changed to “deliver value frequently”.
See below the 12 PM-oriented Agile principles, with their original wordings included for full context.
This is the yardstick against which all project success will be measured. Not how closely you meet project specifications or the contracted objectives—but how happy the customer is with the final product.
It’s therefore crucial to understand the customer’s desires at the outset, so that project execution can be geared towards satisfying them as much as possible.
Original wording: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In traditional PM, last-stage changes can often become heated exchanges centered around scope creep and changing costs. Within the Agile framework, however, requirements and expectations are constantly being revised based on actual project progress.
Thanks to your established and collaborative contact with the customer (remember your Agile values!) late-stage requests should be welcomed as a way to further improve the product, rather than a hindrance to your intended route.
Original wording: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This corresponds directly with the 1st value of Agile: working products over comprehensive documentation. Perhaps the most famous aspect of the Agile method is continuous delivery.
In a software context, this means continuously building working pieces of software. In the project management context, it means being able to deliver the customer visible progress at regular intervals. Exactly what this progress looks like will depend on the specific project.
Original wording: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The team members who are creating the value (engineers, designers, developers, etc) should never work in isolation from other stakeholders. There should be constantly flowing contact between the entire team. This not only ensures the project is progressing smoothly, but also increases the odds of delivering exactly what the sales team has promised—and what the customer expects.
Original wording: Business people and developers must work together daily throughout the project.
In other words, allow individuals to work autonomously. This movement for empowering employees and giving them whatever they need to get the job done (and eliminating micromanagement) feels quite new, but here we see it in the earliest Agile writings.
The idea is that you’ve hired experts for a reason. Ask them what they need in order to deliver their best work, and then provide it. This is an essential part of Agile project management. It increases engagement, productivity and every employee’s sense of purpose at work—all of which leads to a faster, better project delivery.
Original wording: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Instant messaging and email are the most convenient means of communication—face to face conversations are the most effective. Even back in 2001, the Agile Alliance understood the increased dependency on written communication and how it could become a problem.
Direct and frank conversations leave no room for misinterpretation. They’re faster, more reliable, and more honest. While instant messaging can suffice for quick one-to-one clarifications, calls and video conferencing are essential for team discussions. It may be initially more intimidating for some, but it’s ultimately far more effective.
Original wording: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
It’s easy to get bogged down in KPIs, metrics and milestones which, while they might make for an impressive “To Do” list, do not accurately portray your progress. On that basis, one of the Agile principles is that you should measure success by how well the product actually works, ahead of anything else.
So stop focusing on hours worked or problems solved, and always bring the team back to how well the product works.
Original wording: Working software is the primary measure of progress.
Even today, many workers and managers consider “hours worked” to be the measure of a good employee. However, the truth was well-understood by Agile’s founders: the pace of work must be sustainable and consistent rather than reckless or excessive.
The plainest example would be pulling late-nights to compensate for a lack of progress earlier in a project. Instead, maintaining an achievable and sustainable workflow will allow employees to function at their highest level more often, avoiding the need for heroics to get a project across the line.
Original wording: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
When your team is run superbly and all moving parts are synchronized and fluent, you can adapt and pivot with relative ease. It’s a very simple encouragement for a team to do its best work everyday.
Original wording: Continuous attention to technical excellence and good design enhances agility.
This is our personal favorite of the 12 principles because it highlights a massive flaw in the operational model of so many companies and project managers.
Doing more work does not necessarily mean making a better product. Look at it this way. Your team has a certain amount of effort they can contribute each day. If 30% of that effort is on unnecessary work, then the customer is only getting 70% effort worth of final product. The goal is to eliminate unnecessary or non-value adding work as much as reasonably possible. Keep objectives, tasks, solutions, and meetings as simple and short as necessary—no more and no less than that.
A simple way to self-monitor principle #10 is, for every action taken or decision made, to ask this question: does this add value? If it doesn’t, then scrap it and move on to another task.
Original wording: Simplicity—the art of maximizing the amount of work not done—is essential.
This echoes the sentiment of principle #5, except that the original principle was more heavily geared towards the software development environment. You should not only encourage your team to do the work the best they can, but also to volunteer ideas, feedback and criticisms of the broader process.
Encourage your team members to challenge the status quo and suggest improvements at any point in the project. Give your collective team, not just the individuals, the power to change and improve the project.
Original wording: The best architectures, requirements, and designs emerge from self-organizing teams.
In other words, Agile teams should always be flexible. You are no longer in the game of following prescribed rules and agreements to the letter: if you find a way of delivering the project more successfully—removing bottlenecks in your processes, saving costs, improving communications—it must be acted on.
Original wording: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
