Project management is an important tool for product managers and an area where we have choices. I often hear Agile practitioners talk about the evils of more planned methodologies, like Waterfall and Stage-Gate. Like most things, these areas are not so black and white and the nuances are important. My guest, Chuck Cobb, is the perfect person to address these topics. He is the author of the best-selling book “The Project Manager’s Guide to Mastering Agile” as well as four other books on Agile Project Management and Business Excellence. He has also developed a very successful online training curriculum on Agile Project Management, including a free course he is offering to listeners.
In this interview you will learn:
- how to compare waterfall and agile approaches,
- the problems agile project management strives to solve,
- why both planned and adaptive approaches need to be used, and
- common issues encountered when adopting agile project management.
Practices and Ideas for Product Managers and Innovators
Summary of questions discussed:
- Let’s start by describing the two big general concepts we are discussing – traditional vs agile project management. To start with, waterfall and agile are widely misused terms. In a strict sense, waterfall was developed by Winston Royce in the 1970s. It means a phase-gate approach with approvals between phases. In today’s world when people say waterfall, the word is used loosely and generally it means anything that’s plan-driven and not agile. The term agile also has many different meanings to different people. Many people talk about agile as if it were a specific methodology. Scrum is very widely used and when people say agile they typically mean Scrum. So the word agile has some broad meanings as well. Many people see the choice between plan-driven and agile as mutually exclusive and that’s not accurate. It’s more like a continuous spectrum of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme. It’s more a matter of fitting the methodology to the project and to the business rather than force-fitting a project and a business to one of those extremes.
- When should a plan-driven approach be used? A plan-driven approach works in situations that have low levels of uncertainty, like building a bridge across a river. If you have a situation that is relatively straight-forward, it’s well-defined, it’s repeatable, a plan-driven approach is a good choice as you can take the lessons you’ve learned on one project and do better on the next project because it’s similar and follows the same model.
- When should agile be used? Agile works best in environments with high levels of uncertainty. An example is finding a cure for cancer. If you were to develop a project plan for finding a cure for cancer, it would be ridiculous to try to develop a detailed plan with schedule and cost information. There’s just too much uncertainty. It’s a wasted effort to try to develop a detailed plan. In that kind of situation, people are more concerned about the goal of finding a cure for cancer than they are about having a detailed cost and schedule breakdown of what it’s going to take to get there. It’s based on an empirical process control model. The word empirical means based on observation, meaning that as you go through the project, you’re continuously adjusting both the product and the process to complete the product.
- Often when waterfall and agile approaches are discussed, the conversation quickly becomes one of “waterfall is bad” and “agile is good.” Is it that simple? No, it’s not. Saying agile is better than waterfall is like saying a car is better than a boat. They are two different things, and each has advantages or disadvantages based on the environment that you’re in. So agile is not inherently good and waterfall is not inherently bad. It’s more a matter of fitting the right approach to the right problem.
- What are companies doing to incorporate agile practices in their work? It’s all over the map. There’s a lot of companies that just want to jump on the agile bandwagon and many times it’s a superficial kind of thing. It might be just a brute-force approach to get it done because they see it as a way of getting products to market quicker and they wind up working people overtime and weekends to get things done quicker, and call that agile. That’s not the right approach, obviously. Agile is heavily dependent on training and coaching to do it right. You can’t just take a cookbook approach like waterfall and do step 1, 2, 3, 4, etc. It really requires some good intelligence among everyone on the team–developers, Scrum masters, etc. Everyone has to be intelligent enough to figure out how to do things and adapt the process and the product as they go along, so it requires a lot more skill. At a corporate level, it could require some corporate change, because there’s significant cultural changes that may be required. Agile requires breaking down walls and barriers and developing more of a collaboration.
- What are some common issues organizations encounter as they pursue the use of agile practices? I like to say it’s a journey, not a destination. There’s an on-going learning effort and there are stages of learning associated with getting into agile. It can take years for a complete transformation of a major company. You might start out small, you might start out with just a pilot effort on one or two projects, and expand it.
- Chuck’s free eCourses on Agile Project Management
- Chuck’s blog, ManagedAgile.com
- Chuck’s most recent book, The Project Manager’s Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. The book contains the case study, among others, that Chuck mentioned in the interview.
“Agile Project Management is an oxymoron.” – heard at meetup event from an Agile author
Listen Now to the Interview
Thank you for being an Everyday Innovator and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.