Agile project management is not a methodology but a mindset that focuses on change management, frequent feedback and value creation. It is particularly effective in uncertain, fast-changing environments, but it is not applicable to all projects. Agile operations are based on self-organising teams, clear roles and structured ceremonies, while traditional project management approaches retain their raison d'être.
In this post you can read about the following topics:
Content
Project management basics and evolution
Project management is not new. As early as the 1960s, the need to manage the creation and development of a large, typically unique product or service according to a controlled process was recognised.
The internationally accepted definition is that project management is the application of knowledge, skills, tools and techniques in performing activities to meet project requirements. However, we prefer the simpler "art of getting things done".
Like so many professions, project management has evolved over the years, sometimes organically, sometimes consciously. In the beginning, project management did not exist as a profession in its own right, it was often just a 'hat' given to an individual working on a project (even if not called that). However, over time, and as the complexity of the tasks increased, it became a fully-fledged role in its own right.
Project triangle: scope, time, cost
Whatever the project, there are three main factors that affect all projects of this kind.
These are:
- the scope (what to do)
- the time (when to deliver)
- the cost (how much it costs)
To this day, with little exaggeration, all projects are moving in this triangle, trying to balance and satisfy the customer's needs (everything, fast, cheap).
The appearance and limitations of the waterfall model
With the waterfall approach, which became widespread in the 1970s, the success rate of projects has increased considerably. This was because success could be achieved through conscious planning in a relatively predictable environment, which was then not changing too rapidly compared to today.
However, in the 1990s, this approach proved increasingly inadequate. As technology advanced rapidly and the number of projects increased, more and more work was found to be unnecessary, and delays and cost overruns became more frequent.
This recognition has given rise to a variety of methodologies other than waterfall.
Project management methodologies, approaches
With the development of project management, different approaches have emerged, which have been embodied in different methodologies. A project management methodology is a set of practices, techniques, processes and rules used by those involved in projects.
Today, wide range of methodologies have been developed, some "out of the box", but also some solutions developed at organisational level.
Methodologies grouped by change and delivery
If we want to group them, we basically define 4 types of approaches. This can be identified by the extent of change and the frequency of delivery, so the approach depends, among other things, on whether we want to deliver through one or two or more components, sub-products, elements, increments, and the extent of change we expect in the expectations or even in the environment, which is a common cause of these changes.
In our experience, agile approaches are most successful where we expect a high degree of change and uncertainty, and we want to manage this with, among other things, high creativity and frequent delivery, including feedback. This is where agile might be most ideal.
What is agile project management really?
In many cases we see that the understanding of agility and agile project management is different and often wrong. A common misunderstanding is that agile is identified with a specific methodology, when in fact it is a broader approach.
Our approach is that the tools, ceremonies and roles are part of the methodologies, and for the sake of example, the most commonly used Scrum framework is just one of many agile methodologies.
Agile approaches and methodologies
Agile methodologies include, for example, lean product development, eXtreme Programming, or any hybrid solution based on the same values. These methodologies may differ in terms of roles, processes, ceremonies, but they have one thing in common, and that is a mindset and a value focus.
Agility as a mindset
This is why we usually advocate that agility is a mindset, a way of thinking, which can be embodied in the lives of organisations and individuals in many ways. These values and the principles behind them are well described in the agile manifesto but although these seem infinitely simple, the way they are applied is not always clear.
To quote the manifesto "(...) we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
In many cases, the values described above are not sufficiently emphasized in projects, and their reinforcement can be achieved, among other things, through the appropriate application of agile project methodologies or the development of organizational agility.
However, it is always important to stress that not all projects should be managed along agile methodologies, we believe that there is still a place for traditional approaches, which we believe can be tailored along agile values.
Misconceptions and the realm of chaos
Agile methodologies provide a structured, organised operational framework. Chaos is the complete opposite, yet in many organisations we see operations that are wrongly attributed to agility. This is often the result of a misunderstanding or partial application of the agile approach.
The most common misconceptions are:
- Agile projects do not need to be planned
- Agile projects do not need to be documented
- Agile projects are completed faster
- Requirement owners have less work in an agile project
- Agile approaches are right for every project
- In an Agile project, you don't need to set a goal in advance, it will become clear as you go
- We do daily stand-ups, so we are agile
- As an agile project manager, I will have less work in agile projects
The latter is particularly interesting because we often hear from so-called “agile evangelists” that “there is no project manager in agile approaches.” We tend to disagree with this view. While it is true that this role is not formally defined and does not exist in the traditional interpretation, in our experience, with a different perspective, there can indeed be a place and value for agile project managers in the context of agile ways of working.
Differences between traditional and agile project approaches
There are fundamental differences between traditional and agile approaches. The methodologies are of course different in terms of process, roles and ceremonies, but the main difference lies at their roots, in the way of thinking.
All the elements of the triangle cannot „move” along the triple constraint described earlier, there must be a fixed point.
- In traditional projects, the scope (i.e. the "what?" question) is typically defined first and the planning process looks at how much time and cost we can deliver it.
- Agile approaches, on the other hand, consider scope as a variable. In other words, they consider a fixed time-box or budget and try to deliver the maximum (but still realistic) value to the customer by keeping within these bounds, and fix the scope only for the given iteration.
Role differences
Aspect | Traditional project management | Agile approaches |
|---|---|---|
Central role | The project leader plays a central role | Sharing the responsibility |
Responsibility for planning | The project leader is responsible for planning | The team decides on the amount of work that can be undertaken |
Implementation and monitoring | Responsibilities of the project leader | The team takes responsibility for the implemenation |
Decision-making power | High level of decision-making and authority | The team defines its working methods |
How the team works | Not self-organising | A self-organising, cross-functional team |
Representing the interests of clients | It does not appear as a separate role | Represented by the Product Owner |
Requirements management | Not specified | Prioritisation, documentation and acceptance by the Product Owner |
Team support | Not a separate role | Agile coach / Scrum Master |
Scrum Master task | Not applicable | Removing impediments, ceremony support, team protection |
Ceremonies and operations
Traditional projects work through meetings, while agile approaches use structured, goal-oriented ceremonies. They are designed to ensure transparency, collaboration and continuous learning.
The ceremonies may vary from one agile methodology to another.
The main ceremonies of the Scrum methodology:
- Sprint planning - The objective is for the team, in collaboration with the PO, to define the work to be undertaken for a given iteration along the client's priorities, commit to its delivery and plan the work for the iteration.
- Sprint - 2-4 week time cycle, during which the team works on the increments to be delivered.
- Daily scrum - Also known as the daily standup, the 10-15-minute daily ceremony is designed to ensure transparency, so that the team can see who is doing what, what has been achieved, what is still to be done and to voice any impediments that may arise.
- Refinement - To ensure that the work is sustainable, it is worthwhile to organise and prepare tasks beyond the current sprint at regular intervals. The main purpose of this ceremony is to have the right quantity and quality of tasks available for the next sprint planning, i.e. to give the team feedback to the PO whether the requirements in the backlog (for simplicity we will call it the requirements list) are clear, understandable, i.e. whether the team is able to estimate and plan with them in the next planning.
- Retrospective - Although this is one of the most important ceremonies, in practice we see that it is the one most often abandoned by teams. The purpose of retro is to improve and develop the process and collaboration, so there is a need for strong self-reflection, learning lessons and formulating specific actions that can be taken immediately. This can be a delicate area, as people are generally less comfortable talking about themselves and mistakes.
- Review/demo - At the end of each iteration, the team presents what they have created during the iteration, and the PO decides on their acceptance in this ceremony and gives feedback to the team on whether they are on the right track with the product.
The above are the main ceremonies used by Scrum, which are in the common interest to be effectively observed and implemented. In practice, we often see that teams "jump into" the sprint, there is no proper planning and preparation process before them. In business, this may also require a business case, product-level planning and release definition. The process for this can be very different, you can experience the process we use and in most cases have worked in our agile simulation.
Managing change and requirements in agile projects
Traditional approach
- Success depends on a detailed specification of the work to be done and the product to be delivered
- The scope of the project is set out in requirements specifications
- For larger projects, these documents can run to hundreds of pages
- In our experience, it is difficult to formulate requirements in a way that is understood in the same way by both the customer and the supplier.
Agile approaches
- Applies the principle of simplicity
- Does not prefer comprehensive, lengthy specifications
- It uses a concise, prioritised list of requirements, the product backlog
- The backlog contains the customer's expectations
- Typical elements: user stories, epics and spikes
- Other names may be used, such as themes or features
Requirement types and estimation in agile projects
In agile projects, requirements take different forms, depending on the level and purpose at which you want to address them. These elements vary in level of detail, but they have in common that they support team work and decision making.
User story
- Short „stories” describing the needs of customers or users
- Independent requirements in good cases
- They can take several forms
- They are testable and set a clear target
- A common form: „I as ... would like to ... in order to”
Epic
- Larger „packages”, which can usually be broken down into several user stories
- Their role is particularly important in pre-iteration planning
- They help you define the minimum expected functionality (MVP)
Spike
- Tasks that explore a specific topic
- Typically used to clarify technical or methodological issues
- Their implementation requires an investment of energy on the part of the team
Estimation in agile teams
- Estimation can be along different dimensions (e.g. story points, time or other units)
- The point is not the absolute value, but the comparison
- The goal is to decide which tasks fit into a given iteration
FAQ: Frequently asked questions about agile project management
In conclusion, we have collected the most frequently asked questions about agile project management.
What does agile mean? What is an agile project?
The agile approach is a flexible, adaptive way of working that focuses on managing change, frequent feedback, and value creation. Agile projects are implemented in accordance with agile principles, typically through iterative ways of working, continuous learning, and regular feedback loops.
Which organisations should consider adopting agile ways of working?
The agile approach is particularly beneficial in organisations where the environment is changing rapidly, expectations are not fully known in advance and incorporating feedback is key. In stable, highly controlled environments, traditional approaches are often more effective.
How long does it take for an agile transition to pay off?
Agile is not a one-off implementation, but a learning process. In the short term, there are often tangible improvements in collaboration and transparency, while real business results are typically seen in the medium to longer term.
Is it possible to run traditional and agile projects in parallel within an organisation?
Yes. Many organisations successfully manage a mixed portfolio of projects, where the nature, risk and uncertainty of the project determines the approach taken. Agile and traditional approaches are not mutually exclusive but can complement each other.
What are the most common reasons why an agile initiative does not deliver the expected results?
In our experience, the most common cause of failure is not the methodology but the superficial application of the approach. If there is no change in mindset behind the introduction of agile tools, operations can easily slip back into previous patterns.
Do you need external support during an agile transition?
Not always, but in more complex organisational environments it can be a significant advantage. An external expert can help avoid typical pitfalls, speed up the learning process and support alignment between teams and managers.
Does agile require change at the leadership and team levels?
Both. Agile is sustainable when the day-to-day operations of teams and management decision-making are aligned with agile values. Neither level can operate sustainably without the support of the other.
What is the meaning of refinement in agile projects?
Refinement (also known as backlog refinement or grooming) is the regular agile activity during which the team and the Product Owner together review and refine the elements of the product backlog. The goal is to ensure that the requirements are understood, sufficiently detailed and estimated so that the next sprint can be planned efficiently.
How can we help?
In recent years, our colleagues with experience in agile coaching, product ownership, development, and consulting/training have supported dozens of agile teams and organisational agility initiatives.
We are not agile evangelists, and we do not believe that agile approaches are the solution to everything. We believe that these tools can help in everyday work and that incorporating this way of thinking into day-to-day operations, to the right extent, can bring short-term success to projects and organisations.
If you would like to learn more about the fundamentals of agility, Scrum, or the Kanban approach, we recommend our agile project management programmes.
If you are a project manager, Product Owner, or a newly appointed Scrum Master and would like to try out the planning process and tools in a real project environment, we recommend our agile simulation.
Our training map for Scrum Masters and Agile Leaders is available here.
If you have any questions or are unsure how to proceed in this topic, please feel free to contact us!
