
Why I'm not a big fan of Scrum - keso
http://okigiveup.net/not-big-fan-of-scrum/
======
cageface
I've been doing Scrum-driven development for a few years now after working
much more independently for most of my career. I understand why managers like
it because it at least lends _some_ structure and predictability to what is an
inherently unpredictable enterprise.

But the author's criticisms of the incentives of Scrum are on point I think.
Because the stories are always articulated in terms of user facing features
they encourage developers to hack things together in the most expedient way
possible and completely fail to capture the need to address cross cutting
concerns, serious consideration of architecture, and refactoring.

This is how you can get two years into a project and have managers and clients
that think that things are going well when the actual code is an increasingly
unmaintainable rats' nest. Good devs confronted with this kind of mess will
eventually burn out on sticking their necks out defending necessary but opaque
refactoring tasks and move on to greener pastures.

~~~
maxxxxx
In my view the only way to handle this is to make constant refactoring part of
the work without telling management. If you ask for permission for refactoring
you will almost always get a "No".

~~~
matthewmacleod
We tend to bundle that work up and include it in tickets with the full
acknowledgement of the rest of the team.

"Oh, since we're adding new email features, we'll need to clean up some of the
old email code. That will add additional complexity to this task, so we will
estimate it higher."

It works, allows us to still track the impact on velocity, keeps everyone
informed, and makes technical debt clear and trackable.

~~~
xwkd
I believe this is the correct approach. You're not hiding the complexity of
the work, and you're also not compromising on quality. This leaves only the
task of saying "no" when asked if you, "for now, could just..."

------
apeace
This was my favorite point out of them all:

> What about contributing to open-source software? Reading the code of an
> important external dependency, such as the web framework your team uses, and
> working on bugs or feature requests to get a better understanding was not
> part of any Scrum backlog I've ever seen.

Working at various startups, I have developed a methodology of contributing
back to open-source projects we use without accounting for it in sprints or
the ticketing system. It involves getting to the office an hour early, over-
estimating on my other tasks so I have time for something extra, and a
sprinkle of office politics.

And yet, it is some of the most valuable work I have done. Not for me, but for
the companies I've worked for.

To get an in-depth understanding of that one Django or Express.js feature you
use, or even better, to find and fix a bug that affected the business or may
have affected it in the future, just gives you that much more of an edge over
your competitors. Say goodbye to that nasty workaround you had to use to get
around the bug--now it Just Works exactly how you need it to!

What's more, it's attractive to engineering candidates when you get to tell
them the story of when you fixed a big bug in Socket.io.

The best engineering managers I have had have been receptive to the idea that
this type of research and/or contribution to other projects should be
considered "work" that provides value to the business.

~~~
icc97
Fixing a bug in OS software and consequently avoiding a workaround should
count as double points in Scrum

~~~
slashblake
Biggest mistake in scrum is to give points for bug fixes, even if they're not
yours.

------
frandroid
We now use Kanban on our team, after using Scrum for a couple years. Pointing
is a process to discover unexpected hurdles or uncover hidden knowledge from
coworkers, and as a guideline. By not having sprints, you just focus on your
current ticket, and not artificial deadlines or points. Tickets will be done
when they are done, and managers don't have expectations of completeness that
as disconnected from reality. We've added priority swim lanes to our process.
We have a prioritization meeting with PMs every week to assign priority to
tickets, order items in the high and medium priority lanes, and review blocked
items to see if anything can be nudged back to a working column. The process
is clear, the expectations are fluid, the work gets done in the time it needs
to get done.

~~~
lmm
There's certainly a lot to like about that approach. But my experience is that
it makes it very easy to end up with tickets that end up taking months
(because there's no longer a natural point at which to stop and take stock),
and/or accepting tickets that don't really have clearly defined acceptance
criteria, which risks working on something that won't actually turn out to be
useful. I don't like the artificial 2-week cadence of Scrum but I think I
might still prefer it to not having one at all.

~~~
a-priori
When I worked on a team like this, the rule was that when you came free and
are looking for work, before you started any new stories you looked at the
work in progress to see if you can help out to expedite any of it. The idea is
that it's everyone's responsibility to try to minimize the work in progress
(Lean).

We also had the general expectation that one story should generally take no
more than about two weeks. Before starting a story, if you think going in that
it will be too big, then you try to limit the scope or defer parts of it into
new stories until you're confident it can be done in two weeks.

Once a week we tracked how long stories were in the "In progress" column, and
once it'd been up there for three or four weeks, people started asking how
they can help wrap it up. I think the longest I remember a story being in
progress was about 6-7 weeks, and that was real uncomfortable for us. Typical
times were 1-3 weeks.

So we had a weekly cadence for demos, and product owners liked that they would
see steady, regular progress rather than being inundated with sudden large
dumps at sprint boundaries.

~~~
frandroid
Two weeks! Any story that takes more than 2 days is generally broken down into
smaller stories. A two-week project is more like a small epic...

~~~
a-priori
Lots of teams have different expectations about how granular a user story
should be, and some of this has to do with the project. How fast can you
design, develop, test and deploy a meaningful amount of new content?

One explanation for the longer time is that we had a process where for each
user story we'd write a short, informal design document and send it to the
team and stakeholders for review. For non-trivial stories we'd then meet to
discuss them and come to a consensus about how to implement it. This probably
added about a day or two to a story's duration, but it meant that we had a
solid system at all time. It also often served a similar purpose to a
retrospective, or produce topics for a retrospective, because these meetings
would surface any technical debt and other impediments to progress. It also
served as knowledge transfer and helped the team converge on design principles
and expectations.

So these meetings had a cost, but we felt it was essential for practicing
agile design. We didn't find this made us slow to react. On the contrary,
because this kept our technical debt low, and our software well designed and
well understood by the whole team, it meant we could pivot on a dime.

I think there's a real risk in going too fast. Maximum speed should not be the
goal of a software development process, and I don't think any business really
wants that. The two primary goals should be: 1) to make predictable, steady
progress over long periods of time, and 2) the ability to change priorities as
quickly as possible as new information emerges. If you have to sacrifice some
speed to get there, it may be worthwhile.

------
joe8756438
I disagree with most of the major criticisms here. I think it is a valid
description of an experience using scrum half-heartedly, but not an argument
against its purpose or value.

Points, for example, the argument is based on the premise that teams are
obsessed with points. What if the teams use points as a framework to discuss
complexity? I have worked in scrum groups where if something was given a large
point value it would be questioned and "split" to break the job into component
tasks that could be done by separate people simultaneously (or some now some
later).

Long meeting times with the wrong people in the meeting? That's a managerial
issue and has nothing to do with scrum.

Writing stories is the main art of scrum and without good stories it is
pointless. A story can be written to encourage a developers to improve quality
of a codebase, share knowledge with another team, or take time to learn
themselves. A really good story would encourage these things and also deliver
customer value.

Any system for managing software development hinges on good communication.
SCRUM's main advantage to me is that it provides continuous opportunities for
face to face communication. If you fail to take advantage or engage with those
opportunities then it won't work, but I bet another "framework" wouldn't
either.

~~~
gmarx
Perhaps but this could be viewed as the "no true scotsman" thing. My main
objections to Scrum are a) you need to shoehorn things into user stories that
are not naturally expressed that way (as a user I would like all relevant data
in the database associated with standard ontology?) b) In a special domain
(healthcare) it requires good developers with some level of domain expertise
and I find this rare c) (and this is a management issue) people think you can
remove important aspects of the methodology (e.g. colocation of resources) and
have it still work

~~~
monknomo
I feel like specialized domains in general require devs with domain expertise.

Maybe waterfall with unusually good specifications can use cog-like devs, but
the few times I've seen that done it didn't turn out very well.

~~~
gmarx
Agreed

------
camtarn
Quoting a nice idea from the article: "One way to achieve this might be
putting work items through what I would call an algebra of complexity, i.e. an
analysis of the sources of complexity in a work item and how they combine to
create delays. The team could then study the backlog to locate the
compositions that cause the most work and stress, and solve these knots to
improve the codebase. The backlog would then resemble a network of equations,
instead of a list of items, where solving one equation would simplify the
others by replacing unknowns with more precise values."

I've never been on a team that does pure Scrum - even ones which intended to
do so always ended up with what we termed "Scrum-ish": taking the ideas from
the base methodology, but adding a whole level of 'house rules' aiming to
patch up obvious gaps. For instance, always making time for one refactoring or
technical debt task per sprint, tracking accuracy of estimated time versus
actual time elapsed (deeply uncomfortable but very useful!), the hundreds of
different rules around trying to make standups shorter and more useful.

I am a big fan of well-run retrospectives, though: they can be a really nice
way to feel empowered as a developer, especially when you have one
retrospective identifying that Thing A keeps causing everyone pain, and the
next retrospective having everyone say 'Hey, Thing A is so much better now!'
Never realized they weren't 'meant' to be about technical matters, though: in
our Scrum-ish teams, they were always open for all topics, and I think that's
a very good idea.

Of course, the fun thing about Scrum-ish teams is now you have a whole new
level of debate that can happen: "We're failing because we're not doing Scrum
rigorously enough!" vs "We're failing because we're doing Scrum too
rigorously, and what we need is more house rules!" ;)

~~~
jcadam
Retrospectives for us consist of the dev team sitting in a room getting
lectured by the PM on why we consistently fail to close all of our stories,
and asking for our opinion on what new processes can be introduced to fix it.

Of course, feedback _is_ solicited, but it is an unspoken rule that criticism
of project management is verboten. However, criticism of self and others on
the dev team is absolutely allowed and encouraged, and so the brown-nosers
amongst the team use the opportunity to make themselves known.

~~~
existencebox
This is familiar to me. However, I'm not sure you'll like my "fix". The PM
should never be outside the discussion. The moment they become a separate
entity, an unaccountable entity, dev can become more and more pathological. It
is for us to stand up to that, communicate the difficulties in task
estimation, keep a strict paper trail on when specs get shifted/scope creeps
so that we have a well backed response when this discussion happens.

I would even argue that in the same way the "brown nosers" are trying to make
some positive impact for themselves, as risky as it is, you can do better by
fighting bad product management. If you feel the pain, your team does, and
likely, your manager might as well. (if it's also a separate entity from the
PMs.) The loyalty and trust you can build by defending your devs and being a
force for good can be absolutely invaluable as your career goes on.

By and by, although I acknowledge the risk, if you shape your rebuttals well,
you can find yourself bringing PMs to your side (a recent "spirited"
discussion in which a PM was refusing to institute KPIs to track their
features ended with their other PM peers questioning their resistance and
backing the eng push for better telemetry, because when it came to "how can we
justify how well we're serving clients if we _don't know_" this speaks even
across lines.)

------
lkrubner
I think the argument for scrum is something like "Our big organization has
complicated politics and scrum is one way of dealing with those politics."
However, I often wish the management would directly address the internal
politics that undermine productivity. I realize that it is awkward and
uncomfortable for managers to talk honestly about the differences they have
with other managers and other teams, but that is also their profession. That
is, working through any relationship that undermines productivity is the job
of a manager.

I wrote about this here: "The Agile process of software development is often
perverted by sick politics"

[http://www.smashcompany.com/business/the-agile-process-of-
so...](http://www.smashcompany.com/business/the-agile-process-of-software-
development-is-often-perverted-by-sick-politics)

------
wtbob
> What I have a hard time understanding is why the ancient, simple
> communication form of text is given second seat. The truth of the matter is
> that, especially under the constraint of distributed teams, it's difficult
> to beat text.

That's a really good point. I'd be excited to see what a team could do if each
developer wrote a one-page memo about what he did and what he was going to do
once an iteration, and a few sentences for each day. Throw 'em in a log, and
they might even aid the retrospective.

~~~
douche
What a fantastic history of a project that would be...

Maybe we could just go back to .plan files, like Carmack.

------
cechner
Scrum proponents (a label I would tentatively apply to myself) would tell you
that 'you're doing it wrong' but unfortunately a point-by-point reply to this
article would detract from the general problem here: Scrum is intended to be
the straightest line towards measuring your real progress on a project, and
not much else

If youre working on a project where it is important that you have as-accurate-
as-is-realistic an idea of the size of the project, or more specifically your
progress through that project, then I can't see how a methodology could be any
simpler.

If having a good idea of the size of your project over time and your progress
through that project are not very important from a management perspective, the
Scrum artefacts will seem like, and will probably in fact be, needless
overhead.

Scrum is not opinionated about the actual development methodology so claims
about how it affects the code that is written are themselves a bad smell IMO.

~~~
humanrebar
> Scrum is not opinionated about the actual development methodology so claims
> about how it affects the code that is written are themselves a bad smell
> IMO.

Scrum is actually part of the problem, IMO. I've seen many teams turn scrum
into a hammer and treat all future problems as nails.

Example problem: The foobar story has failed failed for the third sprint in a
row.

Likely discussed in retrospective (plausibly good ideas, mind you):

\- We need to break down stories more before we estimate them.

\- Or we need to stop underestimating foobar stories.

\- Or we need to focus on unblocking subtasks related to foobar stories.

Probably unconsidered:

\- The foobar code is a mess and needs to be refactored.

\- Or the foobar subsystem is too coupled to the Fizzbuzz subsystem.

\- Or the need for some developer tools to increase productivity in the foobar
ecosystem.

Since scrum is methodology oriented, methodology is the first tool teams reach
for when a problem is encountered. And I see this _after_ team leads make it
explicitly OK to discuss technical subjects in retrospectives.

I'm not a psychologist, so I can't describe why this phenomenon happens, but I
see it regularly.

~~~
altcognito
All of the items you listed under unconsidered should be brought up by the dev
team. If the dev team is uncomfortable bringing them up, then that's probably
a sign of friction between the dev team and management, which is _really_
common.

------
grandalf
I think Scrum is successful in organizations where there is a lot of finger
pointing and cynicism, and the engineering team is happy to measure progress
in "sprints" in order to deal with upstream requests that they fundamentally
don't respect, and possibly a product vision vacuum in which decision are
routinely made and reversed, making careful and judicious architecture
impossible.

In such an environment, developers prefer to drastically over test their code,
and to undertake work in manageable sprints that let management claim success
and understanding even when neither exist.

If you already have a very strong product market fit, and you need to hire
developers whose judgement you don't trust, or if there are extrinsic sources
of timeline pressure (like investors or non-technical management who think
developers are lazy... essentially anyone other than users or customers), then
Scrum is perfect for your organization.

The other constituency that seems to love Scrum is product managers who either
have no vision for the product or no control of the vision, and are
essentially being asked to be cat herders and manage engineers without earning
their respect or having any authority over them.

------
bgruber
Re: daily standups. A lot of what the OP criticizes standups for is what I
like about them. The content is only half of it. In my experience, it can be
very easy for a team to cease feeling like one and instead become a loosely-
coupled collection of independent contractors. 15-20 minutes a day of forced
synchronous communication goes a long way to making you feel like you're
actually on a team and therefore act like it, and is well worth the minimal
time. This is especially true if the team isn't all in the same physical
space. It can be disruptive, so scheduling it at the right time is important.

Of course, if you already have meeting overload, standup is going to feel like
the worst.

~~~
therealdrag0
I also like it when after the standup updates, most of us stick around and
shoot the shit for 10 minutes. Good way to build camaraderie.

------
mms1973
In my opinion, the good thing about Scrum is that you can tweak the rules to
fit your needs, aka, "Scrum in name only".

The daily standup, IMO, should be only to remove impediments, and if you have
none, then a sentence or two will suffice. I see the DS as the most useful
meeting, as you are aware of what your workmates are doing.

And if Scrum is still a pain in the back, then you have Kanban, which is sort
of Scrum without the straitjackets.

~~~
blub
This kind of tweaking is frowned upon and you will be chastised for doing it.

Yes you can do it (and probably should when you understand the purpose of each
Scrummy practice), but don't expect to be praised by Scrummers.

~~~
nl
I've had people on my team frown at my tweaking.

I'm extremely happy to discuss the reasons I want to change something, but all
to often the only counter-argument is "that isn't Scrum". I'm 100% fine with
that, but I'm not going to do something if the only reason for it is religion.

------
zelos
_" Because the assumption is that refactoring will be a few hours' work, or
even shorter if it's renaming a class here and replacing a file there. These
are only the most superficial cases of refactoring, however..."_

That always bothers me, too. The changes you can make continuously are hardly
worth bothering to worry about, because they're so small and quick and decent
developers will do them automatically. It's the changes that take several days
or a week that really make the difference in the long term.

~~~
afroisalreadyin
Exactly my point. The changes that are risky (difficult to do, might take more
time than planned) are those that will make the greatest difference in all
code quality aspects. And these are the ones that are pretty much impossible
to integrate into Scrum.

------
scotty79
I think people don't understand the reason and given flexibility tend to
choose completely counterproductive things to do.

For example the only purpose for points and velocity is to give product owner
idea of how much time will have to pass before a thing might even have a
chance of being done. It tells him that you, for sure won't get this thing and
that thing in next 2 weeks.

The only utility of points for the developers is when doing planning poker. If
something gets a lot of points then this means people are not sure how to do
it and the thing needs to be discussed and broken down.

After that, points have no use for the team and team shouldn't even be aware
of its velocity and how much they burned so far this sprint. Those are the
tools just for the product owner and scrum master.

If product owner is satisfied with "it's going to be ready when it's going to
be ready" then points after planning poker can be forgotten and you don't even
need to calculate velocity. It's still worth to do the planning poker for the
sake of the team discussion and so the product owner can deprioritize task
that are hard but not crucial.

But turning points and velocity and performance measure is dumbest thing you
can get, because then it get's screwed and loses all utility. Same thing in
estimations. If manager is going to negotiate estimates then you can as well
not do it at all because they no longer carry any real information and are
becoming just the reflection of managers hope slightly skewed towards
developers hope (which was already overly optimistic).

~~~
Sammi
And velocity is not comparable between teams, because different teams will
normalize their complexity points differently. The amount of complexity points
that any type of task is given, is supposed to be emergent in that team,
because this makes a team's optimism/pessimism bias moot. The reason to use
complexily points and not time estimates is also exactly this - to remove
preconceived anchoring.

------
justsaysmthng
The author mentions this, but I'd like to insist on it a bit more:

Scrum is a system of managing people, not a software development methodology.

It's about transforming programmers into cogs and gently forcing them to obey
certain rituals every day, until they slowly give up their individual
creativity and initiative and become good 'team players' .

And when someone says 'team player', I hear 'you belong to us now'.

I disliked scrum since the moment it was decreed upon our team.

And that's because pretty soon our team became obsessed with points and
respecting the religion rather than doing the actual work.

The final drop came when I refactored some code, made it twice as fast using
half as much memory (the proverbial 'much better'), only to have to fight the
team to accept the changes, because that wasn't in the backlog.

Methodology is only good when it helps you achieve your goals easier and
faster, safer, etc.

But when the methodology _becomes the goal_ , then your job changes into
satisfying the methodology, rather then being the best at what you like and
enjoy.

And this is the exact status quo that larger organisations love - people
focused on small irrelevant tasks, while the 'grand scheme' is determined by
management.

Not for me. I use certain parts of it in my work today (develop in sprints,
demo at the end of sprint, planning, backlog and current tasks), but if I see
"we use scrum" in the job description, then I'm not your man.

------
greyman
For our dev team Scrum works fine, the key is to use it just as a framework,
and not following every rule to the letter. For example:

\- Obsession with points

We don't have that obsession, sometimes we even don't assign story points,
just hour estimates

\- Meeting extravaganza -

Again, for example remote people don't need to attend all meetings, sometimes
we just clarify the work items outside the meetings.

\- The sprint has its own backlog, which can be changed only in agreement with
the team and the product owner.

We also don't have this... if I finished my tasks, I just move new item from
backlog to sprint and work on it.

\- Refactoring, reading code, researching a topic in detail are all seen as
"not working on actual story points, which is what you are paid to do".

This has some truth to it... regarding research, we do this outside the Scrum.

~~~
awesomerobot
I'm a designer and my experience with small scrum teams has more or less been
the same - a lot of the issues are handled by developers who are given some
agency to self-manage and who are half-decent at doing so. I've only worked in
one environment that was true scrum, and I don't know if it was the process or
the organization — but it felt so overly boxed-in.

The last point has been the biggest one for me. Across multiple organizations
working in the scrum process I've occasionally felt like just getting some
time to talk to developers for future exploratory work is like pulling teeth
because the scrum process relies so heavily on tangible tasks. I think that's
a time management thing that has to be established with teams ahead of time —
like "hey 80% of your week are these tasks, but you have 20% set aside for
research/discussion'

~~~
blub
One can do this 80%/20% split. Not sure if it's mentioned in some official
guide or it developed through trial and error.

Usually the 20% is reserved for bug fixing tasks which can't be estimated and
therefore can't be included in the Scrum framework.

One of my projects has a "technical backlog" which is actually just a Jira
task with multiple subtasks which gets dragged from sprint to sprint. As you
can imagine this doesn't work so great from a process/tool perspective, but it
gets the job done (i.e. Major refactorings can be and have been performed).

The thing with Scrum is that a lot depends on the PO and SM. If they're open
minded and experienced you can get something decent. If they're dogmatic and
pray at the altar of Jira, prepare for suffering.

------
chatwinra
This talk about agile by one of the founders was posted on Hacker News a while
back, it is good, and I think complements this post:

[https://news.ycombinator.com/item?id=11548334](https://news.ycombinator.com/item?id=11548334)

To summarise, the issue Dave Thomas has with agile is that it has become a
prescriptive framework, 'Agile' (with a capital 'A'), rather than what it
originally started out to be, which is a means of being agile (small 'a').

I really liked this talk, and agree with both him and the OP of this thread
that some parts of the 'Scrum' as a prescriptive framework may not work for
you.

I find it a bit strange that the OP singled out the retrospective as being a
negative- for me this is the best part about 'Scrum', as long as you're not
too prescriptive about it.

Really the retrospective is a chance to improve yourselves as team each
sprint, and it's a chance for people to get stuff off their chests. It
shouldn't be just about scrum, it can be anything - adopting new approaches to
development eg: TDD, discussing the state of the code, anything. That's what
makes them (for me anyway and I think(!) my teams) enjoyable & useful
meetings.

~~~
blub
An effective retrospective requires creating a safe environment for sharing
ideas and a SM which can foster such an environment.

I am guessing that such an environment is quite rare, hence the percieved lack
of utility of the retrospective.

I can speak from experience that this is very hard to do. I expect that I will
have to deal with a brewing technical conflict in the team soon and I'm not
sure what's the best way to do it. I've also seen what happens if such
coflicts are sweeped under the carpet and it's not nice.

------
andyidsinga
>> The daily standup deserves a blog post of its own. This religious ritual
has become a staple of every team in the world. Ten minutes of staring into
the void, talking about what you did while no one else listens, because they
were in the middle of something five minutes ago and will go back to it in
another five minutes, and waiting for everyone else to finish.

I've had this happen my times while I was leading the project - it bugs me.
I've ended up reducing daily standups and replacing with walking around
(physically and virtually) and chatting with people and getting similar
results. Of course, "similar results" here is that I heard what someone had to
say but nobody else did - so a key to this walking around approach is to tell
each person what other people are doing in order to connect the dots.

On the surface this might seem terribly inefficient, but there are a lot of
positives, biggest of which is building good relationships with team members
and learning about all the other little things going on in life.

On the down side, for people who are only part time on my team (not uncommon
in my bigco setting) there is extra scheduling effort and discipline required
to make these chats happen frequently.

------
neilni
One of the most essential part about Scrum is that it aligns the understanding
across all the stakeholders, including business owner, customer, designer,
developer etc. Hence the meeting, prioritization, backlog, daily standup/daily
write up as development process artifact etc to focus on the priorities that
create the most business value under flexible scope, fixed time and fixed
money. scope, time and money are the three variables of a development process.
At the end I think the author is proposing with the process for a flexible
scope, flexible time and flexible money, which often is a internal project
that doesn't have direct business applicable value. In this case, the author
should really just break into another side team without business owner and, or
even without project owner and simply use Kanban as the solution, instead of
sticking around with Scrum. I believe every process has its shortcomings, but
instead of pointing the wrongs, I'd appreciate more if the author describe
what the situation/stage/type of this project, and why scrum doesn't work in
this case, and how a different approach can optimize the outcomes.

~~~
JoeAltmaier
Except most of the 'stakeholders' don't give a fig for what the Engineers
value. Like technical debt, robustness of the solutions, relieving bottlenecks
both in code and in development.

So Engineers get herded into little incremental projects that management can
swallow as having 'business value'. And the herd marches toward the cliff as
the code base wanders around the solution space but never gets fundamentally
sound. Anyway, that's my jaded (from experience) view.

~~~
tootie
No process will solve the lack of understanding. Also, this goes both ways
since engineers frequently don't give a fig about business priorities.
Sometimes your refactor isn't really that valuable and is costing the company
money.

If you have a culture of trust between departments, you should be able to have
honest conversations.

~~~
JoeAltmaier
That's exactly the call that gets made again and again, by managers. They
rarely value code quality; so easy to dismiss with "that's just a refactor".
Converse all you want. Business folk are not going to believe that Engineering
isn't foolish and just "costing the company money".

~~~
tootie
That's the culture difference between working in a cost center and working in
a profit center. If you just tell business our code is messy and we want to
make it nicer, they will tell you to fuck off. Tell them you need to reduce
operational risk and maintenance costs. You need to meet each other halfway.

------
cheriot
Keep in mind that Scrum was designed by consultants working for organizations
that don't understand software development. So they designed a process that
can make sense to people outside our industry. In order for it to go well,
though, the person running the Scrum process needs to know how shit really
works. This is rarely the case.

~~~
vpeters25
> Keep in mind that Scrum was designed by consultants working for
> organizations that don't understand software development.

Scrum was "designed" by Ken Schwaber, a software project manager at the time
looking for a better way to control software development processes.

Schwaber discovered he could use an empirical process, rather than a defined
one, to control software projects. He created Scrum following this principles.

~~~
cheriot
Good point, thanks. I was thinking of XP coming out of Chrysler.

I'll stand by the last two sentences of that comment, though.

~~~
vpeters25
> the person running the Scrum process needs to know how shit really works.
> This is rarely the case.

I agree, while a very simple process, people who don't get it tend to
complicate it. They focus on the process instead of the result.

Most failed scrum teams I've seen out there skip the retrospective meeting,
which is in my opinion, the key of the whole thing: that's the meeting where
team members usually realize they "own" the process and can steer it any way
they desire.

------
timwaagh
managers like it. control. results. evaluation. they get to treat programmers
like laborers. programmers don't really have anything to gain with it. what
surprises me, is that sometimes programmers ask for it. it illustrates how
strong the desire is to follow the latest trend.

~~~
dasmoth
>>> what surprises me, is that sometimes programmers ask for it. it
illustrates how strong the desire is to follow the latest trend.

While I'm far from a Scrum fan, it's not necessarily the worst thing in the
world. For instance, it's probably better than "just do what the project
manager says", especially if he tends towards micromanagement. And double-
especially for people who thrive in group discussions but have trouble
managing 1:1s.

I suspect the trades also look different depending on level of experience.
Scrum, at least in some incarnations, tends to be quite egalitarian, so I can
see it appealing to more junior devs in environments where they feel the
seniors get to do all the interesting stuff.

------
nxzero
Maybe it's me, but the real issue with professional scrum masters is that it's
rare to find any that practice agility as a way of life.

Majority of professionals I've met appear to lack any ability to improvise and
literally just follow the book on what to do without any critical analysis of
how their situation fits with the defaults provided.

Basically, my issue with scrum is its community.

~~~
VLM
Superficially the google term you're looking for is "cargo cult"

But how to fix cargo cult depends on the root cause and there are many:

1) Authoritarianism, my boss said read this book, this book said XYZ,
therefore XYZ is true. How could the book possibly be wrong? Or for book,
insert rockstar ninja consultant or training class or whatever.

2) Religious belief, sure none of this makes logical sense but if you have
blind faith and are not one of those apostates, it'll work just fine. Just
relax and perform the ritual.

3) Deep game, where we actually run on anarchy or waterfall but someone needs
XYZ on their resume so superficially we've skinned it as XYZ. Dig enough and
you'll find what really runs the place is something else.

4) Blame games, a large part of management is how blame is distributed, not
just distributing work, and when a subgroup who thinks they're agile-ing to
distribute work comes in contact with a group using agile mostly to distribute
blame or to stall for time or just to goof off on company time, its kinda like
matter-antimatter.

------
hidro
I like how Scrum promotes transparency and trains each individual to become
self-managed (or at least getting better at it). But it often feels like it's
being hyped up, with many people getting obsessed over its practices/rituals.

Estimating work is a nice idea, but using 'story points' for it just feels
like a bad API decision - I have never seen a new Scrum team member (including
me) getting it at 1st try.

And maybe it's just me, but having a full time, dedicated Scrum Master, who
serves solely as a facilitator (without having any actual role in product
delivery) is a nightmare, especially for teams that are used to Scrum
practices.

~~~
UK-AL
"I have never seen a new Scrum team member (including me) getting it at 1st
try." \- I've never seen one get an accurate time based estimate either. Even
experienced ones.

~~~
matthewmacleod
That's one of the reasons that Scrum doesn't use time-based estimates.

------
thefastlane
do we see bank analysts playing 'planning poker' when it comes to putting
together pitch decks or research analyses? no. and they'd transfer out of any
group where a manager tried to implement such a practice.

if a software engineer is more than a couple years out of college, i don't
think she/he should put up with it either.

~~~
humanrebar
> do we see bank analysts playing 'planning poker' when it comes to putting
> together pitch decks or research analyses? no.

Most industries (don't know about bank analytics in particular) are more
personality driven and/or more repeatable. There are few industries that:

\- make entirely new things on a regular basis

\- are mysterious to laypeople

\- cannot ship 50% of a solution and get 50% of the value

~~~
zelos
I don't think those are all that true of software in general. Most software
isn't particularly new: how many "Yet Another CRUD app" projects are there?
And with software you _can_ ship a percentage of the features and add more
later, unlike (say) hardware manufacturing, civil engineering, chemical
engineering or architecture.

Maybe software is reasonably different in that there are a lot of management
level people with little technical knowledge of how the work gets done? I
don't know how that compares to other similarly technical industries.

------
daly
John Cleese (Monty Python) in "Meetings, Bloody Meetings"

[https://www.youtube.com/watch?v=ZWYnVt-
umSA](https://www.youtube.com/watch?v=ZWYnVt-umSA)

You need to rent this video and show it to the team. (and rent "More Bloody
Meetings").

Scrum is a management technique, not related to programming. In fact, it is a
"micro-management" technique. However, those who lead don't seem to know how
to conduct meetings. I don't see scrum training that even hints at the
fundamentals of management, even the fundamentals of meetings.

------
lazerwalker
So I've never done Scrum-with-a-capital-S, but I've worked in environments
that practice by-the-book Extreme Programming, as well as other flavors of
Agile.

I agree with a lot of what the author is saying. They're describing a process
that appears to be relatively broken, and identifying some good reasons why
they're broken.

What's missing is flexibility. As per e.g. the Agile Manifesto
([http://www.agilemanifesto.org](http://www.agilemanifesto.org)), the entire
point of frameworks like Scrum is to provide a loose set of processes that you
adjust and tweak to your specific team. If you're blindly following the
process, and slavishly adhering to things like how precisely your daily
standup MUST work, you're following the letter but not the spirit. You're
being "Agile" with a capital A, but your team isn't actually being "agile"
(the adjective), which is actually the important bit.

The correct response to "our team is unhealthily obsessed with story points,
and yet doesn't get value out of them" (or standups, or retros, or whatever)
isn't to say "story points are broken". It's to say "this bit of process isn't
helping us right now. What can we do to modify the process to provide more
value to our team?"

------
cheriot
No methodology can save us from managers that don't understand what they're
managing. For various reasons this is more common in software development than
other fields.

------
ebbv
I find points far more useful than time based estimates. The trick is to use
points like categories and not try to treat them as 1 point = N of something.

During my training the analogy was to categories of dogs based on size. So
like a Chihuahua is maybe a 1 and a Great Dane is maybe an 8 (and there's 7
categories of dog size between them.) But a Malamute might also be an 8. Even
though it's shorter than a Great Dane, it weighs maybe the same because it is
more thickly muscled. But neither of those dogs is equal to 8 Chihuahuas.

The point being that if you categorize stories like this, treating point
values as categories rather than as 1 point = N of X, then that makes pointing
a lot easier and a lot faster as your team builds up a methodology (what
categories your team uses and what they mean is up to you, it doesn't matter
as long as you are consistent.)

This leads to meetings taking less time, and leads to a more consistent
velocity than if you do something like 1 point = 2 hours or 1 point =
something else rigid.

If SCRUM doesn't work for your team by all means you should abandon it. But,
to me, it sounds like his team is using it badly. It sounds like they are
being really rigid, and it sounds like a few adjustments could lead to a lot
more happiness. But maybe not.

------
0xmohit
It's worth mentioning a somewhat dated post "Thoughts on Scrum" [0] by Jethro
Villegas [1] who works on Mozilla Firefox and earlier managed engineering for
Flash Player.

[0] [http://junglecode.net/thoughts-on-scrum/](http://junglecode.net/thoughts-
on-scrum/)

[1] [http://junglecode.net/about/](http://junglecode.net/about/)

------
dudifordMann
I agree that there are individuals and companies who have defined such ridged
structure and expectation into their Scrum method that they can no longer be
considered an agile approach missing two of the key purposes of agile
approaches:

* Individuals and interactions over processes and tools * Responding to change over following a plan

Now, I cannot say that Scum abstractly is a bad approach to _attempting_ to be
more agile. Many of us have employed some form of it with varying degrees of
success, but, the expectations on software developers from a business
perspective are more rigid for business development and tracability purposes,
which can,on occasion, omit the consideration of resource demands and
complexities.

Often, i believe, it is that a lack of understanding the purpose of the agile
manifesto and the poor implementation of a method at the top level of the
developer and managment ladder which is the underlying cause.

In the post, the author cites 3 hour or more meeting where he feels there are
too many people there. This would be an item for the retrospective feeding the
next iteration, but he only says "Blergh" about the needed feedback.

He states that the standup is more ritualistic, but the point is to ensure
each member understands where the sprint stands, inspire collaboration, but
really take ownership of the code. It could be that the team size is too big,
or that the team really has not taken ownership of their code.

When all is said and done, you have to buy into the Scrum process, the process
has to be flexible, and the stakeholders have to not believe it is a magical
development method that fixes all the issues of the software development
process.

~~~
Meegul
His complaint about the standups interrupting productive work rings a bell
with me though. I see no reason why a daily status update over the general
channel on slack doesn't serve the same purpose as a standup meeting. In fact,
make it so there's a loose timeframe, say 30 minutes, and you wouldn't be
interrupting people, nor forcing them to stare at a wall.

My team hasn't tried anything like that, but I think it could really be
useful. It encourages better communication throughout the day as well, as it
gets people using Slack. Plus, it gives managers the ability to keep track of
what people say each day.

~~~
cableshaft
For me, the daily status meeting at my current job has been the only time I
can guarantee the team lead will be available to answer questions, as he tends
to get pulled into meetings (or is busy marking up tasks or working on code
reviews) most of the rest of the day.

At this place, where there are lots of different code bases of various quality
and approaches to how the features are implemented has shifted over time, I
tend to have questions most days.

I have worked at companies where we're only really working on one thing and
I'm familiar enough with it that I really didn't have to ask any questions
(they also didn't care much on how it was implemented, either, just that it
worked) and daily status meetings were pretty much a waste of our time and
ended up becoming more like once every other month.

------
Fifer82
I want to make bad, difficult to maintain code, I want to spend more money
doing it, and want to extract all of the enjoyment out of programming for
those on the project so that innovation is stifled. Would Scrum be a good
choice?

------
alistairSH
One of the first things I was taught when I did my first Scrum Master course
was that scrum is just guidelines. Teams are self-organizing and need to do
what works for them.

Most of the criticisms in this piece can be resolved by team members adapting
processes so they work for the team.

I've also encountered most of those problems in non-agile, non-scrum teams as
well. Instead of obsessing over points, it's hours.

Meeting hell can happen anywhere. Good employees will tell their managers when
meetings become an impediment. Good managers work to fix it (and pro-actively
try to prevent it).

I always find it odd when somebody complains that sprint goals need team buy-
in to change. Why is that a bad thing? Adjust and move on. Sometimes things
don't go as planned, sometimes they go well. Hopefully, it all averages out at
the end.

Anyways, I guess I view scrum (or any other methodology) as a loose set of
guidelines, not strict rules that must be enforced at all costs. If management
is forcing the rules, even when they are becoming impediments, that's a sign
of a management problem that is unlikely to be cured by a change in
methodology.

~~~
softawre
Exactly true. I hate to say "that's why all of these articles are dumb", but
really - is adapting something to your people that hard or unexpected?

------
davidgerard
Scrum/Agile-English Dictionary
[http://reddragdiva.dreamwidth.org/594955.html](http://reddragdiva.dreamwidth.org/594955.html)

But with our new Silver-Bullet Development Methodology™, it's a completely new
world where none of your decades of experience apply! This changes the nature
of development forever!

p.s.: we sell certifications!

(repeat for a new Silver Bullet roughly each decade)

------
depr
>The daily standup deserves a blog post of its own

I found this to be a really good article about standups:
[http://www.yegor256.com/2015/01/08/morning-standup-
meetings....](http://www.yegor256.com/2015/01/08/morning-standup-
meetings.html)

------
hoodoof
Scrum is the worst possible development methodology, except for all the
others.

~~~
tjl
There's a lot of development methodologies and if you actually think this you
probably haven't seen many of the others.

It regularly seems to me that people think that there's Agile/Scrum and
there's Waterfall and that's it. The first year engineering design course (and
the first year programming course) in my department cover a number of
different approaches.

------
nutheracc
NoEstimates: [http://ronjeffries.com/xprog/articles/the-noestimates-
moveme...](http://ronjeffries.com/xprog/articles/the-noestimates-movement/)

~~~
matthewmacleod
That's a great idea if you don't have any customers or constraints.

In the real world, there are externalities that have an impact and require
some estimation. Maybe we have to provide new support materials to customers,
or finish a contract with a third-party data provider, or change our
infrastructure. It's exceptionally hard to do some of these things without
being able to make commitments of some kind. Estimates allow us to create a
guideline, and subsequently alter either the thing we are going to deliver
(i.e. dropping lower-priority features) or the time we are going to deliver
(i.e. missing the deadline).

If I hired a builder, and he told me that he refused to estimate the amount of
money or time it would take to construct my property, you can be sure I'd move
on. I have no idea why we'd consider it appropriate for an engineer to do
this.

~~~
GrumpyYoungMan
>If I hired a builder, and he told me that he refused to estimate the amount
of money or time it would take to construct my property, you can be sure I'd
move on. I have no idea why we'd consider it appropriate for an engineer to do
this.

When every builder (i.e. engineering team) anyone ever hired everywhere blew
through their estimate ~70% of the time, perhaps it's time to reconsider that
stance. See the Standish Group's annual CHAOS Report for an example of
software project success statistics, e.g.:
[https://www.infoq.com/articles/standish-
chaos-2015](https://www.infoq.com/articles/standish-chaos-2015)

Estimates are just mutually agreed upon lies that engineering teams tell
themselves.

------
jschulenklopper
> The use of story points appears to be one of the defining features of Scrum.

Practice and experience may have led to this conclusion, but it will be good
to know that the (original, Scrum-defining) Scrum Guide,
[http://www.scrumguides.org/scrum-
guide.html](http://www.scrumguides.org/scrum-guide.html), doesn't even mention
nor defines "story points". Obviously, there is planning and estimation
involved in Scrum, and story points can be a metric used for "amount of
work"... but it's not a defining feature.

------
purpleidea
Just read the summary which I highly agree with and will quote here:

> So, in summary, Scrum

* wastes too much of the developers' time for management

* does not lead to good quality code

* is a control freak which does not leave room for new ideas and innovation.

------
vannevar
There are some valid criticisms here, though on balance I think the author
enumerates costs without considering benefits. But the biggest complaint is a
result of a common misconception: that scrum is somehow a replacement for
software design. It is not, nor is it intended to be. The author seems to have
a glimmer of understanding that this is the case:

 _Scrum, however, is much closer to the problem solving approach, where
analysis (breaking down a problem, and reassembling the solution) is the
organizational tool. In order for an interpretive community to emerge, an
organization needs ambiguity, open-ended conversations, and alternative
perceptions. All of this, Scrum leaves to something else, whatever it is._

But then goes on as though Scrum precludes any kind of thoughtful design or
experimental innovation. Nonsense. Nothing in Scrum suggests that a team
mindlessly go through sprint after sprint without ever pausing to have design
sessions or build prototypes. And there is scant mention of the product owner
at all; it's as though the author believes that software is designed by
developers, for developers.

Scrum is a way to implement a software design, flexibly and with the
understanding that the design will change along the way. How you decide what
to implement, how you arrive at that initial design, is up to you. If your
organization doesn't understand how to create and manage the abstractions that
make up a software application to begin with, then Scrum isn't going to save
you.

------
ricardobeat
As usual, criticism is strongly shaped by experience. My experience is also
limited to three or four workplaces, but I have never, ever, seen this "race
for points" and definitely not being "awarded" the points at review time. The
points don't mean anything by themselves, it's an abstract measure of effort
whose value fluctuates wildly, influenced by team dynamics, individual
productivity, type of work being done etc etc. Failing to understand that is
starting with the wrong foot.

------
speby
This article is, rightly so given the author, written from the perspective of
an individual contributor on a Scrum team.

First, the author refers to Scrum as a methodology. It is not. Scrum is a
framework, and being based in agile principles, is much more about a way of
thinking and working. It should not be used as a purely do-this-then-that
prescriptive approach to getting software built. As we now can see, there many
organizations that tout being "agile," when their true behaviors and output
are merely agile window dressing. Also known as "fragile" instead of "agile."

I disagree that Scrum is not useful to many organizations and teams. In
particular, organizations that basically lack any process (trust me, I've been
in a number of them) and it's kind of a free-for-all or based on whichever
executive screams the loudest gets what they want when they want it.

What is missing here is why Scrum can provide useful, especially in terms of
velocity. A team's velocity can serve as an underlying basis for projecting
how long things can take. Like it or not, internal "users" or "stakeholders"
in an organization as well as many external ones expect to get some idea of
when things are going to start happening and when things are going to be done
happening, for particular features or commitments. As expected, this involves
being able to at least intelligently (and based on historical data) make a
reasonable prediction at dates.

Entire books have been written about software estimation and no framework gets
it right.

------
pjbster
After working in Scrum for over a year, I find myself in violent agreement
with every point in the article.

For me, Scrum has always been nothing more than an “Agile Bootstrap”. The core
idea within it is very simple: try something and examine the results. Stick
with what works and try alternatives for what doesn’t. Repeat. And, above all,
_learn_.

So Scrum starts you off with a list of practices to get going with. The whole
litany of backlogs, story points, sprints, daily stand ups and retrospectives
is nothing more than a vocabulary - a pattern language for stakeholders. It’s
got pros and cons - a good way to bring people together but it needs to be
recognised as a crutch and ditched quickly before the team comes to treat it
as an article of faith to be defended at all costs.

And this is where so many agile coaches fail in my (limited) experience. When
I was undergoing scrum training, it was hugely disappointing to hear
colleagues asking questions of the trainer along the lines of “Can a scrum
master multi-task among teams like an anaesthetist in a hospital?”. Or “What
does Scrum advocate when a production incident requires someone in the team to
drop out and assist?”. Or “Can we have scrums of scrums?”.

The answer in _every_ case is the same: try something - anything. See how it
goes and decide whether to apply that approach again in future.

------
jackcosgrove
In my experience, people matter more than methodologies. If you have good
people on your team, product and dev, then you can make any methodology work.
If you have bad people, no methodology will work. Advocating for one
methodology or the other is far less important than hiring the right people.

That said I prefer Agile to Waterfall by a lot, and Agile developed in
reaction to Waterfall so I think it was a success.

~~~
tjl
It may be that Agile developed in reaction to Waterfall, but that just says to
me that the creators didn't look at all the other methodologies out there.

------
dimino
Scrum definitely sucks, but it sucks less than most of the other options.

Kind of like democracy.

If you don't like meetings, planning, or giving estimates, you probably don't
like working on software for a living, because I simply don't know how to
build software without meeting with other people, coming up with an idea, and
telling the people giving me money when I hope to be done.

------
neo2006
Both devs and managers are attracted to scrum for two different reasons: \-
devs like scrum because of the agility of it and the though that they will
have more control on how to evolve the product and the code base and have the
freedom to architect and develop the way they see it right. \- managers like
it because it gives them an oversight on how the team is performing and a
possibility to have a more accurate estimate the a rule of a thumb. In my
opinion scrum stop working when devs think that it's complete freedom and
control over the product and/or managers think it is a magical spell to
increase team productivity. Another reason that make scrum goes wrong is that
religious believe that every rule in scrum manifesto needs to be applied as is
so magic can happen, scrum is not a recipe but a guide that need to be adapted
to each team, organization and context. Trying to follow the rules religiously
will always fail.

------
vpeters25
> First of all, what are story points? Are they measures of time it takes to
> complete a story? If yes, then why are they not in terms of time? Are they
> measures of complexity?

Story points are a measure of "relative amounts of effort". A 2 point story is
twice as hard, as far as effort to implement it than a 1 point one.

> Scrum meetings (aka rituals) have been among the most miserable hours of my
> life...

Would you rather have many meetings almost every day, or a single big ol'
meeting every few weeks so you can focus on coding without interruptions?

> The review meeting causes utterly unnecessary anxiety (Oh my god, will my
> feature work?)

It should not cause anxiety because it MUST work. The review meeting is to
show stakeholders a "potentially shippable product increment". Everything you
show on the review meeting should have been extensively tested already.

> Why estimate stories that you are going to break down anyway?

You only break down stories if they are too big. You are not supposed to work
every detail on a planning meeting.

> but in Scrum, the retro is explicitly supposed to be about the Scrum process
> itself, not about the codebase

The retro is not about the scrum process but about how it is working for the
team. All these issues you have already complained about should be reserved
for this meeting where the whole team can decide which adjustments to make.

> The main goal of Scrum is to minimize risk and make sure the developers do
> not deviate from the plan. I will come back to "Scrum controlmania" later.

It is regretful that, like all the other "why scrum sucks" posts I've seen on
HN, it all boils down to a bad scrummaster not managing expectations and
taking the time to explain where the process really comes from.

~~~
JoeAltmaier
For some engineering tasks, the work and the planning are almost the same
thing. Once you've explored the problem, the code is the small part.

When asked to estimate, the answer is "I'll let you know when I'm getting into
it". Then you're made to do a 'spike', which is indistinguishable from doing
the task. Except do it in a day now. So the Engineer thrashes around trying to
figure it all out in a day, and comes up with some number. The planning phase
is now over, so they're supposed to just execute, regardless of what (bogus)
number they found. So they start. At the end of the sprint, they've done less
than if they'd just started the task the first day. They get 'measured' as a
low performer. Of course its the process that's performing badly, not the
Engineer. They get frustrated, resentful and stop cooperating with the scrum
master.

I've seen this so many times at so many places its just exhausting. No amount
of discussion can convince the evangelical Scrum experts that something is
wrong with the process.

~~~
vpeters25
In agile, the estimates should be decided by consensus of the whole team.
Requiring a single engineer to come up with an estimate is a smell.

Here is a quick 4 step planning meeting process based on planning poker:

1\. Pick story from backlog, explain in a couple minutes what do you think
would take to implement it.

2\. Team members pick an estimate of the effort.

3\. If there is consensus, note estimate on story, pick next, goto 1.

4\. If there is no consensus on estimate, have highest and lowest explain why
they picked their estimate, goto 2.

If you are expending more than 5 minutes on a story and there is no estimate,
push it down and move on. It's not ready for development. The whole planning
meeting should not take more than 1 hr.

This process, allows everybody involved in development to have an idea of the
overall project and chip in with their experience to impact estimates (this
might require refactoring class X, it might be hard to test, will conflict
with Y and Z, etc)

~~~
JoeAltmaier
And that's where the 'incremental tasks with no architecture' part comes in.
When the scheduler needs rewritten to support whatever robustness; when the
server feeds need to be redundant; maybe only 1 team member has any real idea
what it takes. Coding isn't always about putting up another web widget or
making another database entry.

~~~
vpeters25
That's the point: while there might be just 1 team member with a clear
understanding of the effort, everybody gets to pick an estimate based on their
own knowledge of the subject matter, even if they know nothing.

The exercise of just enumerating in a couple minutes all the steps to complete
such a story gives everybody, including the one who is going to do the job a
clear idea of the effort or whether they need more information before
proceeding.

Btw, while Scrum is great for software development, they are not ideal for
maintenance and/or infrastructure management where a defined process such as
waterfall might work better. Trouble tickets and bug fixes should be kept
outside the sprint unless they become stories.

~~~
JoeAltmaier
Again, for a simple story where everything is known, sure. But some stories
are all about figuring out _how_ and _what_. The actual doing may be simple.
The Scrum process fails.

------
mrharrison
I guess there are many way to use points, but what was described in this
article isn't the way we use them. Points are great for a group of people to
groom a story (estimate a features difficulty). Points are an estimate of
difficulty. The way we do it is we have a story that describes what feature
will be built, then as a group we talk about it and then all at the same time
(so we aren't persuaded by others) rate the story with points (level of
difficulty) and if we all (developers) rate it at the same points then we add
the points, if we have different opinions on the points (level of difficulty)
then we discuss why we think it's easier or harder. And this helps others who
wrote the story foresee issues or know of other simpler solutions. Works great
if you ask me, and that's how we were taught to do it.

------
koistya
"As any developer will tell you, software development is a marathon, not a
series of sprints."

I would argue with that.

------
geeklover
We use Kanban among our team. Our favourite tool is www.kanbanery.com It helps
us with our everyday work and lets us to track our progress. Before we started
working on a kanban board we always had a problem to kick off our huge
projects. Now, we cnvert plans & ideas into doable tasks, so you can easily
kick off your projece. We love working with Kanbanery because it has many
features that make our work easier, like: priority & estimation markers to
show how important and complex a particular task is. In case of bottlenecks,
instead of sending a long email with an explanation, use the blocker attribute
to let your team know what’s going on.

So all in all I still think that Scrum & Kanban can make your life easier.

------
je_bailey
The aha moment for my team which changed us from a mindset of dealing with
scrum to enjoying it was when we moved from aiming towards a number of story
points to complete towards committing to the stories that we could
individually complete in a sprint, without a concern for the associated story
points.

All of a sudden story points disassociated with time. They just became a
number. a combination of complexity and understanding.

A lesser, but still important shift, came with our changes to backlog
grooming. When part of that grooming included poker planning to estimate
points. This Spread that chore out, and our Sprint planning is now
approximately half an hour as the team goes down the prioritized list and
commits to stories.

~~~
Udik
Is each developer just working on as many stories as he can in a sprint,
picking from a prioritized list? Because otherwise, how do you estimate what
you can complete in a sprint? Don't you commit beforehand to deliver a certain
amount of stories? And doesn't that translate to a certain number of story
points?

~~~
je_bailey
We get the prioritized list, we review our other commitments in the upcoming
Sprint, and starting from the top of the list we go down and developers pick
which ones that they will work on. Since we've groomed these stories, we have
an idea of complexity and one or more developer may have already taken the
time to identify exactly what needs to be done.

We don't commit before hand to deliver a specific number of stories, or a
specific number of story points. That would never work. Rather we focus on
what individuals believe they can achieve. Our velocity has become pretty
consistent and our delivery of story points is close to 100%

------
mmattax
I managed a small team of engineers and synchronous daily standups just broke
down with remote teams and timezones.

It also just felt unproductive - it became something we did to feel like we
had "best practices" when in reality it was a waste of everyone's time.

I got the sense that everyone would essentially forget what they said/heard at
the end of the meeting (or was simply tuned out).

I ended up launching a tool to solve this problem:
([https://jell.com](https://jell.com)).

We're a lot happier showing a "todo list" with each other and still have a
place to write out the challenges/progress we're making - all while respecting
each others time.

~~~
douche
You don't need to be remote or across timezones for this to happen. I can't
help but feel that standups are a huge waste of time. If it is a thing that
really needs to be done, why not do it asynchronously in a slack channel when
you show up, rather than interrupting everybody and wasting a collective work-
day across the team every day in lost flow time, by doing it synchronously at
some always-inconvenient time?

------
_Codemonkeyism
State of our industry, being "fan" of something or "not a big fan" of
something.

You should not be a fan of a tool, but use the right tool for the job. If
Scrum is the right tool, use Scrum. If Kanban is the right tool, use Kanban.
If Six Sigma is the right tool, use Six Sigma. If waterfall is the right tool,
use waterfall.

Second, if you can't use a tool, don't use it (I've seen companies using Scrum
with excellent requirements engineering, rearchitecture/refactoring, headroom,
...)

------
user5994461
Been doing scrum forever. Even before it existed. And yet I never had to use
points, ever.

Scrum Meeting:

\- Follow the list of topics for today

... (may include)

... Show progress and new features

... Get feedback

... Discuss blocking points and resources needs

... Get update on supplier status (if buying/selling anything to 3rd parties)

\- Decide what are the priorities for this week

\- Schedule the meeting for the next week (send the list of topics you'll talk
about)

That's overly trivial. It mostly comes down to schedule a meeting every 1-2
week, show/say current status, repeat...

No need to call that scrum and put fancy names on it.

------
retbull
I've been noticing more and more that I code around the stories rather than
following the best practices from the beginning. When I am adding a DB
connection and we don't have liquibase or fliway in place I can't add it
because that is a ticket for next week and I need to get it done now. I write
code that sucks so that I don't break from my sprint and possibly work on
something else first.

~~~
douche
I struggle to believe that people follow a management practice that is broken
enough that it encourages doing things the wrong way and slavishly adhering to
a procedure. Wait, never mind... I just saw my Dilbert day calendar...

------
tecmobowlbo
I'm not sure I understand the first complaint; no where in the official guide
is the word "points" or "story points" mentioned. I've worked on at least 2
Scrum teams that didn't use story points. All the stories were broken down
until they were all of approximately the same effort and then we planned
sprints based on number of PBIs.

~~~
loopbit
I've almost always used story points and actually find them useful. As for the
author's complaint, for me the key is this:

> First of all, what are story points? Are they measures of time it takes to
> complete a story? If yes, then why are they not in terms of time?

I don't think I've ever read the official scrum guide, but ever since I
started using scrum (around 2004) the concept of story points was clear: They
were "perfect days", i.e. days where you don't have any distractions and
nothing goes wrong and everything works first try.

As a fairly experienced developer, I can easily estimate how many of those
perfect days will take me to do a task (at least if it's a technology I know).
When estimating, the whole team estimates all tasks until there's a consensus
(and you are right, ideally, all the stories should require similar effort).

After that, the "perfect day" thing is forgotten, the estimates have no unit
and the velocity starts playing it's role.

And here's exactly why I like points: The link between real days and points is
lost, it doesn't matter. All that matters is that you completed X points in a
specific sprint. Chances are that you'll complete X points in the next sprint.
Iterate through a few sprints and you'll have a pretty good idea of what will
be finished when.

------
hawleyal
It's a project management methodology, not a software development methodology.
Some of these gripes seem not to be accusations of the method but actually the
application by whatever organization.

------
Marazan
Interesting to see he thinks two weeks is the default sprint length.

I thought 1 week was the default and it certainly works for my team. The
various scrum meetings are short and snappy and have high value.

------
pbhowmic
What's the alternative? Give me a credible one and I will change my mind about
Scrums. It's not great but I need an alternative, one that is better enough to
abandon scrums.

------
yclept
I feel like there's a standard blog post that can be posted in response to
opinion pieces like this, and it would be titled "x is not a panacea".

------
obiefernandez
You'd love this [https://medium.com/modern-agile](https://medium.com/modern-
agile)

------
mattei
This is so spot on. Use the parts that work, modify to suit the teams needs.
I've seen this done to a massively productive and happy team.

------
davidrupp
Everything I Need To Know About Agile I Learned From Reading "Extreme
Programming Explained: Embrace Change, 2nd Edition (The XP Series)", by Kent
Beck and Cynthia Andres.

Oh, and from working side-by-side with the best practitioners in the business
at ThoughtWorks for three years. But the book is sufficient.

------
inanutshellus
Alright, I know this has already dropped off the front page, but I figured I
had something to offer to the conversation...

First, as background, I'm a software engineer, not a "scrum coach" or
anything, but I've been on a Scrum team for _nine years and nine months._ (I
know, right? Our first Scrum project was Nov 2006. The set of people has
fluctuated over the years but it's still a pretty tight ecosystem.) Just this
morning we were requested to make videos about our team(s) to explain why we
work so well, so this is pretty apropos.

Second, I really did read the article through and thought it was well thought-
out. Notably, I felt they came from a different mindset than mine, a different
workplace, and I _am_ a fan of Scrum, so here are my feedback points--I hope
they're considered positive, helpful and constructive:

 _TL;DR_ : I feel like the author is not empowered in his workplace. Time to
upgrade your scrum team mindset.

* Remember that a scrum team is self-organizing and self-managing. Specifically, I'm replying to: "The daily standup is in my opinion a manifestation of a significant but unspoken component of Scrum: Control" implies you don't know or don't practice this and is likely the actual source of your problems with Scrum.

* You mention disliking pointing stories because they never match up with the points on tasks. Points on stories are done because you haven't created tasks yet, so you can't use task hours to add up to a story, and you need to figure out relative complexity before you start.

* Getting points (RE: "I don't get the exact response that was expected, so no points for you.") - Here, the team decides whether it gets points, not a user in a review. That sounds weird, but so does a user saying "No points for you! (soup nazi voice)" in a review. Stick with me here: If you get feedback that says you need to do significant rework, it's clear there was a misunderstanding between your product owner and the business. Make a new backlog item, point it, prioritize it, move on. (If this happens more than once consider how far apart your vision is from your user and their vision of the project!)

* Demoability as a requirement in Scrum (specifically responding to "How can you demo that your code base has become more habitable?") - Business folk understand the value of "plumbing" (pipes in your house aren't visible, but they sure are handy when you want to take a poo). They don't like showing up to meetings to talk about plumbing, though, so either skip that meeting entirely or tell them what will be possible when said plumbing is complete. Point is, don't die on the hill of demoability just to say "See! Scrum sucks! I can't demo all this plumbing!"

* Meetings every two weeks - If they're painful, you're doing something wrong. If it's not ready, it doesn't go in the demo. Don't kill yourself for a demo. It may be a "sprint" but you're still _actually_ in a marathon, so just pace yourself well.

* You mentioned disconnected users. If you have bored users, get better about grouping the meeting. Split it into two meetings, if need be. We don't; we say "Hey, _finance folk_ , you'll want to pay attention the first 15 minutes of the meeting then you can go. You're welcome to stay, but you'll see app features that won't affect you"

* Daily Standup - For high-performing teams, the daily stand up is training wheels. Anything you learn in a daily standup should make you mad. ("Why did you wait til the daily stand up to tell me you [finished X|were blocked|needed this info|are ready for me to test]!"). Do them if you need to. If you do need them, ask yourself why. e.g. who isn't a communicator? Who would've blown you off were they not in this required meeting? Those guys are your blockade for more than just a daily scrum meeting.

* Sprint durations - You make it sound like you don't have a choice. Your team chooses the duration of the sprint.

* "I find the idea that you should get somewhere by sprinting repeatedly [and the rigidness of items in a sprint] rather weird." The rigidness is there to protect you from outside forces, not prevent your team from getting the job done. e.g. It's there to prevent the VP of Marketing from showing up and saying (psst, hey, could you add a blue link on the homepage?" .. "Oh, that link is wrong, make it into a popout." ... "oh, that popout should be a flash video" ... then suddenly you're missing your deadlines to the VP of Finance. It's there to give you a defense mechanism against folks above you trying to work-around their peers for your valuable time.

* "The Scrum coach will find fifty ways of attacking each and every one of these topics, but all of them will be in the form of one more thing. One more meeting, one more document, one more backlog, one more item in the definition of done. " I don't think so, man. It's all about taking the training wheels off, not adding brakes. Maybe you have people working against you. Working against being in a team. In order to protect you from them you're all being laden with extra BS. For us, every painful thing that slowed us down was cut. Blocades were fired. The world got good.

* "Every story in scrum has to end in customer value. [...] why even bother with refactoring?" The team can be a customer. "As a software engineer, I must refactor my [blah] to facilitate [blah]." No need to jump through artificial end-user-centric hoops. When/if you mention it outside the team, just hand-wave them and call it "plumbing." Everyone understands plumbing (as in, pipes in your house you can't see but appreciate every time you flush.) You still get points for work done, you still get value, you're still being a responsible engineer keeping their house clean.

* "What is the job of a software developer? Writing code? I don't think so. I think it's inventing and customizing machine-executable abstractions" Not to be trite, but I'd say the job of a software engineer is to offer solutions to business problems. Usually this is by way of "I've got a hammer so let me hit that hangnail for you", but really, that's all we are, is problem solvers... but... _shrug_

Re: Ideas for Alternatives:

* "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values." I'd love to see some practical examples of this. It sounds more complicated than the simple off-the-hip-shot estimates we get with points, but the idea has promise.

* "The other proposal I would have is to get rid of the review, planning and stand-up meetings." You should be doing these judiciously anyway, not dogmatically. Free yourself of the chains of dogma and just do these when they have value. The thing is that they ARE good training wheels. If you're not in a high-performing team and you skip straight to "just do it when you need it" then you never get into practice, you never get used to them, you ... never do them. They do have value, and you should do them when you can demonstrate value in them. So... Ascend when you're ready to.

------
carlsborg
It's a dev methodology not a religion :/

~~~
kps
Right; religion only makes you go to confession once a _week_.

------
mhale
The most important agile practice, imho, is far and away the Retrospective. A
good retrospective process will fix all other problems.

In the post, you sort of dismiss it out of hand because it is supposed to be a
discussion limited to scrum, but that is an arbitrary and self-imposed
restriction. You are doing it wrong. Remove that restriction and the doors
will open up.

The retrospective is about creating time for the team to review what works and
what doesn't about the software development process in general (no need to
limit to scrum).

I've seen retrospective discussions veer into company culture, the need for
faster hardware, testing processes, etc. Anything related to making the
software, the software development process, or the team better should be on
the table.

A good retrospective enables the team to use its sprints as experiments to try
different things, to evolve the practices to better fit the needs of the team
and organization. If stand-ups aren't working, go a sprint without them, or
doing them differently -- whatever change would address the weakness
identified by the team -- then in the next retrospective reflect on whether it
actually improved things. Rinse and repeat. Done properly, a good
retrospective will enable your team to evolve and get better and better with
every sprint.

Points can be frustratingly fuzzy, but they serve a valuable purpose. They
give a measure of team productivity (e.g. velocity), even if imperfect. Yes
points can be gamed, but a team should learn quickly that gaming only serves
to fool themselves. Because of they can be gamed, I'm not a fan of using
points as an externally visible "vanity metric". They should only be used or
shared within the team. They should not show up in performance reviews or
presentations to management. But points can be very useful as an internal
metric for the team to measure whether or not tweaks to the process made a
positive impact. You need some way to objectively measure the success or
failure of your process experiments.

Of course, any metrics used are themselves certainly deserving of scrutiny and
fine-tuning, as poor metrics lead to poor decisions. To me the benefit of
points (or t-shirt size estimates) over something like hours is that in
software development, hour-precision estimates give a false sense of accuracy.
It requires more effort to provide more precise estimates, yet they won't be
any more accurate (given the inherent non-repetitive nature of software
development). Thus, the use of a coarse-grained measure like points serves to
re-enforce the notion that the estimate are inherently imprecise and that we
don't want to waste effort on greater precision estimates.

All that said, whether or not to use points or any measure of team
productivity at all is a team decision. If the measure isn't serving the goal
of improving the software and the software dev process, then change it or get
rid of it. That's the beauty of the retrospective -- it explicitly encourages
this sort of process-hacking and fine-tuning.

Embrace the Retrospective!

------
landmark3
mandatory link to alternative: [http://programming-
motherfucker.com/](http://programming-motherfucker.com/)

------
clifanatic
I got my first programming job, while still in college (as part of a co-
op/internship program) in 1992, for the U.S. department of defense. As you can
imagine, everything was BDUF there. It was very frustrating and the most
annoying part was the massive disconnect between what the users expected,
which was that they could suggest a change and see it on their desktop an hour
later, and the reality of change and release management, regression testing,
unexpected side effects, code entropy, etc. etc. Some time around 1999, I
started to hear about "extreme programming" (XP), and when I looked into it, I
breathed a huge sigh of relief, because here were people whose opinions people
seemed to be paying attention to making the same observations that I was, but
far more eloquently than I ever could, in a way that seemed to be resonating
with users and project managers. I guess I'm too much of a "glass is half
full" type, though, because it didn't take too long before XP gave way to
"agile methodologies" which became "scrum" which is really BDUF with
micromanaging daily standups.

------
stevesun21
After I read this complain-based article, my only question for this author is
what's your fix/suggestion? Otherwise, I don't get what the point of this guy
write this article.

~~~
humanrebar
Describing drawbacks and problems is value added. Theoretical physicists
regularly know about problems for decades before solutions are found.
Precisely describing the problem can get the intelligent diaspora organized
around finding improvements to the situation.

~~~
stevesun21
Did you just compare a project management methodology with theoretical
physics? Sounds to me like you try to compare apple with orange. Sorry, I
don't follow you.

~~~
rimantas
He did just compare problem solving with problem solving. Sweeping problems
under the carpet does not get them solved.

