Press "Enter" to skip to content

The Death of Agile (Allen Holub)

so I’m going to change tone a little bit
here because I’m not going to talk about
code at all I’m going to talk about how
to produce code and in particular I’m
going to talk about agile not because
well let’s put it this way I think agile
is by far the best way that we know to
produce software and at the same time I
think the notion of agile software
development is being completely
destroyed by most of the agile community
so when I talk about the death of agile
what I’m really talking about is the
death of what I think of as real agility
and a replacement of real agility with a
kind of fake agility that is suitable
for corporations but doesn’t really work
in the real world so let me explain
exactly what I’m talking about so I
would explain it if my clicker was
working there it is good so the reason
I’m doing this talk is because as a
consultant I often come into companies
and give them advice about agile process
and I am just getting sick to death of
dealing with the aftermath of the
certified scrum guys and right is that
they come in they do their thing and
they leave this behind them and the the
real there are a lot of issues
surrounding that but scrum is really a
problem is the problem it is not the
solution and the basic problem is the
notion of a cargo called now the cargo
cults happened in the Pacific Islands
during World War two is they’ve
Islanders are living happily on their
islands without any cares in the world
eating fruit as a drops off of trees but
they were living in the Stone Age a few
minutes later it seems a bunch of
soldiers land on the island they make a
runway and then airplanes start landing
and the airplanes bring with them the
20th century so all of a sudden these
guys have gone from the Stone Age to the
20th century because of these air bases
and five years later all of those
soldiers get back onto their airplanes
and they fly away and the people who
lived on the island are back in the
stone Age’s and what they saw were the
airplanes is what they said if we could
only bring the airplane
they’re going to bring back the cargo so
what they started doing is building
things that look like airplanes in the
hopes that if they build it they will
if the airplanes flying overhead see
their brethren on the ground they’re
going to land and bring the cargo with
them which of course didn’t happen now
the problem with a cargo cult then is
what they’re doing is they’re going
through the motions as the guys in the
cargo cults would build fake conning
towers and they would wear coconuts over
their ears pretending to be head phones
and they would act as if they were
working Airport in the hopes that the
airport airplanes would land and the
problem is that we do this all the time
as we see cargo cults everywhere and the
biggest cargo cult of all in fact is the
modern corporation is that corporations
are cargo cults because they believe
that there are certain ways to do things
and they cannot conceive that there is
another way of doing things I
participate a lot in one of the LinkedIn
agile groups and one of the
characteristics of this group is that
there’s a constant stream of wrong
questions there’s a constant stream of
questions that have that are so wrong
that you don’t even understand how
someone can ask them in the context of
agile somebody will always say why ever
every couple weeks somebody posts a
question what’s the role of a project
manager on the agile team and the answer
is there is no project manager on the
agile team but people don’t understand
that is that they’re so convinced
because that’s the way the corporation’s
think that a project manager is a
necessary part of work that they cannot
imagine a world in which a project
manager does not exist so like the
proverbial camel here is that a
corporation cannot fit through an eye of
the needle is that it can’t make the
changes that it needs to make because
it’s a cargo call because it does things
over and over again by rote without
really understanding why it’s doing any
of the things that it does in particular
what they’re looking for is a very
specific process that they can follow
the corporation’s are really into
process is that what they want to do is
they want to do something easy they want
to bring in the trainer’s they want to
train a few people in the engineering
department to follow some process and
they think that by following that
process that there will be some sort of
good result but in fact you don’t get a
good result by following a specific
process it just doesn’t work in other
is what the corporation’s want is this
kind of agile right they want a canned
thing right something that you can just
roll open up the can and do it and it’s
somehow going to magically change the
way that things work in a positive way
but often when they bring in the agile
this kind of agile they they don’t
really want to change the way things
work they just read about agile
someplace and they think it’s a good
thing and it’s think that there’s going
to be some kind of benefit but they
don’t really know what the benefits are
so this is just really really a bad idea
now what is agile really agile is
defined by the agile manifesto and the
agile manifesto as you can see here is
very simple there’s only four points on
it and the first one is the most
interesting one is that the way that
people work with one another is more
important than processes now notice that
it doesn’t say instead of process is
agile has a lot of process associated
with it and the processes help but the
processes are not canned things are
things that the individuals come up with
as they interact with each other in
other words the word agility has to
apply to the process as much as it
applies to anything else if you’re not
agile in the way that you build software
then you’re not going to be agile so the
whole notion of individuals and
interactions over processes and tools is
kind of fallen by the wayside as scrum
is a process and a lot of people believe
that scrum and agile are the same thing
and that’s just wrong scrum is a process
so by saying we’re doing scrum what
you’re saying is that the process is
more important than the people that are
doing the process and that just is not
going to work in any kind of situation
now my rule of thumb here then is to
make sure to see if something makes
sense in any sentence where you see the
word agile if you can replace that word
with the word flexible then you’ve got a
proper sentence if you say we things we
do things in an agile way that works for
me if you say agile says that we should
do X that doesn’t work for me at all
what we want is flexibility the whole
point of a of agile is to get agility in
other words what we want to be able to
do is we want to quickly adapt to
changing requirements be those changes
coming from inside or outside either the
customer is mandating them
or we are mandating them because there’s
some process internal process things of
technology thing that changes and we
need to change internally but what we
need is agility we need flexibility we
need the ability to change in a
corporation at least many corporations
are incapable of doing that so I suppose
the one thing that I will agree with the
agile skeptics about is that I think the
vast majority of large companies cannot
ever be agile because it is the very
nature of those large companies to not
be flexible about things in flexibility
is just it’s just built into things
right there’s our rule of thumb here
where we have to work with then is how
do you how do you define that it’s agile
if there is a significant requirements
change and it could be significant right
I suddenly have to make this a cell
phone app can you do it that’s the
again can you do it quickly you know
think about what’s involved with making
this change there’s a lot of training
that has to go on there’s a lot of
learning that has to go on you might
have to bring new people into the team
in order to help you make the change
right our goal is to get the app into
users hands in a few weeks
well again speaking as a consultant I
can tell you that when I’m hired to do
training often as long as four months
elapses from the time that I’m first
contacted by somebody who needs the
training until the time that I can come
in and actually give the training
believe me if it takes four months to
get training you’re not agile so we have
a corporate process that’s there for
some reason
right somebody has decided that
corporate governance mandates that we
have controls over our spending and what
that’s doing is it’s making it
impossible for the organization to be
agile friction Neil talked a moment ago
about friction is this is what we’re
talking about here is friction is that
what agility is really about is
eliminating friction within the
organization and if you have an
organization in which you cannot
eliminate friction the the chances of
you being agile are basically zero which
brings me to my second kind of major
point here is that the corporation’s
believe that agile just happens inside
engineering and that all that you do is
bring in the trainers and teach them
scrum and you’re done but in fact agile
is an organizational thing
there are no silos in an organizational
organization the organization as a whole
is what’s agile not the team’s not the
people on the teams not the departments
but the entire organization because if
I’ve need my training I need my training
now so if there’s a separate finance
department that’s providing friction
it’s getting in the way of me getting my
training there is no way that there’s
going to be any agility inside that
organization the next issue is equally
important is the organization is
structured the way it is in order to
support a process it has a process and
it must support if if you change the
process you must also change the
organization because if the organization
is all built around supporting a
waterfall process for example then you
can’t just suddenly become agile without
changing the support because support for
waterfall will not work if you’re trying
to support agile and there are lots of
things that are part of agile that
people think of as things that cannot be
changed which have to be changed right
the QA department this is one of the
reasons it’s so difficult for agile to
move into big corporations in every
agile process that works testing is
integrated into the development process
tightly integrated you’re testing every
20 minutes on the outside I test every
two or three minutes as I’m programming
by the time the so called sprint the
iteration is finished the code is fully
tested and ready to deploy which is to
say there’s nothing for a QA department
to do which means that the director of
QA is not going to be very happy about
this which means that he’s going to be
fighting really hard to prevent agile
from happening inside the organization
because he’s going to lose his job now
if it’s really an agile organization he
wouldn’t lose his job is what he would
do is change his job in a flexible way
so that he could actually do real QA
which is to say it would be his job to
look at everybody’s processes and make
suggestions about whom how to improve
them but a lot of people are unable to
make those changes because again they do
not have the flexibility product
development groups they don’t exist in
an agile organization the product that
is developed by the customers
who are talking to you on a day-to-day
basis if your customer cannot walk in
the front door of the corporation you
cannot be agile and it’s very difficult
for somebody who’s not an employee of
the corporation to walk in the front
door believe me the governance practices
we were talking about finance related
practices a moment ago is this basic
idea of if I need the training I need it
now not in six weeks
if I need a new piece of software I need
it now an agile team has a budget and it
spends it however they feel like it the
entire team decides to go off to a
conference they do that they don’t ask
anybody they just do it they need to buy
a piece of software they do it right now
they’ve got to manage their budget the
budget is not infinite but they’re the
ones making the choice not some separate
governance related organization
deadlines there is no such thing in the
agile world all of the planning and
agile is based on priorities all of it
100% of it we’ve all seen the Iron
Triangle picture right scope versus time
versus money well in agile the
assumption is what’s going to change
most often is scope requirements always
change and if scope changes in a way
that some event that needs to happen
isn’t going to happen I have to release
at some tradeshow the only options you
have are to reduce the scope a little
bit or to increase spending which is to
say bring on another team so if you’re
managing in an agile world and you have
a time deadline if you will do you’re
looking at like a trade show what you’re
doing is actually observing the process
is that agile is a very transparent way
of doing development and doing a
projection based on the observed
performance of the teams that are doing
the work and if your projection is not
right then you bring a new team on or
you reduce scope those are your options
but there are no deadlines there are no
milestones there’s no estimation in the
traditional sense it just doesn’t happen
that’s a hard one for people to give up
but there we go so there aren’t any
timesheets because you don’t need them
you’re not doing time-based stuff
there’s no kind of organizational
friction is that there’s a basic lean
concept that any effort or time or
energy being spent
doing something that is not directly
supporting putting valuable software
into the hands of the users
that’s all waste filling out an expense
report or a timesheet is not providing
customer value so one of the things that
an agile organization has to do is
reduce friction by eliminating
everything that is in the way of putting
value into the hands of the customers
including all of this junk that we’ve
just been talking about there is no
project management and agile you trust
people to do the work the teams manage
themselves there’s no middle managers at
all in fact in an agile world so all of
this stuff has got to go and big
corporations are not going to do it is
they are cargo cults they believe that
all this stuff is necessary for a
company to function and that a company
who doesn’t do this cannot function and
that’s nonsense of course there’s some
very large companies that function quite
well in an agile way but most companies
don’t believe that that’s the way things
are going to work they have their
managers and they expect them to work
like managers and more to the point when
some things become agile they expect
that these same people are just going to
change their job titles and suddenly
everything’s going to be fine right and
it’s not what it is right is that the
job titles is not just a change in title
is it’s functional it’s a basic change
in what you do agile companies are
organized very differently this is
Spotify people talk a lot about scaling
agile Spotify has about 500 programmers
in it right now which is about which is
big enough for me to say this model will
work regardless of the size of the
company I would argue that if you have a
project that is requires more than 500
programmers that what you need to do is
break up that project into smaller
projects there is no project on the
planet that requires more than 500
programmers I’m sorry
in fact most most projects with 500
programmers on them could be done quite
well by 5 programmers so if it’s what if
I can do this we can scale I’m not going
to spend a lot of time looking at this
picture but the main thing that I want
to point out here is that we do not have
a hierarchy we do not have a org chart
that’s in a tree form with managers and
controls and that kind of stuff we have
a kind of matrix though this isn’t a
matrix organization but there’s no boss
the individual tribes which are groups
of groups of groups if you will do have
one guy a system architect who’s
effectively a member of all of the teams
whose job is to make sure there’s some
architectural coherence across the
system so the people are building but
he’s not ordering people around either
he’s saying well you know we’re doing
this over here already
so if we do it this way instead it’ll
all fit better and this is a process for
grownups so the people on Team B say ok
we’ll do it that way then because
they’re being flexible so nobody’s
ordering anybody around this is a very
collaborative kind of process which
brings us to scrum is that scrum scrum
is none of the things that I was just
talking about it’s a fixed process it
has two characteristics that a lot of
people don’t know about is first of all
if you look at all the processes in the
world all the agile processes in the
world scrum is one of them and people
equate scrum to agile I don’t know how
many times I’ve heard people say well
agile says X when they mean scrum says X
the second problem is that scrum is a
relatively small thing and agile is a
relatively big thing there’s a lot
associated with agile in fact agile is
not really even just agile is that lean
techniques have a lot to do with running
an effective company in an agile way so
it’s even bigger than one guy here scrum
is a very small thing scrum is defined
by a 16 page document and frankly you
can’t define any process in a 16 page
document it just can’t be done so it’s
very small more than the point
the scrum guys imagine that scrum can be
done in a kind of bubble where the the
nobody outside has to care about what’s
going on inside that bubble but we were
just seeing people do have to care is
that the purchasing procedures of the
organization affects what goes on inside
the bubble so it’s not a separate bubble
it’s not something that can be isolated
the scrum guys also have no respect at
all for the existing processes of the
organization when they come in is they
imagine they can just bulldoze those
processes out of the way and replace
them with scrum but what they’re really
replacing them with is nothing because
the scrum is not going to work in a
situation where you’re not changing the
entire organization and if scrum is not
going to work people are not going to do
it a lot of places a lot of times when
you see the organizations that have
brought in the scrum guys a year later
they’re not doing anything even close to
scrum anymore because they’re not
getting the support they need to make it
work so they don’t do it in terms of the
smallness you look at extreme
programming and extreme programming is
made up of a largest set of practices
the interesting thing about this is the
practices are all interwoven and
interlocked in complex ways for example
one of the key practices in extreme
programming is that you need to be
testing all the time you’re testing
every two or three minutes as you’re
writing the code another important
practice in extreme programming is
constant aggressive refactoring is that
every time you look at a piece of code
if it’s not right you fix it but the
fact is you can’t do that if you don’t
have your tests in place you can’t
cherry pick these they’re all meshed
together to make one unified process now
you can modify this process and in fact
the the XP teams do that all the time
but they know what they’re doing they
understand well I have these benefits
and this has this interaction with those
things and if I change this then I have
to change this other stuff too in order
to compensate you look at scrum though
and what have they done first of all
they have cherry picked two things they
have stolen the XP planning game
directly as scrum planning is nothing
but extreme programming planning and
then they have stolen a bunch of the
little stuff stand-up meetings and that
kind of stuff and then they’ve taken to
other things that transmogrified them to
the point where they’re unrecognizable
the whole team among other things says
you should have an actual customer in
the room with you people think that when
you’re doing extreme programming you
don’t do design that’s nonsense what you
are doing is you’re doing the design
incremental e as the program evolves
instead of spending three months talking
to a user before you start coding you
put the user in the room with you so you
can ask them the question immediately
before you start coding the user
interaction is still there you’re still
talking to your users you’re still doing
design but you’re doing it as you’re
working well they’ve gotten rid of the
user and they’ve replaced it with this
management Lackey called the the project
manager where the product owner edit
write the product owner is not a
customer the product owner is usually a
representative of the marketing
department so all of the guarantees that
you’ll get about billion valuable
software they’re gone and then they put
in the rigid time box which they call a
sprint which is also a huge waste of
think how much waste there is in trying
to size a story so you can do it in a
two-week sprint and think of all of the
sturm and drawing that happens when
you’re one day off right we’re at the
end of the sprint but there’s still one
more day’s work to do and that’s such a
hassle that often people don’t do that
day’s work and you end up with buggy
software and that’s just not okay so
this is flying in the face of agility
also this stuff just doesn’t work the
next problem has to do with the
certification mills which produce
certificates which have no value at all
you take a 16-page scrum guide you read
through it so I’ve spent an afternoon
curled in front of the fire with my
scrum guide I go online I take a
completely automated test which is
graded by a computer comprised of 35
multiple-choice questions
I get a grade of 60% I don’t know about
you but when I when I was in elementary
school 60% was considered a failing
grade but if I get a failing grade
that’s good enough I get my certificate
I am a master now the problem is is that
those corporations think of this as some
kind of diploma they think of the
certificate as being meaningful and why
because they do that what you get is
something that is at
destructive because if you imagine that
the guy that has a certificate is
competent and he’s not and things don’t
work you don’t blame the guy you blame
the thing that he’s supposed to be
competent in doing you say agile doesn’t
work you don’t say that scrum certified
scrum guy didn’t actually know what he
was talking about so certification is
not only meaningless it is actively
destructive especially when companies
use certification as a criteria for
hiring because it doesn’t tell them
anything useful
they bring in people that don’t know
anything about agility but they’re
certified and then they imagine that
they’re somehow agile it just doesn’t
work now the worst case of this is safe
the problem with safe is that safe is
designed to be acceptable to a
corporation but it’s not safe that is is
that in other words if you look at safe
it’s just the same old same old
at the bottom you’ve got scrum which is
barely agile in the middle you’ve got
the same old stuff that you always used
to do well we haven’t accomplished
anything real here we look at those flat
hierarchies a moment ago you don’t have
a flat hierarchy and safe you just have
the same old corporate hierarchy that
you ever had all the governance stuff is
still in place it’s not real and it’s
not necessary agile scale is just fine
we saw that with Spotify why do we need
to do this special thing and it’s
because again the corporation is a cargo
call they can’t imagine taking a big
project and breaking it up into smaller
projects so this is fake agile this
isn’t real agile now mixed into this is
a whole set of tool vendors who are
supporting this dysfunction is that all
of these tools force you into working in
an old-style way is that what they’re
doing is taking waterfall style
management and trying to impose that on
top of agile process by doing ridiculous
things like burn down charts there are a
complete waste of time as you spend more
time entering data into this thing then
you get useful information out of it and
that time is waste it’s time not spent
providing direct customer value what do
you need when you do agile in the way of
tools right
is agile exactly and the thing is is
that agile is basically very very simple
what agile is first of all is that it’s
a culture and the culture is the most
important thing not the process and
again I’m not saying process isn’t
important but a specific process is no
better than any other specific process
provided that is working out within an
altar of agility so for agile to work
you have to put the proper culture in
place which is to say that agile
infusion in order to be functional has
to come from the top down it is the CEOs
job to manage the culture of the
organization so if the CEO does not
understand what agility is about there
is no way that he or she is going to set
up a culture that supports it so culture
is central the second issue is trust
everything in agile depends on trusting
people to do their job they’re one of
the REA in other words you don’t have
managers why don’t you have managers and
it’s because I trust people to do work I
don’t need to sit there with a bullwhip
and crack it over their heads in order
to get them to work I trust them and you
get trussed up and down the chain I
don’t need to make them get sign offs in
order to go to a conference because I
trust them to assess their abilities
understand that if they go to the
conference they can increase those
abilities and then let them go it’s all
about trust the other issue is that the
things on the left here communication
simplicity courage all these values and
principles inform the things on the
right the practices is that the
practices exist because the principles
exist and the principles exist because
the values exist so unless you have
those principles and values in place the
practices that you come up with they’re
not going to be functional so we get
back to the principles to the basic
principles is that everything depends on
ultimately communication and simplicity
and courage and feedback and if you
don’t have that inside the organization
as a whole then you can’t really do
functional work
everyone following what I’m getting at
here this is probably the most important
thing that I can say is that the culture
is more important than anything and that
the principles are more important than
the practices and that any practice that
works in the framework of the principles
is a good practice at least from an
agile point of view the process itself
is very simple you start off by talking
to your customers and find out what they
need and then you break off a small
chunk of that and you build it and you
give it to them that’s it everything
else is icing and you do this on a small
loop write that loop is a two-week loop
and the reason it’s a two-week loop is
because the general assumption of all
the agile processes is that people don’t
know what they need until they have
something in their hands so upfront
requirements gathering doesn’t work
because the requirements that you gather
are never correct so the process itself
is very simple the tools for the process
are very simple you need a whiteboard
you need some post-it notes you need
some index cards and some thumbtacks and
that’s it if you’re working remotely
maybe you’ll mix a couple other things
into this you need some good
communication software you probably need
to take that that whiteboard and put it
into a computer someplace but that’s
inferior actually this agile is all
based on a face-to-face communication
two people are physically standing in
front of a physical board will be able
to do better work than two people
working electronically the real problem
with the electronic version is it’s
hidden inside the computer instead of
being sitting up on the wall where you
can see it every day when you’re walking
by it so when it’s hidden you tend to
not think about it if it’s a physical
thing it’s out there where you can think
about it so those are all the tools you
need and again we go back to our
corporations and they’re not thinking in
these terms they’re thinking in terms of
big expensive tools because they’ve
decided that that’s what they need in
order to handle this a complexity that’s
completely unnecessary and we don’t need
any of that we need very simple things
so we come back to the basic agile
principles we finished the first one
let’s look at the other ones our main
goal here is to produce working software
now over comprehensive documentation
there are still still some corporations
that have a documentation fetish but
they’re getting to be less and less as
time progresses general rule of thumb is
that if nobody is ever going to read
anything don’t bother to write it the
vast majority of documentation is never
read by anybody so it’s not it’s not
valuable it’s waste it’s another example
of waste but by documentation they don’t
just mean software documentation they
mean all paperwork inside the
organization any kind of paperwork
that’s getting in the way of producing
the working software is not is not
desirable you want to collaborate with
your customers not negotiate with them
customers don’t know what’s hard so they
often ask for things that you can’t
build a negotiation leads to dysfunction
I want you to do such-and-such and I’m
saying sure I’ll have it next week
there’s an xkcd comic there was the –
who was to this effect a couple weeks
ago and then somebody comes in a few
minutes later and says I need this other
thing and you go sure I need 15 research
assistants in a 7 million dollar budget
and I’ll have it for you in eight years
and the person the person who’s actually
the question is often the same person
they don’t know that one thing is art
and another thing is not hard well if
you could if you negotiate the next
thing that person is going to say how
about three years with eight research
assistants and you go no well maybe four
right and this is not solving the
problem for one thing even the 15
research assistants in five years or
eight years as a guess so negotiating is
not going to help any if you collaborate
though you sit down and you go that’s a
really hard problem but if we make this
little change it turns into a really
easy problem do you think that’ll work
and then the guy who comes in with the
idea says well yeah maybe but if we do
this other little thing maybe it’ll work
a little bit better and you collaborate
so this goes way beyond contracts this
goes goes into the way that you work on
a day to day basis
you need to be able to respond to
changes at all levels I just said a
moment ago that if the word agile
applies to the process itself if the
process isn’t working change it
notion of retrospectives comes out of
this but the most functional agile teams
do not do retrospectives because our
highly functional agile team will
instantly recognize that something’s not
working every better will huddle
together they’ll come up with a solution
they’ll put the solution in place and
then they’ll move on a retrospective is
kind of a transitional measure it’s
something that you need before you get
good enough to be able to make those
changes quickly then there are the
principles let’s look at just a few of
them the welcoming changes of
requirement even late in development
right and the basic notion of harnessing
to change for the composite for the
customers competitive advantage is
important here is that an agile team is
in a service role it’s their job to
solve other people’s problems not to do
stuff because it’s cool and not to do
stuff because it’s techie and it makes
them feel good but to do stuff because
it increases the but improves the
bottom-line your customer
whoever that customer should be the
change the requirements are going to
change they always change so setting up
things where they can’t change is not
going to work another flaw in scrum is
they say once the scrum starts there
will be no changes well what’s what’s
that about I’m five minutes into the
scrum and I realize that we’ve got a
requirement wrong and we can’t make any
changes it’s not going to work as you
have to accept them at any point in the
process the developers of the business
people are working together on a daily
basis that means they’re in the same
room with each other that does not mean
that they send memos back and forth that
does not mean that the business people
ask nicely before they do something
arbitrary anyway it means that they’re
on the team literally they’re sitting in
the same room you’re talking on a day to
day basis the individuals are more
important than anything and that it is
the job of the company to support the
individuals if you have a situation
where somebody has to argue in order to
get the support they need to do their
job there’s no way that you’re going to
have any agility
the constant pace issues have to do with
the way again most corporations work
deadlines milestones all of this stuff
what this is a way to manipulate people
into working overtime company meals
high-quality cafeterias inside the
building that’s all manipulation that’s
all ways to get you to work overtime
agile companies will not do that because
they know that tired people can’t do
good work you have to be able to come in
every day rested and ready to go and if
you can’t do that you can’t be agile the
team’s themselves have to organize
themselves right I did a class yesterday
the end of the class we did an exercise
I said we’re going to go on a break when
I get back I want you guys broken into
broken up into four groups of five or
six I want you to pick a project that
you’re going to work on and then I left
them alone and I came back and they did
it well the organization has to work
that way you don’t assign people to
teams you don’t break up teams teams
form they do the job and then maybe they
reform but usually not they usually stay
together as a team and that’s best but
it’s up to the teams to make those
decisions not some sort of some sort of
management layer so I’m going to finish
this by thinking about Charles Darwin is
that agile is by far the most effective
way to develop software and the
companies that do things in an agile way
are going to have a huge evolutionary
competitive advantage over the companies
that don’t those big corporations that I
was just talking about they’re the Dodos
is that they’ll keep doing what they’re
doing but their competitors who are
working in an agile way are not limited
in the same way that the corporation’s
are limiting themselves so they’re going
to just wither away maybe there should
be a picture of Marx instead of a
picture of Darwin but the point in other
words the point that I’m making is that
eventually evolution will help us here
eventually the companies that can’t do
things in an agile way will cease to
exist but most companies don’t have that
as a goal it’s not part of their their
corporate mission statement that they
will cease to exist in five or ten years
because the competitor can move faster
so really when it comes to Jill
we have no choice we have to embrace
change and just do it so that’s that’s
what I have to say
Please follow and like us:

Be First to Comment

Leave a Reply