Mindsets: Waterfall, 1st & 2nd Generation Agile

April 28, 2012 — Posted by Al Shalloway

“We can't solve problems by using the same kind of thinking we used when we created them.” Albert Einstein

I had mentioned in my last blog that I’d be discussing how to pick which practices you should be doing.  However, in thinking about this, I realized that there is one other step you must first get clear on.  This is being clear about the mindset you have and whether it works well for what you are trying to accomplish.  Mindsets are often difficult for people to analyze and/or challenge. Mindsets typically show up as the way it is so people don’t challenge them.  Given most people in the Agile community now appreciate the difference between Waterfall and Agile, I think it could be useful to create a table with how those mindsets differ along with how 1st and 2nd generation mindsets often differ.  I’ve written a couple of earlier blogs on this that you might find of interest: and The Importance of Mindset and The Importance of Mindsets – Part II. Of course, these comparisons are not literally correct. People typically haven't talked about mindsets.  I am just trying to expose different ways of thinking.

I want to be clear why I am comparing mindsets here. It is not an attempt to show one mindset is more correct or useful than another.  Certainly, there is not a best mindset for all circumstances.  However, many of us believe our mindset reflects reality.  It does not - it is just how we frame reality.  When we can see that there are alternative mindsets, it helps defeat this myth.  We are then free to look to see if our mindset is serving us or limiting us.  We then have more freedom to change our mindset to something that works better for us in the situation we find ourselves in.  Unfortunately, few people take the time to reflect on their own mindset but tend to defend it in an attempt to prove its worth. This is because many people identify themselves with their mindset.  This is also unfortunate as it severely limits their ability to reflect on their mindset as doing so feels like a reflection on their own self-worth.

Where 1st and 2nd Generation Methods Are Similar to Each Other



1st Generation Agile

2nd Generation Agile


Requirements can and should be detailed in advance before work on implementing them begins.

Customers will not understand their requirements fully.  Even if they do, developers will not be able to understand them perfectly.  It is better to incrementally discover the requirements by building part of the system and learning from it.

Same as 1st Generation

Delivery of value

Best to deliver in full, complete chunks

Deliver value incrementally.

Same as 1st Generation.  Lean, Kanban and Lean-start up put some extra emphasis on Minimal marketable features, Minimal viable products, etc.

Main Areas Where 1st and 2nd Generation Methods Differ

How To Start a Transition from Waterfall


Start at the team. Have impediments to the team dictate how improve the rest of the organization.  If necessary, define new roles and practices and follow them until the team "gets is."  Remove impediments to these practices.

Take an holistic view of the entire value stream. Look at what is the root cause of the impediments to flow and work on that.  Start with what you do now, initially, respect current roles, responsibilities, and job titles.  Change once visibility and understanding are present.

How to Change Culture N/A Change culture by insisting on certain practices until the team gets better with them. This was extreme (pun intended) during the initial phases in XP where teams were warned that if one didn't do all 12 practices it wouldn't stick.  Scrum has continued this by chastising those who don't do Scrum properly as Scrum-butters.  The challenge is that even when the practices are followed things often don't stick when impediments due to otherh parts of the organization, those not following the practices, are encountered. Change culture by starting where you are, create an understanding, and attempt to create a culture of continuous improvement. Side note: this is not as satisfying at first in that you can't point to big changes and show how much success you are having.  However, it is much more likely to still be growing and improving a year later
Respecting People We may respect them personally, but don't provide much respect professionally.  We have management tell them what to do. Respect means professionally and personally.  Let them figure out how to self-organize their work. Respect in same way as first generation Agile, but also respect the human condition.  That is, people don't like too much change.  Accept how people learn and create an environment in which they can grow.  Just saying do it, just doesn't do it.  Acknowledge it isn't a technical problem, it's a people problem.
What Is Agile and What Is Agile Based On? N/A Agile is based on values and principles. Agile is based on values, principles, an understanding of human behavior and product development flow.
Approach to learning People can be told what to do and trained in basic skills needed. People learn best by doing.  Understanding will come after people have done the work for a while.  Retrospectives at the end of iterations is frequent enough for re-thinking and improving one's process. People learn best by doing while also being presented with the theory of why the suggested practices work. Learning what to do may be complicated, getting people on board with it is complex - hence a combination of practice and theory is essential.  A continuous learning model, a la Rother's Toyota Kata, is ideal.

Organization and focus of Requirements

Top-down, providing full detail

Requirements focus on the customer.  They are gathered in the form of stories and decomposed into manageable chunks of work.  These stories are put together into releases. This is a somewhat small pieces put together to a release approach.

Requirements focus on the customer within the value proposition of the business. Because of the product portfolio view of 2nd generation methods, it is realized that just focusing on customer value may have us continue creating value for this customer set when we should switch to building value for another set.  Requirements are created from a business capability perspective using Minimal Marketable Features or Minimal Viable Products, etc., to create a release plan within which stories are developed.

How to achieve improvement

Focus on management telling workers the best way to do the work

Focus on the people doing the work figuring out the best way to do it and telling management how management can help them.

Have management create an environment for people to do their best and have people self-organize within that environment

The relationship between people and process

Use process to tell people what to do

People over process

People and process (i.e., process is important, but must be created by and serve people)


Management dictates process to teams

Somewhat ignored initially other than making it clear management should not interrupt the team. Teams do provide visibility of the progress and results of their work to the team, during and at the end of  the iteration. While many in the Scrum community have finally abandoned the chickens and pigs story, the fact that it ever arose in it indicates the change in attitude about management.  It is inconceivable that the story could ever have occurred in Lean/Kanban as close working of management and teams is one of their tenets.

Teams recognize that management is essential to the creation of valuable software.   In addition to the visibility provided by 1st generation methods, 2nd generation methods make their workflow visible.  This happens through the explicit policies of the teams’ workflow.

Level of workflow definition

Workflow is defined and stable.  Teams are intended to follow the workflow.

It is not possible to explicitly define workflow except on entry to the team’s work and on exit from the team’s workflow.

Workflow is defined from the input queue of the team until it is delivered

Scope of methods

Look at the entire value stream.

Focus on the team

Look at the entire value stream.

Team Structure

Teams are fungible and can be put together as needed to maximize utilization.

Organize people as cross-functional teams and keep them fixed.

Cross-functional teams are most effective, but are not necessary.


Planned completely ahead an given to teams

Pulled by team in batches.  Manage workload implicitly via time-boxes called iterations.

Pulled by team in small pieces. Manage workload explicitly via work in progress limits.

Other Differences Between 1st and 2nd Generation Methods


Not used

Time-boxing used for managing iterations.

Time-boxing for managing flow discouraged, but can be done. Cadence used to coordinate activities, reviews, data gathering.


It is important to conform to the specification

Conformance is not something to strive for.

Conformance to the best workflow you know (and changing it when you learn) is a good thing.

Technical – Design

Design the system up front

Little to no design is needed.  Complete design via emergent design is possible.



Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


In case you haven't seen it, there is a good book: Mindset, by Carol Dweck.

I do not practice Agile Gen #1 as you indicate, and have many issues with what you describe. Likely due to the fact that the terms are difficult to convey a precise definition.

* Reqts org in #1 (customer) & #2 (business) are the same in my book. Reqts are organized to best serve the business (assuming the customer represents the business).
* Achieve improvement - i can't see either way working in isolation. In my mind it is always a blend of both 1 & 2.
* people & process -- #1 & #2 are the same. I'm a process nut, but temper it to the team.
* management -- not sure how it is ignored by #1. Unless you mean Cowboy Agile or something.
* workflow -- workflow is very explicit in #1, where we go from user reqt to delivered/deployed feature, and all steps in between. workflow is a huge part of agile #1 IMHO
* scope -- not sure what that even means. however, it seems that your default for #1 (have you practiced some form of #1?) is typically to assume the team ignores the needs of the business, and cares only about making themselves happy. for my teams, "it's the business, stupid" is the James Carville-like campaign slogan.
* team -- not sure why #1 keeps teams fixed. Teams fluctuate. Deal. I don't recall it being an edict to fix the team. Plus, to be agile, you often need to pull in certain specializations as needed.
* conformance -- to say that the team blatantly ignores the business need to meet conformance in #1 is based on what? Why would an agile team balk at not fulfilling a business need? That's not agile, that's belligerent.
* technical design -- little to no design is needed in #1. I think that is a myth, or a lack of understanding. Excess design is avoided, but very few actual teams go into a project blind with no idea as to what sort of architecture or design they are striving for.

But, I will admit, I have not observed hundreds of teams doing Agile #1. But had I observed teams doing most of what you imply as being "normal" for 1st generation agile, i would be critical.

Jon:Thanks for your comments. Re customer and business owner perspective being the same you are making my point. I think they are different you are saying they are the same.

XP & Scrum do not talk too much about how to help the business decide on what's important. XP talks about the customer Scrum assume the Product Owner has already decided what to build for the customer.

Scrum was originally defined as a black-box process - hence, not explicit workflow. 

In any event, don't take what I am saying too literally, it's intended to make you think about different mindsets.

I do think they are changing though.





I actually think there is a difference from first gen agile. It's the de emphasis of requirements completely as something necessary to capture business objectives.

The replacement is to take leanstartup MVP oriented techniques to evaluate tech delivery based on business measurable outcomes.

Re: How to start
Are you familiar with New Lanchester Strategy? I'm currently thinking about how it can be applied to organisational change as I'd think that addressing an entire value stream may be strategy for the strong but not necessarily for the weak.

Re: Story organisation
How would a business vs customer organisation of stories look like?

I did a horrible job explaining my ideas there. Please re-read that row.


Hi Alan,

I understand you, but I think you are making an horrible mistake by confusing different concerns. Agile is a set of value and principles, nothing more. Manifest by various practices performed by teams dating back to the early 90s that have manifestly worked for them. Why? Well because they embody the values and principles.

Now attempts to make these values and principles mainstream have mostly failed. Having another go, using a somewhat different approach, and labeling that effort Agile #2, is nothing more than a rebranding effort at best.

Let's leave Agile out of it and talk about adoption strategies. There are many Agile teams who are successful and see the distinction you make as a false one. As for adoption, both approaches you describe have the same fundamental flaw. Good people make good organizations/teams. These people embrace progressive values, and principles, because they appeal to them. Not because they were somehow hoodwinked into it.

Whilst there is an industry built on the idea that values and principles can be readily packaged and sold. Most people see this for what it is, a marketing and sales effort. Like In all aspects of life, change comes from within and is the responsibility of each individual involved. Rehashing the sales pitch and expecting a different result has been tried and failed several times before.

No doubt in a couple of years someone will be pitching Agile #3. It's not the first time. My guess is that we are are already up to Lean #6 or so, but whose counting :)


If you called your comment: 1st generation Agile has nothing to do with adoption strategies, I agree.  2nd generation Agile (Kanban and Lean in particular) definitely do.  Your definition of Agile is also 1st generation.  Maybe I should add another row. Thanks - think i'll do that.

Hi Alan,

Looking forward to your new column. I suggest you do some reading on fad-cycles. How they are created and why they fail. There are a number of common ingredients amongst fads. "A promise", the claim of "universality", a "bandwagon", followed by "disillusionment" when the espoused benefits aren't realised by later adopters and finally rejection. When the idea is "disparaged".

Now none of these phases is rational. They have to do more with human psychology then the objective facts. No single approach to Agile adoption is universal, and for some, Agile adoption will never occur.

Uncle Bob's organisation Object Mentor, adopted XP from Kent Beck in a couple of weeks. They got it straight away, because there was much overlap with their incumbent values and beliefs. Now contrast this with a stayed command and control enterprise. Kent Beck having a chat with the CEO isn't going to cut it. Both men will leave the discussion with different ideas over what Agile is, because there is little common ground between them.

None of this has anything to do with Agile. It also happened with BPR, Lean and any other Management theory that has appeared in the last 40 years. All built on truth, but extrapolated beyond their natural zone of appeal/applicability.

Agile isn't for everyone. Now you may be saying the same. In which case call Agile #2 something different entirely, so there is no confusion.



I have to admit that you always seem to assume folks aren't as educated as you - "suggest you do some reading on fad-cycles."  I have studied how people learn and stick to things and fail ...  I have been observing/studying this for decades.  The fact that we don't agree doesn't mean that I am ignorent of such things.

I think much of the problem is that people don't want to think.  They jump in to things that look like a solution and want an easy solution.  But everything that comes up is not necessarily a fad.  My moving from XP to Scrum to Lean to Kanban does not mean that I've been moving from fad to fad.  It means I've learned what I can and I move on.  Continuous learning is not a fad.

I do not think everything under the sun is a fad.  BTW: I think the latest fad is trying to avoid fads. :)


Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile