Why Apply Agile Project Management Principles (part 1 of 2)

why-apply-agile-project-management-principles-1-of-2Many new projects seem to fail at the beginning, especially in hindsight, when looking back after months of development and product delivery progress. There have been many cases where agile projects did not even go over the Agile Manifesto which as most would should have been the first step. Beyond the 4 value statements from the manifesto, are the 12 principles that help guide the agile practitioner in keeping up with the 4 value statements. As we will see, all 12 were very cleverly worded and cover all angles that the agile mind would live by.

As part 1 of a 2-part series we will give further insight as to what those 12 principles are and why they are important for up-keeping in the context of agile project management principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (in non-software projects this would refer to product).

When we look at this first principle we see that customer satisfaction is the first thing that comes up, but that is not to say we need to do everything the customer wants outside of reason. This is why the second part of the principle mentions early and continuous delivery of valuable software/product. In all instances the customer relationship starts where ultimately there is a product to be delivered. If you note, the “early” part is also deliberate since it is essential to building the quick ROI for the client. The “continuous” part represents the iterative part about agile methods that allows for features to be built in with the value requested by the customer.

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

The requirements of an agile project are reflected by the Backlog (Product and Sprint). The backlog is the crux of the agile project methodology and workflow process, and is the basis of the work that needs to be done by the agile team. This principle of welcoming changing requirements in the format of a backlog allows for prioritization and re-prioritization at any moment within the sprint for the Sprint Backlog, and the Product Backlog throughout the agile project. Typically, the high level of transparency through daily scrums, and kanban boards, etc., allows for the agile working team to change requirements to reflect the ROI, resulting “customer’s competitive advantage” as needed and without the resistance that a project would have in a traditional waterfall setting.

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

The only way to gain return on a product is by confirming the results. Therefore the need to deliver “frequently” is tied to getting the most out of continuous delivery. This is part of the reason for preference to the shorter timescale, since that would provide more delivery cycles (iterations or sprints) and all resulting feedback loops from the customer and business. The other reason for preference to the shorter timescale is that it mitigates risks by allowing for developing time-sensitive competitive advantages (quicker time to market) of the software or product. When using lean tools the work-in-progress (WIP) becomes evident and quicker cycles prevent any wastes (so-called “muda”), and locks in the value of the delivered product.

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

When referring to working together daily this primarily refers to all agile team roles in the same room, face-to-face communications, and not so much on texting and emailing. Gaps in the daily interactions leaves room for unconfirmed value, and possible waste once business people and developers fall out-of-the-loop. The other key phrase is “throughout the project.” Some business roles, and developers may tend to fade in and out of the project if they are assigned to more than one project, and are spread thin throughout the course of the project. This leaves gaps in expectations and confirmation of progress when it is needed most.

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

When a project gets started and is ongoing, we need to make sure we don’t get in the way of agile team members that are experts in their domain. This is where we build in the element of “trust” and leave them to do what they do best. Giving them the environment and support relies on the scrum master role where there is a need to protect the agile team from outside distractions, and help remove blockages when they appear.

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

The key here is that people are to engage in “people-friendly” situations that promote easy communication with the least amount of “out-of-context” risk as possible. Body language makes up about 55% of communication, and therefore represents the most powerful component when compared to 7% verbal and 38% tone of voice. Since email messages can take on a tone the reader chooses to interpret them by, a message may be interpreted as malicious where in fact it could have been completely benign. The other advantage of the face-to-face communication is that everyone benefits from osmotic communication whereby knowledge and information is gained from background discussions from fellow agile team members. This presents an overall advantage since it effortlessly keeps everyone on the same page.

For the second part of this section  << click here >>

[Source for Agile Manifesto Principles: Manifesto for Agile Software Development]
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]


This work is licensed under a Creative Commons Attribution 4.0 International License.