
Leave scrum to rugby, I like getting stuff done - lanecwagner
https://qvault.io/2020/05/18/leave-scrum-to-rugby-i-like-getting-stuff-done/
======
LandR
Scrum is a way to take a below average or poor developer and turn them into an
average developer.

It's also great at taking great developers and turning them into average
developers.

Everyone just wants to take something easy off the board that you can get done
in a day so you have something to report in tomorrows daily scrum. It's just
everyone trying to pick the low hanging fruit. THere's no incentive to be
smart and to take time to think about solutions, if nothing is moving across
what are you even doing? You're letting the team down! The velocity is
falling!

I think if you have hard problems to solve you solve them by giving them to
smart people then leaving them the fuck alone. You don't constantly harras
them everyday demanding to know what they did yesterday and what they plan to
do today. With daily updates where is the incentive for the smart people to
work on the hard problems? They now have the same incentive as the junior
developer, find the easiest tickets to move across the board.

Sometimes I will want to just be alone and think about a solution for a few
days. If I do that though I'd have nothing to say at the scrum. So instead
I'll pick the user story where the colour on a front end was the wrong shade
of green or a spelling mistake! See, I knocked out 2 stories in one day,
before lunch! Go me!

And it all looks like progress because stupid cards are moving across a
pointless board.

Scrum exists because managers don't trust developers to get things done
without constant supervision and an ever present threat of looking bad for
your team.

It takes a team of potentially really smart people and turns them into a code
production line. It's depressing.

~~~
thanatropism
> Scrum is a way to take a below average or poor developer and turn them into
> an average developer. It's also great at taking great developers and turning
> them into average developers.

Given the available pool of poor/average/great developers, this may be the
correct decision.

Model: There are a1, a2, a3 developers of poor/average/quality. Poor
developers cost p1, have a default productivity of q1. Average developers cost
and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings
everyone's productivity to q2. Note that no one gets a raise or pay cut.

Without Scrum your total payoff is

    
    
         a1*(q1-p1) + a2*(q2-p2) + a3*(q3-p3)
    

With Scrum it becomes

    
    
         a1*(q2-p1) + a2*(q2-p2) + a3*(q2-p3)
    

So what you need from Scrum to be worthwhile is that

    
    
         a1*q2 + a3*q2 > a1*q1 + a3*q3
    

i.e.

    
    
         (a1/a3) > (q3-q2)/(q2-q1)
    

Now, let's say 60% of programmers are poor; a1/a3 is 1.5.

    
    
         q2 - q1 > 3q3 - 3q2
    

So even if poor developers improve by 1/3 while great developers are
downgraded by 1, we're better off.

    
    
          1

~~~
kstenerud
Or just fire the bad developers.

Reminds me of
[https://youtu.be/VAAOnmOlrLU?t=155](https://youtu.be/VAAOnmOlrLU?t=155)

~~~
thanatropism
But bad developers are cheaper and also more interchangeable.

Of course star developers hate Scrum. But star developer code is often crummy
too, and technology advances so fast that I'm glad for every dollar I didn't
pay for divine Win32 code.

------
kstenerud
I've yet to find myself in a scrum or agile situation that wasn't
dysfunctional.

The most common sin is the standup, where each person talks for 5 minutes
about something while everyone else tunes out. It's a complete waste of 30
minutes a day, made worse because you're tired of standing and just want to
get back to doing things or meeting with people you actually need to meet
with. I understand the theory behind it, but I haven't seen that actually
happen in my entire 25 year career.

Next up is the sprint, which I've actually seen work somewhat in some
companies. Generally, when they're doing it right, they'll have a "next up"
lane for things that someone is serious about, in priority order, and actively
maintained by the stakeholders (with an arbiter). And then the "backlog" is a
black hole where things go to die (which isn't a bad thing). People grab from
the "next up" lane the things they think they can get done in a sprint
(keeping in mind the priorities), and off they go. That's the best case. More
commonly, it's a morass of crap nobody cares about anymore, complete with
questionable tasks, top-down requests (with no pipeline to discuss), or not
broken down into manageable chunks.

Generally, when companies adopt "agile", there's a lot of paperwork, meetings
and activity, but very little communication and accomplishment. The only worse
thing I can think of is peer reviews.

~~~
Lutger
Did you work at many different companies, one or a few? It's interesting to me
because I don't recognize this at all.

Quite the opposite. Standup take no longer than 15 minutes, we frequently
address issues which otherwise would have led to lots of rework. You need some
discipline to do it right however.

Lot's of engineers are afraid to ask for help, or too proud. The standup helps
people get help sooner. It also often shows where two people are actually
doing the same thing, take a wrong path, help prioritize etc. I can't imagine
a software project without a standup anymore.

It's funny, if I would pick out the two single most valuable things out of
agile I would say standup and peer review.

~~~
kstenerud
I've worked at many different companies. The first were all waterfall (because
XP hadn't been invented yet). My next scrum team sizes were 5 (scrum), 3 (no
scrum), 2 (no scrum), 15 (waterfall), 4 (scrum), 4-10 over time (scrum), 5
(scrum), 6 (scrum), 9 (scrum).

I've never seen what you describe actually happen (although I know that this
is the theory behind it).

TBH I haven't really noticed much difference in the accomplishments of scrum
and non-scrum teams.

------
caust1c
I'm no scrum fanatic, but there's real value in doing estimates at the
beginning of work, then reviewing how long it took at the end of work (without
revising estimates mid workstream).

The point of separating these from actual time is not to make people feel
better about themselves, it's about accounting for how much unplanned work
there is in your organization which is different from org to org and even
project to project.

By reflecting on how many "story points" some piece of work took, then you get
better at estimating how much calendar time something will actually take.

FWIW, I've never seen this work in a team setting. I use it in an individual
setting where I estimate work for myself, then gauge how much I can get done
in the context of a project or org.

~~~
hrktb
I always wondered how it worked in functionnal organizations so perhaps You
could tell me.

We were told the base principle was to have a stable team and a stable stack,
and at some point we had reference tasks to calibrate our point system.

But then we had team shuffles about every 6 months ~ 1 year, so team velocity
was a fantasy.

Then we changed core libraries, introduced services using new stacks, built
new API, adapted to other teams’ new paradigms.

And all of these changes felt to be for the better to us. Everyone would have
left if we kept everything inu place for the sake of point consistency.

Basically, how did you deal with change ?

~~~
loopz
If you read your own post, for you, the answer gives itself. For managers and
executives, maybe the answer is different?

------
supermatt
Scrum isn't for everybody. I would say it is for organisations or departments
whose business is not developing products, but who develop products to service
their business needs. For everyone else, there are many better options to
choose from.

That said, lets clear up some misinformation:

1) Scrum is vague? It said it right there: "Scrum is a framework" \- Scrum is
NOT a process, technique, or definitive method.

2) On delivery windows - "I’m not against management being informed… but at
what cost?". Scrum works well for businesses/departments that have a
development need, not where the business IS development. It needs to fit into
the business, not vice versa, and that means managing stakeholder
expectations.

3) On scrum managers - "let the lead developers handle the job." Of course! Or
your development team manager, depending on your org setup. The roles in scrum
are ROLES - not a new org structure.

4) Estimates - sure, points are stupid. They literally make no sense. They
aren't prescribed by scrum in any way, shape, or form. There is nothing wrong
with using time as an estimate. Period.

I think the target audience of Scrum could be made a LOT more clear. It would
save a lot of heartache and hate. I think successful marketing and
certification have become the chief enemy of Scrum - orgs have tried to
shoehorn it in everywhere, and thats not what it is for.

------
robertlagrant
> An API that could have been completed in 2 months will now take almost 4
> months because I’ve wasted time putting in artificial stopping points along
> the way. My imposter syndrome starts to set in, but at least management will
> have pretty burndown charts.

This seems to be a failing of the author.

~~~
cdmckay
And when he delivers the API in 2 months, it's not what the customer wants and
has a bunch of problems that are difficult to fix because he delivered it all
at once instead of incrementally.

~~~
taneq
Not all (or even most) software developed is developed in a vacuum for a
customer who has no idea what they want. Much software is developed as part of
a larger system where functionality is relatively well known in advance and
where rapidly iterating on potential UIs and APIs is neither needed nor
useful.

There's definitely a time and a place for Agile-derived methodologies but not
every project is a nail for this particular hammer.

~~~
jrochkind1
> Much software is developed as part of a larger system where functionality is
> relatively well known in advance

Also, however, most software, especially 'enterprise', doesn't actually do
what it's users need, and is a nightmare for it's users. That the
functionality it would deliver and how it would do so was decided by managers
in advance doesn't mean it actually works for those using it.

~~~
taneq
This is true, much 'enterprise' software is awful. And the key to it is that
(as you accurately say) the functionality is decided by managers, rather than
being determined by business analysts and UI/UX designers based on the actual
users' workflows and feedback. No software development methodology is going to
fix that.

~~~
jrochkind1
Agreed 100%. But once you have people with the responsibility and authority
and skill at determining based on actual users' workflows and feedback... in
my opinion and experience, iterative design works -- even "rapidly iterating"
ideally -- a _lot lot better_ than assuming "functionality is relatively well
known in advance", as the GP taneq suggested. Even experts at UX need
iterative feedback to get it right, in fact an expert at UX is likely to know
and tell you this, that's what their expertise tells them.

(And note even OP concludes by saying he _does_ like "agile", just not "scrum"
\-- so taneq in arguing for avoiding rapid iteration for "functionality
relatively well known in advance" is not necessarily making the same
evaluation as OP either).

Part of what always happens in these discussions is we all come from our
experience. I've seen it work, in such a way that convinces me it was
_because_ of it's iterative nature that it worked. taneq above, I would guess,
has not.

As a field, we still haven't done great at working out a methodology to
extract/abstract from these differing experiences to general consensus
principles, when it comes to "how we write software". So we're all just
arguing from our experiences, and such arguments show that experiences really
differ. Not sure what to do with that. The arguments just go round and round.
I don't think attempts to make this "empirical" and "data-driven" have proven
satisfactory, they often seem to suffer from artificiality/lack of validity to
me too.

(And as far as personal experience -- I think _most_ of us who have been
around 10+ years find that our opinions about 'the right way to do it' change
over time, as our experiences show us different things; but that doesn't
necessarily mean those who have been around longer are more likely to be right
and should be defered to; clearly that defering to experience rarely happens
anyway).

------
yoz-y
> Let’s also say that in my head I believe the whole task to take two months
> if I can work consistently.

Believe it as much as you want but this estimate has a massive chance of being
wrong. After that the reasoning falls apart.

Also don't assign time to points, that's completely missing the point.

~~~
bvrmn
> Also don't assign time to points, that's completely missing the point.

Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there
was an implicit points -> time conversion table. And management can walk in
and ask why you promise to complete a task in 1 point. It makes no sense at
all.

~~~
yoz-y
One article I quite liked was the one about Commoditized Excellence.
[https://barryhawkins.com/blog/posts/the-myth-of-
commoditized...](https://barryhawkins.com/blog/posts/the-myth-of-commoditized-
excellence/)

It would be ironic to resume the article but the gist is that when rather
complex reasonings get distilled into few bullet points tagged with a catchy
name, then they get misused and criticised for things the original idea
expressly called out.

In this case you shouldn't be promising management anything because the points
only mean something in the context of a team.

~~~
bvrmn
If you dig deeper then scrum overall is a very complex thing trying to solve
non-root problems. It is very ironic that scrum is Commoditized Excellence on
its own.

Scrum in a nutshell:

1) We need to periodically check product to cut invalid activity on early
stages. Let's do it in sprints with defined goals!

2) Great, now we need to complete a goal to the end of a sprint. How do we
know that a team will fulfill a goal? Lets plan a sprint according to team
capacity!

3) What is team capacity? It is a historic velocity metric measured in time
per task in past sprints. But estimating time in time units is ... ... mambo
jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad,
sorta. So we introduce points to estimate task size.

4) How do we estimate? Planning poker every sprint!

5) And let's add formal process to evaluate every sprint to be more serious!

It's an artificial construct to solve point 2) only. Drop a goal completion
requirement and scrum will not be needed.

~~~
yoz-y
If you remove buzzwords though it makes more sense:

1) It is impossible to have specs for a complete project at the beginning. So
let's ship piece by piece and accommodate spec changes as they are discovered.

2) We need at least some visibility on what to do so let's bundle a few short
tasks for the (literally) foreseeable future.

3) Since we can't estimate task duration precisely because nobody ever managed
to do it, let's find some measure on how much work we can get done.

4) How do we estimate this: empirically by progressive approximation.

5) This is not actually necessary.

Also I think that one of the more interesting parts of the planning poker is
discussing the why a task may or may not take a long time. It can give insight
into system complexity to people less familiar with a specific part of the
project.

I must say though that the goal completion was more of a unicorn where I
worked. We always had sprints overspill to the next one but that was not
necessarily an issue.

If there is one thing I dislike about the scrum it is the rigidity which is
often introduced. I think a laid back approach to it makes it more useful.

~~~
bvrmn
> 2) We need at least some visibility on what to do so let's bundle a few
> short tasks for the (literally) foreseeable future.

Backlog on every level is always non-empty. So sprint filling is not a
problem. Planning step is not about visibility. You can have a near roadmap
with any process.

But scrum tries to promise that we put only particular amount of tasks to be
able to finish it. Sorta, in my experience there were only few finished sprint
cases in different jobs with different teams, with and without scrum master.
And from this moment scrum goes over the rails. Why we need this restriction
at first place?

------
jon-wood
I've always been quite fiercely against Scrum as a development process, and I
still am in the context of constantly evolving cloud based services, but I've
recently seen it being done to great effect for mobile app development.

I think this is similar to Pete Hodgson's clarification[1] that gitflow (which
he originally documented) isn't suitable in that sort of environment. If
you've got a constantly deployed set of artifacts it doesn't make sense to
plan in two week blocks, and then freeze a release. In the world of software
which has actual discrete releases then you either have a massive gap between
releases as you get everything just right, or you say "every two weeks we'll
release what's ready", and for that approach Scrum works really well.

When you're working on cloud hosted services the typical approach is more of
releasing things as they're ready, possibly sitting behind feature flags or
partial rollouts, and for that Kanban has worked much better in my experience.
It gives more flexibility around changing priorities, and space for the
inevitable production incidents and technical support that can suck up a week
of time out of nowhere.

[1]
[https://twitter.com/ph1/status/1260702766118232065?s=21](https://twitter.com/ph1/status/1260702766118232065?s=21)

~~~
bryanrasmussen
I agree scrum is too heavy for a release every two weeks thing, what it's good
for in my book is:

You have a very big project to make and you know exactly what it needs to
contain, examples:

1\. you have an application that users already use but you need to move off a
platform by a particular time or you are screwed. So you know exactly what you
need to replicate in the new platform (your current functionality) and you
have a set deadline to do it in. For me it was the company got sold and we
needed to be off of Thomson Reuters platform within a year or pay over
$100,000 a month to use it.

2\. You have entered into a legally binding contract and you know what the
application is going to need to contain and what you can drop without getting
sued or not getting paid.

If it is your own application you can always stretch timelines out a bit to
get to where you need to be, or you can decide to drop features to get to
where you want to be. But once there are other people in there you might not
be able to stretch timelines of drop features, and then you need something
that gives you a way of alerting you beforehand if you're going off the rails.

~~~
Scarblac
If you know exactly what needs to be done, why do all the extra work to be
able to divide it into sprints?

The whole point of sprints is that requirements are allowed to change, just
not more frequently than there are sprints.

~~~
bryanrasmussen
you have it in sprints because you have a deadline so you can see how well you
are progressing towards your goal by seeing how many issues are fixed in their
sprint, going over to next sprint etc. It's not a lot of extra work to divide
it into sprints, especially as you have people whose tasks are to divide
things into sprints and keep track of things.

------
oneplane
Every time another one of those anti-agile or anti-agile-scrum pops up it
seems to just be someone having a bad experience.

The point of a methodology isn't to follow the methodology, but to use what is
useful. Maybe 1 or 2 weeks per sprint isn't useful. Then maybe don't do that.
Or maybe you can't estimate how much time your development might take. In that
case, maybe do a little more thinking instead of presenting a black hole of
time to the people that pay you. Take apart the problem until you do get a
sense of how complex and/or time-consuming it might be.

Same goes for the deliverables or measurable impact; just because something
has a name "an endpoint, a button, a page" doesn't mean that that defines a
quantity of work or defines what you can or must deliver. Plan for what you
know can be made, not for what you don't know. Having 6 months of 'planned'
development seems highly unlikely to be successful, why not plan 1 month at
most, and re-plan when you are near the end of the run. If people keep
planning things they cannot predict it's going to keep failing.

~~~
choeger
> The point of a methodology isn't to follow the methodology,

In scrum, it is. Scrum was developed for managers to distract from the fact
that they know nothing about software. So the methodology is all there is. Go
ahead, ask a (non developer) scrum master about why there need to be cross
functional teams, when 80% of your work never crosses the component boundary.
Or go ask them who priorizes bug fixing (do this when PO, Ops, and customer
care share the same room, hilarious!).

~~~
oneplane
I'm not sure what managers have to do with scrum here. A manager is a person
that insulates business from the execution on a non-functional level.

Perhaps this is a difference in where you work (the company, the culture, the
country), but here a manager is just someone who has the job of making sure
there are no obstructions and people have what they need and don't get shifted
around too much.

Priorities are made based in input from owners, users and developers, and
cross-functional teams are something that you do in a SIG, not in a
development team.

Maybe SCRUM (R) as a commercial idea has a lot of things it wants you do to,
but that's not really why you'd even consider something; you consider
something because it might help you or clarify something for others, and for
novices it can be great if you don't have the experience, skills, insight or
level of thinking to come up with a self-improving process by yourself.

------
DanielBMarkham
Sort of a whirlwind tour of all the misconceptions the average dev might have
about agile/scrum.

Yet again, here goes.

\- The problem here is dogmatism, both yours and whoever is "doing scrum" to
you. There is no Scotsman! He ran away. That is, it's only if you're insisting
whether you're doing it right or wrong can you start to have the conversation
about what is right or wrong. Your premise is invalid.

\- Confusion over terms. These things are much better represented mentally by
the image of a bookstore. You arrive at a bookstore and want to read up on
some stuff related to teams and planning. Cool! There's a scrum section, just
next to the agile section. Guess what? The books don't all agree with one
another, and that's fine. It's a marketing term, a place to go for ideas.

It gets worse after that, with dysfunctions of estimating and so forth, but
you start out with your head in the wrong place, whether you love X or hate X,
it's not going to end well. Do stuff you like, make stuff people want, and get
stuff done. If that's not working for you, here's some titles of sections in
the bookstore where you might want to read some other stuff. There are other
sections. If you find some sections that have cool stuff, let me know. I might
could learn some neat stuff I might use one day.

That's it. It's nothing more complicated than that. You can go to those
sections and learn a whole bunch of stuff about various problems you might
have. Try some if you like. Or not. What you can't do is go to that section
and pull some book out as if it were a recipe and then "implement" it on a
team or organization. It doesn't work like that, and it's never going to work
like that, whether your view is from the top or bottom of an org. You're doing
it backwards. It hurts when you do that? Ok. So stop doing it that way.

------
dogman144
Estimate the work that comes in, commit to that work for x amount of time +/\-
5-10% variance, evaluate ability to finish it all, and re-balance accordingly,
all in all is a pretty effective productivity approach.

When the alternative is a near certainty miss of waterfall and tremendous,
tremendous cost overages, then scrum starts to look like the less ugly dance
partner.

Consistent challenges I see for anti-Scrum arguments:

1) Their POs are doing a _horrible_ job defining what an MVP is, or the devs
aren't following good MVP practices. The MVP solution as something that works
outside of Scrum is well proven in numerous other contexts, regardless of what
a developer designing an API may think.

2) Their Scrum Masters are allowed to turn into managers, not process
governors. The silly SM metrics SMs start to make to increase their job
justification suddenly govern teams and paychecks.

3) Their management doesn't understand what POs and SMs are really supposed to
do.

4) Ok, present an alternative to Scrum, waterfall, in a way that works with
financial reporting and accountability to the people that pay the bills and
paychecks. This is the major sticking point. Criticize Scrum :thumbsup: Come
up with an alternative that meshes with the reality of software the profit-
seeking business :silence:.

------
quickthrower2
Good points in the article but I have to mention a scrum master isn’t supposed
to be telling people what to do, but rather coach on the scrum process.

~~~
chrisseaton
> but I have to mention a scrum master isn’t supposed to be...

This is a major problem with Scrum. There's always someone telling you you're
doing it wrong. If nobody's able to implement your big idea properly, maybe
the problem is with the idea or how you're explaining it, not the people
trying to do it.

~~~
a_imho
_There 's always someone telling you you're doing it wrong._

Of course there are, and they are probably paid handsomely for their insight.
How is a process that wants to implement _individuals and interactions over
processes and tools_ not a parody?

------
ubermonkey
In my experience, the vast majority of developers grousing about scrum and
agile are mostly mad they're being made to (a) talk to their coworkers or
attend ANY meeting at all or (b) account for their work.

But hey, it's HN, so I'm sure there will be absolutely no other positive
comments about the methodology here.

------
wayoutthere
I look at it this way: Agile is a bare-minimum project management methodology.
That can mean different things for everyone, so look at "traditional Agile
practices" as a menu rather than a recipe. If scrums don't work for your team,
then either don't do them or find a way to make them more useful.

I've always felt that most companies do "scrums" wrong. It's not supposed to
be an hour-long status report; it's supposed to be a 15-minute check-in to
identify blockers and connect people so those issues can be addressed _outside
of the scrum_. A good scrummaster should be able to clamp down on the "status
report" aspect of it, but it's really hard to find a good scrummaster since
it's largely seen/compensated as an entry-level position.

------
kemiller2002
I think the theory of scrum is great. When you think about it, Scrum does most
of everything that we should be doing. Thinking about problems before tackle
them. Talking everyday about the problems in case someone needs help. Course
correcting when you need to.

The problem is management. Tools (burn down charts) now become executive
metrics. Amount of code completed now becomes a review item for advancement.
We've applied measures to things that are inappropriate for what they are used
for, and because of this honest communication has been replaced with guarded
statements to make sure that the team never stumbles with its work. No matter
what process an organization uses in those places will fail, because
management wants to hear things are running fine.

------
matthewmacleod
I, too, like getting stuff done.

The way I get the most stuff done is meeting with the rest of my team every
two weeks to:

\- Look at what stuff needs to be done next, based on the stuff we want to do,
stuff that other people want us to do, and stuff we don't want to do but need
to do anyway

\- Figure out between us how much work is involved in doing that stuff

\- Review how much stuff we did in the last two weeks to see if we did what we
expected to

\- Use that information to agree between us how much of that stuff we think we
can do in the next two weeks

\- Make sure that we have all of the information and prerequisites to do that
stuff

\- Based on all that, to estimate how long all the stuff will take, pick which
stuff that we expect to be able to reasonably do, and prioritise what's most
important

Then every day, we check in for 10 minutes to see if there are any problems
doing the stuff, if unexpected stuff needs to be done urgently, or if we want
to show the stuff to anyone else.

Once every two weeks, we show everyone else what stuff we did and answer any
questions about it; once every couple of months, we all sit down together with
other people, look at our list of stuff that we want to do over the next six
months, make sure we all agree on what the plans are over that timeframe, and
make any adjustments we think we need to.

Someone is in charge of making sure that all those things happen, that
everyone has what they need to do their stuff, and that everyone outside the
team knows what stuff is being done.

This is just Scrum using words that don't piss engineers off to the same
extent. Scrum is nothing particularly special or magic – it just provides a
basic set of tools and terms to describe a bunch of interactions and help keep
them on track, and they are for the most part pretty reasonably tools.

And here's the reason this is not a good article – it makes the same basic
mistake as many others do and assumes that a development framework is somehow
supposed to magically fix your broken team. A bad manager is a bad manager,
regardless of whether you call them a "scrum master" or something else.

------
lanecwagner
Author here, love the comments. The biggest criticism that makes me want to
revisit and edit the article is the 2-month -> 4-month API example. I remain
convinced that the Scrum process that I describe is OFTEN responsible for
slowing down projects AT LEAST this much. That said, I think I need to come up
with a better example. It's honestly hard to explain in words.

------
lasereyes136
Scrum is a tool. It can be used well, it can be used poorly. It is good for
some situations and bad for others. The author of the article makes some good
points with the key for me being Scrum isn't agile. For me Scrum is a place to
start an agile transformation but it is often the wrong place to end your
transformation.

------
rergaerg
Dont need to see who wrote this, clearly a very junior engineer with a lot of
opinions and not a lot of experience.

------
tgaj
Seriously, you don't plan 14 sprints at once. You plan for one sprint, and you
need to synchronize with the rest od the team. Scrum is about teamwork and
product iterations, if you start from "i need API with 14 endpoints" and you
will do that alone then that's not Scrum.

~~~
the_other
Totally!

\- How do you know you need 14 endpoints? \- What do they do? \- Do you need
them all delivered in one go? __Why? __\- Can you make something, useful to
the bulk of your users, with three or four endpoints? \- Who uses the
endpoints? Can they do some of their work whilst you make your endpoints? \-
What goes over these endpoints?

All these, and more, affect how you build and what you build. Scrum, and agile
in general, should help you organise the work (where "work" includes planning,
design, collaboration, as well as build and release), and gives you space to
improve the quality of the work (when it's done well).

------
foobar_
Can't we just create a new methodology called blame game ?

------
michaelmior
I don't really feel the need to read this since I'm currently working from
home on Rugby Ave.

------
mnm1
At my current job, scrum is just a half hour meeting every day where people
discuss whatever for however long and the most important is the status update
to make sure management knows that you are working. The upside is we don't do
sprints, retrospectives, scrum master etc. although estimates are still
required. Someone will probably claim this is not scrum, the no true Scotsman
fallacy. I wouldn't mind much if it wasn't early in the morning at such a
shitty time it messes up the whole day's schedule by interrupting sleep for no
reason. Whatever. It's management's loss as contributing meaningfully, by
speaking or listening, is simply impossible. The half hour duration is
extreme. It's a great argument against such meetings, regardless of what they
are called, especially morning meetings. It definitely makes the whole day and
especially the morning much less productive due to draining the natural energy
one has in the morning. Really, I can't think of a way it could be worse other
than it being earlier and longer.

