In today’s world, there is often a heated discussion that can be found around the water cooler on what methodology is better: agile; traditional; SDLC; ITIL; hybrids; and the list goes on. Over the past few years ‘purists’ have sprung up saying that their methodology is the only way to successfully complete a project on time and within budget. However, I challenge you to consider the possibilities.
Consider that no matter the methodology, that there are five core components:
- You must have a requirement or a need that someone wants filled;
- You must design how you are going to meet that need;
- You must then build it to meet the need;
- Hopefully, you test it; and
- Finally, you put it into production.
Regardless of framework, these same five core components are there. Whether you do them in a traditional sense where you gather all the requirements first or gather for incremental deployment, it is just method to complete the need.
Now let’s consider the Agile Manifesto Principles. When I look at these, I see these same principles relevant regardless of framework used. Let’s look at them individually:
- Customer satisfaction is the highest priority through continuous delivery. This is possibly through scheduling iterations within a more traditional framework.
- Allow for changing requirements. I never stopped requirements from coming in regardless of framework.
- Deliver frequently. Again, this can be done through scheduling iterations.
- Business and IT must work together. Regardless of framework this is a necessity.
- Make sure the individuals are motivated. I always did this even when running a traditional waterfall.
- Face-to-face conversations. This is always the best way to communicate, and is not specific to just agile practices.
- Working software is a way to measure progress. True even in traditional methods.
- Promotion of sustainable development. Also true when running in traditional iterations.
- Attention to the technical excellence. EVERY project has a focus here regardless of framework.
- Maximize work done. Of course, even with Prince2 and Traditional.
- Best resources emerge from self-organized teams. This can really be debated as those that have more cross-functional experience are often the best all around.
- Team reflection. Happens through the life of any project.
For me, these principles are the same regardless of how the project is being run. So why is it that some people believe that these principles are only applicable to agile?
Now let us consider the team dynamics. Some may argue that teams that are self-contained gain more experience while others would argue that resources that have a greater reach into multiple areas gain more experience. In one instance, you could unintentionally create a single source of information which in the event of turn-over, could be disastrous for the team and the organization. On the other hand, the knowledge is shared among several, giving less risk in the event of turn-over.
From a human resource perspective, self-contained teams also offer a different challenge. Is it feasible that every team have a person that is specific to the need such as infrastructure, system engineer, developer, quality assurance, business analysis? In most organizations no because then there is a possibility of losing some of the consistency since every team then is at the freedom to do things their way. However, on the other hand, this gives them the freedom to just work as they want as fast as they can. This is a question that is centered around not control, but regulation and internal policies.
Regardless of method, regulations and internal policies must be considered. Yet, I have heard some vendors training people and saying ‘ignore internal controls and regulations’…some even said ‘don’t worry about SOX’. Hmmmm……makes one wonder does it not?
One thing that I have also seen is those that are practitioners of more traditional models have an easier time simply doing agile, because we have already done it but we called it iterations. For those that have only practiced agile, they can often have a difficult time with internal policies, regulations, and practicing traditional.
When it comes to documentation, it is still needed even in agile as it is for any framework. How the documentation is completed may differ since it is done in stages…again no different than when doing traditional iterations. There may be those that say documentation is not needed, but would you want to bury a treasure and not have a map to get back to it?
Some may find this article intriguing…others may immediately get defensive. This is why I challenge you to just look deeper. These are not so different after all if you peel back the skin of the apple a little bit. Understanding how these are related can also help in any transitions or activity scheduling. Understanding that these principles are the same, regardless of framework, will also demystify the differences that you believe surround you.
Of course, with new ‘methodologies’ come new tools. However, are these tools really able to provide for all aspects? And which tool do you use? Often some of these tools can only provide one service, leaving you dependent on another service. An example might be Jira and Confluence being paired up. One to provide the work sequence and one to house the information. Other tools such as Clarity provide it all in one. Making sure you understand the capabilities of the tool, regardless of what frameworks you are using, is very important as well. Don’t just buy it because it is shiny and new.
My thought: There is one Project Management Methodology and whether traditional, Agile, SDLC, ITIL, or others, these are simply methods used to complete the methodology. Even the definition states that a methodology is simply a system of methods that are used in an activity or study. So, in the end, I challenge you to consider the possibilities. I would be interested in comments and constructive conversation as I work to complete my doctorate on this very subject.
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
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
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are 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 we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
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.