A number of people over the past years have been praising and cursing the Agile movement. For a number of reasons I think most of them actually miss the most crucial point, and for that reason I'll risk becoming just one more of them and do a post about Agile.

Some Myths About Traditional Project Management

Before I start talking about Agile, I just want to clear up some misconceptions people have about traditional project management (and by traditional I mean what became embedded in the Project Management Book of Knowledge).

You can't change the scope of a traditional project

That's the first naive argument that is made in the defense of Agile, and it's probably the thing that raises the most eyebrows in experienced project managers and engineers.

A good project manager, regardless of the size of the project, regardless of the methodology, will have several checkpoints along the way to make sure that what is being delivered actually fits the requirements, specially when the requirements are subject to change.

There is an entire sub-discipline for Change Management, which gives a lot of tools for the project manager to make sure that needed changes are incorporated in the project as coherently as possible. After all, the point of the project is to actually satisfy the initial requirements, the product being built is not the end goal, it's just how we meet those requirements.

On a traditional project, QA doesn't see the product until it's done

Sure, a lot of inexperienced project managers make that mistake, but this is not how you're supposed to run a project. You are supposed to build quality assurance mechanisms along the entire project, if you're raising a building, you make sure you perform the quality checks for the concrete in the foundation before you start anything else.

Quality Assurance is something that must exist through the entire life of the project, it's not a phase nor a milestone. There are also several tools to be used for QA, not just having a separate team validate the software, although independent auditing is always good.

On a traditional project, there are no early releases

I think the reason for this myth is that when people think of traditional projects, they think of things like bridges and skyscrapers, where it's really hard to make an intermediate release, but it's incredibly common for projects to actually have several milestones along the way where real products are delivered.

Doing intermediate milestones for your project is clearly a good idea. It improves the transparency of the project and it gives the chance for the customer to validate that what you built so far is as useful as expected.

How Traditional Project Management Actually Goes

Let's imagine you have a requirement of raising a building to host a company with one thousand employees. A building that can fit one thousand people but has no air conditioning is not useful, a complete building that only fits one hundred people also doesn't solve your problem, so you want your contractor to commit to deliver the full building within the budget that was agreed upon and within the expected time frame.

Even after the construction starts, you can still do changes to the project, sometimes changes happen because you change your mind (e.g.: build all open spaces instead of offices), but sometimes you need to change because of external reasons (e.g.: there's a sudden rise in the cost of a material, so you need to find alternatives).

Likewise, the Quality Assurance should happen even before the construction starts, by making sure the materials conform to their specifications before they go into the building, once you pour the concrete in the foundation, you want to perform tests on it and the same goes on along the entire project.

And finally, the customer will definitely visit the site several times during this process and will make sure that what is being built is coherent with his understanding, and if that is not the case, even when that was the scope definition, the project will be changed.

I'm pretty sure after looking at it that way, no one would say that what I described above can be understood as an Agile project. This is the most stereotypical case for traditional project management, it just so happens that traditional project management does not actually match the naive descriptions that some Agile evangelists ascribe to it.

So What Is The Point Of Agile?

The main difference between the construction business and the software business, in this context, is how effective our requirements gathering is. In the construction business, when you describe your requirements and an architect makes a sketch, the construction industry is pretty good at identifying all the underlying requirements as well as the breakdown of the cost for each.

The software industry, on the other hand, despite significant academic effort on that area, still has a really hard time capturing the requirements from the users, and when that is done with good diligence, we still have the problem that the requirements change too fast, specially when compared with the construction industry.

The point of Agile is, primarily, to admit that problem and then work on that assumption. The extent to which the methodologies embrace that is, however, beyond what most people realize.

There Is No Spoon^WProduct

The fundamental point of agile methodologies is to understand that there isn't a product, at least not in the sense that Traditional Project Management understands. If you're working with Agile methodologies, what you have is an amount of people working for a small amount of time, to achieve an immediate goal.

If you're starting an agile project, you're not building a three-story house, you're going to work on the thing that returns the most value to the customer that you can actually deliver within the next couple weeks. If the customer is living on an empty lot right now, maybe we should just build a wooden shack.

Sure, we should keep in mind that we will probably have to build a different structure, so we should probably place the shack in a corner of the lot instead of the center, but we won't really build the foundations required by a three-story house at all, we will just build the shack, because the customer will be able to move in and will no longer have to sleep exposed to the elements.

I understand that our over-engineering minds will be cringing right now with the idea of not building the right foundation, but that is actually the fundamental point. If, by the end of this first iteration, the customer decides that instead of starting to build the three-story home, he'd rather connect the wooden shack to public utilities, we get to that right away and deliver that, and now the customer has a livable home with running water and electricity, instead of still being in the elements while we build the foundation for the three-story house.

And this is where the trade-off of Agile becomes visible. Let's imagine that in the end of three years, we ended up actually building a three-story house, as we thought we would have to do. In that case the end-to-end project will have been massively more expensive, because we probably built and demolished entire houses a few times. This would be the worst-case-scenario for Agile.

If, however, after living for six months in the wooden shack, the customer decides to build a garden, a gazebo and never actually build the three-story house, we will have saved the customer a huge amount of money, not to mention the fact that the customer has a livable home since the first month, instead of waiting the full time that it takes to build a house only to find out that he doesn't need that much space.

The Customer Has To Move Into the Wooden Shack

This, I think, is actually the fundamental truth of the agile methodologies. The entire point is that it is a risk-sharing between the developers and the customers.

If all we're doing is developing in small sprints and doing demos of the product that we designed in the beginning of the project, we're still just doing traditional project management with a different Task Assignment methodology, and we're still risking building something that is not going to deliver the expected value.

If the customer doesn't move into the wooden shack, he may never realize that all he needs is a wooden shack with a garden and a gazebo. If we are not actually delivering the value to the customer of the project on each iteration, the customer will not be able to judge what, after that sprint, the thing with the most value will be.

The customer has to be as open as the developer to the idea of investing in an open-ended project, and that is actually, maybe not so surprisingly, very hard to sell.

Developers have to accept the idea that a customer may, at any point, say "what I have is already good enough", and shut down the project, regardless of what your vision for the whole system is.

Customers have to accept the idea that the developers need their participation, even if it means suffering through incomplete solutions as we find out what is the thing that is the most important to work on the next sprint.

Both Developers and Customers are very used to the idea of designing complete solutions to big problems, and it takes a lot of courage to say that we are willing to take a longer path just in case we're wrong.

Because the data tells us that we're wrong most of the time.