The Core Beliefs of Waterfall, Agile and Lean

written by Aleem Khan on October 30, 2017 in Agile with no comments

Core Beliefs of Waterfall, Lean and Agile

Suggested Duration: 30 Mins.

Recommended Size: 9 to 12 people

Needed Supplies: Printed Copies of Core beliefs of Waterfall, Agile and Lean

Procedure: Download the core beliefs file, print file using single side using landscape page format and cut each paper into four equally sized portions. Lines are marked on the sheets. In the end, you should have printed statements on an index size cards.

Place three main cards (The Core beliefs of Waterfall, Agile and Lean) on the table in a row.

Shuffle the rest of the cards and ask participants to read one by one using a round-robin fashion. After each read, a group can discuss, agree and place the card under the associated approach.

As a facilitator, you may have to re-emphasize essential learning points and guide team appropriately throughout the activity.

This learning activity does not only improve the basic knowledge of Waterfall, Agile and Lean but also help participants to identify the differences between each belief system.

Before you run with your team, I suggest providing them with a quick overview and highlights main characteristics of each approach. I ran this exercise couple of times in my PMI-ACP Exam Prep session as well as with my coaching clients and made the following observations.

  • Almost every single person recognized statements related to waterfall
  • People are having difficulty in distinguishing between Agile and Lean. Most of the time you will hear that, but we do the same in Agile)

Good luck and please do provide your observations and ways to improve this activity, so we all can benefit from it.

Correct Answers:

The Core Beliefs of Waterfall

  1. You can know everything required to build a software product properly at the start of the project
  2. Customer can accurately tell you what they want at the start of the project
  3. You need to get feedback from the customer until the end of the project
  4. Manager, developers, and customers can gauge the status of a project by looking at completed milestones as reflected in the documentation. That is, given proper documentation, it is not necessary to deliver complete, tested software until the very end of the project
  5. You can effectively have separate groups do analysis, design, code, and test. That is, there is little loss of information in the handoff between these groups
  6. Handoffs between people in different roles can be done efficiently by writing down what was done in each step
  7. You can test at the end of a project and achieve that required quality
  8. Management can demand that certain work be done at a certain time and should expect it to happen
  9. Giving people many projects to work on simultaneously is a good approach to achieving 100% productivity because then everyone is always busy.

The Core Beliefs of Agile

  1. You cannot know everything required to build a software product at the start of the project
  2. Customers cannot accurately tell you what they want at the start of the project; instead, they will gain clarity as the project proceeds
  3. You want feedback from the customer as often as possible and you want to give developers feedback on how they are doing as soon as possible
  4. Working code is the most accurate way of seeing the progress of the development effort
  5. A group working together minimizes delays as well as the loss of information between people
  6. Moving to test to the front of the development cycle improves the conversation between developers and customers and testers and, thus, improves the quality of the code
  7. While management can set expectations for what work is done, management must not demand how that work is done
  8. Working on one project at a time improves the productivity of a team

The Core Beliefs of Lean

  1. Most errors are due to the system within which people work rather than to the individuals themselves.
  2. People doing the work are the best one to understand how to improve the system
  3. Ad hoc is not an acceptable process
  4. Looking at when things are done in a process is a more useful guide than trying to make sure every step of the way is as efficient as possible
  5. Our measure of success must be related to the amount of time between when ideas come in and when they are manifested as value to our customer
  6. Management must work with the team to improve the way it works to improve its own efficiency
  7. Team are most efficient when the amount of work is limited to their capacity
  8. Team efficiency improves by minimizing the amount of work in progress at any one time
  9. When evaluating actions, we must optimize the whole, not merely improve individual steps in the process
  10. There are principles in software development that must be followed in order to reduce waste

Interested in Agile? visit our Agile bootcamp page

Interested in Lean? visit our Lean Leadership workshop page

Reference: The core beliefs are from the book “Lean-Agile Software Development: Achieving Enterprise Agility” by Guy Beaver; Alan Shalloway; James R. Trott