
Why I'm done with Scrum - hkarthik
http://lostechies.com/jimmybogard/2012/09/12/why-im-done-with-scrum/
======
fingerprinter
When I took over development of a extremely dysfunctional engeering team at an
established startup with 100 people, the first thing I did (after watching for
a bit to learn) was put in scrum. It worked. And it worked really, really
well.

2 years later, it didn't work anymore. The team had matured, the organization
itself had adapted to the leaner processes and mindset and, in time, the
actual scrum process was too much. It was time to change again...

And that is something I think most agile advocates don't realize. Agile should
be viewed as an organizational tool that has prescripted and prescribed rules
that work in general, but maybe don't work in the specific. It is great if you
need something forceful with books or documentation in the beginning, but in
time, the organization should mature to the point where agile/scrum/whatever
is actually too much.

One last thought. I highly recommend people look at agile for the times when
you need a drop in process....but there is absolutely no subsitute for hiring
quality people capable of making good decisions. Agile will get more out of
bad developers, IMO, but having nothing and good developers you trust is
always going to be more productive.

~~~
shaunxcode
Agile should also be subject to Agile. I like to think of it in terms of the
Viable System Model in which the system has the potential to change itself
based upon feedback. Put another way - make sure your implementation of
Agile/Scrum supports tail call optimization and macro expansion or face the
reality of being stuck in BlubScrum.

~~~
gutnor
Agile is a toolbox of best practices and tricks. You need to use the ones that
make sense. That is formalised in methodologies like SCRUM by doing a
retrospective after each sprint.

For inexperimented teams, it is a good idea to start with out-of-the-box scrum
and remove/replace bits that are not working out for team after a while.

For experimented teams, you just start with just a daily scrum end of day and
add bits as you go along. (effectively start with 1 day iteration)

------
martincmartin
I've done a bunch of reading about Scrum. If you read between the lines, you
realize that Scrum was created and popularized by consultants who go into
dysfunctional teams/organizations, and tries to fix the worse problems. For
example, the idea of a sprint is for a team to be able to work for at least a
couple weeks on a single thing, without people being asked to work on other
"small" projects, or without the entire direction of development changing
every week.

Once the team is functioning well, you can usefully relax a lot of the aspects
of Scrum.

~~~
gaius
Scrum is by and for management, not developers. Want your devs in at 9am? No
problem, hold the standup then. Want to easily replace your dev team with an
outsourced one? No problem, a Scrum team is a black box as far as the rest of
the organization is concerned, one with a well-documented interface. Etc, etc.

Ir's insidious because it tricks devs into thinking it's for them.

~~~
javajosh
What does management want anyway? Do they _want_ a black box with a well
defined interface? What other options do they get?

It seems to me that this question depends very much on the kinds of
commitments management is making. Which in turn depends on whom they are
making them to. If it's to a customer that has some hard requirements,
enumerated in a contract, and providing those is the source of money, then
management's focus is (and should be) executing those requirements. Which
would seem to imply that a black box is just fine.

The problem is not the desire for a black box approach, but that boxes fail.
Management is risk averse (and their risk aversion is what keeps your paycheck
coming, in theory).

(Actually, black boxes are creeping into software development all of the time.
For example, there's no reason to not have fast PSD-to-HTML turn-around
anymore. That process has been black-boxed. Not shrink-wrapped, but black-
boxed. Yes, there are still quality variations, questionable use of excessive
markup, etc, but its not bad.)

Anyway, I just question your tacit assumption that management wanting a black
box with a well defined interface is a bad thing. It seems like a reasonable
goal.

~~~
gaius
It's not healthy for the organization as a whole if the only point of contact
between "the business" and the developers is enshrined in the Product Owner.
It is however very amenable to empire building and short-term cost savings,
both of which are examples of a manager favouring their own interests over
that of the organization. In short, Scrum is most useful for those for whom a
dysfunctional organization is their goal. That the turkeys (devs) are voting
for Christmas themselves is the icing on the cake.

------
debacle
> With Scrum, there is an explicit commitment ... on what stories are going to
> be delivered within the sprint,

No, there isn't. You adhere to your burn-down, not to your feature set. Scrum
is _time_ driven, not _task_ driven. The whole idea is to become better at
estimation so that Scrum appears task driven, when really it's just because
your team is that good at estimating.

> Iteration planning meetings are seriously expensive.

Then you're _doing it wrong_ (god, I feel awful for saying that). If you're
spending that much time in pre-sprint planning, people aren't bringing enough
to the table and you're not defining your problems well enough before trying
to solve them.

> I hate the term “scrum-but”.

Ironic that that sounds like exactly what the environment you were working in
sounds like.

> This might be a bit controversial, but the big difference between Scrum and
> things like Lean Software Development for me were the difference of focusing
> on process versus delivery.

I think this is a "forest for the trees" issue. Scrum is about abstracting the
process into a rigid and lightweight framework so you only have to think about
it, at most, fifteen minutes a day (unless you have the misfortune of being
the Scrum master/cat wrangler)

> It can’t, and it’s not a problem with your organization if it doesn’t. It’s
> a problem with Scrum.

That's a non-sequitur. It's a problem with neither. If my company can't
implement a waterfall methodology because our clients require faster
iteration, that doesn't mean there's a problem with either - it's just not a
good fit.

But if your company tries to implement Scrum and throws it out six weeks or
six months later because it's "too hard" or "bad," my assumption is that real
Scrum probably wasn't happening.

Will Scrum work for everyone? Fuck no. Scrum is _hard_. It requires the kind
of buy in that, if you've got it, you probably don't need Scrum anyway.

Can Scrum work for everyone? Probably. Scrum is only hard when you've got
conflicting goals. If you have a smart enough team, you can tweak your sprint
lengths from as little as a few days to as long as six to eight weeks, and
after you've been on Scrum for a few sprints your planning meetings should
take an hour or two, tops.

~~~
sethg
In my experience (six months at a job that does Scrum and, I think, does it
very well), the thing that slows down iteration planning meetings is when the
product manager hands down a one-sentence feature description, the engineers
say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-
minute discussion in order to expand that one sentence into something
resembling a spec.

~~~
debacle
If the project manager throws out a feature description like that, just say
"Yes" and throw it to the bottom of the backlog - it'll be revisited when it's
well defined.

~~~
anthonyb
No - because you're not the business owner and don't decide what order things
go in the backlog.

A better way is to just give a sufficiently large estimate: "That's 100
points* due to risk and uncertainty." If they want a more detailed estimate,
then they have to give a more detailed story.

* - whatever will give you 6 +/- 3 months

~~~
tetha
This is one of the best things an older programmer has taught me. If people
want estimations on vague things, give them 8 month full team full time.
Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month.
Move the office furniture around? 8 month. People talking to you learn quickly
to give out more precise specifications.

~~~
anthonyb
I should point out that just throwing out a 100 point story over nothing is a
bad plan career-wise - you definitely need to be able to back it up with
reasons (we need to interface with systems x, y and z, this is comparable to
other system w which took 8 months, we don't have any spec for doing a, b or
c).

In that sense the 100 point estimate is a real one - a "small" feature (eg.
add a form to your web site) might be two or three weeks of work.

------
tosh
The problem with SCRUM is that it is not agile. That's why we see most of the
pragmatic companies adopting a kanban or scrumban approach and they see good
results.

I would argue that just having a kanban board during stand-up meetings and
"walking the board" instead of interrogation-like status reporting is going to
do wonders to team collaboration atmosphere, morale and actual productivity.

You start to see and talk about the flow of value, what's next, what's in the
moment ("what can we do right now?). You see context. All of that is missing
with SCRUM or only possible with a highly motivated and responsible team that
communicates a lot automatically.

I'm not yet saying that kanban is solving the software crisis [1] but it
turned around quite a few teams that I've seen and been part of.

DISCLAIMER: I'm working on <https://www.blossom.io> which is a lightweight
kanban board.

1: <http://en.wikipedia.org/wiki/Software_crisis>

~~~
manmal
Can you elaborate on why Scrum is not agile? You are the first I read claiming
this.

~~~
tosh
Great question.

I might have a harsh tone in my previous comment but I've got really
frustrated with scrum (or implementations of it) over the last few years.

Scrum in my eyes is a process and from what I've seen it makes teams very
process oriented. The whole idea of scrum master certification and the success
it had in enterprise adoption might have something to do with that.

It incentivises teams (at least all the teams I've seen) to work _for_ the
process as good as possible. They focus on complying to the process, getting
estimates right (or working in a way that makes the estimates right), they
focus on the backlog instead of throughput or frequent re-prioritization …

If you can free yourself from viewing the 'process' as fundamental religion
it's easier to apply agile & lean principles like focusing on delivering value
and improving the framework, changing things, changing the process so it fits
your needs, etc.

In a nutshell: I see scrum incentivising people to work in a way that is not
agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process
itself (at least I see no one doing that, except teams that adopt kanban and
scrumban or do scrum but …).

But I'm interested in learning from people who've made other experiences. It's
an exciting topic.

~~~
vannevar
_I see no feedback loop for the process itself..._

If a team fails to deliver the functionality they committed to, there are
consequences. Before the next sprint starts, they figure out what went wrong
and incorporate that knowledge going forward. That's feedback on the process.
And whether they have a green sprint or a red one, their velocity on the
sprint is measured and used to project forward. Again, that's feedback on the
process. Then there is a actually a dedicated retrospective phase at the
sprint review where the team gives specific feedback on how the process went.
The whole point of having sprints is to _ensure_ that there's frequent
feedback on the team's performance, distinct from any feedback they get on the
product itself.

------
leothekim
The author is right that, with scrum you end up focusing more on process and
not delivery.

There are nice things about scrum, but I think scrum followers are too
doctrinaire. It has some well-defined practices and is associated with that
agile "manifesto" that you are compelled to buy into if you adopt scrum. Being
doctrinaire about anything is guaranteed to distance you from reality - you
give project managers a weapon to coerce you into worrying about how to break
down your work into a velocity and stories and tasks. Any time you enforce a
process like that, you are disengaging yourself from the reality of having to
ship something.

~~~
vannevar
Scrum is focused almost exclusively on delivery. Every sprint, you should be
delivering working features. It's not that hard: every sprint, you commit to a
set of stories to finish before the next sprint. Every day you meet briefly to
tell everyone how you're progressing and to air out any impediments. That's
about it. To me, scrum is stripping process down to the bare minimum you need
to be effective.

~~~
barrkel
And it's fantastic when you're on a tight schedule! Instead of running fast
all the time, you just sprint, then sprint, then sprint, etc! Works like
magic. No one burns out at all.

~~~
MartinCron
I don't know if you meant that in a sarcastic way, but this does touch on a
pet peeve of mine with Scrum, the word "sprint" is, by definition, not a
sustainable pace.

~~~
anthonyb
So call it something else, like "an iteration".

------
vannevar
FTA: _Scrum forces iterations, forces feedback, forces smaller iterations.
These are all good things, which I loved about Scrum._

And yet the author spends most of the article denying that these aspects of
scrum are useful at all. Planning sessions are "highly inefficient," a "quick
meeting between the architect and the developer" is better. What if someone
else has an important piece of information that the dev and the architect
don't? Maybe another dev on the team has done something similar in the past,
and could have warned that the estimate was low? He won't be in that meeting,
to avoid being "bored to tears" with a story he isn't working on.

 _So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy,
then it will work for you._

Obviously, if something is hard, there can't be any possible benefit to it.
It's so much easier to get rid of all that process stuff and just churn out
code as fast as you can. What could possibly go wrong?

~~~
gutnor
The author has a point. Scrum is costly. Obviously it is more productive to
silo specific knowledge to specific people, generally the expert (or more
motivated) in that field.

At least it is in the beginning. People leave, experts become expert teams,
silos widen and it soon become the good old planning nightmare we have all
learned to "love" in enterprise development.

~~~
adrianhoward
_The author has a point. Scrum is costly._

I would prefer Scrum _can_ be costly... it will also remain costly if people
don't actually do the inspect and adapt bits of scrum and aim to improve the
process.

I say this as somebody who is actually not a huge fan of Scrum :-)

 _Obviously it is more productive to silo specific knowledge to specific
people, generally the expert (or more motivated) in that field._

Actually - I often find that isn't true. If you silo knowledge then those
people become bottlenecks in the process. Since their the _only_ people
everything has to flow through them that relates to that topic.

For example I find that teams improve if the "UX Expert" switches from being
the person who does all of the UX work, to being the person who facilitates UX
work among the whole team.

That way the easy stuff gets done by the whole team, and the UX person is
freed up to focus on the tricky stuff and stops being a bottleneck for general
progress on the UX front.

------
at-fates-hands
> Iteration planning meetings are seriously expensive.

I completely agree on this one. I've worked in several corporate environments
utilizing Srum and the planning meetings were always a huge waste of time. I
would rather light my hair on fire than sit around a bunch of PM's trying to
figure out what features to include/exclude.

Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does
Scrum/Agile right anyways." Which made me wonder if there is indeed a right
and wrong way to do these.

~~~
jt2190
In my experience most teams do planning completely wrong. The goals of the
planning meeting are simply:

    
    
      1. Do a relative-size estimate the top n stories in the backlog. (Where n is 
        some number slightly larger than the number of stories that usually fit
        in an iteration.)
      2. Pick the stories to complete in the iteration.
    

That's it.

I often see teams:

    
    
      * doing one-by-one story estimation, and debating over how many points to assign.
        (The statistical method completely fails when it's done this way.)
      * getting into long discussions over the spec. (That's between the dev
        and product owner, to be figured out during the iteration.)
      * worrying too much about accurate estimates
      * worrying too much about how much work to take on

~~~
smhinsey
I think the reason this happens is because no matter what people say, the idea
that if you can't finish a story within a sprint it will simply slide into the
next one is anathema.

People spend more time on estimation when the consequences of mistakes are
higher. If you can't realize that a story is larger than you thought and
reprioritize mid-sprint without it being equivalent to missing a deadline in
your old model, it's not going to work. In my experience this is the key
failure mode of scrum.

~~~
michaelfdeberry
I agree, but I think some of the pressure for accurate estimates come from
managers wanting to track employee time.

I had a manager that would pretty much go through the board and ask who did
what card so he compare the estimates to the actual time.

------
michaelt

      Iteration planning meetings are seriously expensive.
      Group discussion around design, group estimation, group 
      acceptance, all highly inefficient. [...] I remember just 
      getting bored to tears listening to discussions around 
      stories I wasn’t developing on to begin with.
    

That's quite team size dependent. In a scrum team with 4 people this isn't a
problem - but when the team's twice as large it doubles both the amount of
work to plan and the hourly cost to assemble the entire team, quadrupling
planning costs.

If a team is structured in such a way that a developer knows they won't be
working on a story, that seems like a logical line for splitting into two
scrum teams.

------
vpeters25
Every time I come across "why scrum sucks" articles like these I can quickly
point the problem: the ScrumMaster.

#1 - Iterations are less efficient than pull-based approaches: A good
ScrumMaster keeps an eye on the burndown chart and negotiates with the
stakeholders and team to either add or remove tasks from a sprint. My first
sprint ever as ScrumMaster, we estimated a 3 months project, we did everything
in 2 sprints (1 month)

#2 – Iteration planning meetings were wasteful: You are doing them wrong. A
good scrum master keeps everybody focus on one user story at a time and keeps
the meeting moving. I use a 3 min stopwatch in my phone. The whole meeting
should not take more than 1 hr (I do 30-45 mins estimate new stories, the rest
to plan and commit team to next sprint)

#3 – Scrum is highly disruptive in established organizations: A good scrum
master servers as a bridge between traditional management and keeps them out
of the team's backs. This one is the reason I don't like being ScrumMaster
anymore. A good ScrumMaster needs great people skills, I rather write code.

~~~
erichocean
So scrum has a single-point-of-failure that organizations, more often than
not, see high failure rates with?

And we're still recommending companies adopt this, when the failure rates are
both known to be high, and catastrophic when they occur?

~~~
vannevar
Companies still do project management, and the project manager is a single
point of failure. The reason the failure rate is high is that scrum is
relatively new and companies still think they can get away without having a
scrum master, while they know from long experience that they need good project
managers.

------
cocojumbo123
Actually what the author describes is a natural path of evolution for that
team. Scrum (as a process) contains the possibility of changing the scrum
rules themselves - although it is strongly recommended one does that only
after they get experienced (e.g. they actually manage to get shippable product
each iteration).

When the focus is on the process itself and not on delivery there is something
rotten in Amsterdam.

Scrum can be a micro-manager's dream (think of the visibility on who is doing
what at almost hourly level) - case in which one can end up with focus on the
process not on result.

------
mmanfrin
Minor counterpoint to the bit about meetings being boring: As a QA person, it
is incredibly valuable to us to all be together so we can discuss things with
the devs that are otherwise getting overlooked in bugtracking software or even
in our chat. It makes it so that those orphaned problems can find a home.

But our meetings are short. 5 or 10 minutes max. If you're getting bored than,
to quote another commenter here, _you're doing it wrong_. Quick summaries,
major problems, then get out the door.

------
base698
You haven't really jumped the shark with scrum until you have in place a scrum
of scrums, and a scrum of scrum of scrums taking up half the day for all the
key players.

------
dpham
I work at Webs and we also recently abandoned scrum for a more kanban
approach. While all points in the article resonated with our company, the
biggest problem we had was not delivering projects on time.

We focused too much on fitting as much work into a sprint as possible for
maximized throughput. The problem with that, especially when you have alot of
projects going on at the same time, is that alot of work was being burned
across the board, but the needle for each individual projects didn't move
forward fast enough and we ended up missing deadlines.

Another problem with scrum is that it turns creative developers into code
monkeys, and this in turn lowers code quality. Developers are constantly
worried about trying to meet deadlines for the next two weeks rather than
taking the time to do things correctly. This ultimately creates technical
debts and hurts the team in the end.

(also, if you're a manager and you use the developer points burned in order to
rate performance and distribute bonus, then fuck you)

~~~
pherk
I very much agree with the last point. Objective evaluation of a developer is
much more than burned down points.

I worked at Amazon and could see evidently that Scrum was turning good
developers into mediocre ones. But not many raised a finger against it as
Scrum was seen as the norm. And there was no scientific way to establish this
fact.

------
ajsharp
In my experience, Scrum / Agile / XP tend to be more about the process than
the results. I find these methodologies to be particularly useful for
contractors and consultants, primarily because the value proposition for a
consultant is much different than it is for an employee.

A consultant comes in and typically some sort of statement of work or master
services agreement is agreed to by both parties, which outlines roughly the
work that will be performed over the course of the engagement. Once work
begins, some Agile hoops will be jumped through (storyboarding, etc) in order
to further establish and agree upon the work that will be performed. This way,
at the end of the engagement, when the consultant has been paid for 3/6/9
months of work, they can point back to what was agreed upon each step of the
way and say, "See, we're delivering what was agreed upon way back when."

Employees at most software companies, and certainly at early-staging
companies, don't work like this, nor should they. As a product engineer, your
job is, in a nutshell, to figure out through software how to make the business
work. There might be a high-level strategy laid out for you, there might not
be. Either way, you're engaged in an inherently creative activity in order to
devise and implement a solution to make users happy, and hopefully make money.
Whether or not the employee delivered upon what was agreed to three months
ago, or whatever the timeframe, is irrelevant (at least it should be).

The question should be, "Is your work having a positive impact on the
business?". There is an inherent necessity to quantify "positive impact" when
working with consultants, partly because they cost a lot more in the short-
term, and partly because the nature of their work is generally less creative
and more controlled.

So, if you trust the people you work with, and the company communicates it's
vision well, IMO Scrum and Agile are too much procedural overhead. Of course,
you have to meet those two conditions :)

------
gstober
I read through the first bunch of these comments and scanned the rest...you
guys, you guys... I might have missed it but I didn't see anything about
client delivery that is viable...or do you have other reasons for being in the
software game? Who really cares what process you use? As a client I want to be
involved, I want to see how you're doing on an on-going basis, I want stuff
that works well, I want stuff I can use and I want to alter by vision as you
deliver because my business can change...

------
snarfy
The effectiveness of scrum really depends on the team size. The larger the
team, the more bureaucracy is needed to manage it.

~~~
ronnier
What's a good team size?

~~~
tarice
"Fewer than three Development Team members decreases interaction and results
in smaller productivity gains...Having more than nine members requires too
much coordination." - Scrum Guide, page 6

Source:
[http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru...](http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf)

------
cpenner461
Several comments about the notion that at some point you outgrow Scrum. For
those who have reached this point, I'm curious what you've switched to? Or has
it been more of simply relaxing some of the constraints/procedures? Asking
because I've recently started to wonder if/when we'll need to modify our
mostly-Scrum process.

~~~
adrianhoward
The most common (productive) change I've seen is a move to something that's
closer to the pull/kanban/lean approaches.

For example a pattern I've seen a few times goes something like this:

* Teams get good at breaking down and estimating backlog items, they tend to all become the same "size" and need about the same amount of "work"

* Product Owners get good at prioritising the work so that the most valuable stories are at the top of the queue

* Dev team and product owner turn have a collaborative relationship rather than a boss-minions relationship.

* The combination of those three factors means that the planning meeting basically turns into "we do the next N stories" where N is the number of stories you get done every sprint. So the utility of this meeting disappears.

* The process of work flowing through the team starts resembling single-piece flow. Everybody works on the next most important thing.

* People start continually delivering, rather that just being able to deliver at the end of the sprint.

* The last two points mean the utility of breaking work into sprints kind of vanishes.

* Everybody notices that they're doing flow-ish things rather than batch sprint-ish things and starts looking to the lean / kanban world for ways to optimise the process further.

------
gleiva
We started doing Scrum around a year ago and it has worked well for us. I feel
some of the points described in the article about Scrum are not because of the
framework itself but because there could have been a lack of a Scrum Master,
which is an important piece in the puzzle, to ensure Scrum effectiveness.

------
demian
We need to drop the idea that there is THE methodology to organize software
development. I like the approach of this post, but I would had prefered a
little more context on the type of projects he manages.

A professional software manager should be able to identify the key aspects of
a project, and with that define the methodology (borrowing from different
aproaches and using different tools). Some projects require centralized design
with a top-down approach, and more of a "programming workforce" self-
coordinated with some progress metric. Other projects require more
sophisticated engineering design, technical expertise imbued in a creative
enviroment by a relatively small team of engineers/developers.

In my opinion, iteration is all about exploration. Scrum basically discards
the role of a "designer" for the systems. But sometimes you need a designer.

------
michaelt

      Iteration planning meetings are seriously expensive.
      Group discussion around design, group estimation, group 
      acceptance, all highly inefficient. [...] I remember just 
      getting bored to tears listening to discussions around 
      stories I wasn’t developing on to begin with.
    

That's quite team size dependent. In a scrum team with 4 people this isn't a
problem - but when the team's twice as large it doubles both the amount of
work to plan and the hourly cost to assemble the entire team, quadrupling
planning costs.

If a team is structured in such a way that a developer knows they won't be
working on a story, that seems like a logical line for splitting into two
scrum teams.

------
wballard
Interesting points, but I feel that the root cause of these process debates is
one un-natural act: estimation. Personal opinion is that far too much energy
is put into processes to generate predictability, which is only practical when
you have done it before, repeatedly.

All this focus on estimation, points, timing -- it just doesn't create what is
needed to both do a great job and go fast: clarity.

This is why I don't run my shop with deadlines. I have no experience that
deadlines/sprints/iterations make things faster, or create better ideas -- the
things I'm actually interested in.

------
njharman
Excellent observations based on actual experience.

A refreshing change from the usual "I don't understand what agile is but I did
something I called agile and it sucked so I'm now blogging about how agile is
broken".

------
g123g
The #1 point mentioned in the article was my experience as well. For a tight
deadline project if we decided to do everything based on the complexity points
and team velocity it would take 6 sprints and a total of 3 months. But we just
decided to ditch it and sit around a table and finished the whole thing in 2
weeks straight. So my experience is that if you are working with a dedicated
team it is better to finish the work based on the best of your ability rather
than time boxing into some artificial time limits.

~~~
kevingadd
How would Scrum turn a 2 week project into 3 months? Are you just saying you
were terrible at estimation, or what? I don't understand what you ditched,
specifically, and how that produced an improvement.

~~~
SoftwareMaven
In timeboxed iterations, you have to be _very_ careful that work doesn't
expand to fill all available time. If you are a little conservative with your
estimates, its easy to double the time the _necessary_ aspects of development
would take. Little, unnecessary tweaks becomes more important than putting
four hours into the stretch goal that is going to spill into the next sprint.

Six times is a bit much, though. That sounds like they haven't worked out
their estimations yet.

------
MartinCron
The fundamental thing I've realized while looking for "the optimal end-state
process" is that _it doesn't actually exist_.

Scrum is, for many development organizations, an incremental improvement over
what they are doing now. The biggest problem that I have with Scrum (and all
prescriptive methodologies) is that it's presented as a vision for the right
end-state instead of a set of tools that you can use to help find the right
process for your immediate context.

~~~
mongol
I so agree with this. If there was such a ting as "100% scrum compliant" it
would be a bad goal to strive for. Not because it is bad in itself, but
because the process should be adjusted to the situation.

------
leothekim
Also, obligatory: <http://programming-motherfucker.com/>

------
JoelMarsh
There seems to be some very scrum-savvy people here. I have used it many
times, but I am interested in your thoughts about how designers typically work
within that framework. In my experience design and scrum don't play very
nicely together. Thoughts?

~~~
adrianhoward
There are a bunch of folk (me included) who spend a lot of time thinking about
getting UX and Agile folk to play nice together. You can find some of my
rantings via lanyrd <http://lanyrd.com/profile/adrianh/>.

You'll likely find Jeff Patton's work of interest - this might be a good
starting point
[http://agileproductdesign.com/blog/emerging_best_agile_ux_pr...](http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html).

There's a stack of stuff under <https://pinboard.in/u:adrianh/t:agile/t:ux>
that you may find interesting. Some of it may need filtering through my brain
before you see the agile/ux connection though :-)

The UX track at Agile 2012 had a bunch of great sessions around getting UX and
agile running well together (bias warning - I produced the track :-)
<http://agile2012.sched.org/overview/type/user+experience> \- I think all the
sessions have slides now. Nag me if not.

There are also the sessions from Agile UX NYC earlier this year
<http://agileuxnyc.com/presentations/>

Personally I'm finding UX works better outside of an iteration context with a
more lean/kanban approach. The stuff Janice Fraser is doing at LUXr for
example <http://www.slideshare.net/clevergirl/>. Google around the "Lean UX"
topic. Ignore the folk who talk about it as if it's just about less
deliverables. It's more than that.

Finally the agile usability mailing list
<http://tech.groups.yahoo.com/group/agile-usability/> is a useful place to
chat about this sort of stuff.

~~~
JoelMarsh
Amazing. I'm glad I asked. Thanks!

------
the1
just code. code well.

~~~
sethg
You can code, code well, and then discover that the feature you just
implemented was something that the upper management actually didn’t consider
to be very important, or that they wanted something completely different from
what you thought they wanted. That’s the sort of failure mode that Scrum and
other development methodologies are trying to protect you against.

~~~
the1
I tend to think bringing in agile specialists and installing scrum process to
save the project is a bit dogmatic. If you worked on a project for sometime
and wrote/rewrote a lot, you probably know what's needed to be written. It's
fairly unlikely the scrum process actually helps at that point. What keeps you
going at it is probably "faith" you built through out the year since the onset
of scrum installment... and, just a habit.

 __

If you are afraid of writing unneeded, unimportant, and unpopular things
enough to label them as a "failure", your focus may be to find needed and
important things for your audiences.

Your focus may be to read the draft to a select sample audiences everyday,
every week, continuously, and apply various analytical techniques to different
statistical models you built from the feedbacks to overcome your fear of
rejection, and "manage" direction, completion, and shipment of your writing.

Or just write. A lot. And read. A lot. You'll "get" trends. You'll "get" what
works and what doesn't. Of course you need feedbacks. Of course you need plans
and management especially if you are co-writing with many authors.

But my focus is still to write.

------
jpatil
What people fail to realize is that Scrum is a specific process. There are
actual guidelines on how it should be implemented and what the team make up
should be. People think they can take Scrum and tweak it to meet their needs
(even if it hurts the process) and have it still be effective.

People believe that they can "scale" Scrum to teams of 100s of people, in
different locations, across time zones and with people who speak different
languages and expect it to work the same. It wont and was not designed to.

Additionally, Scrum is not designed to handle unanticipated work. How many
times will a team be working on a sprint when a fire happens, especially at a
large company? The team needs to disrupt the sprint and handle whatever
unplanned work it is, from a defect a major customer change request or
whatever. The whole sprint gets thrown out of wack and what was defined as the
ship requirements needs to be redefined on the fly. However, Scrum allows
partially done work and if a new work item is injected at the end of sprint,
the Q&A team may not be able to meet the new ship requirements of either the
new work item or the rest of the sprint work.

With that said, Kanban was designed to not be a prescriptive process. Kanban
is all about making small incremental improvements in WHATEVER YOU ARE DOING
NOW. By visualizing work you are able to see where you are becoming overloaded
and where blockages are occurring. By adding WIP limits and through pull
instead of push you are helping to even out the flow of work and ensure that
work is getting completed to 100% at a relatively constant speed. There are
other aspects of Kanban that help, specifically metrics, the CFD, and swim
lanes, but really with these two aspects, you can constantly visualize what is
going on and figure out how to improve your work process on demand and in your
own way.

While I am a big proponent of Kanban for countless reasons, many organizations
cannot simply change overnight. Many organizations cannot grasp the concept of
no time box and continuous deployment. Putting faith in the work ethic and
self organizing capability of the developers doesn't jive with many companies
(even though the studies show teams are much more productive when self-
organizing). Other people, like the author, like the idea of iterations. In
addition, many teams see great value in doing the retrospective. Lastly, the
teams in the organization may have been trained in Scrum and been doing it for
years. To all of a sudden change to something new can cause major disruptions
in work and full on rejection and revolt.

For these types of organizations, I tell people to try Scrumban or Kanban with
Iterations, whatever you want to call it. Teams can use Scrumban as a stepping
stone to becoming more Lean or then can just use it going forward to improve
and scale Scrum. Using Scrumban, teams can move slowly to self-organization
and from estimating to prediction. They can handle injected work more easily
and move to continuous deployment. Moreover, they reduce multi-tasking/ task
switching and ensure a even flow of work.

For anyone wanting to learn about Scrumban, I send them to this video ->
<http://www.youtube.com/watch?v=0EIMxyFw9T8> It's an awesome video that is
just over 6 min long. I don't know who these guys who made it are and am not
promoting them but the video does the job well.

