There are a few trends that I’ve been noticing over the last few years when it comes to how clients manage their projects. The most constant seems to be the attempt to apply Agile methodologies, and by extension Scrum, to projects outside of software development. For the purposes of this article I’m going to use Traditional Project Management (TPM) to refer to the Project Management Institute (PMI) view of the world as defined in the Project Management Body of Knowledge (PMBOK). While the PMI doesn’t dictate a specific methodology, to most organizations this means “waterfall” where one phase of the project flows into the next like a waterfall, and only in one direction, because water can’t flow up a waterfall of course. It’s easy to see why everyone is hopping on the Agile bandwagon- Who could resist the allure of faster results, lower costs, and let’s not forget, no Gantt charts!

There are zealous advocates of some of the alternative methodologies out there, and they usually win over the PMO or executive sponsors with big promises and cite examples of failed programs that grew bloated and never delivered. Unfortunately, many organizations trying to be “Agile” struggle or fail because of a simple reason- they don’t grasp the fundamental differences between strict TPM by the book, what they are actually doing in practice that causes projects to fail to deliver value, and how Agile/Scrum is different from the two. They therefore end up trying to execute some form of “agile” traditional project management that doesn’t address the organizational issues that are causing their problems in the first place. Having a daily stand-up and no detailed project plan doesn’t mean that the project is going to deliver faster and it definitely won’t prevent the micromanaging executive from requiring 12 “touch-points” every week to change scope.

In this post I’m going to cover three major lessons to help Project Managers understand when it’s a good idea to apply Agile/Scrum methods to their projects and what principals they will need to embrace if they’re going to be successful. Over the next two weeks I will talk about the problems that Agile/Scrum won’t solve, how to actually launch the first project using these lessons and how to drive adoption of better Project Management. You can subscribe to get these as soon as they’re posted.

Agile Isn’t Always The Solution

Before I talk about how to transition from Traditional Project Management to Agile/Scrum it’s probably worth noting that sometimes this isn’t the solution. There’s a lot of great marketing material and books out there evangelizing Agile/Scrum as the Holy Grail and the only fix for a broken, old-fashioned methodology that was never meant to be in the first place. Waterfall is commonly cited as an example of a flawed, non-working model. This usually stems from some references to a 1970 paper by Winston Royce where Royce, the often cited father of the methodology writes, “I believe in this concept, but the implementation described above is risky and invites failure.” Not really a gleaming recommendation. Unfortunately this is only in reference to his introductory method and he goes on to describe the modifications which fix the flaws. Don’t believe the hype, Waterfall has it’s place but is often poorly understood and implemented. No method that’s poorly implemented will work well, Agile/Scrum included. I find it’s generally a good idea to use a phased, waterfall methodology when the requirements are clearly evident in advance, well defined, and stable and will use proven methods or technology. That’s not to say you can’t use an Agile/Scrum method to manage these types of projects, but you may find you don’t get the full value out of the method and there will be added benefits from the TPM structure.

Lesson 1: Agile/Scrum ≠ A project without a plan

To understand why many companies struggle to transition let’s first understand some of the key differences between TPM and Agile/Scrum and the challenges faced as Project Manager. The PMBOK takes a plan-oriented and activity-centric approach to Project Management. This results in a series of processes that have various input and outputs. The Project Manager must ensure that these intermediate project deliverables are planned and delivered at various stages of the project. Compare this with the Agile development process which emphasizes the production of tangible results as soon and as often as possible during the project life cycle, managing the team relationships and facilitating interactions. This means that the role of an Agile project manager is fundamentally different from a TPM Project Manager. The Agile Manifesto acknowledges the need for some of the same deliverables as the PMBOK, but doesn’t emphasize the Project Manager’s role in creating or controlling them.

This is a hard transition for many project managers to make. What I commonly see is that transitioning project managers either don’t make the switch (applying plan-oriented methodologies but calling it Scrum because there’s a Stand-up instead of a status meeting), or they assume that Agile/Scrum just means not having a plan. There is a difference between not having a plan and planning for what you know and can deliver in a set time.

Lesson 2: Knowing The Difference

Many organizations and project managers fail to make the transition because they don’t appreciate the differences between TPM and Agile/Scrum. Knowing is half the battle on this one. Here are some of the most important differences to understand:
Plan vs. Value Driven
Agile/Scrum takes a value driven approach to the project while TPM is driven by a goal to plan the whole project up front. It’s important to understand that this doesn’t mean that an Agile/Scrum project doesn’t have a plan. There is a plan for each release and iteration, but these plans focus on prioritizing the features that deliver the most value. This is different from TPM where a complete plan is created up front detailing every activity and task required for the project.
Predictive vs. Empirical Approach
Traditional Project Management uses a predictive approach, meaning that the Project Manager tries to predict the future based on assumptions to develop a plan upfront and once this plan is set, change requests must be evaluated case by case. The design shouldn’t change after it’s approved, and development shouldn’t start until the design is complete. This is very different from Scrum which, according to Jeff Sutherland the co-creator of Scrum, “implements an empirical approach based in process control theory.” which is a fancy way of saying that the Scrum Master and the team adapt to the results of current and previous sprints to adjust delivery targets and make changes to the team to increase velocity. Each iteration is adjusted based on the data from the previous sprint focusing on how to deliver more value during the next sprint.
PM-Organized vs Self-Organizing Teams
One of the primary roles of a Traditional Project Manager is actively organize and structure the project team and assign roles and responsibilities. A Scrum Master steps back and lets the team organize themselves. The Project Manager facilitates communication and provides an environment for the team to deliver.
Stakeholder Management vs. Involvement
In TPM stakeholder management is a significant part of the Project Manager’s job. Usually this is done via a collection of status reports, progress charts, and update meetings where the Project Manager reports out on the project. Scrum dictates that the product owner is actually part of the Scrum team. Because the business stakeholder is part of the team and is a party to all decisions the use of elaborate status and progress reporting isn’t as necessary.
Planning From the Bottom-Up vs. Top-Down
Traditional Project Management is bottom-up, meaning that a project is planned by from the beginning by detailing individual tasks into a Work Breakdown Structure (WBS) resulting in a complete project plan at the beginning of a project. Scrum is Top-Down, meaning that a roadmap is developed in the beginning of the project which is elaborated progressively into releases and sprints.

Lesson 3: Learning to Let Go

There are a few habits and practices of TPM that never seem to die. A Project Manager will need to break these habits if they are going to successfully transition. While it’s simple in concept, most organizations refuse to let go of these habits out of fear. Even though some of these habits are the reason TPM projects are failing to deliver value, they always seem to creep into the Agile solution many of my clients implement. This is where it’s important for the Project Manager it build the trust of their organization by piloting a small project or using a well thought out interim methodology. Often it’s impossible to break these habits until the entire organization understands the Agile principals and is ready to embrace them.
Habit #1 — Planning Everything Up-front
In an Agile/Scrum project you will not know all of the requirements before starting the project and they will always be prone to changes as the project advances. TPM’s complete and detailed project plans need to be replaced by “Just In Time” planning for the parts of the project that delivers the most value and are most understood at the time. In theory this should be an easy sell. How many projects have you managed where the Gantt chart or project plan dreamed up in the kick-off was realistic even a few hours after the meeting? The reality though for most companies is that project sponsors want the Gantt chart as a confirmation that the project manager has control of the project and knows what they’re doing. In an agile/Scrum project the sponsor (Product Owner) is an involved member of the project team and realizes value faster and incrementally allowing them to change their mind and adjust as they see the project coming together, which brings us to…
Habit #2 — Formal Change Management
A Scrum project fundamental is that the project team is empowered to make decisions because the Product Owner is included in the process. By tying the hands of the team to make decisions and changes many organizations are ensuring that their Scrum teams will not be effective. If a project team doesn’t have the authority to make decisions without adding an agenda item to a steering committee next month, they have not been empowered enough to be successful.
Habit #3 — Time, Scope, or Budget
TPM introduces the concept of the triple-constraint. The Project Management “Iron-Triangle” must be aggressively managed by the Project Manager in TPM. In a Scrum project, Time and Cost are fixed (“time boxed”) during each sprint and scope is determined by the team itself and is locked down at the beginning of a sprint. It’s not the Project Manager’s role to manage and set them. This can be a struggle for some Project Managers as external interests will always try to add scope, cut budget, or crash timelines. TPM let the project manager evaluate these change requests and work them in, usually leading to fire drills and heroics which ends up voiding the original project plan anyway. In an Agile/Scrum project the Product Owner must let go of this and agree to lock in scope during the sprint planning. The risk is reduced by the sprint duration so the course can be changed at the end of the sprint, rather than going back to the design phase after 6 months for example.

In Conclusion

Organizations are trying to become more “agile” by adopting Agile/Scrum concepts on non-software development project. While these concepts may reduce many of the pain points they have been dealing with for years and the solution seems straight forward, It’s important to not get fooled by the simplicity of The Scrum Guide (“Hey! It’s only 17 pages!”) or think that you can just import the easy concepts without thoughtful assessment of the fundamentals. Organizations should look at the problems they are trying to solve by moving to Agile/Scrum and evaluate if they are really TPM problems or organization problems. If they are the latter, Agile/Scrum won’t be a magic solution. There are lots of pitfalls on the way to Agile/Scrum, and poorly understood and implemented Scrum can be much worse than poorly implemented TPM.

Vince Dasta is a Technology consultant and the author of “Building Phone Applications” a cookbook for building telephony applications. For more insights on Project Management check out his blog at http://vincedasta.com

This article was originally published at http://vincedasta.com/p/pitfalls-on-the-road-from-traditional-project-management-to-scrum/