Agile, Traditional or Hybrid Project Management? (A Comparison)

0

+++ What Makes Agile Project Management So Popular +++ What You Should Know about the Difference to Traditional and Hybrid Methods +++ Which Method to Use In Which Case +++

By Johann Strasser                                                                                                      Read article in German

Everyone is talking about agile project management. Many project managers are expected to “be agile”, but they are often unsure what that means exactly. This article clarifies how to best choose a method. You will learn:

Looking Back: Traditional Methods in Project Management

When looking at the history of project management, it quickly becomes clear against which background traditional advance planning methods were developed. Tools such as

  • Gantt Charts for the representation of time (developed in 1910) or
  • PERT & CPM for dependencies (developed in 1958)

and organizations such as

  • PMI and IPMA (founded in the 1960s) or
  • Axelos / Prince2 (founded in 1996)

date back to a time when many large-scale projects of longer duration were the norm. At that time, we were mainly concerned with engineering projects that had a high mechanical share.

The goals were thought through to the end, at least theoretically, and the implementation of change requests was expensive. In this sense, changes were often regarded as disturbances. The goal attainment was the unalterable focus.

Therefore, traditional project management approaches offer numerous methods for steering and control. Even today, they work well for industries such as building, plant engineering, the pharmaceutical industry and a few others.

Our tip: Traditional project management approaches are likely to be suitable in the following cases.

  • The requirements are largely fixed from the beginning, and the work can be planned well.
  • In environments with high legal or regulatory requirements.

 

Methods of Agile Project Management Are Popular, But What Does Agile Mean?

Agile work methods in project management are more recent, and come from software development (with some inspiration from the ideas of lean manufacturing).

Agile methods have the following characteristics:

  • They are suitable for projects with shorter duration.
  • They support flexibility in goal attainment.
  • The focus is more on customer benefits than on an overly rigid adherence to goals.
  • Hence, changes are desired, if they bring about meaningful improvements.
  • They are easy to use and have fewer rules than many traditional methods.
  • In addition, they rely on a simple self-organization of teams and therefore a lot on trust.

The latter also becomes clear in the Agile Manifesto of 2001:

Agile project management, traditional or hybrid 1

Figure 1: The 2001 Agile Manifesto

The listed agile principles of the manifesto all put the emphasis on interaction. To a certain extent, they aim to get away from rigid workflows and bureaucracy.

Scrum – The Most Common Agile Method

With Scrum, a Product Backlog with User Stories replaces detailed product specifications. These describe customer wishes. What’s more, the Product Backlog is worked out step by step in the course of the development processes. Therefore, it is a “living” artifact.

Ever heard about Agile PMOs? Find more detail here.

In consultation with the stakeholders, the work to do is planned at the beginning of a Sprint for the period of the respective Sprint. Afterwards, planning takes place in the developer team on a daily basis in the Daily Scrum. At the end of each Sprint, you look back:

  • The results of the Sprint are presented to the stakeholders in the Sprint Review.
  • The team-internal inspection takes place afterwards in the Sprint Retrospective as part of the self-organization.

In the Retrospective, teams look at the methods and process they used as well as the team dynamics. If necessary, they determine improvements for future iterations.

In agile project management, one does not simply ignore the progress measurement either. On the contrary, progress must be assessed promptly to make it possible to react fast where necessary.

This happens, for example, with the aid of Burndown Charts. You can derive the speed of the team from these. This again can give you an idea whether the Sprint Backlog was appropriately filled or further improvements are necessary.

Agile project management, traditional or hybrid 2

Figure 2: Diagram of the Scrum method in agile project management and a Burndown Chart (on the right)

Beside this pure form of Scrum, further varieties exist as for instance Reliable Scrum (with Critical Chain elements) or other agile tools. These include, for example, Kanban Boards in which there are no roles, as they serve simply to visualize workflows.

Our tip: Does your project meet the following criteria?

  • At the beginning, the requirements are largely unclear.
  • The goals are to a certain degree flexible.
  • Only short planning horizons are possible.

 

In this case, agile methods could be a suitable approach for you. Scrum in particular can be interesting for you if you wish to work fast and flexibly towards your goal. To make it easier for you and your stakeholders to implement rules and a regular Sprint cadence, we recommend the appointment of a Scrum Master to support the process.

Motivation behind and Meaning of Agile Methods

So why were the methods for agile project management developed at all, and why would you need them?

The reason is that the circumstances of product development have changed. Today, many products contain an increasing amount of electronic components and software. You can recognize this even when buying a car: where you might have been able to fix things yourself in the past, ever more complex built-in systems have made this almost impossible today.

Learn more about Program Management Solutions in Product Development and R&D.

At the same time, the costs of software development have risen compared to the manufacture of mechanical components: there is a higher demand for variety in design and development. In a more and more interconnected world, it is also important to keep the customer benefit in mind. While ignoring customer benefit used to have little consequence in the past – this is no longer the case.

Besides, hardware is becoming increasingly standardized and therefore cheaper. Software, on the other hand, is becoming more and more extensive and expensive. Moreover, it is highly flexible, and changes are often permitted until shortly before the development deadline.

Goals in Traditional and Agile Project Management

Therefore, traditional and agile project management also differ in the way they treat goals. In traditional project management, goals were a stable element, and costs and deadlines often had to adapt to these. In the agile world, it is exactly the other way round.

Costs and schedule are fixed in the agile environment. So if the desired or planned scope is not feasible within these limits, it must be adapted. In the best case, it may be even be expanded, if you have time and money left at the end of the development.

Agile project management, traditional or hybrid 3

Figure 3: The different approaches for traditional and agile project management

In the traditional approach, the concept and the specification based on it provide the basis for the implementation. The acceptance and use of the resulting product only come at the end.

In the agile world, by contrast, you are more version-oriented. In an early phase, customers get to see a first version of the product. Hence, they can see and evaluate results from the outset. Accordingly, you adapt the following versions and thus the original rough plan to this feedback. Then, you continue the development.

As a result, you will find: the more intensive your collaboration with the customer is, the better and more customer-oriented the result of your work will be.

In the end, the risk of experiencing surprises is significantly lower than with methods that plan ahead for the longer term. The benefit for the customer increases step by step with each iteration.

Our tip: Tell your stakeholders from the start that agile methods require intense collaboration with the customer to work well. Make them, as well as your team, realize that these methods should be accompanied by a certain openness towards new ways of working. They also need to know that it is completely normal, if it takes time to establish these processes, and that the maturity level of Scrum teams only grows with increasing experience.

Agile project management, traditional or hybrid 4

Figure 4: Comparison of traditional and agile project management methods

The question you should ask yourself when selecting a method is: can I allow myself to be flexible in my goals?

Naturally, a product has to have certain properties to permit division into already usable components. This will be harder with a construction project than with software, since in the first case only the overall outcome serves a purpose at all.

MVP – Minimum Viable Product

This is what the idea of the Minimum Viable Product or MVP is based on. You supply your customer with a first prototype of the targeted product. Of course, it will not be particularly beautiful or equipped with all functions. However, the stakeholder can already use it for the desired purposes. This is what you call an MVP. In addition to an early profit from the use of the tool, you receive valuable feedback allowing you to optimize the final product.

Agile project management, traditional or hybrid 5

Figure 5: The road to the Minimum Viable Product (MVP): it should be already usable and similar to the targeted final product.

Clear Distribution: Traditional and Agile Roles and Processes

In traditional project management, there are roles such as:

  • Project sponsors
  • Project managers
  • Team members

All of them have clear responsibilities.

In Scrum, there are three important roles:

  • Product Owner
  • Scrum Master
  • Development Team
Agile project management, traditional or hybrid 7

Figure 6: Comparison of roles between traditional and agile project management (example: Scrum)

The Product Owner is a person who is specifically responsible for the product requirements and represents the stakeholders.

Scrum Masters ensure the implementation of the Scrum process. They support the team and focus on the removal of impediments.

Note: By the way, Scrum Masters can also get a certification to support them in their work and master the theory better. A Scrum Master certification is considered the most basic of all possible training courses. It can also be helpful for other Scrum team members.

The Development Team, the third role in Scrum, has a lot of autonomy. Its tasks include:

  • Estimating the workload.
  • Selecting its own tasks based on the workload.
  • Informing the participants, once these are completed (according to an agreed Definition of Done).

In agile methods, the team also provides important feedback in Reviews and Retrospectives, not just the stakeholders.

In Scrum, the roles are clearly distributed – but Scrum has a different focus regarding project responsibility (compared with traditional methods).

Our tip: Familiarize yourself with the Scrum Guide to learn more about the roles, before staff members take them on. Of course, your team members can keep their previous job titles and still act in Scrum roles.

Communication in the Traditional and Agile Environments

Communication is the key when roles interact. In traditional environments, this often happens in the form of status reports. The following meetings can take place:

  • Kickoff at the beginning
  • Planning and status meetings during the project life cycle
  • Project review with Lessons Learned at the end.

The thought behind the meetings described in the Scrum Guide is to have as few discussions as necessary. The meetings specified above include:

  • Planning
  • Daily
  • Review
  • Retrospective

These should suffice to cover all issues.

If stakeholders insist on formal reporting, you can refer them – at least in theory – to Scrum Boards and similar sources of information or offer them participation in the Reviews.

The Sprint Backlog shows transparently what people are currently working on.

Product demonstrations in the Reviews also ensure transparency.

Resource Management in the Agile Environment

Regardless of the method, you will not be able to do without solid resource management for project portfolios in the enterprise. For this purpose, you need a central database, which – in its complexity – only a Project Management Office (PMO) can coordinate.

Agile methods work with fixed product / project teams. This makes resource planning much easier.

At the project management level, however, this is not enough. In both agile and traditional methods, you must always consider absences and operations when determining the actual resource availability.

Different deadlines in traditional projects often lead to difficulties, if resources are scheduled for individual tasks in several projects. If staff members change from one project to another, this can lead to disruptions in the workflow. That might have a negative effect on productivity (see figure below, left column).

The transition of a staff member from a project to another becomes much easier, if you keep the makeup of individual teams constant for at least one Sprint. In the case of multiple projects, do match their Sprint lengths and cadence. In this way, changes can take place more smoothly at the end of a Sprint (see figure, right column).

Agile project management, traditional or hybrid 6

Figure 7: In traditional planning, the change between projects is more difficult than in synchronized agile planning

Our tip: Try to adhere to the same planning cadence across all projects for a smoother change of team members between projects.

Hybrid Project Management – Mixing Traditional and Agile Methods

Hybrid project management is essentially nothing but a combination of the methods described above. It can take different forms – find just four examples of hybrid models below.

Find further information on hybrid project management in this article.

  1. Agile concept and specification, traditional implementation
  2. Traditional concept and specification, traditional implementation for the hardware and agile implementation for the software (dependencies between both must be taken into account)
  3. Traditional concept, specification and implementation of hardware and software, agile integration
  4. Traditional concept, specification, implementation, and acceptance, but in regularly planned time periods (iterations) – hence no traditional-agile but a traditional-iterative hybrid. The point of this is: if all projects harmonize in their iterations, this is often an advantage for all.

Example of a Software Solution: Linking Microsoft Project to Jira

Now, how does one transfer all these suggestions to software?

In agile projects, the projects managers may work with Microsoft Project while their project team members track their tasks with Atlassian Jira. This is a case where the integration of MS Project with Jira would make sense.

In the transfer:

  • Phases in Microsoft Project become versions in Jira.
  • Work packages in MS Project become Epics in Jira.

In Jira, the Epics transferred from MS Project are planned in detail with Issues. The effort is added, e.g. in Story Points. Subsequently, the sum of the Story Points per Epic is transferred back to MS Project. Thus, the project manager gains clarity in planning and in monitoring the completion later

It is also possible to synchronize actual hours and status information from work packages in this way.

Get to know the integration of MS Project and Jira in more detail.

With the right solution for detail information in MS Project, you can moreover see the status of work in the current project at a glance:

Agile project management, traditional or hybrid 8

Figure 8: In MS Project, the product TPG ProjectDetails shows the status for each task. Through integration, these data come directly from Jira.

This is only one example of how complex project planning can be reproduced and controlled in software with the aid of selected methods.

Our tip: There are possibilities to interconnect proven and familiar programs. Rather than changing the software landscape in your business units, you should find out about possibilities of system integration. This allows all participants to continue working with the tool that is familiar and perhaps best suited for them. At the same time, decision-makers receive significantly better data.


A Selection of Important Success Factors for Agile Project Management

Should you consider using agile project management methods, there are a few important points to take into account:

  • The PMO at your company needs methodological expertise. It should be able to decide between traditional or agile process models. In each case, the PMO needs to be able to select the suitable processes.
  • Your company needs a system which is suitable in its entirety. Your stakeholders should also commit themselves to the selected processes.
  • For solid planning – even with agile methods – you should include only estimated tasks in a Sprint. Your Product Owners should prioritize tasks accordingly.
  • The agile autonomy for teams can also lead to surprises: you should be aware of this and be able to intervene where necessary.
  • As the first step to agile project management, it is important to establish rhythmic timing. You can introduce real agile working methods in a second step.

Conclusion and Recommendation

This article has demonstrated why agile project management methods are so strongly in demand at present. It has introduced you to the differences to traditional planning methods.

You have learned which method is most suitable for which case:

  • Traditional project management is suitable for projects that can be planned in advance and have clear requirements from the outset. Change requests can be met with good change management. In addition, it works well in project environments highly regulated by laws or regulations, for example.
  • Agile methods are best if you are still uncertain at the beginning of the project where exactly you are heading. Together with the customer, this is established step by step over several iterations.
  • Hybrid approaches are advisable wherever a project can be broken down into sub-projects that differ in their degree of plannability.

In conclusion, we can say: there is no “single right method” that applies to all projects. You must choose the appropriate method for the given project situation.

Which methods do you use in your enterprise? For which scenario? Write a short comment now.

Final tip: Subscribe to the TPG Blog Newsletter now and never miss another blog post.

 

print this article

Share.

Leave A Reply