#4. Philosophies methodologies and frameworks
One of the first difficulties that a novice project manager may encounter is the ability to distinguish between philosophy and project management methodology. It can be very confusing, because over time, there have been many books written by different authors, some of which became bestsellers, and each book expresses a different opinion about what philosophy is and what methodology is. If also, the rookie project manager reads a couple of web articles, this will only add to the confusion, and he may well lose interest in this question, or he'll jump to a conclusion without understanding it completely.
And unfortunately, it doesn't stop there. In offices, conferences, and forums, one can come across heated arguments between project managers, disagreeing over whether X is a philosophy and Y, a methodology that brings no value to the community.
Bearing that in mind, let's take a thorough look at this topic.
First, we need to understand how the "philosophies" and "methodologies" are related to each other, so that we can begin to make sense of it all.
Let's start with a definition of science:
Science is a particular type of cognitive activity, the purpose of which is to develop an objective, systematically organized, and informed knowledge about the world.
Simply put, if a specific set of ideas is formed, and these ideas have not been previously described by other sciences, and moreover, these ideas are widely accepted in the world: we have a new science.
Management is a science that studies the control of intellectual and material resources.
Whereas science is based on facts and axioms, philosophy, which is a derivative of science, has an ideological, more abstract core. Philosophy is a belief system that changes our attitude toward life. Philosophy, in general, shows how we are guided by default when making decisions in our interaction with the outside world.
If you believe that people who wear sneakers or classic shoes are more talkative and trustworthy, then this is one of the elements of your philosophy, as it, to some extent, determines your attitude to people.
Philosophy in project management is a set of ideological principles that answer the question, "What do we need to take into account when managing a project." For each individual project, we can outline the philosophy that will meet our goals as well as the goals of the project.
Whereas philosophy shows us what we need to take into account in project management, the methodology is a set of principles and practices which enable us to answer the question, "How can I manage this project?" A methodology may consist of many different principles and practices that can be used selectively, depending on the specifics of the tasks to be solved.
A framework is essentially a ready-made, self-sufficient structure with predetermined rules and practices, the preservation of which, so the theory goes, should lead to predictable results.
In the context of project management, the framework is a proven, standalone workable scheme of actions that, in its pure form, does not require the addition of any other practices. However, we can choose a methodology that is more consistent with the goals of the project, consider what additional principles and practices we need, and add a couple. Then we can put them into practice on the project, bring it to a successful conclusion, and give some cool name to the framework approach we used (because it was a modified version of a framework though :) ).
Philosophy, Methodology, and Frameworks in IT-projects
These days, Agile is an extremely popular and highly appropriate philosophy in IT projects.
The philosophy of Agile is based on 4 points of a manifesto which was written and agreed by 17 independent IT experts back in the year 2001 (Italic = copy-paste):People and interaction are more important than processes and tools. A working product is more important than comprehensive documentation.Cooperation with the customer is more important than agreeing the terms of the contract.Readiness for change is more important than following the original plan.“That is, without denying the importance of what is right,
we still value more what's left. ”
As you can see, there is not a word about how to manage projects and what practices to use, although fundamental principles to bear in mind when managing projects have been clearly stated.
And despite this rather abstract introduction, Agile is by general consent regarded as more of a methodology than a philosophy, and the reason is that the creators of the manifesto, at the same meeting in 2001, also declared 12 Agile principles in addition to the 4 values:
We follow these principles:Customer satisfaction is our highest priority, thanks to the regular and early delivery of valuable software.Changing requirements is welcome, even in the later stages of development. Agile processes allow changes to be used to provide a competitive advantage to a customer.A working product should be released as often as possible, with a frequency of from a couple of weeks to a couple of months.Throughout the project, developers and business representatives should work together every day.Motivated professionals should work on the project. To get the job done, create the conditions, provide support, and trust them completely.Direct communication is the most practical and effective way to exchange information both with the team and within the team.A working product is the main indicator of progress.Investors, developers, and users should be able to maintain a constant rhythm indefinitely. Agile helps to develop such a sustainable development process.Constant attention to technical excellence and design quality increases project flexibility. Simplicity - the art of minimizing unnecessary work - is essential. The best requirements, architectural and technical solutions are born from self-organizing teams. The team should systematically analyze possible ways to improve efficiency and adjust the style of their work accordingly.
Here we see there are more specifics, and so, for an attentive manager, such an approach can be the answer to the question "how to manage?" thereby allowing us to assert that Agile is a methodology.
This combination of abstract and practical approach can give rise to confusion. But it means that we can use the values of the Agile manifesto, in tandem with the principles of a completely different methodology, and there will be nothing to worry about as long as our decisions are for the good of the project. Or vice versa, we can use Agile principles along with the values that our company professes. In other words: we use corporate values as our philosophy (the question "what to take into account?") and the principles and tools of Agile (the question "how to manage?") as our methodology.
Thus, the values that guide you (the question "what to take into account?") are the essence, your philosophy. In turn, the principles that describe how to manage a project are your methodology.
So now, we have a general understanding of what philosophy and methodology are.
There now follow some examples of the most popular methodologies for your general information. (You can go through the pictures quickly, just to improve your understanding of the overall picture. I will not go into details – if you wish, you can easily google any of the obscure terms):
Lean (Lean Manufacturing / Lean Development, often used and interpreted as a philosophy):
FDD (Feature Driven Development):
XP (eXtreme Programming):
And now a few outdated methodologies (I post them here because I spent time long ago collecting and filtering information on them):
If you wonder if it's worth it to read about outdated methodologies:
All methodologies had value at the time when they were created. They were developed by intelligent and competent specialists of their time, and I would not regret any time or effort spent communicating with such people. The fact that they came to the decision to draw up many rules to optimize the processes of their time is reason enough to pay attention to the material they developed. At any rate, there is no harm in studying these old methodologies, and the potential benefits are proportional to our skills in using the information derived.
So in conclusion, we see that one can choose to use just the values of the methodologies, making them our philosophy, or only the practices, infinitely varying them according to our needs.
Now let’s briefly go through a couple of the most popular frameworks and end the article with a lyrical digression.
As I have already described, a framework is a self-contained system with pre-verified instructions, which, if you follow them, should, in theory, lead to specific results. Frameworks, unlike philosophies and methodologies, are used by everybody. The reason for their popularity is that even if you know nothing about project management and understand practically nothing of what is written in this article, or have never even heard about philosophies and methodologies, there is nothing to stop you from simply taking a framework, putting together a team, hiring a novice manager and telling him/her "We will use the [insert name of framework] ” and wait for success.
Frameworks simply tell you what, where, when, and how to do it, and in some cases, what to fear, what to pay special attention to, etc.
At first glance, it may seem that a framework is all you need to conduct your business in this sector, but ... well, it’s not that simple ☺
If you master the skill of using the framework, this will enable you to run a small company that can engage in outsourcing and brings in some profit, working mainly on small projects.
And so the reader may well ask, “What’s the point of philosophy and methodology? Take the framework, memorize it, and conquer the world!” In fact, there are several reasons why it’s not so simple:
- Ignorance of the explanations regarding philosophy and methodology in this article will not help the project manager, because mere knowledge of frameworks will restrict the manager to the scope of small projects, thereby hampering his/her professional and career development;
- A command of high-quality management processes is only possible if the manager understands the fundamental components of modern management, as well as the history that led to this development;
- The world is conquered not by frameworks but ideologies based entirely on philosophy. There are many examples of this in modern world history. ☺
Let me give an example of high quality: a highly organized, self-contained team that has absolutely no internal conflicts, and which puts customer value and customer priorities above their own desires and ambitions. While it is comparatively easy to achieve such synchronicity and mutual understanding in a narrow circle of friends (e.g., a group of 3-4 people), as the size of projects (and, therefore, the team) increases, the lack of an ideological component (philosophy) and coordinated approaches to work (methodology) will lead to constant conflicts, inconsistencies and misunderstanding of top management decisions. Moreover, ad hoc solutions are no panacea: we could try to invent a process “on the fly”, but it will take a huge amount of time and nerves, which, perhaps, we could spend much better if we clearly outlined our principles and priorities from the very beginning.
But what if we are not interested in quality? We just want to have a company, employees, a bunch of small projects, and an intelligent expression on our face while sitting in our own office – in that case, the framework is sufficient for us. Moreover, there are many companies whose entire foundation rests solely on frameworks – in fact, more than half of the total number of outsourcing companies involved in software development.
And now, more about the frameworks themselves:
Kanban is very popular among modern companies, and it's also the subject of clan wars: its adherents wildly resent when Kanban is called a framework or methodology, because in its original form, in its original idea, Kanban is neither the one nor the other. Kanban cannot be considered a framework because it is too inferior and abstract for a framework. Still, you cannot call it a methodology either, because it contains many clear rules, tools, and instructions that are typical of frameworks.
Kanban was originally developed in the second half of the 20th century as a system for planning and managing production flows of Japanese industrial companies. At that time, it was called the method. In certain circles, to avoid a dispute, it retains that name today (and that, hopefully, concludes the clan war).
In IT companies, only the key tool from Kanban is used: its board.
In its classic form, the Kanban board has three columns. The first column is called “To Do” and it contains the tasks that need to be done. The second column - “In process” (or In Progress, Current, etc.) – lists the tasks that have been dragged into it from the “To Do” column to make it clear that they are in progress. The name of the last column is “Done”, and consists of the completed tasks, once they have been dragged from the “In Process” column.
In this classic form, team members pull tasks out of sheet lists according to the FIFO (First In - First Out) principle: tasks at the very top of the “To Do” sheet is executed first, and so this sheet is often used as a way of prioritizing tasks.
An example on a stolen picture:
Details in the form of my old notes, for additional reference:
TThis is the most common framework (in 2018, 56% of IT companies used it, and there is a growing tendency). We will be discussing it frequently in the following articles, so I will not go into detail here.
Hybrid - SCRUMBAN
As you can guess, this is a hybrid of Scrum and Kanban. Basically, Kanban uses the board and the FIFO principle.
A hybrid of Scrum and XP. From XP, the following elements are mainly used: TDD (Test-Driven Development), Code Refactoring and, Continuous Assembly.
If you would like to read more about the popularity of frameworks and methodologies, you can take a look at VersionOne’s latest public report (and in my opinion, they deserve praise for their philanthropic efforts):
In this article, we have discussed project management philosophies, and methodologies and understood their differences. We examined how philosophies, methodologies and frameworks relate to each other and discussed the meaning of each of these categories.
We considered the most popular elements of each category, and in general, I think it worked out quite well, isn’t it?
In the next article, we will learn about the different types of software development cycles, as well as focus on common aspects for Agile teams, gradually delving into the workflow.