10 Common Misconceptions about Agile Project Management

Over the last decade or so, the Agile movement has taken the software development world by storm. In this article you will learn 10 misconceptions about Agile projects that you as an Agile Project Manager must know. 

Agile has far-reaching benefits to software projects specifically and to projects in general. This framework has ignited many, many success stories. Teams adopting Agile have seen quality and productivity soar, and achieved greater success and growth more consistently than ever before.

While Agile has showered benefits on its followers, the movement has also marginalized some project roles and responsibilities. Key amongst them is Project Management.

Talk to any Agile project team member, and they will argue how Project Management is so Twentieth century. They will tell you they don’t need project plans. They will make you believe that they only look ahead up to the next couple sprints. They will implore you to understand that costing and estimates are unnecessary, even a hindrance, to successfully run a project.

10 misconceptions

1. Agile projects don’t need a plan

OK—let’s debunk what everybody thinks is passé first up, shall we? Too many Waterfall projects failed because they did way too much planning. And too many Agile projects fail because they do way too less planning.

Yes, Agile projects fail when they don’t plan. And yes, Agile projects need a plan.

By plan, I don’t mean an Excel spreadsheet with 250 rows’ worth of tasks, start and finish dates, task-level estimates, status, Baselines, Gantt charts. Agile projects require lesser upfront planning—you usually start with ballpark solution design, plans and estimates, however, none of these have been refined to guarantee the plan like the 250-row behemoth.

If you work for a medium to large corporate, your project will undergo a degree of initial scrutiny. The ‘draft’ artefacts I mentioned above will serve to support the initial scrutiny, and provide a platform to initiate the project once approved. This is directly opposed to waterfall-type projects that seek to ascertain close-to-accurate plans and estimates after approval and before kick-off.

Once an Agile project is in flight, planning happens continuously and inherently. The ‘draft’ artefacts are continuously refined through the duration of the many scrums and sprints that make up the project.

If you work for a company that doesn’t track project costs, cost vs benefits, or doesn’t need to commit to any dates to its stakeholders, good for you. If you don’t, you need a plan—yes, even if you work for a startup. Especially if you work for a startup that is trying to deliver a successful product and grow its business.

By the way, different projects, teams and organizations tend to hide the plan under different pseudonyms, but all successful projects, teams and organizations have one thing in common—they plan.

2. Agile projects don’t need upfront sizing

How do you decide whether to greenlight a project? One of the integral components of Project Initiation is estimation. Again, don’t get me wrong—I don’t mean a futile exercise at accurately estimating at task-level upfront.

When deciding whether to go ahead with a project (the ‘initial scrutiny’), it is absolutely essential to estimate—approximately—how much the project is going to cost end-to-end. When thinking about cost, the Project Manager is forced to identify all systems, teams, infrastructure and support necessary to complete the project.

Such a “level zero” estimate is invaluable in aiding project approval, and during delivery, it will help keep a lid on expenditure. More importantly, an estimate will help the Project Manager understand whether the project will deliver enough value to justify its cost.

3. Agile project management means no reporting

Reporting on Agile projects is different to how it is carried out on Waterfall projects. Other than that, Agile projects do report progress. It just happens that reports are driven by agile boards such as the burndown chart, sprint velocity, etc.

And to top it all, unlike waterfall project reports that in themselves are a full-time job to collate and generate (I’m looking at you, PMO), Agile reports—when set up right—can be generated more or less with the touch of a button.

Whatever tools you use for Agile Project management, you will have the ability to collate individual scrums’ progress and roll-up into a project progress report of your liking. You might even find that your senior leaders value seeing more visual and intuitive detail about the project’s vital signs.

4. Agile projects will report to Management through waterfall mechanisms

We’ve established Agile projects need to report progress. Let’s look at the opposite end of the spectrum.

If you have any experience of Waterfall, you know the Project Steering Committee is where key senior leaders review progress of a project—with the information provided ‘first hand’ by the Project Manager. I place first hand within quotes because—you know it—that’s a joke!

SteerCos aren’t as frequent as show and tells (usually), and don’t provide the level of detail that a show and tell can (most certainly). Committees don’t look at the detail when reviewing progress, and therefore fail to see the direction a project is heading until it’s too late.

Agile expects senior leaders and sponsors who have a vested interest in the project, to spend more time on the project than off it. This means participating in sprint planning sessions, to ensure their requirements are understood; attending show and tells, to ensure what’s being delivered meets their expectations; and regular touch-base with the team to provide continuous feedback.

Don’t send a PowerPoint—invite people to attend your show and tell. Don’t show screenshots—provide a link to the actual build environment; ask senior managers to log on and test the product themselves. That’s a more powerful and visual way to demonstrate progress than any other.

5. Agile delivers Speed

Wrong. Agile delivers quality. Speed is just an incidental offshoot, and not a given every time.

If you begin planning an Agile project with ‘I will have delivered the first release at half the time it would take with a Waterfall approach’, you’re going to fail. If, on the other hand, you begin by committing to ‘deliver optimal scope and quality given time and cost constraints’, pragmatism will help you strike that evasive balance among cost, time and quality.

As your team gets experienced in delivering high-quality work, they will assist you in planning better, cutting the fat out. The lean-and-mean project plan that delivers at hyperloop pace is an outcome of better planning and delivery. Not the other way around.

6. Agile projects don’t need documentation

There isn’t a lot to say about this one. A lot of people either mistakenly, or lazily, conclude that Agile projects don’t need documentation. Don’t believe them.

Documentation is crucial—be it Agile or waterfall. Documentation covers basics like maintaining a repository of information about the system, meeting internal and external (regulatory/legal) standards, etc. Documentation allows a project team to physicalize valuable knowledge gained when building a system.

When the dust has settled and you and your team have moved on to better things, documentation is what holds things together for day-to-day maintenance of the system. And there are other reasons—like the internal audit guy that’s trying to make sure you did your job the right way.

7. Agile projects can’t work to a deadline

In my experience, even regulatory projects that have strict deadlines have benefitted immensely from going Agile.

For instance, in complying to a regulation to make advisory fees more transparent to customers, my client needed to deliver a software project to a strict deadline—with major financial and reputational repercussions if they didn’t. We used Agile to deliver the project, and delivered it slightly ahead of the deadline and at 70% of the original cost.

8. Non-functional requirements can be dealt with at the end

This is a trap that Waterfall projects consistently fall into, and a trap even for Agile projects. I have covered Non-Functional Requirements in detail previously. NFRs define how a system should work (performance, accessibility, reliability, operability, etc.), and can sometimes take as much time as functional requirements to fulfill.

And at times, starting NFR delivery too late will result in unforeseen and major changes to scope.

9. Agile projects don’t need Project Managers

This must be the most hilarious misconception about Agile on this list. Overnight, poor adopters of Agile decided to do away with the Project Manager’s role, replacing them with myriad others—Scrum Master, Engineering Lead, yada yada. And none of these roles took responsibility for managing an end-to-end view of a project.

Name their role what you will—Programme Lead/Manager, Scrum Lord, Lead Scrum Master, Scrum Master. Inventing cool monikers won’t take away the need for a Project Manager from an Agile project.

The Project Manager’s ability to have and manage the end-to-end view is what keeps the various parts of an Agile project together and hurtling towards the same goal.

And finally…

10. Agile is a Project Management framework

Agile is a way of life—a cultural shift, not a set of rules, steps or processes like Project Management. Adopting Agile brings a level of ‘Plan-Execute-Feedback-Start Again’ discipline to projects. That doesn’t mean Agile needs a Project management framework of its own (despite what many others would have you believe).

Like I said previously, Agile projects fail—quite regularly. That is because they didn’t apply Agile the right way. A good Project Manager understands their job, and knows how to effectively use Agile to be more efficient. You don’t need an all-new project management framework to tell you what you already know.

Agile Project Management isn’t the name of a new framework—it refers to doing Project Management in an Agile manner, to help make software of better quality, and incidentally, at lesser cost and in lesser time.

Planning an Agile project isn’t an excuse to skimp on Project Management principles. Learning to differentiate Project Management principles and Waterfall practices is the key to success as an Agile Project Manager.

Do you have any more myths and misconceptions about Agile Project Management to share?

Discuss your views in the comments section below.