
We are doing it wrong – the truth about agile development - matt_loves_data
https://www.linkedin.com/pulse/we-doing-wrong-truth-agile-development-matthew-hogan/
======
j_s
Extensive discussion on agile yesterday under My 20-Year Experience of
Software Development Methodologies |
[https://news.ycombinator.com/item?id=15476357](https://news.ycombinator.com/item?id=15476357)
(Oct 2017, 142+ comments)

>sytelus: _The obvious problem is that these folks prescribing the development
process are not active developers._

>mmcnl: _The agile manifesto was in fact drafted by software developers. Also,
agile doesn 't prescribe any process at all, in fact, it does the opposite.
Agile in essence is quite beautiful, unfortunately it gets twisted and turned
upside down until it's just another methodology (which is exactly the opposite
of its original meaning)._

------
maxxxxx
"Agile" should have stopped at the Agile Manifesto. The principles described
there are useful. Scrum sounds good in theory but in reality I have never seen
it really work. Mostly it devolved into a micromanagement tool.

~~~
mattmanser
I read this in the article, and had to wonder what on earth it had to do with
making things:

 _If you are the scrum master, keep doing what you are doing. Keep coaching
the development team on our core values of openness, commitment, focus,
respect, and courage._

~~~
maxxxxx
The scrum masters I have seen (including myself) turned quickly into
bureaucrats that mainly managed deadlines. In theory the scrum master should
constantly improve processes but from what I have seen they quickly get
blocked by management and don't achieve much.

~~~
conradfr
I jokingly called my last scrum master a "glorified assistant", he didn't like
it.

~~~
maxxxxx
You start out with great intentions but then you realize quickly that you have
no authority at all. We had problems with our JIRA setup so I tried to buy a
few hours with a consultant to set it up correctly. This request got declined
so it was clear to the devs that I couldn't help with things. The only thing
you have is tracking hours.

------
amyjess
Agile always comes off as if it were intended for small consultancy firms who
do specific jobs for individual customers. That honestly doesn't sound like a
place I'd ever like to work at. I'd rather work for a company that puts out
mass-market products with near-monopoly status and takes a stance of "you'll
take what we give you". Basically something like Microsoft or Adobe.

To me, agile is endless micromanagement. Tracking every little thing in JIRA
and having constant pointless meetings. The next time I look for a job, I'm
going to categorically rule out any company that uses JIRA at all.

And then there's a particular quality associated with agile that just comes
off as cult-like. A while back, I was googling "scrum master" to find out what
one actually did, and I stumbled on the official scrum page [0]. Some of the
terminology on that page just jumps out at me saying "this is a cult" (in
particular, the phrase "servant-leader" is used in an almost religious sense).
If someone were to state what's on that page in real life, I'd start backing
away slowly. And the cult-like feel is only reinforced by the agile
community's peculiar use of ordinary words such as "story".

[0] [https://www.scrum.org/resources/what-is-a-scrum-
master](https://www.scrum.org/resources/what-is-a-scrum-master)

~~~
tincholio
The last company I worked at had officially switched to "agile" last year
(even though in practice, it had been working that way since earlier). They
sent some guy from the India office (halfway around the world) to discuss with
the different scrum teams about "ceremonies", "retrospectives", and all kinds
of similar BS. That definitely smells of a cult.

~~~
Domenic_S
If a consultant was brought to a manufacturing facility to discuss ISO 9000,
would that be culty too?

------
wellpast
“You need to spend 20% of your sprint refactoring.”

Yes! Agility is largely a function of (the quality of) your code assets, so
much more so than your team processes. And you can’t keep a code asset at
quality unless through constant vigilance (ie, refactoring).

Now we only need to talk about who is doing the refactoring and what are their
values?

~~~
maxxxxx
The number "20%" scares me because people will makes his a hard rule. Soon
you'll have to justify why you didn't refactor your stuff.

~~~
phillipwills
Or worse, I spent 1 hour writing it, so 15 minutes refactoring... And done, no
more refactoring...

~~~
wellpast
Agreed. I prefer the descriptive not prescriptive consideration here. Is
refactoring an essential part of your process or no?

------
crimsonalucard
The real problem isn't Management style. Agile would be irrelevant if every
programmer found it incredibly trivial to refactor huge portions of the
program or very hard to introduce even one bug into the system....

We see a problem, we don't completely understand it, we think it's a problem
with process but the same issues happen regardless of process, so then the
issue must not be process... What's the common connection between all of this?

The complexity of code. Bugs, development time are directly related to coding
style and coding technology and that is where the real issue lies.

The article author references martin fowler. Martin Fowler advocates a style
of programming which makes it harder to refactor and easy to introduce bugs.

~~~
jasonmaydie
> The complexity of code. Bugs, development time are directly related to
> coding style and coding technology and that is where the real issue lies.

but this is not looked at by management at all. All they see is task with
estimations on them. Estimations are then used to plan timelines and make a
budget. It never takes into the tech defit into account. Agile projects almost
always start of rosy, end up vague work never done state.

------
Chiba-City
I invite folks to look at all methodologies within an overall CMM framework.

I fashioned a 90's Agile type methodology based on Release abstractions and
project progress visibility.

There were always 3 Releases (MRTP - Multi-Release Technology Plan) for
parking inbound feature requests from inbound stakeholders. Developers shared
"minds eyes" on future releases.

Then we group scheduled integration deliverables (not activities) by Weeks.
Rare deliverables were given longer extensions. Sharing a spreadsheet of
weekly deliverables to the next release required enough analysis to share the
schedule abstraction.

Going dark was impossible. Everyone documented short "So Far, More To Go,
Defer It" lists with short rationales similar to version control commit
comments. We could push schedule breaking "features" to future releases. Every
Thursday was integration and retime boxing of the schedule. The dev notes were
collated into report "Weeklies." In practice, more continuous integrations
were daily to his weekly hard integration targets.

The methodology started with a workbook of about 15 product planning exercises
from User "day in the life" to "operational cost estimate" spreadsheet
formalisms.

In practice developers shared a subset of the planning formalism "intermediate
representations." But all stakeholders (business too) were fully aware and
SIGNED ON to every planning step skipped for schedule or cost necessities.

It was very ritual high visibility human applied "design by contract." We had
a perfect execution record on early Linux tooling with teams from 2-15
(Product Planners, Information Architect, Soft Devs, System Architects) on
about 125 high pressure engagements. Most was a mix of Java Servlet, SMTP and
C telecoms projects. We had to write our protocol handlers back then on
shifting sand.

I might write it up as "The Adrenaline Way." It doesn't easily apply to
individual, exploratory or Kanban content "journey without a destination"
project teams. But it applies well to products with inbound and outbound
marketing teams involved.

------
Sir_Cmpwn
Where can I read this without logging into LinkedIn?

~~~
j_s
I was able to just close & re-open the link, the second time there is no login
prompt.

~~~
Sir_Cmpwn
Thanks, it worked on the second try.

------
dingo_bat
> Defer decisions until the last possible moment. Wait until you have all the
> information you can get – you’ll make better choices. If you make a decision
> too early, you may get it wrong.

I cannot disagree more with this. You should make decisions as soon as you
have a minimal amount of data. If you keep waiting the last possible moment,
you will get a product that is the product of the least possible time.

If you make a decision too late, you have 100% failed.

------
jasonmaydie
Err no. Agile really is multiple things to different stake holders. To devs
agile is something completely different from Project Managers or Customers.

Customers see it as a really fast, transparent and easy way to run projects

Project Managers see it as a way to keep track on a projects at a high level
view and mostly for metrics and reporting

Project leaders use it to assign tasks to minions

Minions see it as a way to work independently without looking at the big
picture.

Who is looking at the big picture? nobody. that's why agile fails.

------
et-al
Text-only link for those who can't be bothered with LinkedIn:

[https://pastebin.com/Pq0T3Krs](https://pastebin.com/Pq0T3Krs)

------
PatientTrader
Defer decisions until the last moment possible is one of the best things to do
when making a tough decision. Its weird how we praise "quick decision makers."
They are more or less simply gambling. Information tends to grow exponentially
overtime. By waiting your chances of making a sound decision increase.

~~~
smanatstpete
"Information tends to grow exponentially overtime. " Maybe true. However, the
opportunity cost of playing the waiting game also tends to follow a similar
path.

~~~
PatientTrader
That's true. But any investor/CEO/Business owner will tell you: It's better to
be late and right, than to be early and wrong.

~~~
PakG1
What happened to fail fast? ;)

------
Sujan
What is this "Rework" book he refers to? I can only find the book of the same
name of Jason Fried and DHH on Amazon...

~~~
detaro
that's probably the book they mean.

~~~
Sujan
Oh.

"the body of knowledge in those tomes" threw me off - quite the opposite of
Rework.

