101 Inspiring Quotes About Agile From Mountain Goat Software

Download as pdf or txt
Download as pdf or txt
You are on page 1of 103

When to use iterative


development? 

You should use iterative
development only on projects
that you want to succeed.

An organization that 

treats its programmers 

as morons 

will soon have 

programmers that 

are willing and able 

to act like morons only.

Do the planning, 

but throw out the plans.

There is nothing
so useless as
doing efficiently
that which should
not be done at all.

The only way to go fast is to
go well.

The value of an idea 

lies in the using of it.
“ Nothing endures but change.

Stable Velocity. 

Sustainable Pace.

The secret of getting ahead is getting started.
The secret of getting started is breaking your
complex overwhelming tasks into small
manageable tasks, and then start on the first
one.
As ScrumMasters, 

we should all value 

being great over 

being good.

It seems that perfection is reached not
when there is nothing left to add, 

but when there is nothing left 

to take away.

It is a capital mistake
to theorize before
one has data.

Everything stinks
till it’s finished. 

Planning is everything. 

Plans are nothing.

Adopt the attitude 

that continuous
planning is a good
thing – In every
iteration, expect
your plans to change
(albeit in small ways
if your planning is
effective). Don’t fall
into the trap of
thinking that the 

plan is infallible.

Right and wrong 

cease to be 

useful concepts 

when you’re talking about
software development.

If you want a
guarantee, 

buy a toaster.

A market is never
saturated with a 

good product, 

but it is very
quickly saturated
with a bad one.

As a software development consultant, 

I've never encountered 

a successful software company 

(although my sample size is limited) 

in which the team and project leaders
were not technically savvy.

The important thing is not your process.
The important thing is your process for
improving your process.

Most teams aren’t teams at
all but merely collections of
individual relationships with
the boss. Each individual
vying with the others for
power, prestige, and position.

Keep your roadmap simple 

and easy to understand. 

Capture what really matters; 

leave out the rest.
“ When forced to work
within a strict framework
the imagination is taxed to
its utmost – and will
produce its richest ideas.
Given total freedom the
work is likely to sprawl.

Simplicity is 

the ultimate 

sophistication.

Scrum is like your mother-in-law,
it points out ALL your faults.

Failure is simply the opportunity to
begin again, 

this time 

more intelligently.

As a general rule of thumb,
when benefits are not
quantified at all, 

assume there aren’t any.

This indispensable 

first step to getting 

what you want 

is this: 

Decide 

what you want.

Anyone who has never 

made a mistake 

has never 

tried anything new.

That which is a feature to
a component team is a
task to a feature team.

Be honest – 

Without objectivity 

and honesty, 

the project team 

is set up for failure, 

even if developing 

iteratively.

To be uncertain is to be uncomfortable, 

but to be certain is to be ridiculous.

Software is the most malleable product.
Companies need to use this
characteristics to their competitive
advantage, and sticking to traditional
waterfall development negates this
advantage.

The more elaborate 

our means of communication, 

the less we communicate.

Everything is vague to a degree
you do not realize ‘till you have
tried to make it precise.

Scrum without automation is like driving 

a sports car on a dirt track – you won’t
experience the full potential, 

you will get frustrated, and you will
probably end up blaming the car…

As an Agile coach, you don't
need to have all the answers; 

it takes time and a few 

experiments to hit on 

the right approach.

Plans are worthless, 

but planning is
everything.

Bug fixing often uncovers
opportunities for refactoring. 

The very fact that you’re working
with code that contains 

a bug indicates that 

there is a chance 

that it could be clearer 

or better structured.

In XP, we don’t
divide and conquer. 

We conquer and
divide. 

First we make
something that
works, then we bust
that up and solve 

the little parts.

After working for some years in the
domains of large, multisite, and
offshore development, we have
distilled our experience and advice
down to the following: 

Don’t do it.

First-time product owners
need time, trust, and support
to grow into their new role.

If you tell people where to go, 

but not how to get there, 

you’ll be amazed by the results.

Success is not final, 

failure is not fatal: 

it is the courage 

to continue that counts.

People are 

remarkably good 

at doing what 

they want to do.

I like to think of this [testing] in parade
terms. When you’re working a parade, it
is better to march in front of the horses,
rather than behind them, sweeping up.
Worse yet, what if they are elephants?

If you define the problem correctly, 

you almost have the solution.

We define an agile tester this way: 

a professional tester who embraces change,
collaborates well with both technical and
business people, and understands the
concept of using tests to document
requirements and drive development.

As the tests get 

more specific, 

the code gets 

more generic.

You improvise. 

You adapt. 

You overcome.

Planning is 

a quest for value.

To say that companies or CIOs
are reluctant to embrace agile
is like saying they wouldn’t
take aspirin for a headache.
And they’re not only 

not taking the aspirin, 

they’re banging their heads
against the wall and 

wondering why it hurts.

Our greatest weakness
lies in giving up. 

The most certain way to
succeed is always to 

try just one more time.

As a rule of thumb, 

for every user who
tells you about a
problem, there will be
between 10 and 100
other users who
experienced the same
problem and didn’t
think to get in touch.

Luck is not a factor.

Hope is not a strategy. 

Fear is not an option.

To achieve great things,
two things are needed:
a plan, and not quite
enough time.

Grand principles that generate no
action are mere vapor.
Conversely, specific practices in
the absence of guiding principles
are often inappropriately used.

The thing is, Bob, 

it’s not that I’m lazy, 

it’s that I just don’t care.

If everything seems 

under control, 

you’re not going 

fast enough.

Prediction is very difficult,
especially about the future.

To improve is to change; 

to be perfect is to change often.

Whether you think
that you can, 

or that you can’t, 

you are usually right.

Every great product owner
needs a great ScrumMaster.

The more they 

over think the plumbing, 

the easier it is 

to stop up the drain.

It doesn’t matter 

how good you are today; 

if you’re not better next month, 

you’re no longer agile.

Focus on idle work
not idle workers 

to achieve fast,
flexible flow.

It’s never about 

how you start – 

it’s always about 

how you finish.

Agility means that 

you are faster than 

your competition. 

Agile time frames 

are measured in 

weeks and months, 

not years.

We regularly coach groups that ask, 

“How can we calculate how many people
we will need?” Our suggestion is, “Start
with a small group of great people, and
only grow when it really starts to hurt.” 

That rarely happens.

A good plan violently executed now 

is better than a perfect plan 

executed next week.

We don’t need
an accurate
document. 

We need a
shared
understanding.

If you have a choice of two things
and can’t decide, 

take both.

Agile leaders lead teams, 

non-agile ones manage tasks.
“ Change is scary, but
complacency is deadly.

Design and programming 

are human activities; 

forget that and all is lost.

Scrum focuses on being agile 

which may (and should) lead to improving.
Kanban focuses on improving, 

which may lead to being agile.

When we go into that new project, 

we believe in it all the way. 

We have confidence in 

our ability to do it right.

Agile teams produce a continuous
stream of value, at a sustainable pace,
while adapting to the 

changing needs of the business.

People with goals succeed 

because they know 

where they’re going.

Opportunity is missed by
most people because 

it is dressed in overalls
and looks like work.

In everything we do, 

whether writing tests, 

writing production code, 

or refactoring, 

we keep the system 

executing at all times.

Agile is all about teams
working together to
produce great software. 

As an Agile coach, you
can help your team go
from first steps to
running with Agile to
unleashing their full
Agile potential.

No matter what the problem is, 

it's always a people problem.

It is always wise
to look ahead,
but difficult 

to look further
than you can see.

Although self-organizing 

is a good term, 

it has, unfortunately, 

become confused with
anarchy. 

The benefit of allowing a
team to self-organize isn’t
that the team finds some
optimal organization for
their work that a manager
may have missed. Rather, it
is that by allowing the team
to self-organize, they are
encouraged to fully own the
problem.

Everyone is a genius. 

But if you judge a fish 

on its ability to climb a tree, 

it will live its whole life 

believing that it is stupid.

There’s no sense in being precise 

when you don’t even know 

what you’re talking about.

In a good shoe, 

I wear a size six, 

but a seven feels 

so good, 

I buy a size eight.

Kill your product 

if a pivot is not 

beneficial and 

persevering 

no option. 

It's tough but 

the right thing to do.

Remember: 

it’s not the documentation 

that needs to be in sync, 

but the people.

The first thing to realize when
formulating your first DoD (Definition
of Done) is that it isn’t cast in stone.
You don’t need to spend an eternity
deliberating what it should be,
because it can evolve over time.

Any fool can write code that 

a computer can understand. 

Good programmers write code 

that humans can understand.

However beautiful the strategy, 

you should occasionally 

look at the results.

Be prepared to cut your losses –
Canceling bad projects early 

is success because you save time,
money and resources that can be
applied to better opportunities.

The best way to get
a project done faster
is to start sooner.

Optimism is an 

occupational hazard 

of programming: 

feedback is 

the treatment.

Inside every large program, 

there is a small program 

trying to get out.

People don’t adopt a methodology,
they adapt it.

Be fixed on the vision,
but flexible on the journey.

“Scaling agile” always
sounds to me like “scaling
small-batch, hand-crafted
artisanal beer.” You end up
with Bud Light

You might also like