Project methods – Waterfall versus Agile

I have been reading a lot of discussion recently regarding the use  of different methods for planning, implementing, and managing projects.  Many methodologies exist in the industry; two of them are:

  • Traditional Waterfall (some would say PMI PMBoK but not necessarily) model
  • Agile (SCRUM, Extreme, etc.)

I read a really good article last week in the Harvard Business Review Blog — A Better Project Model than the “Waterfall” by Jeff Gothelf. In this post he talked about needing a better model than the traditional waterfall model.

Here is a summary of Jeff’s post:

The main argument is that waterfall methodologies, which have been around for a long time, have a fatal flaw–they depend on accurate requirements. The problem with this dependence is that requirements are often wrong. He discusses giving teams the ability to work with clients to find out what the real requirements are. One of the quotes from his post that I really like was from Josh Seiden, who said, “In software development, reality bats last.” What he means is no matter how much planning or optimism there is about the software product being built, the only true project success is the reality of customers using it to solve real problems.

He goes on to share examples of Agile methods, in which teams use lists of features that are prioritized by product owners (not developers) to drive the project. In addition to prioritized lists, he suggests that each project team should be handed specific success criteria. These  criteria must  be quantifiable and directed to specific outcomes that meet customer’s needs.

My own opinion of this conversation is that it is not either black or white–waterfall vs. Agile.  As both as PMP, certified in waterfall methods, and a PSM, certified in Agile Scrum methods, I contend that a blend of both methodologies is often the right answer. Agile requires small, bite sized “sprints” with smaller teams in order to produce results. However, many projects are quite large, with as many as 300 people working at any one time. In these cases, running lots of small teams with sprints can become a project management nightmare. Using an approach that allows some portions of the project to use a more traditional waterfall method, and other parts of the project to use Agile, can make the overall project more management while still achieving the desired outcomes.

As I’ve stated in prior posts, requirements are not easy to capture, especially in complex software products. There are many techniques today (including Agile) which allow us to work with real users and discover the true requirements and needs and the measurable outcomes that must be produced. One such technique, Performance DNA, is used by my organization to ensure that all requirements are identified and linked back to prioritized outcomes.

In closing, as an experienced project manager who is certified in both methodologies, I am suggesting that “either/or” is not the right discussion.  Instead, I propose that a combination of waterfall and Agile is more likely to be the right approach.

Do you have experience using a blend of waterfall and agile, or do you prefer one over the other?

Scrum Advice: Creating the First Product Backlog

Scrum methodology is gaining recognition as an effective way to manage development projects. So, I thought it might be a good time to talk about some of the main elements of the Scrum framework for the PMs and managers out there. A good place to start is with the “Product Backlog” – which for the novice could be equated loosely to the functional requirements list.

The Scrum product backlog delineates the functions required to provide the outcome desired by the product owner. According to Ken Schwaber in “Agile Software Development with Scrum”, the backlog includes a list of all the functionality, features and technology needed to complete a development project.

Although the product backlog sounds like the requirements document used in traditional waterfall software development methodology, it is not. Don McGreal, VP of Training at Improving Enterprises, LLC and my Scrum trainer, describes what happened in his experience to requirements documents under traditional software development methodologies, “Never did we ever build what we first came up with in the requirements phase.” In the project close out to assess how well the system met the specified requirements, we didn’t. We would ask, ‘what went wrong’ and there was a blame game or a lot of excuses about unplanned for events. The managers would then decide that the solution for next time was to make the requirements more detailed – more time should be spent upfront on creating the complete requirements.

However, spending more time trying to create a perfect requirements document at the beginning of a project is doomed to failure. Admit it, says Don (and I agree completely), before anything is built, “users, customers, even experienced practitioners cannot specify everything that should be built.” Instead of spending weeks, months or even years creating a comprehensive requirements document in the beginning, Scrum practices acknowledge that requirements will change during development and recommends creating only an initial list of things the product or system needs to do.

The first product backlog is based on a vision, business analysis and even marketing promises. The initial list gets the team started working on functionality quickly. During the development, the requirements listed in the prioritized product backlog — which is updated before each sprint — will evolve into what can and should be done using empirical data gained by writing and testing code.

Creating the product backlog is the responsibility of the product owner. He or she may create a high level description of the end product’s capability as a vision statement or concept of operations. The product owner may get inspiration from user stories of what they do currently and what would make their tasks easier. There is a real art to collecting useful user stories. I suggest:

  • Having many conversations with potential users. Carry a set of index cards to the meeting. On each card there is a sentence that begins, “As a _________________, I need to do _______________.” This simple format device gives the product owner a concise statement of a requirement.
  • Holding a brainstorming session with a small group of users and facilitating discussion about what they need to do their jobs. Having several people talking together creates an environment where one person’s comment will stimulate the thinking of others.
  • Working with customers, create a scenario that walks a user through an entire series of steps needed to achieve a successful interaction with the system. Each step in the scenario can be an item in the initial product backlog. Add scenarios for many types of user’s needs.
  • Meeting with the development team to review the vision and initial product backlog. Add items to the backlog to accommodate identified needs for further research or infrastructure requirements needed to get started.

From these activities, the product manager builds the prioritized initial product backlog. The product manager gives the team a presentation of the product vision and the product backlog list. The team and the Scrum master meet to plan the first sprint, which may achieve completing the highest priority task or may break that high priority task into several sprint tasks.

Remember that Scrum’s power comes from iteratively evaluating product backlog priorities and tasks. As Project Managers we have been doing this for years in order to make sure the project goals are still valid.  Over time new tasks are added to the backlog. Each sprint planning meeting accepts the highest priority tasks that can be completed during the next sprint.  At the end of a sprint, the team delivers the demonstrable functionality of the backlog task, revisits how the deliverable fits within the product vision and identifies the next priority tasks from the product backlog.

The above ideas are methods I have found successful to create the initial product backlog. If you have techniques you find particularly useful to begin the Scrum backlog generation, please share.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site