
Fixing Scrum (2019) - bobm_kite9
https://riskfirst.org/estimating/Fixing-Scrum
======
Terretta
Title close to click-bait or false advertising, since this article just argues
Scrum is broken. Suggests next article will get into fixing.

> _If the thesis that “90% of everything is waste” then Planning Poker is also
> a waste, and we should devise a planning process to avoid this._

> _In the next article we’ll look at how we might do that._

~~~
bobm_kite9
Author here. Sorry you think that. I see the article title has been changed,
although I wrote this about 3 weeks ago so I'm not sure why it's been labelled
as (2019).

This article focuses on the Timebox issue. I'll be posting the follow up in a
couple of weeks, will post on HN... although there's plenty of other content
on this site that covers where I'll be going with that solution.

Apologies if it didn't cover everything you wanted - but I find that long
articles tend to lose the readers too easily, and I'm trying to keep to a
single main point-per-article in my writing as a matter of discipline.

I'll look forward to your thoughts on the next one.

~~~
loopz
The ending is your actual point, which is excellent. With scrum being so
oversold in companies, it's a hard sell though. So an article _starting out_
with this premise would perhaps gain better traction:

 _" But actually, we’re now three degrees away from the original problem of
trying to build the right thing. The team is focused on figuring out how much
they can get done in a Sprint, not whether they are building the right thing.
Scrum purists might argue that this is the purpose of the Sprint Goal, which
should be agreed in advance.. but actually this is usually just a bunch of
items from the backlog, shoe-horned into a sprint-sized chunk of time."_

~~~
bobm_kite9
Author here. Yes, the overall feeling I'm getting from the responses is a
disappointment that I didn't get to this. Initially that had been my intent,
but as I wrote it I realised I was trying to crowbar too much into a single
article.

However, I am pleased that people seem to agree with this article's diagnosis
of the problem.

The next article will build upon this one (and others in the series).
Hopefully it will be equally well considered on HN, I am interested to see how
it goes down.

------
29athrowaway
Take a look at the most lasting, highly successful open source projects used
by most companies today.

They have something in common:

\- Full-time software engineering managers? 0%

\- Full-time product managers? 0%

\- Full-time project managers? 0%

\- Committed engineers focusing in implementation working on flexible time
schedules: 100%

The true inefficiencies that managers spend their careers looking for, are
right there in front of the mirror.

[https://youtu.be/rQKis2Cfpeo?t=114](https://youtu.be/rQKis2Cfpeo?t=114)

~~~
pinkfoot
They also all share not having to make payroll every 30 days.

~~~
29athrowaway
They certainly help your ability to make payroll every 30 days.

Some open source projects are sponsored or backed by foundations, and
contributors do get paid.

------
runawaybottle
I’ve become extremely apathetic towards Agile. Whatever, this how a company
needs to manage it, fine. I’m not wasting time wrapping my head around it.
Tshirt size or point poker stuff or ‘As a developer, I would like to’ stories,
like seriously, whatever. It’s not going anywhere and doesn’t always make
sense, so I just suck it up and truck along.

Here are my stand up updates: I worked on the same shit as yesterday mostly,
I’ll let whoever needs to know something know something. No roadblocks.

~~~
deanCommie
The thing is, it's not all about you.

Source: I am a developer like you that has the exact same instinctual attitude
about it. Here is why it's wrong.

Project managers need to build schedules so they could coordinate dependent
features across multiple teams.

Marketing needs to orchestrate launch announcements and fixed activities that
are not quite as inflexible as printing millions of CD-ROMs, but still require
dates.

And managers, ultimately, are held responsible for a project delivery, so they
need to track it's progress, understand what things are ahead (lol) or behind
(yup), which areas need help from more people, more seniority, or less scope.

All of this needs to come together for any successful project of any
reasonable complexity.

None of this is new, or news to you, of course. Here's the part you're
missing: The way things USED to work was that PMs, Marketing, Sales, and
Managers would come up with processes that worked for them, and forced it on
development teams, regardless of how it made the devs feel.

Agile was an attempt for the developers to take ownership of their process
bottoms-up. Planning poker, standups, sprints, all these ideas were invented
by developers to make their lives EASIER not harder. And none of it was
supposed to be panacea - the only way to do things. Each team is supposed to
figure out the right balance of what works for them.

So don't be apathetic. You are an active contributor to this process. Take
pride in the fact that you have a lot of autonomy about how to define your
project structure in an agile environment. Change what you don't like, and
figure out what works the best for your team.*

* Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.

~~~
TsomArp
Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own
way of delivering software which basically was: meet with users/stakeholders,
talk about what they need, build a first version in 2 to 4 weeks, release,
test, adjust, repeat. For me it makes so much sense agile that I don't get why
some devs don't understand the beauty and simplicity of it.

If you want to know more about the why of the standup, and what is the idea
behind it, read Borland's tell: [https://www.scruminc.com/origins-daily-
standup/](https://www.scruminc.com/origins-daily-standup/)

~~~
FZ1
The origin of the "standup" is just a regular daily coordination meeting -
like thousands of organizations have always had.

Ever heard of a "morning sales meeting"? They've existed for decades - short,
to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This
kind of thing exists in hundreds of other businesses as well.

Much like everything else in scrum, they are just trying to take credit for
something people already did - so they can package it and sell it back to
people as if it were a novel idea.

There's nothing new or special about scrum - except a reduction in
productivity because of the additional overhead and meetings.

------
brightball
The issue with Scrum is everything revolving around 2 week sprints. That
doesn’t allow for much in terms of variability, longer term scheduling, or
planning dependencies across multiple teams. Plus, in order to try to make the
commitment/forecast accurate you have to invest a hefty amount of planning
time every 2 weeks.

The Scaled Agile (SAFe) approach is dramatically better here. You plan 8-12
weeks at a time across all teams and invest heavily in planning for 2-3 days
of that entire time period. The planning time is synced up for all dev teams
so they can communicate and work out cross dependencies.

The other perk here is that you’re goal is to commit to the 12 weeks and not
every 2 weeks. That allows for more ups and downs and there’s a built in 1.5
week buffer at the end specifically to account for overrun.

You end up with a clear picture of what’s coming in the next quarter or so
without flavor of the week course changes outside of a significant emergency.

~~~
Ididntdothis
To be honest when I saw the diagram for scaled agile
[https://www.scaledagileframework.com/](https://www.scaledagileframework.com/)
the first my BS meter went off big time :). It definitely doesn’t deserve the
word “agile” in it. It feels more like the management pipe dream of the
perfectly predictable machine for software development.

~~~
lostcolony
Yup. And the OP did nothing to dissuade me from that. 12 weeks instead of 2
isn't actually helpful; the whole goal of the 2 week sprint was to find a
balance between minimal amount of time needed to recognize 'we're going to
take longer than anticipated', and actually being able to deliver something
useful. Going to 12 just means that you won't recognize things are slipping
until the quarter is up.

~~~
brightball
You still break things into 2 week iterations over the 8-12 weeks. You still
check in on things, get feedback and determine if changes or pivoting is
needed. Nothing stops that.

What it does stop is all of the planning meetings crammed in every 2 week time
period while also giving a forum for planning between all of your other teams.

There’s no advantage of scrum that is denied with SAFe. It just gets rid of
most of the problems that I’ve experienced with it in the last 10-15 years.

------
eberyvody
ended with a cliffhanger! OP eloquently picked apart the predominant system
without a clear alternative :)

mostly agree with the premise though, and I'll add that "sprint" is insane
nomenclature for something that you do continuously week-in and week out.

my question for the author (and ya'll) is how to reconcile the time-waste of
estimating with the fact that you do indeed need some estimate of how long
something is going to take in order to decide whether you should prioritize
doing it (we like RICE [0]). as the designer on a startup team, i'm not going
to push for designing / building some crazy VR UI no matter how much we hear a
customer asking for it, but i'll definitely design some 3d button transform
hover states or other small finesse if the front-end eng says it's easy to
implement. i'm sure i can think of a less extreme example, but not today.

[0]: [https://www.intercom.com/blog/rice-simple-prioritization-
for...](https://www.intercom.com/blog/rice-simple-prioritization-for-product-
managers/)

~~~
ellius
My most recent team ran a version of XP, and I found IPM (iteration planning
meeting) to be one of the most effective and important things we did. We had a
very good back and forth with our Product Manager, with conversations usually
going something like this:

PM: Let's go through our prioritized features. First we would like Feature A.

Team: That's probably easy, we can do it in a day or so.

PM: Great. Next we need Feature B. I know this one looks a little more
complicated.

Team: Yeah, that's more like a week.

PM: That probably isn't worth it to me. We can probably push this feature back
a couple releases, and maybe take out part of it.

Team: Would it help if we just did Part X? That seems like it would give you
most of the value and it would be much easier.

And so on. The constant cost-benefit analysis, reprioritization, and rescoping
was a great lever and made the team very productive.

The other 4 things, all related I think, that made us effective were:

• Everyone sitting together. I could go ask the designer or PM a clarifying
question at any time.

• TDD. I would constantly start to write a test and realize that something
didn't make sense—some assumptions were conflicting, or we needed to do
another story before the one I was working, etc.

• Pairing. Many times I'd have written the test, had cleared my plan with the
PM, and my pairing partner would point out a different perspective or catch
one of the things I described above.

• Frequent releases, about quarterly at first and down to bi-weekly at one
point.

In all cases, what we were really doing is optimizing the value of NOT doing
things. We were helping the PM understand her costs, but we were also helping
her eliminate huge chunks of wasteful work, e.g. building things users didn't
want, things that didn't integrate well, and so on. Estimating was a piece of
it, but it was really the buy-in from the business to accept our estimates and
more importantly to trust us as partners in the scoping and planning process,
and doing that process fluidly, that made us successful.

------
lostcolony
'How can we, as software developers, minimise the chance of building the wrong
thing?'

Make sure you're hiring the right product people?

I've never "built the wrong thing"; I -have- been told to solve the wrong
problem, or been given incorrect information, or been left with unresolvable
ambiguities from product that I've just had to arbitrarily pick between.

That may seem like a picky distinction, but it matters. I've never gone back
and said "Huh, yeah, you defined the problem really well, then were super
responsive with my following up with you, but I somehow wrote code that did
something completely different to what we specced out together". Invariably
it's been product not knowing what they actually want, or being hellbent to
build something stupid (massive amounts of effort for no revenue impact, etc).

~~~
hinkley
> “How can we, as software developers, minimise the chance of building the
> wrong thing?”

I had an immediate histamine reaction to this statement. With a site title
like Risk First, it’s like he’s standing right next to the solution but
looking the other way. I suppose we’ll see in the next article if he’s being
coy setting up a scenario so he can make a dramatic turn or not. I’m worried
he’s instead being sincere.

But that question? It’s so much the wrong question. We know from surveys that
couching questions the wrong way invites certain answers and precludes others.
So I have some questions of my own, that are biased toward _my_ agenda.

 _Who cares if you built the wrong thing?_ Or more informatively, _why_ do you
care that you built the wrong thing? Is it because you were wrong? Oh boo boo.
This is a trap intellectuals set for themselves all the time.

You want to know the stuff I recall from school? It’s often the stuff I got
wrong on the test. I get it. It’s a bad feeling. But bad feelings aren’t
automatically bad. There are worse things in life _and_ software than bad
feelings. Like hollowness. A grey heckscape of empty mediocrity teaches you
almost nothing and doesn’t even leave you with a story to tell. Nothing
happened at all, and it was horrible.

How do we, as software developers, minimise our _investment_ (time, energy,
mindshare) in building the wrong thing? That’s a much better question. And
some times it means steering toward the stupid, or the crazy, instead of just
being averse. Steering past it, not away from it.

~~~
haolez
I could understand the author's idea with absolute clarity (regardless of his
merit).

I don't have the slightest idea of what I've just read in your comment.

~~~
rumanator
> I don't have the slightest idea of what I've just read in your comment.

Easy. Not having your way does not mean that you're building the wrong thing,
and feeling bad because your idea didn't prevailed is not a technical problem
nor a sign that everyone else is incompetent or that the process is faulty. In
fact, it just mean that the complainer is unprofessional and immature.

------
oxfordmale
The only way you can fix scrum is by burning it on the stake. One of the core
principles of Agile is to recognize that the best work emerges from self-
organized teams. however, most scrum methodologies completely ignore this and
put control back in the hands of senior management by introducing heavy handed
processes (daily stand ups, retrospective, bi-weekly planning sessions, scrum
masters, etc). You know you are in trouble when a team introduces a definition
of done and you are in deep trouble when senior management starts discussion
burn down rate charts of completely made up story points.

~~~
baxtr
> _One of the core principles of Agile is to recognize that the best work
> emerges from self-organized teams._

Do you have a source for that? I personally have never experienced that. In
contrast, I have experienced that the best work emerges when true trust is
ingrained in the organization/culture, meaning a) mutual respect on all levels
and b) and willingness to criticize the work of others. These two points are
not related to any levels. Senior management can deliver great value to their
teams. It very much depends on how they are involved in the work.

Also note that no team can exist outside of the organization that it funds. A
dev team of 5-7 devs + PM + UX will cost a company roughly 500-700k EUR/USD
per year depending on location. If you want to work on your own ideas with
your team and no management interference then go and found a startup.

~~~
oxfordmale
See, item 11 of [https://www.agilealliance.org/agile101/12-principles-
behind-...](https://www.agilealliance.org/agile101/12-principles-behind-the-
agile-manifesto/)

I am not arguing that teams should work on their own ideas. I am arguing that
there are many ways a team can deliver on the requests of senior management
without using Scrum. Scrum is very dogmatic and this goes against the
principles set out in the Agile manifesto.

~~~
baxtr
I see. I subscribe to that. I am not a big fan of scrum either.

Have you heard about Shape Up by Basecamp? Would love to get some experience
accounts on that method.

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

