Lean UX Part 3 — Agile Teams, Collaboration, and the Real Chaos of UX Work

A simple breakdown of Chapters 7 & 8 of Lean UX.

By Jeff Gothelf and Josh Seiden.

My name is Nayama, I'm a UX/Product Designer, and this post continues my series on the book — now focused on what it feels like when Lean UX meets real teams and real companies.

Watch the video version here:

Lean UX stops feeling "theoretical" here

This part of Lean UX felt very different to me.

Because now the book stops talking only about:

• wireframes
• usability testing
• MVPs
• user flows

…and starts talking about something way more real:

people.

Real teams.

Real deadlines.

Real communication problems.

Real chaos.

And honestly?

That's exactly why I loved these chapters.

If you're new to UX or Product Design, this part of the book explains something extremely important:

How UX actually works inside companies.

Not the perfect social media version of UX.

The real one.

First: what is Agile?

You probably heard the word "Agile" a million times already.

Every tech company says:

"We are Agile."

But if you're new to UX or Product Design, the term can sound confusing.

So let's simplify.

Agile is basically a way teams organize work in smaller cycles instead of building everything at once.

Instead of:

• planning for 8 months
• designing for 5 months
• then launching everything at the end

…Agile teams work in smaller pieces called sprints.

Usually every 1–2 weeks.

The team:

• builds
• tests
• learns
• adjusts
• improves

continuously.

And honestly, this makes sense because digital products change fast.

Especially in e-commerce teams where priorities change all the time.

The big problem between UX and Agile

Historically, UX and Agile kind of fought each other.

Traditional UX wanted:

• deep research
• planning
• polished wireframes
• detailed documentation
• perfect deliverables

BEFORE development started.

Meanwhile Agile teams were saying:

"Just ship it."

"Move faster."

"We'll improve later."

So naturally these two worlds kept clashing.

One side wanted structure.

The other wanted speed.

And Lean UX tries to bridge those two worlds together.

Not by removing UX.

But by changing HOW UX works.

Agile does NOT mean "no UX"

This is one of the biggest misunderstandings ever.

Agile does NOT mean:

• no research
• no planning
• no UX
• no thinking

It just means:

Don't spend 3 months designing giant deliverables before learning if the idea even works.

That's the key difference.

The idea is learning while the product evolves.

And honestly?

That mindset changed how I see design work.

Because sometimes designers get emotionally attached to polished deliverables before validating if users even need them.

And then priorities change.

And the entire thing dies before launch.

Pain.

The "everybody works separately" problem

This part felt painfully real to me.

Because many companies SAY they work in Agile…

…but internally they still work like this:

UX designs first →

Developers build later →

QA tests at the end →

Problems appear very late.

And by the way:

QA means Quality Assurance.

Basically people testing the product before users see it to catch bugs, broken flows, confusing experiences, and technical issues.

The problem is not QA itself.

The problem is when everybody works TOO separately.

Because then the collaboration happens too late.

And suddenly everyone is stressed fixing problems right before launch.

UX is NOT just pretty screens

Honestly, I think this is the biggest message across the entire Lean UX book.

UX designers are not isolated artists working alone creating perfect screens.

Good UX happens when:

• designers
• developers
• product managers
• marketers
• stakeholders

communicate EARLY.

Not only after everything is polished.

And I've seen this happen in real projects MANY times.

You spend days designing:

• beautiful interfaces
• animations
• polished flows
• perfect layouts

…and suddenly somebody says:

"The priorities changed."

Or:

"We're not shipping this anymore."

And now your beautiful work becomes a ghost project.

Not because the design was bad.

But because collaboration happened too late.

That's why Lean UX pushes cross-functional collaboration so hard.

Scrum rhythms (without the complicated buzzwords)

The book also talks about something called Scrum rhythms.

Sounds scary.

But honestly the concept is simple.

It basically means the routines Agile teams follow to stay aligned.

Things like:

• quick meetings
• planning sessions
• progress reviews
• discussing blockers early

And yes… meetings can be annoying sometimes.

But honestly?

Quick conversations saved my sanity MANY times.

Because a 15-minute conversation can solve confusion that would take HOURS through:

• Slack messages
• emails
• endless comments
• random screenshots

Communication early = fewer disasters later.

Modern UX teams are extremely collaborative

One thing I really connected with in the book was the idea of walls full of sketches, notes, prototypes, and flows.

Because honestly?

That looks WAY more like real UX work than those perfect "day in my life as a UX designer" videos online.

Social media romanticizes UX SO much sometimes.

You know those videos:

• perfect desk
• perfect lighting
• one tiny coffee
• one centered MacBook
• no stress
• no chaos

Meanwhile real UX work sometimes looks like:

• 37 tabs open
• Slack notifications attacking emotionally
• FigJam everywhere
• sticky notes
• Miro boards
• confusing file versions
• people debating ideas
• last-minute changes

Real product work is collaborative chaos sometimes.

And honestly?

That's normal.

Chapter 8 — the part that hurts

Chapter 8 shifts into something MUCH harder:

organizational culture.

And honestly?

This chapter felt extremely real.

Because many companies SAY they care about UX…

…but their structure fights against good UX.

You see things like:

• endless approvals
• teams not communicating
• fear of mistakes
• rigid hierarchies
• ego problems
• disconnected departments

Companies want innovation…

…but punish experimentation.

They want creativity…

…but fear risk.

And this chapter basically says:

Lean UX is not just a design process. It's a mindset shift for the entire company.

Sometimes the problem is the system

This chapter talks less about screens…

…and more about:

• communication
• hierarchy
• management
• team culture
• collaboration
• fear of failure

And honestly?

Those things affect UX WAY more than people realize.

Sometimes the designer is not the problem.

Sometimes the system itself is broken.

That part hit hard.

Because as designers, we often think our job is only designing interfaces. But part of the job is also improving communication inside teams — helping people understand problems better, collaborate better, and visualize solutions.

That's UX too.

Designers are NOT "just the UI people"

I loved this section.

Because many traditional companies put people into tiny boxes.

Like:

"You're the designer. You only make screens."

"You're the developer. You only code."

But real product work doesn't work like that anymore.

Good UX requires understanding how different disciplines affect the user experience together.

That does NOT mean you need to become:

• a developer
• a marketer
• a data scientist
• a project manager

…but collaboration matters.

Because UX lives between all these areas.

Not every company is ready for Lean UX

And honestly?

This is important to accept.

Some companies are extremely collaborative.

Others are VERY rigid.

Some encourage experimentation.

Others punish mistakes immediately.

And organizational culture usually does NOT change overnight.

You don't walk into a company with magical UX powers and transform everything instantly.

Change usually happens slowly.

You:

• test ideas
• show results
• build trust
• communicate clearly
• stay consistent

That's how change grows.

Little by little.

Final thoughts

One of the biggest lessons I got from Lean UX is this:

Great UX does NOT only depend on talented designers.

It also depends on:

• healthy collaboration
• flexible teams
• communication
• trust
• experimentation
• company culture

Because real product work is messy sometimes.

And honestly?

That's okay.

Conclusion

This was honestly one of the most insightful UX books I've read because it focuses less on perfect design theory… and more on how real teams and real products actually work.

And I think that's what makes Lean UX so valuable.

It talks about:

• collaboration
• communication
• experimentation
• teamwork
• adaptability
• real-world product work

Not just pretty screens.

And honestly?

That's what UX really is.