Most people when reading this article will say “those are the principles from the Agile Manifesto”! My belief is that these are principles of project management, and not just the agile framework. Let us look at these a little closer.
The first principle states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (Agile Manifesto, n.d.). Well, for years that has always been a principle for me even in traditional waterfall methodologies, and is easily done through iterations. Satisfaction to the customer is always a priority regardless of delivery schedule. One of the challenges I see often with agile teams is that often times the frequent deliveries are needed in order to fix something from a previous delivery so then the question comes down to is this really saving time or money? Definitely up for debate.
The second principle states “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage” (Agile Manifesto, n.d.). In my over twenty years of managing projects I have never turned away a change in requirements, in fact often I would spend time confirming there were no changes if the project ran in a traditional way. Much like agile, as long as the customer was willing to delay or replace something else, and was okay with the potential for additional cost or time, we never turned requirements changes away.
For the third principle it states, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale” (Agile Manifesto, n.d.). Again, as with the first principle this can be accomplished easily through iterations. Almost seems a little redundant.
The fourth principle states “Business people and developers must work together daily throughout the project” (Agile Manifesto, n.d.). Well, I have never been involved in a project where the business is not involved, and even working with developers when needed. As for daily there are many thoughts around this. Agile, as a whole, is supposed to deliver cheaper…but it sure seems like a lot of administration and meeting time is taking place. Definitely up for debate.
One of my favorites is “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (Agile Manifesto, n.d.). Ok, really do I have to say that this is the same regardless of framework being used? Any project would fail without the motivation, environment and support they need. But wait…isn’t agile about teams and not projects so are they somehow contradicting themselves? Food for thought…
This one really was surprising when it states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversations” (Agile Manifesto, n.d.). This almost made me laugh as we all know that face-to-face is always preferable and usually more productive, regardless of framework. This is something you learn even outside of project management practices.
Next was “Working software is the primary measure of progress” (Agile Manifesto, n.d.). I would surely hope that for any IT project that this is the ultimate goal. Although there are key performance indexes that are reviewed, the ultimate success is still working software.
Then we have “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely” (Agile Manifesto, n.d.). This one, in my opinion, should not be a principle. From a human resources perspective when are you taking the time to appreciate and celebrate the work that has been done? Is the expectation that it becomes a sweat shop so to say where it is just work? As for sustainable development, the goal is that the work being done is sustainable, and more importantly can easily be built upon, reused, re-purposed or tweaked. I will admit, this one confuses me as to what the Agile Manifesto really means by this.
We then get to “Continuous attention to technical excellence and good design enhances agility” (Agile Manifesto, n.d.). So again, do I really have to say that regardless of framework technical excellence and good design is always key to the success of the project or initiative? I would also argue that it enhances any framework regardless if Prince2, ITIL, SDLC, PMI PMBOK, or any others.
Next, we have “Simplicity—the art of maximizing the amount of work not done—is essential” (Agile Manifesto, n.d.). Again, regardless of framework simplicity is key. You never want to over process the process or have a process in place just for the sake of process.
This next one is totally debatable: “The best architectures, requirements, and designs emerge from self-organizing teams” (Agile Manifesto, n.d.). Ok, in my experience the best architects come from understanding a wide range of systems. The best people to gather requirements are those that are not so-called experts as they often make assumptions. Personally, I disagree with this statement as I see it play out every day. If there is an architect for one particular product, they may be the best for that project, but by no means measure up to some of the architects I have had the pleasure of working with. In my current role, I see the same for requirements. Those that are self-proclaimed experts make assumptions often, and too often those assumptions are incorrect.
Finally, “At regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly” (Agile Manifesto, n.d.). In my experience, this is done regardless of framework. When I ran projects, we did this every project meeting, and I’ve seen it in the teams that I managed.
After reading this some of you may think that I am against the “agile methodology”. I am not. What I challenge you with is understanding whether or not these are really different methodologies at all. When you consider the word itself, agile is actually more of a method to complete a methodology; the principles are relevant regardless of framework; and agile is just a subject of activities done. If you think about it, ITIL, SDLC and Agile could all just be subsets of an over-reaching project management methodology as well as PMI PMBOK, PRINCE2, ITIL, SCRUM, SDLC, and all forms of agile are also just methods to complete the tasks.
What I am against is companies that take advantage of other organizations selling them on ”new” methods and instructing them to ignore some minimal type of structure or regulation such as SOX, PCI, or PII for example…and yes I have actually heard a vendor tell a company you don’t have to worry about SOX or anything and don’t involve legal in contracts just do it yourself. If you are a vendor that does this then shame on you. If you are an organization that is being told this, then be wary.
So…in the end…Consider the Possibilities.
Agile Manifesto, (n.d.). Principles Behind the Agile Manifesto. Retrieved from Agile Manifesto: http://agilemanifesto.org/iso/en/principles.html
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
Alyce Reopelle, the author of this article, encourages conversation; agree with her or disagree with her, it’s all still knowledge, and she is here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what she are doing, take a minute to share her articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
All articles on this site, this article is protected by copyright.
Author, Speaker, Project / Program / PMO Thought Leader
Over 20 years project management experience with a passion for helping organizations grow their PMO, their project managers, and their teams. My passion has taken me to the pursuit of a Doctor of Education, as I enjoy seeing the proverbial light bulb come on. I am a believer in continuous growth and improvement, and believe that an organizations culture and environment is what drives the growth of PMOs and all areas, and not the other way around.