Agile Planet

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

Saw this tweet the other day…

So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?

Susan Prior drops in on Kate to talk about some new products she would like developed.

“Hi, Susan,” said Kate. “You wanted to talk with me?”

“Hi, Kate. Yes. I’ve got some product ideas that I think we should invest in, and I wanted to talk with you about getting started. Dan is interested and said I should get your input.”

“Sure. What’s up?”

“There are three new products I’ve been talking about with my people and with customers. They’re all getting good reactions from prospects we’ve talked to. I think they would each bring us about a million dollars in the first year after release. I can show you the figures.”

Susan and Kate went over the figures, and talked about the three projects, which were codenamed Emerald, Obsidian, and Ruby.

Kate said: “The revenue looks good for each of these. What do you know about costs?”

“Gil and Jim looked at the specs and agreed that each one of these is about 15 person-months to develop.”

“OK,” said Kate. “What are you thinking you’d like to do?”

Susan said, “I have three people in Marketing who are working up feature stories. I would be the official Product Owner on all three, at least through first release. Development can free up six people soon. I’d like to get those six people committed to these projects for nine months to a year to get the products out.”

“Hmm. How did we get from 45 person months to 72 all of a sudden,” Kate said. “That’s a lot of money, from 375,000 to 600,000 dollars.”

“Well, I figured in a little extra in case Gil and Jim under-estimated, or in case they are late.”

“I understand, though I’m not sure I agree. And why are you going for all the money and time for all three projects at once?”

Susan said, “These are all important and valuable projects. We should get them all under way right away.”

“You’re asking Development to work on all three of them at once? Two people on each or something?”

“No,” said Susan. “Gil and Jim say the critical mass for each product is five or six. So I’ll have the team work on all three products.”

Kate put on her confused face. “All three? Wouldn’t it be better to work on them one at a time? Most important first?”

Susan said, “No. They’re all equally important and equally valuable. They should get equal priority.”

“Equal? Are you sure?”

“Well, as closely as we can tell,” said Susan. “Each of these projects takes about the same amount of time and will bring in about the same revenue flow. So they should get equal priority.”

Kate said: “Let’s test that thought. What if we could only afford one? What should we do?”

“I knew you would do this. This is my chance, and you want to wreck it. You’ve always hated me ever since the beginning.”

“Calm down,” Kate said. “I don’t want to wreck anything. And I don’t hate anyone. I can’t afford it, it poisons my soul. I just asked a question. What if we could only afford one? What would be best to do? Would you like to take a break to think about it?”

Susan steadied herself. “No, I’m OK. I’m just so excited and scared about this. These ideas are really good. They could make a difference to the company and I can show what I can really do.”

“I’d like that, too. You got off to a bad start with the team on Empire. But I know they are willing to work with you on this,” Kate said.

Susan asked, “You know? How do you know?”

Kate laughed: “I know almost everything around here. People tell me things. I think it’s because I spend so much time in the coffee room.

“Gil and Jim have both said, several times, that they respect your ideas and would like to see them get implemented.”

Susan calmed down some more. “They did? They never told me.”

Kate laughed again. “They’re programmers. They never say anything personal to anyone. It’s their job.”

“Good point. Anyway, if we could only do one, it should be Obsidian.”

“Why Obsidian?”

Susan said, “Three reasons. It’s a bit simpler, the prospects we have talked to seem more enthusiastic about it, and we understand it better.”

Kate thought, then spoke. “Those seem like good reasons. Thanks. Now, thinking again about doing these as you propose, let’s look at some pictures.”

This time Susan laughed. “I knew I could never get out of here without pictures.”

“It could be worse. I could make you listen to me singing. OK. Let’s look at a nine-month plan.”

“OK,” Kate said. “Here’s a planning area. We have the three projects, Emerald, Obsidian, and Ruby. They’re all about the same size in stories, and you’re planning an ideal nine-month project. I won’t show any contingency here, just for clarity. OK?”

“Yes,” said Susan. “We may need the contingency, though.”

“Don’t worry, we’ll talk about that later. Now here is the way features will grow over the nine months, according to plan.”

Kate added feature lines to the chart:

Kate went on. “The features all grow at about the same rate until the projects are all done after nine months. That’s the starting picture, agreed?”

Susan nodded. “Yes, exactly. The developers would work in parallel on all three products”

Kate said, “In parallel. Why is that good?”

“So we could see progress on each product.”

“And why do we need to see progress on each product?”

Susan thought. “Well, so that if anything goes wrong we can do something about it.”

“OK, I guess. Now when do we start making money from these products?”

Susan said, “If it goes according to the plan there and we don’t need the contingency, we start making money shortly after the nine months is up.”

“Shortly after,” Kate said.

“Well, we would have to roll them out with advertising, documentation and training and such.”

“Those couldn’t start sooner?”

Susan said, “Well but what happens if  the developers are late?”

“You keep asking that,” Kate said. “In my view developers are never late. Products are late sometimes, but never developers. I suppose that sounds like crazy talk.”

“Frankly, yes,” said Susan.

“OK, we’ll defer that for a moment. Returning to the picture, we start earning money at three million a year, starting nine months out, is that right?”

“Yes, that’s right,” Susan said.

“OK. Now take a look at this drawing instead.” Kate erased some lines and drew some new ones:

“Susan, now I’m drawing a picture of what happens if we do the three projects one at a time. The new vertical lines are three release dates, at three months, six, and nine.”

Susan said, “But what about contingency?”

“I’ve left that out, as I did in the previous picture. We’ll talk about it though, don’t worry. Now in this scheme, we focus the developers on first Obsidian, then Emerald, then Ruby. Look what happens to Obsidian development:”

Susan said, “Yes. It gets done right away. But the others aren’t even started. That’s risky, isn’t it?”

Kate said, “I’m not clear on why it would be, so marshall your thoughts. But tell me what happens to company revenue with this scheme.”

“Well, we start earning after three months instead of nine.”

“Do we make more, or less, or about the same,” Kate said.

“About the same. Maybe more, because we are in the market sooner and might get more early adopters.”

“What about the impact on this fiscal year, and on our ability to fund projects?”

Susan scratched on a scrap of paper for a moment. “Well, we’d be to market six months sooner and in the first six months I think we get about 40 percent of the 12 months revenue for Obsidian. If we start right away, that would all fall in this fiscal year.”

“Yes! That would be $400,000 and that’s just about the low-end cost estimate for all three projects. What does that do to our concern about deferred risks for Emerald and Ruby?”

Susan thought. “OK, I see. Total cost of those two projects is scheduled to be less than $300K. Even if they completely failed, Obsidian’s first six months revenue would cover the costs. But again, what if development can’t get Obsidian done in three months?”

Kate smiled. “Go with me a bit longer while I finish this picture. Here’s the picture of the other two projects getting done sequentially after Obsidian:

“So here I’ve just assumed we’ll do Emerald next, then Ruby. It could be done the other way. So Emerald is done after six months. What happens with revenue there?”

“If things go according to plan, we think Emerald would bring in about 150K in its  first quarter out,” Susan said.

“Yes. So even that revenue is a big chunk of the cost of doing Ruby, and of course we’re already covered by Obsidian. So by the end of the three projects, we would see $500,000 in revenue, and it would all fall into this fiscal year. And the total cost of the projects you are asking for is around $375,000 if we use the development estimates. Even with six developers, we are looking at expenses of about 3/4 of 600K, or 450K for the nine months. See the difference?”

Susan stared for a moment. “Yes, sure. Done your way, the same projects actually break even this year or earn a small profit. Done my way, we spend $450,000 before we get anything.”

Kate said, “Let’s not think my way your way. Done in parallel, the projects burn through almost a half a million dollars this year. Done in series, they burn $150,000 in the first quarter, then start earning back, and we are back to even by the end of the fiscal year.”

Kate smiled. “If it was your money, Susan, which way would be ‘your way’?”

Susan said, “I get it. My way is to do this in series. That’s what I recommend. Yes, totally. I’m sure that’s what I meant all along. Serial.”

Kate laughed. “I thought so. It’s almost lunch time, are we done for the morning?”

Susan thought. “I think so, yes. I’d ask to have lunch with you but I need to think a bit first. I’m still worried about contingencies and risks.”

“Good,” said Kate. “I’d like you to think about that. As a hint, think in terms of what you can do as Product Owner to manage the risk. But keep in mind it’s your money, and you can just barely afford the $150K a month for your six developer team.”

“That’s scary,” Susan said. “I guess that’s what you feel all the time?”

“Well, it’s the problem I have all the time, Susan. But I’m not very scared. See if you can figure out why. When shall we meet again?”

“I’d like to come in again tomorrow, if that’s OK,” said Susan.

“Sure thing,” said Kate. “I’ll be here. Thanks, this was fun.”

“It was,” said Susan. “Oddly enough, it was. Thanks, Kate.”

“You’re welcome, Susan, and thank you. We could use another three million in revenue.”

This comes from an ISTQB advertisement they spammed me with, today:

“To ensure the quality of any software system, testers and QA professionals must thoroughly test the product. But how do you know that these tests are effective? If your team is conducting ad hoc, informal tests with little guidance or planning, the quality of the end product can be severely jeopardized—negatively affecting your bottom line.”

I don’t like to say things like this, nor am I comfortable supporting people who do. It’s not that it’s untrue– it is not necessarily untrue. But it is the kind of statement that fans the flames of a certain sort of Factory School bigotry in our industry. “Oh, you can’t trust testing unless it is pre-planned, pre-packaged, pre-approved, formalized, etc.”

Notice they say nothing about skill. It’s all about methodology, here, not skill. This kind of setup suggests that the next statement will be about the importance of factory-like test methodology. But that’s not what happens.

“The best way to be certain that you are providing customers with quality software is to make sure your team of testers is certified.”

Friends, I’m aware of no one in the industry– not even my worst enemies, not even Rex Black or Stuart Reid– who would publicly assert this or defend it. In fact, in debates against those of us who think certification is consumer fraud, the most typical move is for certificationists to say that certification isn’t even about skill, but rather about basic knowledge. “It’s a start” they say. “It’s a foundation.” (I reply that it’s a bad start and a bad foundation. Much worse than what it tries to replace.)

But then they allow this sort of advertising to go out! Completely undercutting their innocent-sounding plea! And they wonder why I complain that they don’t have the best interests of the testing craft at heart.

Notice that the “ad hoc and unplanned” stuff doesn’t even logically connect to certification. In fact, wouldn’t a highly skilled tester be far more likely to succeed with an ad hoc testing regime? When Roger Federer plays ad hoc tennis, I bet he still wins.

I think the reasons they start talking about methodology and end up talking about certification is A) their potential customers don’t understand the difference between skill and method, B) method is more concrete than skill, thus easier to evoke, and C) they know that what they say doesn’t have to be true or even logical, as long as it evokes horror and promises hope.

Oh, but there’s more…

“By taking the Software Tester Certification course and earning an internationally recognized certification in software testing, your team will gain the expertise needed to handle your greatest testing challenges; earn credibility and recognition as competent quality assurance professionals; and provide greater value to your organization.”

It’s internationally recognized? By whom? Some people who don’t study testing and some people who study testing and financially benefit from certification. Okay, but it is also internationally ridiculed by serious testers of many nations who wish to raise themselves to a level of skill that can’t be obtained in just a couple of days of training.

I recently encountered Dot Graham, now semi-retired, who told me that it hurts her feelings when people like me suggest that certificationists are only in it for the money. Dot is a sweet person. I don’t want to hurt her feelings. But I point her to advertising like this and I challenge her to explain it in any other terms. If not greed, then what, Dot? Stupidity? Pride?

Dot doesn’t want to argue with me about this. Of course she doesn’t. Rex Black doesn’t want to argue, either. Naturally. What answer could there be? Lois Koslowski once told me that “big dogs” don’t need to debate (in fairness, Lois Koslowski claims not to be a tester. I agree that she showed no testing competence or knowledge in the conversation we had. I just mention her because she did claim to be in charge of the ASTQB organization. Yikes!) This is capitalism in its ugly form– harvesting the ignorance and fear of others. Debate has no place here.

Is there no one in that self-declared professional community who reviews the advertising and stands up for professional temperance and humility?

Amr Elssamadisy reports on InfoQ that automated acceptance tests are “only used by a small minority of the community.”  Is this true?  If you and your team don’t use automated acceptance tests, please let me know how you handle regression tests as the application grows larger.  You can leave a comment here or, if you’d rather not say it in public, email me directly.

OK, I know that “acceptance tests” are somewhat a misnomer.  While they may provide a go/no go indicator for the functionality of a user story, we all know that it’s possible that the application passes the test and still isn’t what the Product Owner or Customer wants.  You still need to show it to the Product Owner/Customer to get their acceptance.  Bear with me, though, and let’s use this common term.

So, a Product Owner, a Developer, and a Tester walk into a bar sit down to talk about something that the system under development should do.  The Product Owner describes the user story.  The Developer and Tester ask questions (and make suggestions) until they think they can answer the basic question, “How will I know that this story has been accomplished?”

No matter how or when it’s done, these three amigos (to borrow a term from my friends at Nationwide) must agree on this basic criteria or things will go wrong.  Turning this agreement into an automated acceptance test (or three) gives it a precision that often tests the agreement and uncovers fuzziness or conflicting definitions in the words we use.  Automated acceptance tests help us express our expectations.

If you don’t use automated acceptance tests, how do you clearly communicate desires (”requirements”) between the business, the developers, and the testers?

If your testing is manually executed, or is automated using record-and-playback, then you’ll have the problem where the testers have to wait until the developers think they’re done before they can start verifying the functionality.  This puts the testers behind from the very beginning.  It also delays the feedback to the developers when the functionality doesn’t behave as expected and results in bug-fix cycles on code thought to be complete.  These things combine to slow down the pace of development.

It’s more valuable to automate those tests while the code is still written.  As development proceeds, you can see those tests start to pass, providing a clear indication of the progress.  If a developer writes code expected to make a particular test scenario work, but the test fails, then you can delve into the issue right away.  Is there a mistake in the code, in the test, or just a lingering disagreement about what we intended to do?  Automated acceptance tests express the growth of functionality in our application.

If you don’t use automated acceptance tests, how do you monitor the progress of development?

Once the functionality works, we want it to continue working, unless we expressly decide it should work a different way.  If we want to know that it continues to work, we need to verify that.  That means that we need to continue to check a growing amount of functionality.  If that checking requires significant human effort, we’ll soon be overwhelmed by it and our progress will get slower and slower.

Computers are great for doing our repetitive grunt work.  Yes, it’s a continually increasing job for them, too, but they’re usually faster than people, they can work longer hours, and they can easily scale to handle more work by adding hardware.  If computers are checking that all of our tests are still working on a daily or more frequent basis, then we rapid notification when we’ve accidentally broken an old feature.  Automated acceptance tests express our confidence that the system continues to work.

If you don’t use automated acceptance tests, how do you maintain confidence that the system still works?

If you don’t use automated acceptance test, please let me know the answers to these questions–especially the last one.

 

A salesman from G2 Test Labs just called me. He said he was from India. He wanted to know if my testing company needed to partner with an offshore lab like his. I’m writing this now, while the memory of the conversation is fresh.

After he made his brief brief opening monologue I asked him “I’m a testing company. Why are you calling me?”

“Maybe you want to have an offshore arm.” He said.

“Well that depends on the skills of your testers. How do you train your testers?” I asked.

“Oh… we don’t do any training. But our testers are certified by other organizations.”

“Which organizations certify your testers?”

“Uh… I will have to check on that and get back to you.”

“Yes, that’s important information. Are ALL your testers certified?”

“Probably… most of them are.”

“Sounds like you don’t know.”

“…”

“Hey, this will make a funny post. Check my blog in about an hour. Goodbye!”

Now, in fairness, the salesman sounded like he was about 22 years old. Perhaps they sent him to call me as part of some hazing ritual.

[Oh, I just remembered, in his opening statement, he mentioned that his company was ISO-9001 certified, too. Wow. That takes me back to 1992, when I was fighting ISO-9001 certification. That certification program turned out not to amount to anything, either.]

Over the past year, I've been working on a startup software business. We're in the process of shutting it down now, actually, but that's a different story. During the past year, I've learned a lot about startups and business models....

We humans like to take a very soft cloud of ideas and give it a name, such as Waterfall or Scrum or Lean or Kanban,  in an attempt to get a better handle on some good ideas. We also seem to have an irresistible impulse to describe how good our Named Cloud is compared to some other Named Cloud. I imagine part of this is no more than a normal desire to share our Internal Cloud with others, so that they may benefit. Sometimes we seem to go overboard with that, to Named Cloud Bashing.

“Kanban is better than XP because Kanban has more WIP.”

“XP is better than Kanban because in XP we have actual programming.”

Sometimes it seems that all this revolves around personalities. I know of a small number of people who appear to me to think Scrum is bad because they don’t like Ken. There must, therefore, be hundreds of people who think XP is bad because of Yours Truly.

Is It Still Scrum If …

Trouble with clouds is that they change. They even run into each other as the wind blows them around. That cloud you stupidly thought looked like a bunny ran into my cloud that looks exactly like a dinosaur. Now it looks totally like New York, and you foolishly  insist that now it is a big dinosaur-eating bunny.

“Is it still Scrum if we use a kanban board instead of a burndown?”

“Is it still XP if we don’t break things down into tasks but just use stories?”

Who the hell cares???

The question we ought to be asking is whether, if we adopt this idea from wherever we found it, will we do better than if we adopt this other idea. The absolutely best way to determine this is to try it. We can get ideas from experts, even if they happen to be proponents of Other Named Clouds Which Shall Be Anathema.

Ad Processem: A Continuing Kind of Fallacy

The process wars have gone on more than long enough.  It doesn’t matter who had an idea, or what process originally contained an idea. What matters is what ideas we apply skillfully and wisely to our situation in order to improve it.

I’ve been helping software development teams improve for a long time now. In so doing, I draw ideas from the whole range of the Fuzzy Cloud Cluster named Agile. I try to give credit where it is due to the individuals who invented this idea, if I know them, or to the authors who best describe the idea.

But that Named Cloud that looks like a Rat today? I don’t think we should care much about that, because the wind is blowing away the front part of it and very shortly no one is going to give a Rat’s Ass about what it used to be.

I've got two public workshops coming up:

Designing Experiential Exercises and Simulations June 22-26, 2009 in Albuquerque, NM.

If you lead workshops or teach classes, experiential exercises and simulations increase engagement and retention. They also make learning (and teaching) more fun. Join Jerry Weinberg and me for this experiential workshop. Participants should come prepared with an exercise or a concept they wish to turn into an experiential activity.

Email me (derby[at]estherderby[dot]com) if you are interested in the Designing Experiential Exercises and Simulations workshop.

Secrets of Agile Teamwork, July 21-23, 2009 in Redmond, WA.

Beyond technical skills, Agile success depends on productive self-organizing teams. How do you develop, grow, and maintain a functioning self-organizing team? It’s not magic, but it doesn’t just happen either. Effective self-organizing teams rely on personal and interpersonal effectiveness. In this hands-on workshop, we’ll discover the secrets to developing the skills you need to succeed and lead on a self-organizing team. My co-leader for this workshop is Diana Larsen.

Register for Secrets of Agile Teamwork through our hosts, SolutionsIQ.

web site news: ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a viable platform that should be seriously considered for many forms of applications - in particular web applications using Ruby on Rails. I also go through some technical lessons, including some thoughts on testing with Active Record.

web site news: Rebecca Parsons and I talk about Google App Engine and the general world of clouds. In the first bit I talk about things various ThoughtWorkers learned from experiementing with App Engine, highlighting issues with testing, persistance, and concurrency. In the second part Rebecca talks about the broader issues enterprises will face with moving to the cloud.

From time to time I like to actually post a bit of code on this programming blog, so here's a stream-of-conscious (as in "not a lot of thought went into design quality") example that shows how to: Open Excel, making it invisible (or visible) to the user. Create a workbook and access individual worksheets Add data to a cell, or retrieve data from a cell Add a chart to a worksheet, with constants for various chart types Save as Excel 97-2003 format and close Excel If you know where I can find the ...

This post has been stewing for a little while, and now I’ve been kicked into writing it up by Naresh Jain’s post on Lessons Learnt from Restaurant Business.

Since Channel 4 in the UK started supporting the Mac for their online replays, I got hooked on Gordon Ramsey’s Kitchen Nightmares series¹. I’ve never worked in a restaurant and I know that TV programmes are a manufactured narrative, but (inbetween all the swearing) there are some interesting themes that come through every week:

• cook stuff your customers actually want. Some owners get carried away with bigger ideas than they can handle;
• reduce the menu to something your staff can cope with. Bloated menus and fancy presentations cripple the kitchen staff. Cut it all back to something they can do well;
• help the staff take pride in their work. Producing stuff badly for unhappy customers is wasting people’s lives, and probably not sustainable. One of Ramsey’s triggers for cussing out the brigade is when they’re not trying—and watch their reactions when they turn it around and he praises them;
• cook your own stuff. Don’t rely on outside prepared stuff unless there’s a very good reason². Bring in good ingredients and, um, cook them;
• take responsibility. You’re the chef/owner/manager/waiter, so do your f***ing job;
• communicate. Head chefs should be talking all the time so their brigade knows what’s going on, waiters and chefs should discuss the tickets so they know what’s ordered, waiters and managers should talk so they know what’s going on with their customers; and,
• see it as it is. The building looks run down, the kitchen is filthy, the food is disgusting. Stop fooling yourselves.

I know it’s relatively easy to come in and see how to rescue a business that’s months away from failing, after all an outsider has the advantage of not having been sucked into the mess. But, even through the box of mirrors that is TV, Ramsey shows two strong drives: total focus on providing the best service to the customer, no excuses; and, total respect for the craft of cooking. He just lights up when he finds a junior with ability and enthusiasm.

Somehow, I feel this ties in with a post from another coach given to immoderate use of language, Mike Hill wrote about how raising your internal quality makes you go faster. I think there’s a commonality of purpose there that we should take note of.

---

1) I mean the UK version of this series. The US series is like a boil-in-a-bag version: manufactured, over-spiced, unsatisfying. In fact, the opposite of everything Ramsey is promoting. But that’s another story.

2) Yes, I know there have been some “scandals” with Ramsey’s London restaurants, but that doesn’t invalidate the point.