6 Myths of Product Development - Take 2

Months ago, I mentioned here a great article. Here is an article about: Six Myths of Product Development.  By Stefan Thomke and Donald Reinertsen.

Strongly recommended.  Especially good for managers and executives.

Here are the fallacies in one list:

• High utilization of resources will improve performance.
• Processing the work in large batches improves he economics of the process.
• Our plan is great; we just need to stick to it.
• The sooner the project is started, the sooner it will be finished.
• The more features we put into a product, the more customers will like it.
• We will be more successful if we get it right the first time.

I wanted to discuss them some, with the hope that I might entice you to read, understand, and act on the article.

Let's do the first two today.  Quickly.

1. High utilization - Myth

Ok, ceteris paribus (other things being equal) high utilization of the resources would be good.  Lower cost per widget.

But in knowledge work especially, we only deceive ourselves. First, it is often based on the false premise that knowledge workers are fundamentally lazy.  Demoralized, demotivated -- maybe.  But not lazy.  (Ok, maybe 1 in 30 has some real laziness, but we do not recommend 'pushing' on high utilization to get that fixed. Fix it another way, and we do in Scrum.)

Second, high utilization, as shown in the article, leads to low through-put from the system (to us, the system is the Team).  Nothing gets delivered quickly.

And in product development (eg, software development) fast delivery is ESSENTIAL. No, it is much much more essential and critical than my capital letters imply.  We barely have a glimpse, in my opinion, about how critical it is.  And in how many ways it is critical.

Once we recognize that, then we must struggle with seeing the utilization level, and adjusting it to the optimum level. (We are not proposing super-low utilization. Just lower, to get the through-put.)  We have some rough techniques for that in basic Scrum. As you become professional in using those techniques, you may want to fine-tune the techniques for each team.

Again, a push for high utilization by managers is killing us. Managers should focus on speedy delivery of smaller things (smaller releases).

2. Large batches - Myth

It often feels as if we become more efficient with large batches. And, it is partly true in a way.

But it is mostly false, and in all the important ways.

Large batches tend to lead to silos. That means we tend not to work together as a team (in all the bad ways we mean with that phrase).

Large batches means that problems are hidden. And hidden problems are much harder to fix. And, in knowledge work, the bad news does not get better with age.

Large batches means that things are not delivered quickly to the customer.  And speedy delivery to the customer is essential.

Large batches allows our knowledge a much greater opportunity to decay in value. In all the many different ways it can decay in value. Often to zero.

I have to mention the 'carrying costs' of large batches.  It leads to much more 'inventory' or 'work-in-process'.  If you could see or visualize the cost of that 'partially done work' and you were a good manufacturing manager, you would be aghast at all the excess cost.

And our work is done by very expensive people.  The accumulated costs are huge.

So, while it seems (and is a bit) more efficient in some ways to have large batches, in net the costs are higher. And the 'time to market' much slower.  A lose-lose.

***

There are two short commentaries on the great article. Please read it.

Question: How do I implement Scrum?

Question from Denise: My organization has decided to go from Waterfall to Agile SCRUM. I have experience with SCRUM, but very little experience implementing it. I was wondering if anybody has this experience? If so, what were some of the challenges you faced? Lessons learned? Best practices?

Answer: This is a big question. And no one can answer if fully for you.  Whole books have been written on this subject and no two 'experts' fully agree.  (I guess I am one of those experts.)

Some basics.

1. It usually starts with one person, driving the idea. I strongly recommend that, whoever is the initial 'agile evangelist', that he or she gather others in support.  John Kotter says establishing a Sense of Urgency, in the right people, for the change is essential.

2. Start a pilot.  Get one team going.  Use it to help you (maybe you personally, or the generic 'you')....to help you identify how it will work at your place. Each place is unique. Each place will have different priority issues. Reality teaches us best what the biggest issues are.  Crystal balls do not work as well.

3. Get some good training. (I am a CST Scrum Trainer.  Smile.  Yet actually all the people who do it well suggest this.)  Train 'everyone'.  What does that mean?  Well, if you have 50 people, I might train 15-20 when I got the first team started.  Train some people around that first Team.  Some of those 'around' people should include managers.

4. Help the managers adjust.  It is new and different for them. And often, some think they understand, but really they all need some help.

5. Get some coaching.  Teams get started better with a coach.  It seems expensive -- it really is cheap.

6. Identify and drive impediment removal.  This is key. Lots to say in this area.

7. Get the Business side engaged.  Or, start working on getting them engaged better.  Often Scrum starts as an IT or technology initiative, but really it is better for all if it is a business initiative.

8. Make the PO better. Usually, the weakest person is  the PO.  Not because George was not good at his last job.  But because the PO role is a different role than George has ever tried to do.  He will naturally misunderstand it, and not dedicate enough to it.  Unless....well, usually, unless the SM and the Agile Coach work on him, and make him (or her) better.

9. Get ready to live and learn.

10. Dan Mezick has a new book, called Open Agile Adoption Handbook.  The idea is to get 'everyone' to want to volunteer to help implement agile (Scrum).  Here is Little's Second Law: "People are remarkably good at doing what they want to do."   The book may seem weird to you at first, or it might not work at your place.  If you look at it, I will be happy to explain more.

Get your first team going. And use that to drive more change.

***

Now, tell us your situation more, in more detail.  What is your role?  How big is the group?  What does your 'dev' group do?  What is your industry?  Who in your organization 'has decided'? How much scaling is there?  (By scaling, I only mean '3 to 7 teams working together on the same product'.)  Tell us any other big issues in your situation.  (Each situation is different.)

That may help us give you more advice.

This is key: It will be hard. It will be fun. You will learn a lot.  You can succeed.  And it will be worth it.

And there is no silver bullet.  Some of the best agile people ever can run into situations that 'will not work'.  Even then, you will learn a lot.

But after a while, if it seems impossible, it might be impossible.  And you might do better to climb another mountain.(Still, don't give up climbing mountains. It's fun!)

Hope that helps some....

***

There might be some Top 10 things I forgot.  But more likely, there are other things to discuss, but they do not deserve the same attention and priority. Example: Which Scrum tool to use. Important, yes. But not in the top 10, not worry the same energy and time, in my opinion.

The Retrospective and uncovering the best impediments

I chuckle when I say 'best' impediments.  Because, by its nature, an impediment is something that is slowing the team down.  It is bad.

But, to get better the Team must focus on the most important things first.  And this is true for impediments.  We must fix the most important impediment first.

It is human nature to ignore impediments.  This is a huge problem.

Why? Because if we do not put the Moose on the table, we can never fix it.

And, for many people, it is very painful to admit all our sins.  Sins we may have been committing for years now. (I tease about 'sin' -- but it really is a sin to have been doing all these bad things, and not admitting to it, and never fixing them.  Honestly. If we are managers, if we are any responsible adult, we must look palely in the mirror and say 'I was a party to this stupidity for years.'  It is humbling. And we have all done it.)

Not every one will feel pain, but we must remember that many do.  So, they don't want to talk about any, or many, or some impediments.  Because of the pain.

They say: "It was good enough." "Nothing really to be improved." "Well, a step forward." And lots other such weasel words.  And by this denial, they avoid what feels to them like pain.

True winners of course freely admit on television that they made mistakes, that they were not perfect.  Tom Brady and Michael Phelps come to mind.  Only when one admits some stupidity or mistake can one get smarter. Truly, as a real professional, our dream is to be perfect, or the best ever.  But we know from years of practice that we will never ever be perfect.  But by using that dream the right way, we can learn to be so much -- so very much -- better than we are today.  But, god, it takes guts.

So ordinary humans (who actually could be winners, even though deep in their soul they fear it) -- ordinary humans remain in denial.

And the Team feels some impediments are personal.  They feel that to talk about it would be a personal attack.  And, to be honest, often a person will feel it as a personal attack if anything negative is said about any part of their work. This will also feel weird to you or to some member of the Team, but that is how human feeling often work.

This is hard.  No, this is very very hard.

We are a band of brothers. We are together.  No man is an island, we are all part of the whole.

And, so every man's sin is my sin.  No...every person's mistake is my mistake.  So, be honest with yourself, admit your mistakes, and learn how to help them admit their mistakes.  Well, to be clear, no one has to admit any mistakes.  We just need to get the Moose on the table and then fix it.  So, do not call it 'his sin' or 'my sin' -- call it 'the Moose'.  And no one owns the Moose.

You cannot imagine the heavy heavy weight of denial that they carry (we carry).  Deep in their soul, they see the impediments, the mistakes. And it takes so much energy to deny them.

In any case, we must struggle hard to put the Moose on the table. Sometimes.

Why else?  Because they 'know' or think -- 'I might mention it, but it's a waste of time -- It'll never get fixed!!'  So, the won't mention the Moose.

The next reason: There is all kinds of human 'bad eyesight'.  Our eyes, for God knows how many reasons, just will not see the things in front of us.  The impediment may be abstract.  The impediment may be in a process flow, and we have not made the flow visual.  Etc Etc Etc.  You as SM must 'trick' them into seeing it.

So, in the Retrospective we try all kinds of tricks to allow the Moose to be put on the table.  To enable us to see the truth.

Derby and Larsen wrote Agile Retrospectives, which gives you lots of tricks. Scrum and Agile tribal knowledge will give you lots of tricks or techniques. In any case, often by indirections we find directions out.  Sometimes a member of a Team will identify a technique.  (But be careful about being too cute.)

And then we must prioritize, and then to take action. And action ONLY on one impediment.  And action where we almost always expect to get measurable results by the end of the next Sprint.  Maybe no a huge benefit, but something. And usually it shows the velocity going up.

So, as SM you are like a psychologist who slowly 'tricks' the patient to see and forgive themselves. So that they can move on, 'fix it' and have a better life.  You must be cruel only to be kind. You are a kind of 'trickster', who allows or enables them to tell the truth.

Agile Reading for Executives

A recent email I sent, slightly edited.

Dear Mike and Mark:

You asked for something to give the executives and managers.

I might send them "The New New Product Development Game" article (see below).  With a short explanation. And then offer them these other things to look at.

Other options:

Software in 30 Days - Schwaber and Sutherland. More from the manager's viewpoint than other Scrum books.

"The Basics of Scrum" - a great paper. I assume it must have been written by Jeff Sutherland, who is great.  I will confirm that. 9 pages.

Drive, by Daniel Pink is great on motivation for knowledge workers. 272 pages.
Video about Drive (Daniel Pink). Here: http://www.youtube.com/watch?v=rrkrvAUbU9Y  About 18 minutes.

"The New New Product Development Game" by Takeuchi and Nonaka -  This is the key paper that led to the development of Scrum.  Many of the key principles behind Scrum are described there.  And the use of the Scrum metaphor in that paper led to the name of "Scrum" for this agile method.  11 pages (HBR)

The Power of Scrum by Sutherland et al.  A "novel" about a manager's journey.  Fairly realistic. Semi-real (that is, I am sure they took a real situation, and modified it some.)  Not a Tom Clancy novel.  But still, a lot of key ideas from an exec's viewpoint, in an easy to read format.  128 pages.

"Six Myths of Product Development" by Thomke and Reinertsen. Wonderful recent HBR article. Not about Scrum per se, but all the 6 ideas (myths) are key to Scrum.  And if executives or managers do not understand these 6 key ideas, and particularly if they take decisions contrary to them, then Scrum will be much less effective.  9 pages. (HBR)

"Scrrum and CMMI - Going from Good to Great" by Jakobsen and Sutherland. Short read about implementing Scrum. 5 pages.

"The Discipline of Teams" by Katzenbach and Smith. Strong, stable, real, dedicated Teams are key to successful Scrum. Extremely common that executives and managers do not value the Team enough.  11 pages. (HBR)  They also wrote a book, The Wisdom of Teams. Recommended.

"Knowledge-Worker Productivity: The Biggest Challenge" by Peter Drucker.  On page "83" there are 6 major points.  16 pages.

Regards, Joe
I will get these all on my website soon.  Some are there now.

Question about Retrospectives and the role of the SM

A very bright and quick class attendee wrote and asked: Why don't you talk in the class more about Retrospectives? And why so much about the PO? Why do you focus on the basics so much?  I want more advanced materials.

First, I actually think we do, as explained below. We do talk about Retrospectives, and we do have some advanced materials. Even in the CSM course.

Here is basically what I said to her, somewhat edited (I wanted to make it better).

First, it is not correct to think of the SMs duties as mainly revolving around the Retrospective (as many do).  Although the Retrospective is an important meeting, you as SM must teach the whole company how to adopt agile and scrum.  (Or adopt it more fully, often much harder.)  In addition, you must help and teach the PO to be more effective;  Th typically the biggest impediment (and multifaceted).  The next highest impediments are usually technical impediments (eg, getting good Continuous Integration and automated test suite).

But, we do a lot around Retrospectives.  The whole exercise at the end of the first day (where we emulate doing a Business Case in the Retrospective) is essential.  I expect you as SM to use that A3 approach to drive higher velocity.  (I recommend you Google the A3 approach and learn more about it.  Jeff Sutherland and Mary Poppendieck talk about it, as well as many others.)

The first problem with many Retrospectives is, as Angel said, all talk and no action.  Classic!

So, you (with the Team) must take action.  In two sentences:
(a) collect data and decide the top impediment for the Team
(b) start to take action

I suggested action in one of 3 ways - with the Team in the Retrospective:(a) devise a solution (Ken Schwaber loves to say it that way)
(b) plan the execution (not a detailed MS Project plan, but 'who will do it and how?')
(c) pull together a Business Case to get a manager to say 'yes' (to $, to give you people, to approve).

And the A3 exercises was all about starting to learn how to make the case to a manager. Which, usually, we are terrible at doing because we do not speak 'manager-speak'.  To the Team, that is a foreign language usually.

The A3 exercise also, indirectly, teaches us how to prioritize. Mainly, by benefits (eg, increased velocity) to costs.  So, a key thing is that you must help the Team prioritize the impediments in a benefits-costs way. And do other parts of the thinking, as implied in the A3 approach.

To learn more about Retrospectives per se, you might read Esther Derby and Diane Larsen's book, Agile Retrospectives.  Esther Derby and Don Gray are giving a course in Atlanta, not exactly about Retrospectives, but I recommend that.  Again, not exactly about Retrospectives.

I have to balance the different topics in the 2 days and I have way too much to say to make all of them a 'good enough' SM.  It is always fine if an attendee says: 'I want to talk about the Agile Retrospective more.' Or asks a question.

Again, your biggest impediment is likely to be a 'not good enough' PO or a business side that does not give you enough PO time or BSH (business stakeholder) time.  As SM, you should spend lots of time making the PO (or the Business side) better.

One of the biggest problems with Retrospectives is that some SMs get too cute.  They have lots of new, cool, weird 'process' -- but the Team does not move much on really getting an impediment fixed.  And that is your time, as SM, to get them to help you.

How can you help?  Mainly the ways I said: (1) identify the top impediment, (2) devise solution, (3) help plan execution, (4) create bus case. Also, the Team needs you in the Retrospective to report back on progress (or not) on the last big impediment, and usually, to tell them "we got it done" (by someone). Again, getting too fancy does not help.  Just say: 'let's devise the solution together' or something like that.  And let them self-org. (Sometimes you have to 'make' them self-org if they look helpless to do so.)

An SM's job requires patience.  It requires the willingness to practice practice practice the basics (yourself), and the willingness to let others do the same.

Yogi Berra said: Think!  How am I gonna think and hit at the same time?

In other words, you and the Team must endeavor to get the practices and the values and principles of lean-agile-scrum so deeply embedded in muscle memory, that you don't even think about it.  It naturally flows.

It is similar to the discipline of learning the piano, which is clear to many people.  Practice, hard practice, even harder practice.  But it is not so clear for the discipline of SM.  Anyway, watching others make mistakes is very trying for the impatient SM, who by now can easily do it herself.  I would be very surprised if a relatively new SM did not need to practice many of the basics a lot longer, to get them into muscle memory.  You know doubt know of Malcolm Galdwell and how he has popularized the 10,000 hours concept.  Not just repetition, but how learning hours either practicing or doing.  And to many in Scrum, sadly, they do many hours just repeating dully the same mistakes -- nothing gained on the 10,000 hours scale.

And we must also see and feel how the lean-agile-scrum 'music' (the values and priniples) plays with the practices.  And we barely even started to touch on the underlying principles.

It is true that some experienced people come to the CSM course, and want to go in-depth into one or two areas. But the CSM course is also a rank beginner's course.  So, if we have beginner's we have to slow down for them.

But bear in mind  that as an SM, yo must learn yourself to teach beginners.  For more advanced people I often say: Think about how you would explain Scrum to a beginner.  KISS.  Watch how I teach, how I emphasize simple things, and make them focus on only the basics.  They cannot advanced until they master the basics. You can observe a lot, and steal from me how to explain to others as a SM.  So, rather than the content, you focus also on the methods.

Now, even the advanced people need to re-learn the basics.  This is because, 100% of the time, they are doing so degree of Scrum-Butt (or you may prefer another phrase for it).  In some way, they have mis-understood.  If you play golf, we can say even Tiger Woods let's some bad habits get back into his swing.  You get the idea. KISS.

Also, simple as it is, it is too complex for them to really do.  Or they can't explain the basics well enough to get people to do them.  It is not the trainer, not Scrum, but simply human nature. The two big things: we forget and we fall into bad habits.  Again, you have plenty to do to get them all to follow Scrum (as you now know it to be).  See the Scrum-Butts list I gave you.

There is lots advanced material in the course, but I kind of hide it.  (I am trying to keep is KISS for the beginners.)

For those who are intermediate to advanced, I have a Scrum 201 course.  And other CSTs have their intermediate courses.  The new CSP path gives you an reinforcement for learning more.  As you know, I think Tacit knowledge is more important than explicit knowledge, but they are both learning.  And with an in-person course or workshop, you cannot help but pick up tacit knowledge from any good Agile person. And, sooner or later, you must have coaching from the best coach you can find.  Every professional sports team does, if they want to be successful.

Please tell give us more questions.  We hope these ideas help, or at least make you think and learn.

Planning Poker Tools

Mike Cohn has the phrase ‘planning poker’ registered.  So, this is acknowledgement of that. And, like Kleenex, that’s what we call the thing itself.  It no longer has a generic name.

And, as some readers know, I like Priority Poker too.

So, for this post…. what are the best tools, sites or apps?

First, I like using the cards themselves.  This is great, except that the proper way of doing it, say with 5 people, is to average the numbers once they get ‘close’.  (We usually define close as ‘within 3 PP cards — ex: all votes are either 5 or 8 or 13.)

So, when using the cards, the hard part is addition and division.  Which I learned, but later got bad at.  Now, if you have Philip on your team (and Philip does addition and division wonderfully in his head), then you have no problem.  If your team is collocated.

But, I don’t always have Philip.

Here are some tools:
http://hat.jit.su  (thanks for Jaime Carter)
Planningpoker.com from Mike Cohn

And there are a host of iOS apps that I know of.  Maybe 15 different ones??

I am still looking for one to do the averaging for me.  But I like those those two sites above.

Comments?  Suggestions?

Impediments – Charlotte Class Jan 2-3

Here are some impediments that were identified

1. Lack of awareness of other projects
2. Unwillingness to say ‘no’
3. Clearing plate of current projects
4. Poorly prioritized projects by management
5. Pulled off project
6. Poorly defined reqs
7. Access to stakeholder / SME
8. Reaction to rapid market changes / demands
9. Budget ?
10. People –> Teams

In addition, these impediments were identified:

1. Unexpected changes
2. Lack of management support
3. Removal of Time, Dollars, People
4. No or little understanding of core requirements
5. Wrong or not enough stakeholders
6. Too many chiefs, no indians
7. SME not available
8. One person doing work
9. Wrong skill set
10. Lack of Communication
11. Unrealistic timelines
12. Resources shortage
13. No resource commitment
14. No defined deadlines (we need them)
15. Mixed expectations
16. Un (not good in various ways) Requirements
17. Budget (lack of)
18. Not enough Scotch
19. Scope Creep

Hopefully these help your team.

When should we do Agile?

This is a question many have asked, and here is my approach to it.

Let me refine the question a bit.  For a specific project or set of work, when do we do Agile?  (This might be the first project or the next project that comes to us.)

Note: This is NOT: (a) Should we implement Agile in this company or group? (b) If I just started implementing Agile, and I want to implement it gradually, how do I choose which projects to go agile first.  We are NOT trying to address either of these questions here.

First, one never chooses without an option.  Here we have two other options: (a) do not do the project, and (b) do it with waterfall.
But, I get ahead of myself.

First, let us define agile as Scrum – plus whatever engineering and other practices the Team already has or could quickly adopt.

Let’s also ask a few more questions:

1. Does the Team want to do Agile?
In this case, let’s assume they would prefer to try Agile rather than do another waterfall project.

Note: If 2 members of the Team hate Agile or Scrum, they will probably make it fail.  I do not recommend Scrum in this case (assuming you must have them on your team). If only 1 person hates Scrum, often we can get him or her convinced in the experience of it.

2. Will the Team do ‘pretty good agile’?
Let’s assume they learn enough, either through books or courses or coaching, or all three.

Note: If they are going to play ‘agile’ completely unprofessionally… my attitude is ‘why bother’.  Let them play waterfall unprofessionally and give waterfall an (in this case undeserved) bad reputation.

3. Is there any change or learning that will occur?
To be frank, I have never been on any project in my career where significant change did not occur.  I have been on a few projects where learning was significantly inhibited. But never on any projects where learning, and learning faster, was not important.

Note: I suppose if the effort were completely repetitious work, then it might be more efficient to do it in a waterfall way.  This does not seem to be the case with Toyota in assembling cars (they use a Team approach roughly similar to Scrum), nor is it ever the case with any knowledge work I have seen.

Some domains of learning: customers (beneficiaries, end-users, buyers, etc, etc), problem(s), solution, product, requirements, minimum marketable feature set, competition, technology, the business environment, the team itself, etc, etc.

Some domains of change: All of the above. Include also the company, the organizational structure or management reporting, the economy, etc, etc.

4. Do you have a Team?
Scrum is built to be a Team sport. It is based played with a real Team, and with a stable Team.  The Team can be of unknown capability or even weak capability, and Scrum adds the ability to identify the biggest weakness and fix that one first.  We want the Team to be ‘strong’, by which I do not mean capability. I mean more that they identify themselves as a Team, and the see the full Team as being responsible for success.

If you do not have a Team, then I question the value of doing Scrum.  Maybe, just maybe, waterfall might be better.  Or at least, something else.

Now, if you have very important work to do, and it must be done, or wants to be done, quickly, then you should be able to argue and easily get a decent (not perfect) Team. So, usually if you can;t get a

Team, you have a very unimportant set of work (compared to other sets), or, your company is not able to act reasonably.  If the later, I might try Scrum to start to show them the value of having a real, stable Team.  It might work.

5.  Is the work important and urgent?
If the work is neither important nor urgent, then I would probably recommend mainly that you just no do the work.  Yet, at least.  (Yes, urgent is perhaps only another way of saying important.)

The importance and urgency have important effects in Scrum. The higher they are, the more value Scrum tends to bring. In many different ways.

Two examples: (a) The more important a project, the more likely you are to get a real, stable Team. (b) The more urgent the project, the more likely the agile ‘learning’ approach to defining when the first release is ready will be helpful.

In my opinion, we project people all do not value enough speedily delivering something worthwhile to the customer.  Speed, time to market, beating out the competition — these things are far more valuable than almost any project team rates them.

***

As you can guess by now, if the above conditions are met (which seem to me quite minimum and obvious, but apparently that is not so in the ‘real’ world), then I recommend Agile-Scrum.

But let’s talk about why in a different way.

Why?

1. Learning.  Scrum enables more learning than waterfall.
2. Adaptation to change. Scrum makes it easier to adapt to change (in any dimension) than waterfall.
3. Lack of perfect knowledge up-front.  Waterfall would work a lot better if it were true that we knew a lot more useful information on Day 0.  But the truth is we never know 70% of (all the different types of) the information we need on Day 0. In fact, we are never clear, until the project or release is finished, how much of the information we did have on Day 0 was actually useful.  This fact (that we lack perfect knowledge up-front in every domain) is a key input to items #1 and #2 above.
4. Feedback. Scrum enables much more feedback than waterfall.
5. Random Carbon Units.  We are dealing with people here. All kinds of people. The Team, the customers, etc, etc.  Who knew people were so important??!!  In any case, a key input to items #1 and #2 above.
6. Innovation.  Scrum enables more innovation than waterfall.  (This is the positive side to the random carbon units. Random = unexpected = innovation (at least sometimes).
7. Two heads are better than one. This is an old old idea. But with our projects, we have found that the 7 heads of the Team (or whatever your Team size is), with our work, virtually 110% of the time, are smarter than 1 or 2 people.

***

Notice the things I did not mention.  I did not mention complexity or size or uncertainty.
But let me comment briefly on each.

Complexity.  I never see any simple project anymore.  At least simple in all dimensions. Also, I think complexity is a bad stand-in for better terms: learning, change, lack of perfect knowledge up-front.

For example: if the complexity were well-known up-front, then it is not the same as wading into a set of complexity that is largely unknown.

It is true that a more complex project in Scrum might be played differently than a less complex project in Scrum.  But the level of complexity per se is not a decision factor between Scrum and waterfall.

Size. We have found that Scrum is better for large projects than waterfall. If played professionally.  Size tends to mean more unknowns, more learning, more adaptation to change. On the other hand, if played unprofessionally Scrum might be worse than waterfall played professionally.

Uncertainty. Again, I find the concept in this context not very useful.  The relevant questions are, first, (a) how much learning, and (b) how much change.  Only when these approach zero do I want to do waterfall.  And this never happens to me.

One scenario. Imagine a large, important, complex and uncertain project.  Would you rather do it waterfall or agile (Scrum)?  First, let us grant that Scrum must be played differently than in a small, important, urgent, less complex, but uncertain project.  Probably more ‘up-front’ work.  Probably more people will be involved.  Someone will invoke more rules (useful or not). Etc. Etc.  Still, I would rather play Scrum (if done professionally) with the large project than play waterfall.