We need to talk about Planning on Agile Projects

The mistaken interpretation of Agile approaches is turning the Planning into an obsolete and outdated task. And it is very dangerous

It is not a secret that we are living on the boom of the Agile approaches. And, of course, it has it pros and cons.

We have seen this before: In the eighties and nineties, we saw the rise of reengineering, downsizing, outsourcing, ISO-9000, 9001, PMBoK… and other revolutions on management that overwhelmed us with their magic solutions and promises of delivering outstanding performance. And it is undeniable that they brought – and still bring – great results. When are correctly implemented, managed and improved.

The bad things on those times were not the new management tools and approaches. But the way they were marketed. On a transformation era, managers were desperate to improve the performance of their companies and were avid to buy any consultancy service that could offer them something that could make them shine over the crowd. They bought the whole package. But they did not buy the most important: The concept. The idea behind all these great tools. They bought the bright-shining toys. But many companies did not learn how to play with them.

The result was millions of dollars wasted, overstressed teams, bad processes implementation, and – believe it or not – decreased performance.

History is cyclical. It tends to repeats itself from time to time; it does not matter if it happens in the politics, economy, IT or management. Back in the 80’s and 90’s many opportunist consultancy companies and professionals saw in the rise of those new approaches a great opportunity to make some money, taking advantage of the desperate necessity of the companies to be on the “state of the art methodologies”.

I’m observing this happening again. Many consultancy companies are stating that planning is outdated and that you need to deliver things in an “Agile mode”. Time to market is everything. Why waste time on planning when you may deliver things faster?

First of all, it really bothers me when I hear thing like “Agile does not need planning”. That’s a completely inappropriate interpretation of the Agile Manifesto and a great mistake that may lead your organization to a disaster.

The same “bothering effect” I feel when I hear the “Agile Gurus” stating that “The Agile allows you to deliver a project in phases”. Phased deliveries are not an Agile invention. In fact, giant projects were phased back in the 60’s (and probably before that, but due to the lack of documentation we are not sure about this): Take a look at the space programs NASA held. OK, we did not have the terminology and the techniques that we have now. But phased deliveries are not something new!

But, what really bothers me is the fact that, many of these opportunist geniuses are selling out approaches that may be very harmful on the medium and long term to the organizations that buy it without taking the necessary caution.

Agile NEEDS PLANNING: If you don’t plan, you don’t know what and when you are going to deliver. The formalisms, the way we document the plans, the pace it is done may be different. But they need to exist. You need to know what you want to deliver. What are the project’s objectives. As a whole. After thinking the project in its complete scope, you may start to “chop” it down in partial deliveries that bring some gains. And, then, you can PLAN what you are going to deliver first. And how these “pieces” you are partially delivering will work together with the pieces that are going to be delivered later.

What I described above is the macro idea of planning. It is the minimum you need to have in mind to achieve any gain in any project. If you do not do that, you are not Agile, you are not managing a project. You are running a “Go-Horse” approach to deliver something that you expect that will result in any gain (after all, any gain is better than no gain at all).

My concern here is: Are these companies deploying “Agile” approaches with a questionable interpretation really collecting any benefit? Any methodology, framework, best-practice, if not implemented with a clear vision of why are being deployed tend to be frustrating, stressing and, as the time passes – forgotten.

Agile is a powerful set of tools and processes. They are very rich to be implemented only because it is the “trend of the moment”. Don’t waste it without understanding that being Agile is much more than kanbans, post-its and stand-ups meetings. It has to do with mindset, with maturity and culture changing. Above all, it has to do with cooperation, collaboration and teamwork.

A well implemented Agile environment has space to embrace everyone: SCRUM Master, Product Owner, Sponsor, Project Manager… Because all the tasks that you did before will still exist. They are going to be executed in a different way, it will be reorganized, roles and responsibilities will change… but the documentation, processes, deliverables, evidences, they still need to exist! Sponsors and partners like to know where their money is going to and when they are going to have it back. I’m sorry to say, but your status reports, executive dashboards, results estimations and projections and even schedules will keep existing. Laws, norms, will keep being created and evidences of the adherence of your Agile projects will need to be supplied.

The difference is that Agile approaches exposes the problems, gaps and bottlenecks faster than the traditional project management techniques. And, if you are not ready to act immediately after identify a problem, or your corporative culture does not like to take risks and embrace errors, maybe it is better to ensure that you really want to get into this ship. Because, in the short time, you are going to be involved in a total mess, as you deal with the natural challenge of changing. And this, if not well conducted, may jeopardize your initiative.

Start slow. Do not kill currently mature processes. Choose small projects. Try, make mistakes, take a deep dive on them. Correct. Try again… ask opinions of the project team. Write down your Agile process. Repeat the process in a bigger project, adjust the process… create an Agile Model Adherence Matrix. Don’t try to simple erase everything you have just to be on the top of the trend.

Remember: In order to keep your job, your company needs to keep working. And it means that the projects in progress need to be concluded.

And, please, remember: Planning is still an important part of Agile projects. And it will not change: If you think MS-Project is something from the past and you want to move everything to Jira, go on! But PLAN!! Have the vision of the whole project! Know the features, the expected gains. Prioritize the deliveries; don’t forget that they need to talk to each other. Provide estimations to the top management (your CEO DO NOT WANT to understand your burnout chart, trust me). They want estimations. Budgets need to be planned months before the fiscal year close. So, you may try to be as much modern as you desire. But, remember: Some things never change (or they take more time to).