
Agile Scrum: Delivering Broken Software Since 1991  - peteretep
http://www.writemoretests.com/2011/09/agile-scrum-delivering-broken-software.html
======
api
My experience with Scrum is that it has a tendency, especially if implemented
"textbook" with absolutely no flexibility, to completely de-emphasize any kind
of architecture, forward thought, elegance, or big-picture thinking about the
code.

The result tends to be a giant snotball of hacks. In my personal experience
the biggest casualty is efficiency, followed by maintainability and
scalability.

The fact is that good programmers write good code, and bad programmers write
bad code. There is no management "methodology" that can make bad programmers
write good code. There are, however, methodologies that make good programmers
write bad code. Scrum at least _can_ be one of these.

~~~
Aloisius
The textbook way of running Scrum is to have a retrospective at the end of
every sprint where you find faults with the process and tunes it for your
specific environment. If you skip over that part or worse, refuse to adjust
the Scrum process because it breaks some rules, then You're Doing It Wrong.

~~~
bad_user
Ah, the standard excuse for failed Scrum implementations -- you're doing it
wrong.

~~~
rickmb
If a methodology is so simple that it only requires you to do a few things and
you're not doing those, than "you're doing it wrong" is not an excuse, it's an
objective fact.

Besides that, given that Scrum is such a lightweight methodology, it's pretty
hard to fail for competent programmers to fail using Scrum. Worst that can
happen is that they find Scrum isn't an improvement over whatever they were
doing before, which is cool. There's no one size fits all.

But failure is usually caused by other factors. The standard excuse for
failing projects is of course blaming the methodology... Ever notice that in
places where Scrum "fails" that is usually not exactly the first failure?

~~~
lucisferre
I disagree, Scrum's whole design and methodology (simple though it may be)
contains serious flaws. Things like iterations (are we releasing iterations or
features here?), as well as the poorly defined responsibilities of positions
like the product owner and scrum master. Also it fails to adequately define
how teams should confront the problems found in retrospective. Overall it
often leads to a stuck process for the many, many teams that struggle with
Scrum, and blaming everyone else for "doing it wrong" seems like a defensive
cop out.

Scrum is to the product management process as management games like "colors"
are to office team building and group psychology. Overly simplistic to the
point of being nearly meaningless. By itself I find it provides very little
real-world guidance for how teams should improve themselves and their process
at all.

Thoughtful Edit: Don't get me wrong, I think Scrum has an initial value, but
it is "meatless" for want of a better term. Anyone who really wants to improve
a process for a dysfunctional team dynamic is going to need more than just
some iterations and stories. Scrum is a starting point, but more often than
not I think it is little more than that. Blame the team if you want, but I'll
put at least some of the blame with the methodology not providing enough long
term guidance.

~~~
thematt
I don't think it's reasonable to expect the _process_ to define how a team
should confront the problems found in a retrospective. Those project and team
specific problems are likely to be unique and giving the team the framework to
choose the best course of action is likely to more effective than some
prescriptive process that says "If A then do B".

It also wasn't meant to provide guidance on how teams should improve
themselves, that's _up to the team_ to choose the best route to get there. It
excels at enabling the team to make those decisions for themselves.

------
dools
From my (limited) experience, scrum such as this is really geared towards
dealing with the interface between the technical team and a bureaucratic
environment in which they need to operate, although even on our small (2 - 3
man team depending on the project) we use elements of this methodology. It's
just that we don't have anyone to report to, per se.

So really I think this applies to larger software teams, or small software
teams (ie. 1 man technical departments) surrounded by non-technical people to
whom the development process is traditionally a frustratingly black box.

------
neilk
At least in my understanding of Agile/Scrum, there shouldn't be any cards
representing code quality. There are only features that make sense to both the
customer and the developer. The time to write tests and so on should be built
into cost estimation of the feature.

However, as 'api' says, this tends to result in a mucilaginous mess. There
really is a certain amount of work that you have to do on a project which is
just about the code itself. I haven't seen any Agile method capture that in
practice. A manager who listens to the developers will often suspend Agile in
order to get refactorings done.

~~~
daemin
I don't think there should ever be a scheduling item for 'code quality' (and
related activities) in any software development planning/management cycle. If
software developers want to be treated as proper engineers at some point in
time, we should start implementing quality as a default, not as an
afterthought.

Therefore it stands to reason that 'code quality' should always be baked in
when estimating software tasks, same goes for any other related and required
development activity.

------
rubenbos
Really interesting article.

I can imagine there are a lot of companies that don't sell Scrum right. For
example: teams are still ordered to fulfill a fixed scope in a fixed amount of
time. As a team you can't fight that. It's not the fault of the team.

But from your article I understand 'Low Quality Code' and 'technical debt' are
always the fault of Organizers. I don't agree on that.

A team estimates (led by their scrum master) how long they will be working on
a user story. It's their responsibility to take everything account that's
needed. They know how much time has to be spent to get the code right.

The Product Owner just gets the estimates from the sprint planning and knows
how far the team can get. The team said they could do a particular user story
in 5 points right? If that's 5 points with crap code as a result... well,
maybe it was a too optimistic estimate with no space for good code.

------
fauigerzigerk
What on earth does that have to do with Scrum? Pressure to make compromises on
code quality is about as universal an issue as you will ever find one.

~~~
narag
It seems a case of "bait and switch". You've been attracted to a methodology
as defined by experts, but get an _aproximation_ by some random PHB. The
result is similar to Mr. Bean trying to apply ninja techniques as seen on a
Steven Seagal movie.

Sadly, for many of us, it's the only Scrum that we've seen, so expect more
hate. Maybe it _is_ a problem with Scrum, after all. What good is a
methodology that gets so often misimplemented?

~~~
buff-a
_What good is a methodology that gets so often misimplemented?_

Scrum is simple. Its not misimplemented because its complicated. Its
misimplemented because organizations are fundamentally not good at developing
software. Scrum just puts it in your face. You don't even need to actually
write any software to know how and why you are failing. Just attempt to do
Scrum, and see what excuses you make to do not do any given part of it.

------
arctangent
Scrum is a great idea and I use elements of it to manage how I organise my
work. If I've blocked out a month to work on one piece of software then I will
sit down with the relevant team and we'll agree together a "prioritised
product backlog" consisting of a combination of new functionality and
bugfixes.

However, what Scrum doesn't seem to address is how to deal with the bureacracy
in a large organisation, especially where you don't have all the resources you
need to meet demand from different teams who want you to do work for them.

It's been a fairly exceptional month, but I've been forced to switch projects
3 times recently owing to differences in opinion (at board level) about which
piece of work is more important. This has obviously been less than ideal from
an engineering perspective and has left me with just a couple of weeks to
develop a fairly important web application.

I'm currently thinking about how I could extend the Scrum model to account for
multiple projects but I'd appreciate any insights people here on HN have to
offer...

~~~
DanielBMarkham
Work 100% on one thing at a time and decrease your cycle time (length of
sprint) to allow for rapid shifts.

If you have to go to a 3-day cycle time -- as long as you are 100% dedicated
-- do that.

This, of course, assumes you've understood the agile/scrum concepts enough
that you can scale them down to a few minutes each. If you're still having
30-minute standups and 4-hour sprint planning sessions, my advice is not going
to work.

Here's the thing: no matter how stressed out and context-switching the work
environment is, you can only work on one thing. So can you predict what you
are going to deliver and then deliver it? If you can't -- if you can't even
predict day-to-day what you are going to do -- then you're well and truly
hosed. Scrum or agile isn't going to fix that. (BTW, there's another answer if
you are truly in an environment without any structure at all. In that case,
I'd look seriously at some lightweight kanban)

------
buff-a
_Some people say that this should never happen – once the Sprint is planned,
it’s sacred, and that any changes to it need full team buy-in – any
significant number of changes need a complete replan of the Sprint. I’ve not
seen this so far in practice, but it sounds intriguing._

 _Some people_ being, in this case, the people who defined Scrum. If you allow
a product owner to walk in and add stories to a sprint, and the team does not
have the choice to "reset the sprint", then You Are Not Doing Scrum.

 _The Organizers are rarely empowered to change any of those thing, so they
change the one thing they can, but shouldn’t: the build quality._

Again, if the Organizers are not empowered to change scope, deadline, etc,
then They Are Not Doing Scrum.

So Agile Scrum doesn't deliver broken software. Fairy tale fantasists who
believe they can ignore the central tenets of any process and get the results
deliver broken software. Essentially: "People unable to implement a simple
algorithm deliver broken software".

------
rpwilcox
This is why I don't think the product owner should have the sole power over
the backlog.

In addition to business stories that need to be meant there are at _least_ two
other areas whose stories are as important: development and testing. Maybe ops
too, depending on your structure.

With a product owner that doesn't listen to any area beyond business, _of
course_ stories from those other two departments are discardable crap. There
needs to be conversation from the departments involved. Sure, if priorities
change in mid-sprint that's one thing, but there are other voices that need to
be heard beyond business, when planning the story selection.

Likewise, sole product owners might think, "Oh, if we have these programmers
work 16 hour days, instead of 8 hour days, we can get twice as much work done,
and make the deadline!". Again, other voices (voices of reason) need to be
heard in this situation too.

------
lojack
I agree that this problem exists, but I also feel that there is a better
solution than whats listed. Stories should be given points for their
complexity and not for the time it takes. Additionally stories should only be
business oriented, so things like automated testing don't get their own
stories.

Since automated testing does take time your team velocity is what's affected,
and no one has control over team velocity once a sprint has started. Quality
issues that recur affect the calculated velocity and one off quality things
(like setting up continuous integration) should add a buffer to the velocity.
This should be discussed in sprint planning so transparency is maintained.

------
alexkearns
Even if scrum works perfectly, it does not empower developers. In fact, from
what I can see, the whole purpose of scrum is to disempower developers while
giving them the illusion they are empowered.

As the author reveals, under scrum, it is not the developers who decide what
new features to add to the software. It is the product owners.

Who decides the priority of the new features under scrum? Not the developers
but the product owners.

At least under waterfall, developers could get their teeth into a good chunk
of interesting work. They could come up with some fancy architecture or
something. But under scrum, all work is broken up into bite-sized chunks of
work that are rarely challenging and often highly repetitive.

Under scrum, the developer's time and ingenuity are not valued. If a product
owner out of the blue decides to ditch a new feature or radically change one,
wasting the work a developer has done creating it, he does so without a
moment's concern about the developer's wasted time and effort.

In short all that scrum offers developers is a small amount of control over
their workload. Compare that with developers of the past, who would conceive
software and build it themselves the way they wanted, and you can see that,
far from empowering developers, scrum has reduced them to little more than
assembly line robots, at the beck and call of their masters.

I am not saying that we should go back to the past when developers were in
charge or everything but to say that scrum empowers developers when it clearly
does not needs to be challenged.

~~~
bobbles
This is the exact opposite of what SCRUM hopes to achieve. If a product owner
decides to bin a feature, it's because it has been weighed against the options
available and decided that this feature is no longer valuable to the company.

'Wasting' the developer time as you have stated it is a misnomer, as I would
say developing a product you _know_ wont be used by a customer is wasting
time.

Within SCRUM, a developer should have full control of how software is
developed, if a product owner is trying to dictate the way in which a product
is developed, they are stepping too far and the ScrumMaster needs to get them
to back off.

The way for a product owner to determine how a product is developed is to have
a clear set of requirements in place that are testable and achieveable.

~~~
alexkearns
Everything you say seems to back up my point about scrum not empowering
developers.

"If a product owner decides to bin a feature, it's because it has been weighed
against the options available and decided that this feature is no longer
valuable to the company."

And therefore the sweat a developer has put into creating this feature is not
valued. Scrum pretty much ensures that developers will at some point create
stuff that will never see the light of day. Hardly empowering.

"'Wasting' the developer time as you have stated it is a misnomer, as I would
say developing a product you know wont be used by a customer is wasting time."

I would not necessarily disagree with you but it is hardly empowering for a
developer.

Scrum is designed to empower the business, not the developer.

~~~
kstenerud
That is definitely a possibility, but not the common practice.

Most often, a feature is binned BEFORE any development occurs. In fact, I've
only ever seen a feature binned after development started once. It was a
feature that we decided was being introduced too early, required too much re-
architecting, and wouldn't offer any compelling benefits to our customers. And
it saved a LOT of effort and pain to cut the rope early.

Binning work in progress is not a good thing, of course. It's actually a
failure on the part of the manager. But just as you expect to be forgiven your
failures, so too must you forgive others.

> Scrum is designed to empower the business, not the developer.

Scrum is designed to help you as a COMPANY develop a better process for
getting things done with minimal headaches. If as a developer you're opposed
to the company and its direction, why are you even working there?

It's a question of priorities. Are you working to make a good customer
experience or are you working to stroke your own ego? If you're not customer
focused, you shouldn't be writing software for other people.

~~~
alexkearns
My point is not over whether Scrum delivers better software than other methods
(in my experience, it delivers average software consistently, which may be a
good or bad thing depending on your point of view).

My interest is in how the role of the developer has changed over the years,
and how developers have been increasingly stripped of power over what they do.
I believe Scrum is simply the latest step in this direction.

Now, it may be that stripping developers of power is the best way to create
good software (we've all seen the god awful usability of some developer-
created software). But let's not pretend that this is empowering for the
developer, as the author suggests Scrum is.

"Most often, a feature is binned BEFORE any development occurs. In fact, I've
only ever seen a feature binned after development started once. It was a
feature that we decided was being introduced too early, required too much re-
architecting, and wouldn't offer any compelling benefits to our customers. And
it saved a LOT of effort and pain to cut the rope early."

But isn't Agile (of which scrum is part) partly about putting a product out
there and seeing how users or customers respond. There is a built in
acceptance that some new features are not going to work but you never know
until they have been tested out by the end users.

"It's a question of priorities. Are you working to make a good customer
experience or are you working to stroke your own ego? If you're not customer
focused, you shouldn't be writing software for other people."

That is kind of my point. Developers don't get the chance to write software
for other people. They don't have any say how the software actually works, by
which I mean the user journeys, the feature set etc because they have been
reduced to simply turning the fickle ideas of product owners into a reality.

I now work on my own products because that is the only way I can turn my own
ideas for user-centric software into a reality.

~~~
kstenerud
> Now, it may be that stripping developers of power is the best way to create
> good software (we've all seen the god awful usability of some developer-
> created software). But let's not pretend that this is empowering for the
> developer, as the author suggests Scrum is.

That depends on what you mean by "empowering". Do you mean it in the sense
that the developer has the final say on what a program does (i.e. feature
set)? Do you mean that the developer has the final say on how it is
implemented (i.e. architecture)? I would argue that the developer should NOT
have the final say on what a product does, but SHOULD have the final say in
how it does it. Product designers decide WHAT it does and how it should look
to the customer. The developer's job is to turn that product design into a
reality using intimate knowledge of technologies and architectures, and
alerting designers to the reality of what developing according to their design
involves (time + effort), and coming to a compromise if it's too heavy.

> But isn't Agile (of which scrum is part) partly about putting a product out
> there and seeing how users or customers respond. There is a built in
> acceptance that some new features are not going to work but you never know
> until they have been tested out by the end users.

Absolutely. If you build something and it doesn't work for your customers,
throw it out. If you can't handle that, you're ego focused, not customer
focused.

> That is kind of my point. Developers don't get the chance to write software
> for other people. They don't have any say how the software actually works,
> by which I mean the user journeys, the feature set etc because they have
> been reduced to simply turning the fickle ideas of product owners into a
> reality.

It seems to me that you want to be the product designer AND engineer. That's
fine since you have the abilities of both, but that's not the common case. The
ability to write code does not magically confer the ability to design good
products.

And even then, scrum will help you because you can track the morphing of your
designs into concrete products, do the estimation, prioritization, feature
cutting, tracking, and do all the throwing out and redesigning of your own
stuff as customers respond positively or negatively to your product
refinements. And then at the end of it all you can decide how well the process
is working in a retrospective, and refine it to work better for you. Scrum is
a meta-process; It helps you BUILD a process that works for you, and provides
a convenient starting point that works fairly well in general.

------
Zimahl
I've done a fair amount of Scrum and have seen it succeed and fail. Scrum
works and is great, but like most tools it works only for specific types of
jobs.

I wouldn't use Scrum in a situation where the final product is somewhat
defined and is expected at a certain date. Any situation where you ask
yourself 'why aren't we using waterfall here?' is one where Scrum will
inevitably fail.

Scrum is typically great for startups (and sometimes established companies)
that are building something that is more of an idea than a product and time is
irrelevant due to being able to push new features out later if they aren't
done. It helps if your customer doesn't expect polish and is fine with
incremental improvements.

To use the Minecraft analogy, Scrum would be a great process for Mojang. The
target is moving, the features the developers thought were significant
yesterday have found to be of no concern to the users, and thus they can drop
something and focus a new feature. The next version has what's done, not
necessarily what was expected. Waterfall wouldn't work in this situation at
all.

------
jroseattle
From my own experience, where Scrum has broken down is the promise of, after
the sprint, you have something you can "release".

Of course, the term "release" can mean many things to many people. If you're
building something substantial, an initial sprint or two may be dedicated to
simply getting some overall framework in place. It just depends on what you
call "release".

In the cases where I've seen failure, "release" could mean only one thing -- a
shipping product outside the organization to customers. In spite of
declarations from the dev team that no product going to customers would be
delivered. And, at the end of a sprint, with no product prepared to go to
customers, product management decided scrum was a failure. I'm not making this
up.

------
TheCapn
Not sure why, but the site is blocked at my work. Can I get a pastebin of the
content or something similar please?

------
MostAwesomeDude
This just makes me feel like scrum isn't worthwhile. Here's how my work flow
goes, as a developer: There's an issue tracker. A handful of issues are
assigned to me. I know, by memory, which issue's important, because it's
always the one people are yelling about the most. I write the code for the
issue, test, commit, get feedback, close the issue. Done.

I could not remember all of this terminology. Stories? Sprints? Clearly this
is something above and beyond what I ever do. How do people do it? Does it
really deliver on its promises?

~~~
peteretep
Author here...

I once started a contract at a company where I was working with a permie on
this hugely popular site running off the God-awful blogging software.
Everything was a fire that had to be put out RIGHT NOW. And there were two of
us.

Coworker had earned himself a reputation for being unhelpful and unproductive.
This was partly because he had sociopathically bad communication skills and
hated people, but he actually worked hard, and productively. But everyone
thought he was lazy and didn't get shit done.

Essentially his workflow was: work on a task. Someone comes and says "DROP
EVERYTHING, YOU NEED TO ADD A WIDGET TO THE BLOG NOW". So he would start on
that, and 3 hours later, someone would come to him and say DROP EVERYTHING.
And three weeks later, he'd struggle to explain why he hadn't done much of it.

So we (well, I) split the work in to Stories. We estimated them, and stuck
them up on the wall behind us. We found someone who was meant to be the
Product Owner. Whenever anyone came to ask us anything, I'd intercept them
from talking to the coworker, ask them for details on the task, estimate it,
and put all this on a card. I'd then call over the Product Owner, and with the
Requestor, we'd put it on the Story Board.

Suddenly items weren't /that/ important any more. With the opportunity cost
suddenly marked out, many things found themselves inserted far below the
current task being worked on. We'd burn down time against each task. We could
tell you where we'd spent our time, and also, we could tell you what we'd
_achieved_ recently.

Essentially then, with a very small amount of overhead (like learning these
terms ;-)) we suddenly had a system for prioritization and accountability. I
did very little programming in the six weeks I was there - the productivity
gains we saw - both real and perceived - made it look like there were 5 of me
working fulltime.

~~~
daemin
In this case it seems to be a tool forthe developers to manage the
expectations of the 'other' non-development side of the business.

------
shareme
Scrum is for those firms who do not want to hire a real product manager and
empower one after they are hired.

~~~
kreilly
Care to elaborate?

