
The State of Agile Software in 2018 - fagnerbrack
https://martinfowler.com/articles/agile-aus-2018.html
======
hliyan
This may vary from region to region, but my biggest issue with the present
Agile trend is the cargo-culting of SCRUM. Sprints, standups, reviews and
retros, planning poker, all followed blindly, but to no effect. Worse yet, the
dreaded term "anti-agile" is used to shut down any other way of operating.

It has almost become a religion and any attempts at advocating planning
discipline or detailed designs (even in domains where it's called for) are
quickly labeled and rejected as "waterfall". Some project managers trained in
agile methodologies have trouble grasping some basic common sense project
management practices such as dependency tracking and capacity planning.

I recently gave up on all buzzwords and boiled the whole thing down to 3
things:

1\. Deliver things in small, testable chunks

2\. Start with a best-effort plan, but refine weekly based on how things went

3\. If you're blocked or your work is at risk, let others know ASAP

~~~
ChrisSD
The irony being that agile was meant to be a rejection of blindly following a
ONE TRUE WAY. A major point was to periodically review your processes and
adapt them to better suit your situation. The idea being you don't get locked
in to a process that's no longer working and even have some freedom to
experiment.

~~~
gonzo41
But I'm telling you people!, the earth revolves around the sun. \---Burn
him!!!!

We're currently swallowing the Scaled Agile Framework pill and I honestly
think that it's cause maybe 3 serious episode of depression and burnout in 7
person team.

We failed a sprint a while back. No one knew you could do that until we did.

So at least we're learning.

~~~
arcbyte
SAFe is actually fine if you choose an appropriate level and follow the
practices. It's ridiculous how people read that SAFe is "tailorable" and then
promptly do something that is in no way Safe.

Every single day i tell my coworkers to RTFM

~~~
kitotik
SAFe is probably the worst offender of what the article is focused on.

I can’t think of a more anti-agile statement than ‘RTFM’. A more productive
statement might be ‘Update The Fucking Manual’.

------
snarfy
After doing software for almost 30 years now, I honestly believe Agile has
been the most destructive thing to happen to the industry. Software has become
buggy shit that's shoveled out the door as fast as possible. It's not just
your development team, it's all development teams.

Windows 10 update deleting your files? Is it the lack of testing, poor code
quality, too many features or not enough engineers?

Ultimately it's going to boil down to some cargo cult scrum process of
reviews, retros, and bs that we are all familiar with, and Windows 10 is
buggy. Android is buggy. iOS is buggy. Nobody cares about the software. They
blindly follow the process.

~~~
asaph
> Windows 10 is buggy. Android is buggy. iOS is buggy.

Let's not pretend bugs didn't exist in the pre-agile/scrum era. Bugs have been
around as long as software has been around.

~~~
protonimitate
I think it's safe to say that bugs are way more predominant in software that
used to be reliable. It's not that the software was completely bug free, it's
the quantity and quality of the bugs now being presented.

~~~
asaph
I don't think windows used to be more reliable. It used to crash all the time.
Do you remember the blue screen of death[0]?

[0]
[https://en.m.wikipedia.org/wiki/Blue_Screen_of_Death](https://en.m.wikipedia.org/wiki/Blue_Screen_of_Death)

~~~
quantummkv
But I don't remember any BSOD wiping all my documents just like that.

~~~
yoden
I mean windows 95/98 didn't even use a journaled filesystem... a BSOD could
wipe your documents...

------
johan_larson
I've worked at four companies that have claimed to do agile development. Not
one of them has deeply embraced the principles of doing so. Generally they
have added a few easy practices, like stand-up meetings and sprints. They've
kept large-scale chunks assigned to specific developers, defining both the
work to be done and the time to do it, and substantial design docs. Unit
testing tends to be spotty.

We're not living in Agile World. We're living in Fake Agile World.

I have some reservations about true-blue agile, but I'd be willing to give it
a shot. Let's do Fundamentalist Scrum once. I'd be up for it. At least I'd
know whether it works or not.

------
tempodox
> And yet what I'm hearing so much is the Agile Industrial Complex imposing
> methods upon people, and that to me is an absolute travesty.

I find it depressing that Fowler sees the same problem I do. I have yet to
find a shop that practices “agile” in a way that's actually consistent with
the Agile Manifesto. What I've been seeing instead was micromanagement and
cargo cult. All power to make decisions lies with management and if there are
developers involved at all, it's the top one or two who are de facto part of
management.

~~~
johan_larson
Agile methods do have a bit of a problem with the concept of authority. They
really really want to believe that at least within a development team,
everyone is equal. That's not a great fit to actual dev teams in companies
where there are junior devs, senior devs, architects, and managers.

~~~
conradfr
A senior dev in an Scrum team is supposed to do the same work as the junior,
except faster!

Then they'll wonder why the experienced people quit.

~~~
detaro
> _A senior dev in an Scrum team is supposed to do the same work as the
> junior, except faster!_

Where do Scrum principles/rules/... say that? (I have only passing familarity
with, but I haven't seen much that went into more detail than "the development
team organizes itself to complete the tasks", which leaves the internal
structure open)

~~~
conradfr
It's just my experience at multiple companies doing Scrum.

------
airfreak
This might just be the best, well-balanced talk on how agile has gone wrong,
and ways to combat the decay.

I've seen a lot great teams and poor teams operate. A common set of components
in great teams: Technical excellence, freedom coupled with accountability and
giving a shit about the quality of their work.

Poor teams: lack of discipline, not caring and poor technical skills.

I've also seen great teams fall apart due to external influence. That
influence was agile gone wrong, imposed from the top. Freedom: gone, but
accountability remains. Technical practices valued by the team: deprioritized
by the process. Giving a shit: demotivation followed by quitting or being
fired.

------
bsvalley
I started working with agile since day one and it was fun back then. Why?
Because it made projects so much more interesting. We were learning how to do
things differently and it was pretty cool. Unfortunately, it became more
popular and upper management started looking at the benefits of Agile. “Tell
me one reason why we should adopt agile in our company?”. Unfortunately, a
good answer to that was the ability to track the progress and a large increase
in delivery and productivity. Teams hate those words but management love them.

That’s what agile became today, tracking progress with constant status
updates, charts and metrics that tell a team “clearly you did a really bad job
this time” or “you’re late”. Management doesn’t even have to do the dirty job
anymore. Meaningless meetings, less power for engineers, no creativity (ain’t
got time for that!), etc.

It went from a cool way to do things to a perfect tool for factories. No
offense to factory workers.

~~~
JoeAltmaier
And the illusion of getting things done, because tickets! makes it seem like
progress is happening even if churn is all that's happening. Last contract (I
left) was 6 years into churning the same awful pile of spaghetti. I came on
board to help break the logjam. Micromanaging Agile manager put me on fire
fighting, just like all his other reports, just like the last 6 years of
churning had done. Left after 6 months and it was obvious they were going
nowhere.

------
abernard1
My problem with current "Agile" beyond the complaints in that talk is it can
mean absolutely anything. Nothing is falsifiable, and the snake oil industry
views that as a feature.

Most of that revolves around the way retrospectives are handled and the weird
way in which "continuous improvement" is viewed. Agile sees this as continuous
process improvement, instead of say, people improvement, team improvement, or
software improvement. This process for creating process (aka "bureaucracy")
has led to retrospectives evaluating things like burndowns, "What about our
process went well?" or "What about our process didn't go well?", etc. Scrum
has basically a built-in bias to destroy itself: "We've iterated into this
super process-oriented way of doing work, and we did it in small steps....
_Agile!!!_ "

I once made a comment that neither I, my company's customers, nor their
customers were paid in story points. I still think that is the crux of why
Scrum is so broken.

Agility will become more pronounced in software teams when the feedback
mechanism ("retrospective") is based upon 1) qualitatively evaluating product
success, and 2) quantitatively measuring _something_ that is relevant to the
product or business being built and not a peripheral concern like how much
work was done or how it was done. Work done, predictability, and even lateness
have very little to do with product success outside the realm of contracting.

~~~
himynameisdom
Focusing on story points is not Scrum, so why blame Scrum? Rather it's clearly
delineated that a Scrum team product owner's main job is to maximize the value
delivered through development to the customer. 50 story points means nothing
unless the PO has prioritized work that's going to yield the most value to the
client.

Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere
will you find mention of story points.

Stop blaming the framework for someone's bastardization of what said framework
is meant to achieve.

------
pytester
>We have to recognize that and fight against it because some people have said,
"Oh, we're going to 'post-agile', we've got to come up with some new word," \-
but that doesn't help the fundamental problem. It's the values and principles
that count and we have to address and keep pushing those forwards and we might
as well use the same label, but _we 've got to let people know what it really
stands for._

The heart of the problem he's describing here stems from the fact that those
principles were originally quite vague:

* Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?)

* Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software)

* Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?)

* Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk)

Contrast that with, say "develop iteratively, in small chunks and, where
feasible write the test first and release frequently and talk regularly with
the customer" \-- those are specific principles.

If you create a vague set of principles surrounding an idea that resonates
deeply with people then the emergence of a "priesthood" that doesn't
necessarily agree with your original intentions is somewhat inevitable, no?

~~~
virtualized
Yes, the values are too vague. The twelve principles are better for conveying
what Agile is trying to be.

The "responding to change" point means in practice that it's better to deviate
from a plan than to not have any plan to deviate from. The plan has to be
adjusted all the time. For that to be possible, there has to be a plan.

The twelve principles are very basic, common sense. Common sense is not common
though.

~~~
hotcrossbunny
Well said!

------
pjmlp
Around me agile has turned into 2 week mini-waterfalls, and everything else
seems a very distant past.

~~~
Cthulhu_
I've been in a project like that for a while and it was actually pretty good,
we got stuff done on a regular and predictable cadence.

~~~
pjmlp
Not saying it is that bad, just confirming that agile hasn't lived up to the
promises as most companies aren't willing to go all way in.

Which is understandable, because according to my experience it is very hard to
fit all departments into an agile concept, specially in companies which aren't
focused on selling software.

Then you also get stuff like 100% unit test coverage for beautiful management
reports, which blows up development costs, as some teams spend more time
writing mocks and trying to find ways to test UI code than actually writing
product code.

~~~
himynameisdom
You can lead a horse to water, but you can't make them drink it. I don't know
why anyone would blame the water for a dehydrated horse.

~~~
pjmlp
Maybe the water is tainted and staying dehydrated is a matter of survival.

------
venantius
This article really hit home for me living in London. Having spent 7 years
working in San Francisco and the valley, the degree to which "project
management" and the use of buzzwords in the greater London tech scene are
divorced from their original uses drives me absolutely bananas. And what's
worse is that faux-agile has taken such a strong hold that _I_ seem like the
crazy person when I tell them that's not how software is developed in
California.

~~~
mrfredward
I live in the U.S. but I'm working remotely with a mainly U.K. based team
that's doing "agile". The way they do it, at the end of a sprint all your
tests have to pass, but it's normal for the trunk (yes we're using SVN) to be
totally broken until then. That's all a sprint means to them, a block of time
when it's okay for things to be broken.

I think this company got into it's current predicament by buying a ticket
tracker that uses the word "agile" and never learning anything about it beyond
the words in the tracker. Needless to say, the current process isn't working
very well.

------
jeremyjh
Perhaps we need to question the basic assumption that these ideas and values
are worth a damn. The C3 project that started this whole circus twenty years
ago completely failed[0] after if its primary business subject matter expert
burnt out. This stuff only works when you have really good people committed to
each other and their goal. That just isn't something you can expect to find in
most of corporate america. If things are so bad that you are bringing in a
process consultant, its almost a surety that agile cannot work for you.

[0]:
[http://wiki.c2.com/?WasChryslerComprehensiveCompensationSucc...](http://wiki.c2.com/?WasChryslerComprehensiveCompensationSuccess)

------
a_imho
I've always wondered what makes Martin Fowler such an authoritative voice in
software?

~~~
perlgeek
Fowler has been working for many years at a consulting company (ThoughtWorks),
and thus has had insights into many, many software development projects.

Then he has started writing blogs, books, giving talks etc, which has
increased his reputation.

I don't agree with everything he writes, probably because we have very
different perspectives, but nearly everything technical he writes seems to be
very solid, and I've never seen any bullshit from him.

I respect that, lots of other developers do that too.

~~~
pytester
He's definitely no bullshit but he's not very good at contextualizing the
stuff he writes. Instead of writing "we did X in Y situation and it worked out
great, but it probably wouldn't work well in Z situation" he just says "X is
awesome, everybody should be doing it".

And that's the story of how I came to work on a team that maintained ~16
unnecessary microservices.

------
lmilcin
That's unfortunately roughly what I am seeing.

It is pattern of management pushing on teams and then team members themselves
declaring "agile" without willingness to actually understand what and why they
want to achieve this way, without willingness to understand what Agile really
entails and why it works. Being "agile" is a political issue now in every
major corporation. Everybody "is" "agile" because not declaring "being agile"
puts you against your management who themselves don't understand and don't
care and wouldn't recognize Agile way of thinking if they stumbled on it. But
that's just what you have to do because you already have scores of other
things to fight for and you can't fight every war so you decide this is just
one of the things corporations do and you will just try to do your job.

This is really problematic because it completely undermines efforts of people
really understanding and trying to introduce Agile way of thinking. Since
everybody else already "is agile" and since the effects can only be seen
through participation of everybody in the way of thinking and only after a
longer period of practice, the management is very unlikely to ever observe any
Agile team and and observe positive results of that team as flowing from them
working on being Agile.

Effectively management is never going to learn Agile because the setup is such
that it severely impedes any efforts to introduce and promote Agile.

------
dandare
Agile is like a religion. There is not a single consistent definition and any
criticism is easily deflected along the lines that your organization did not
embrace Agile on all levels of management. The uncomfortable truth is that
Agile is internally inconsistent - you can not build an Agile methodology that
will not contradict itself and that will not contradict the real world. A
perfect example is the INVEST mnemonic for backlog items or the notion that
Acceptance Criteria is against Agile.

One Agile coach ($$$) recently told me that the fact that I have contractual
requirements and legal requirements in AC that I need to test for is a symptom
of my customers not being Agile and the government not being Agile.

------
codeulike
I like to sneakily endorse people on LinkedIn with the 'Waterfall' skill tag.

------
asaph
I've always had a problem with the scrum concept of team velocity i.e.
assigning story points to tasks and then measuring how many story points a
team delivers each sprint. The idea that this yeilds any predictive power is
flawed. It's based on the assumption that the team is static. As soon as
someone leaves the team or someone new joins, all the historical velocity data
becomes useless and you need to recalibrate. The reality is that teams are
dynamic. They grow/shrink/change all the time.

~~~
himynameisdom
This is up to the team to help other people understand that
velocity/productivity is more than likely decrease as team dynamics change.
Even if more people are put on a product, the velocity is expected to decrease
as those people absorb new responsibilities. Same story for losing people on a
product.

------
arendtio
I always knew that Scrum wasn't as agile as some people want to tell you, but
this was the first time I read about 'Dark Scrum' [1].

In my opinion, Scrum is a good tool to kickstart the process of becoming an
agile organization, but too often the process languishes there and generates a
lot of frustration.

[1]:
[https://ronjeffries.com/articles/016-09ff/defense/](https://ronjeffries.com/articles/016-09ff/defense/)

------
wokwokwok
This a lovely read, and rings true on so many levels.

Dark scrum huh? Nice.

I feel like there are a lot of people who will read that, about technical
excellence, about teams choosing their own ways to work, about needing to
constantly _change_ and feel uncomfortable about it.

...but, face it. If you do, you’re not doing agile, you’re just calling it
agile.

------
da_murvel
"... much of what is done is faux-agile, disregarding agile's values and
principles." This. It feels so easy to get caught up in methods and tools, to
not make a proper commitment (because it is tough to change the way you work)
and to land in a sort of semi-agile state that no one likes.

------
keithnz
agile is a manifesto that I don't think should have ever become whatever
people think it is today , its sort of become this Scrumish thing with
consultants that try to sell faux zen like wisdom. Some of the silly thought
experiments that were getting done on the email lists about how "extreme" we
could take things that were done around the early 2000s have now become weird
dogma. It's just a mess. I think part of the problem is that some of the core
philosophy that people like Kent Beck were trying to capture and communicate
was actually quite nuanced and subtle that it simply got lost in the noise of
the new "Agile Industry" that quickly latched onto blunt and concrete rules
about how to do things and a lot of things seemed lost and diluted over time.

------
lbriner
Is there a problem in what we might call a meta-framework like agile in that
it requires the "good people" that Martin Fowler talks about when the reality
is that most of our teams are at least partially average?

People have to learn examples of its implementation but are either not
knowledgable enough or trusted enough to start doing things their own way,
which causes the rigidity that everyone is talking about.

That and the fact that tooling is not something that most people can knock up
in a few days so we relay on the software and its somewhat rigid processes
which means we aren't free to innovate fully anyway.

It's a bit like complaining that most musicians only do music the way they
learned at college and do not adapt to the "principles of music".

------
ManuelKiessling
Related: "The Tragedy of Craftsmanship"

[https://blog.cleancoder.com/uncle-
bob/2018/08/28/Craftsmansh...](https://blog.cleancoder.com/uncle-
bob/2018/08/28/CraftsmanshipMovement.html)

------
tnolet
This whole discussion echoes the DevOps discussion and its definition. What
DevOps is and what it means to different people is still hazy and can be
twisted into anti-DevOps quite easily.

~~~
perlgeek
It's even worse with DevOps, IMHO.

Agile at least has the Manifesto of Agile Software Development, which you can
go back to, and see if a given process adheres to the ideas in the manifesto.

With DevOps, you have basically nothing foundational that people can agree on.

------
ggregoire
So it’s probably an unpopular opinion on HN, but I’ve seen SCRUM implemented
in 3 companies during my career and it has been an improvement for each one of
them.

------
denimnerd
my gigantic org is transforming to agile pretty well to be honest. wish there
was some positivity in here. biggest problem is lack of technical excellence
but people understand the point of agile pretty well and we are working
through what makes it difficult to "be agile"

~~~
maxxxxx
If everyone is adapting to it this may work. What I have seen in companies is
that the devs suddenly have to do scrum but everybody else in the company does
business as usual.

In my current company we did scrum training a while ago and not even the dev
managers showed up. And it shows when you talk to them. They have no idea what
agile really means other than sprints and "commitments". So instead of being
an environment where everybody respects each other it has turned into a
pressure cooker for the devs.

~~~
denimnerd
yeah it’s complete buyin from senior execs to business leaders, to business
side employees who are tasked with being product owner. no such thing as a
tech lead, organization got flattened out etc.

~~~
maxxxxx
That's how an agile introduction should be done but almost never does.

------
navane
We're doing agile in a mechanical engineering firm. A multiyear project. The
first thing we'll deliver will be two years from now.

I struggle to put into words why this is such a bad idea because its so
blatantly obvious.

Imagine designing and building the golden gate bridge as an agile process.

~~~
mixmastamyk
Agile process doesn't necessarily mean agile delivery. But I might worry too.

------
borvo
"this realization that people are operating at the best when they choose how
they want to work"

But what if how they want to work is "Dark Scrum"... or some kind of Agile
religion, or waterfall.

------
Khaine
Many aspects of this talk (around the lessons to learn from Agile and failed
Agile) can be applied more broadly to most functions and industries, not just
software development.

~~~
pjmlp
Given the age of software industry we are quite late to the party, hence
relearning history.

I still look forward to proper quality assessment and responsibility like in
other industries.

------
bullen
[https://news.ycombinator.com/item?id=16772788](https://news.ycombinator.com/item?id=16772788)

------
asaph
> ... the reality is troubling, because much of what is done is faux-agile,
> disregarding agile's values and principles.

This is a problem with "agile" and scrum. If the process isn't working for
you, it's your fault for not doing it right. And no one is ever doing it
right. A truly "agile" team is one that operates in some impossibly perfect
Zen-like state that no team achieves in practice.

Maybe it's not you. Maybe it _is_ the process.

~~~
himynameisdom
Scrum isn't a process, it's a framework to utilize your own processes. That's
like blaming the framework of the house for a bad paint job.

------
ryanmarsh
Agile Coach here.

FIRE YOUR AGILE COACHES

The monstrosity that agile has become is an insult to the courageous pioneers
who spoke out and swam against the current (at the time) to save software
engineers from an overreaction to the growing complexity of computer systems.
The result has been an overreaction to an overreaction.

1\. MOST COACHES ARE MUPPETS

Most Agile coaches today have a serious lack of engineering and leadership
experience. They are merely the sum of the Agile classes they've attended and
the book or two they may have skimmed. Most agile coaches do not understand
the theoretical underpinnings of their field and therefore can only parrot
statements from other "agile leaders". Most can't write code, have never
managed anything as large as the groups they coach, don't understand software
development in general, thus you would be a fool to take advice from them.

Here's an example. A friend told me a story this week about a new coach who
came in and pronounced that what they needed was "big room planning". He
proclaimed this without having any context whatsoever. What is one to do when
all one has is a hammer? This is not an anomaly, it's par for the course.

2\. YOU'RE BETTER OFF IF YOU DO IT YOURSELF

Today enough has been published about the dangers of approaching complex
problems with the tools for solving merely complicated problems. You don't
need a Priest of the All Mighty Agile to warn of you of Eternal Damnation and
prescribe the One True Way. Every "tool" any agile coach can use to help you
understand the challenges to production flow (such as Value Stream Mapping)
can all be found in digestible articles on Medium. If you're having trouble
finding these my email is in my bio. If you, as a leader, take the time to
understand your chosen field of Software Engineering Leadership, and then...
you know... actually _lead_ , your organization will subsequently obtain the
necessary habits to continue to change and improve as your company grows and
changes. The value of this cannot be overstated. Most companies calling me for
help today have anemic leadership and that's their problem. They don't need an
expert in software delivery performance to help them skip some of the
boilerplate, they need Extreme Ownership and true leadership. Instead they
continue suckle on the tit of Agile Coaches 5-10 years into an "Agile
Transformation" when they should be up on their own two legs walking and
eating with a fork. Agile Coaches have, if anything become an enabler to the
worst corporate cultures and mindless bureaucracies software engineers have
ever had the displeasure to work under.

3\. YOU CAN'T SHIP BECAUSE SOFTWARE DOESN'T MATTER

Lastly, the reason most companies who struggle to increase quality and
simultaneously increase delivery performance (aka Business Performance in
2018) is because they don't care about software. It is true, no one starts a
bank to have an IT department. However some companies have awoken to the fact
that in 2018 TECHNOLOGY PERFORMANCE IS BUSINESS PERFORMANCE. If you are not
one of these companies you (personally) have two choices, go and work for one,
or lead your company to become one. The alternative is... a steady paycheck?
Even in the most laggardly industries, leaders are waking up to the fact that
getting technology performance right is the only competitive angle. When these
clients call me the things we accomplish are breathtaking. Sadly, they are a
tiny minority. Most companies call coaches so a VP can show he's checking all
the boxes, so they can continue with the status quo. Some financial
institutions may talk about the danger of "Fin tech startups" but when you
have enough in assets that you can coast for 50 years, or you have billions in
infrastructure that a competitor with all the money in the world couldn't
replace inside of a decade, the reality is SOFTWARE DOESN'T MATTER. You can
suck as much as you want because the challengers are so incredibly far off it
really doesn't matter. These places make Agile Coaches lots of money and
they're also the ones who fill the conferences. Technology performance doesn't
really matter at these companies. This is why you (who work in these
companies) struggle to have a sane build pipeline, adequate test coverage with
good tests, communication across teams, and you get nowhere. You're swimming
against a tsunami. It's exhausting, don't waste your time. Find somewhere that
actually sees the leverage technology can provide them and go work there.
You'll be a hero.

------
mathw
Four weeks ago my team changed from not-really-scrum-we're-just-pretending
some some sort of kanban-like process, which was the first real change after I
stuck an item on the wall during a retro which just said "Are we doing Scrum?
Should we be?"

Today we had a retro in which we talked about how things are going, and we're
all more comfortable with how the process fits our actual workflow, and how
it's opened up some other changes that have really helped us with getting
useful stuff done, delivered and in the hands of people who appreciate it.

And this came from within the team, entirely, with the support of our team
lead.

It's not perfect, but it's good, and we feel able to change things. That's why
the other changes happened - because we were reminded that we have the power
to change things, and the company actually genuinely believes that. There are
some things we can't change, or not so easily, because they cross team
boundaries or require money to be spent that we can't convince someone to
authorise, but we have more freedom within the team than we had believed that
we had. Largely I think because most of us are fairly new to the company and
had long ago forgotten the idea of self-organising agile teams because the
very concept was a joke most other places we've worked.

I suspect we'll change things in the future, and we do have some concerns at
the moment about how we split up big bits of work like implementing a
completely new system component into cards of a suitable size and self-
containedness and various other issues around definitions of done, but we'll
work it out. For now, we're apparently more productive, we certainly feel more
productive, and we're all happier because we don't have the entirely
artificial pressure to ship something every sprint. That's not how the
software we maintain works, and not how it should work either. We just ship
stuff when it's ready, because that's what makes us and our stakeholders
happy.

What Fowler's describing is something I've seen so many times. Scrum-adherence
is in itself something of a cult in some places, and it's done without any
mindfulness for why you choose certain processes, the purpose of certain
things and whether Scrum was a good choice for you or not.

And I think honestly that's most people's experience of "agile" software
development, because people have turned it into an industry of its own and
with that comes the books, the rules, the certifications, and the legions of
people who read a bit about it and decided that'd be great and it'd tick the
trendy "agile" box without having to disrupt the company too much.

Bleergh.

Oh and something else my current employer does that I've seen literally
nowhere else? A no-blame culture.

We actually have one.

I wish everyone could try it.

------
hamilyon2
Much, much better transcript version [https://martinfowler.com/articles/agile-
aus-2018.html](https://martinfowler.com/articles/agile-aus-2018.html)

~~~
dang
Ok, we changed to that from
[https://www.infoq.com/presentations/agile-2018](https://www.infoq.com/presentations/agile-2018).
Thanks!

