The formal practice of Project Management has been around since the 1950s when Henry Gantt developed his famous chart. The Project Management Institute was founded in 1969. PMI developed many formal practices and definitions for Project Management. They began credentialing for the Project Management Professional Certification (PMP) in 1984. It has since grown to be the accepted standard for the formal practice ofPproject Management.

In 2001, seventeen thought leaders gathered at a ski resort in Utah to discuss their frustrations with the traditional practice of Project Management. These frustrations centered around the heavy focus on planning and documentation. There was little focus on quality, results, and an all-around philosophy of software delivery excellence. This resulted in The Agile Manifesto, twelve simple principles that defined a set of values and a defined culture around software development.

While The Agile Manifesto was originally focused software development, many other groups and industries have adopted the values and practices.

In the 20 years since then, many forms of agile practices have emerged. While many people call it “Agile Project Management,” it is actually a misnomer.

Agile is not a form of Project Management. Agile is a framework for approaching complex problems. Still people compare it to the traditional form of Project Management – Waterfall.

Waterfall Project Management

The waterfall method is so named because we do all of the work up front and deliver the entire project at the end. Much like a river flows a long and winding path to a water fall at the end.

Using the Waterfall method in a software development environment would typically look something like this: Business analysts would meet with business stakeholders for several sessions to gather requirements for a new system. This would involve one-on-one interviews and facilitated group sessions. Based on these requirements gathering sessions, they would document the requirements for the full system. They would then hold several sessions to review the requirements, get feedback, make updates and review them again. The ultimate goal is to get final sign off from the business community for the business requirements.

The business analysts would then meet with technical analysts and architects to present the business requirements. The technical team would then create a technical design for how the full system should be built.

These designs would then be handed to a development team. The developers would use the business requirements and technical design to develop a working system. When all the software development is compete, it goes to testing.

First, a testing team will perform component testing where they test each component. Next, they do integration testing to test how various components interact passing data back and forth. The next step is system testing where they test full systems working end-to-end.

When all of that testing is complete, the systems are handed off to a select group of business users for User Acceptance Testing (UAT).

This is where it gets interesting. After several months of design, development and testing by the software team, business users get their first look at the system. Many times (most times) the business users begin testing and there is an exchange that goes something like this:

User: This isn’t how we wanted it to work

Business Analyst: But that’s what you said. It’s written right here.

User: That’s not what I meant. I can’t use it like this.

This creates a chain reaction of rewriting the business requirements, redesigning the technical design, recoding, retesting, and resubmitting to the business.

The Role of the Project Manager

This entire process is managed by a Project Manager. The PM creates a project plan, assigns tasks to the individuals, and holds each team member accountable for their tasks.

When changes come about from new or changed requirements from the users, the PM creates a change order. Once the CO is approved, the Project Manager determines the impact to the project and determines a new end date and any additional cost to the project.

Agile Approach

In an agile approach, small portions of a large system are developed at a time and reviewed frequently with the business stakeholders.

First a product backlog is created. This is a simple list of features and functions that the business team would like to have. A designated Product Owner acts as a representative for the business team. The Product Owner defines the features and prioritizes them for the development team.

The development team selects 2-4 weeks’ worth of work and develops that functionality in a sprint: a time-boxed period where they will develop something of value. At the end of the sprint, they provide a demonstration of what they have completed to the business users. The business users provide feedback.

They take that feedback and the next group of prioritized tasks from the Product Backlog and develop for another time-boxed period. This goes on until they’ve provided enough value to the business.

Advantages of Agile

The great advantage of this is getting feedback from the business every couple of weeks. Instead of going down a long path based on assumptions made early on, you can validate with the business and right the ship early on, before too much work has been done.

Another advantage is that as business priorities change, you can adapt. If the businesses market shifts – say a pandemic hits – you can easily adjust. If new legal requirements are imposed, you can reprioritize what the team is working on quickly.

A Whole New Non-Management Approach

Perhaps the greatest advantage of agile, particularly the Scrum “flavor” of agile, is that there really isn’t any management. There are three roles on a Scrum team:

The Product Owner owns the Product Backlog. He or she works with the business team, defines and refines the requirements, and prioritizes what should be done.

The Development Team is self-managing. Based on the Product Owner’s priorities, they decide what they can do and how they will do it for the next sprint.

There is also a Scrum Master. This person coaches and educates the team on Scrum values and practices. He or she also facilitates the various meetings that are held. But no one “manages” anyone.

Where do all the Project Managers go?

The concept of the manager comes out of the hierarchical business world of the 50s. Based on all of the service-men coming back from World War II, the business world adopted the command-and-control style of the military. This worked well enough for a long time.

But many things changed along the way, causing people to begin trying different approaches. In the information age we realized that we had knowledge workers who smart enough that they didn’t need to be told what to do. We also realized that command and control was much more of a power structure designed to stroke the egos of those higher up in the hierarch than to actually achieve results.

This is more than a mere paradigm shift. This is a wave of agile Scrum adoption. It is being practiced in almost every industry. I could result in moving to a world of manger-less teams.

If that happens, where do all of the Project Managers go?

One trend has seen a natural shift of Project Managers becoming Scrum Masters. This may seem logical, but it is an entirely different set of skills. While Project Managers manage projects (it’s not all that creative of a title), Scrum Masters coach and facilitate. They have no authority. They rely on developing their credibility in order to influence rather than manage.

The role of the Scrum Master is not even a leadership role. Since the Scrum Team is self-managed, no one leads. Everyone just has their role.

There are many Project Managers who can easily make the transition. There are many others that thrive on the authority. They like the control of owning the project plan and directing the team on what to do.

There are some old dogs that will learn the new tricks of Scrum. There are some that won’t. My prediction is that the values and practices of agile Scrum will continue to permeate throughout the business world. Hierarchies will go away. Self-managing teams will be the norm. And the command and control freaks will have nowhere to go.

Are you ready for a world without managers?

If you would like to learn more about a career in Project Management, get Lew’s book Project Management 101: 101 Tips for Success in Project Management on Amazon.

Please feel free to provide feedback in the comments section below.

Image courtesy of ddpavumba at FreeDigitalPhotos.net