How to adopt Agile for non-IT projects

This article is a step by step guide on how to turn an existing Agile framework/methodology that is limited to IT projects into something that is applicable to every project.

Basic Steps

Take the following steps, or get someone who can help you with:

  1. Find a Word version of the manual, or find someone to type it for you.
  2. Open the file in Word.
  3. Click on the Replace button on the Home tab of the ribbon.
  4. Type “software” in the “find what” field.
  5. Type “product” in the “replace with” field.
  6. Click on the Replace All button.
  7. Add the following line to the introduction: this framework/methodology is not limited to IT development, and is applicable to every kind of project.
  8. Save the file.

Great, now you have an Agile framework/method that is not limited to IT development.


The following can improve the result:

  • Repeat step 7, once per page; the same message delivered with different sentences.
  • Blame the original resource to be limited to IT development
  • Select a new name for your product.
  • Keep marketing your product.
  • Ask your friends to refer to your product when they are arguing with someone over the fact that Agile is not applicable to every project.


In certain cases, you may have problems with the step 6 of the method explained above; for example, The Scrum Guide doesn’t use the word “software”. It’s a shame, but don’t worry: just proceed to the next step.

Provide evidence

You might face difficult questions regarding your new product. In order to make it more authoritative, create at least two products, based on two different original pieces of work, and cross reference: in each one address the other as a great alternative.

You know the rest.

Build on top of it

If you have more than one product created like this, which I really recommend, it’s time to take the next step and create a new product that combines the two.

Don’t worry, you don’t need to produce any real content; just copy and paste the two existing products, and add an introduction. You can hire a ghost writer to handle the introduction for you as well.


Many people have successfully used this guideline before, but I don’t take any responsibility for any damages, either physically, or mentally ;)

Oh, don’t you have a PM certificate?!

Certificate not found

I used to be against certifications until 6 years ago. The main reasons were that:

I used to, and I still do, see many certified people who don’t know much about the subject. The certificate doesn’t really prove anything, so why bother? And,
I used to be good in the topic, and I didn’t feel like I have to prove it to others by passing an exam and getting a piece of paper (or PDF file).

But I gave up! You know why? Because…

Read the full article on Management Plaza blog.

My Talk at PM Fair 2015, Belgium

PM Fair
It might be a little late to announce it, but I’m going to do it anyway: I have a talk tomorrow at PMI’s PM Fair Belgium. The title is True Agility, and as it might be obvious, I’m going to talk about common misunderstandings about Agile development. The goal is to help the audience benefit more, by avoiding those problems.

For those of you who won’t be there, you can read about some of those points in the Agile & Scrum category of this website.

It’s not a common talk with PowerPoint presentation. It’s an old-fashioned talk, only with whiteboard, and a rather high level of improvisation. Let’s see how it goes.

Scaling Scrum with Nexus

Scaling Scrum with Nexus


Scrum is primarily defined for one team, with a maximum of 9 members. When more than one team is required, the system is called Scaled Scrum.

There are different ways of scaling Scrum. Unfortunately, most of them are focused on generic advice, not clearly defined, or are just too complex. has recently released their own framework for scaling Scrum, called Nexus. It’s explained in a short 11 page guide. In my opinion, it’s the best option, because:

  1. It’s simple, and straightforward. It seems like many forget that Scrum is supposed to be simple. I sometimes even suspect they make it too complex to impress the audience.
  2. It’s practical, and the defining guide is really a definition rather than a set of generic advice. This is, unfortunately, very common nowadays for authors to just provide vogue, generic advice when they are talking about Agile. Many even believe that Agile is nothing but that; while its core should be a framework/methodology. supports this basic need in a great way.

Let’s take a quick look at Nexus.

Read the full article at Management Plaza’s blog.

Scrum vs. Agile

Scrum and Agile are not the same. They are related, but different. Let’s see how.

Scrum vs. Agile

What is Agile?

Being Agile is the use of an adaptive lifecycle, which doesn’t fix, design, and plan the product upfront, but lets it evolve throughout the project based on feedback loops. It allows the product emerge from unclear requirements and environments, and therefore, is very flexible about changes. It’s faster, because changes do not slow it down.

What is Scrum?

So, how are you going to be Agile? You need to have a practical way of using an adaptive lifecyle; you need to have:

  • An step by step approach to the project, and some rules to follow
  • A set of roles and responsibilities to organize the project
  • A number of management products (artifacts) to support your development

These are provided by Agile methodologies or frameworks. Scrum is the most popular Agile framework.

Scrum vs. Agile

The relation between Scrum and Agile is like the relation between a beautiful painting and beauty. Beauty exists in a beautiful painting, but it doesn’t make a “beautiful painting” and “beauty” the same thing.

That’s the same with Scrum and Agile: Agility exists in Scrum, and Scrum is a way of being Agile, but:

  • Scrum and Agile are not the same,
  • and there are other ways of being Agile (using other methodologies/frameworks such as XP, Atern, ADD, etc.)