It doesn’t always have to be 100 %. How to use agile tools in conventional projects.

You hear it all the time: “You can’t make a project 100 % agile! There are always some parts that aren’t agile. It’s best to do hybrid projects.” But what constitutes a hybrid project? Is there even such a thing as hybrid projects?

Honestly, I'm not a fan of the term ‘hybrid’ personally. It’s just not clear what it means. The current consensus is that a hybrid project uses methods and tools from both worlds. So, if we use a risk list in conjunction with an agile project, does that make it a hybrid? Is that even still considered agile practices? Is a conventional project considered to be a hybrid if you hold daily standup meetings? You get the idea.
That’s why I just don’t like the term. What I do like is combining tools and methods from both worlds.

Right now, I’m working as Project Manager on a large international ERP project. COSMO CONSULT is a subcontractor, so we’re only responsible for a certain segment of the project. The project is being executed according to the waterfall method. The first phase of the project – analysis and design – has been completed, and the development phase is just getting started. 

In the first phase, we used agile methods. We had a “daily standup” on a regular, if not daily, basis to let all the participants get in sync with each other. It worked really well and was definitely more efficient than conventional status meetings. The standups were and are attended by everyone – general contractors and subcontractors alike. This way, everyone gets an overview of the project activities, problems are quickly spotted by the project manager, who is then able to respond efficiently. But just holding daily standups doesn’t turn this into an agile project.

The development phase was split up into iterations, each one ending with a system release. This is also an agile method. As for our team, we’re still using our agile project methodology. We implement agile values as much as possible. Yet the project is still being executed according to the waterfall model. So, it’s definitely not an agile project. Is it a hybrid project? Let’s not break our heads over this question. We’re not likely to find any satisfactory answers to it.
Whatever you want to call it, what happened was a reduction in the risks associated with the waterfall model. And that’s exactly what it’s usually about. You want to mitigate the risks of one model using tools and methods from another model. That’s what matters, not the term you use.

Gentle reader, you may be inclined to respond: “all of them?” And you’d be right. Every agile tool can easily be used in conventional projects with no problem at all. At the most, your conventional project will turn into an agile project. At the least, it will simply benefit from the use of agile tools. For example, regularly held retrospectives are a thousand times more efficient and effective than a lessons learned session at the end of the project.

It also makes sense to hold a sprint (iteration) planning meeting. Even if the scope is already defined, this sort of planning is more realistic. In addition, breaking the requirement documents down into user stories makes the implementation of the requirements better and more efficient. If you're going to use conventional methods in an agile project, however, proceed with caution. Tools such as risk lists are certainly useful. But a detailed schedule is not only unnecessary in an agile project – it’s actually detrimental. 

That said, I’d like to make one thing clear, because I can already hear the critics say that agile projects need project management. Yes, they do need it, and they have it, too. It just looks different. To a large extent, it’s also more precise. But what agile projects don’t need is conventional project management. The two don’t match .