
Ask HN: How many of you are actively using scrum/agile methods? - arnorhs
To me it seems like scrum/agile methods are things only used in bigger companies where productivity/motivation of employees might be a big issue - even the quality of the employees. Every time I hear those terms I just get a shiver all over my body, but you still hear them used quite a lot in the software business.<p>I've never heard of anybody talking about those things in the startup world to any extent. Are those methods useful in the startup context? Do any of you guys actually use them?
======
starkfist
Scrum is a trick to get everyone into the office by 9 am. Agile is a disguised
form of extreme micromanagement.

Both techniques have been cleverly marketed as a way for developers to work
together in a state of harmonious productivity, when really they are CYA tools
for managers.

~~~
ww520
Amen. They are slave-driven development methodology.

~~~
AmberShah
Wow you guys have no idea. Please, just because some loser used it as an
excuse to be a slave driver, don't blame agile/scrum.

Daily stand up meetings should happen whenever everyone will already be there.
9 is irrelevant. 10 is fine. If someone is WFH, then they call in.

Agile saves me FROM the micromanagers. Instead of having to be polled every
few minutes, go look at the freaking board! Finally, no interruptions...

------
noss
I use fixed sprint lengths (3w) with fixed team members, and a backlog of time
estimated items that the product owner prioritizes.

I would not go back to not doing this, as it allows focus (sales people fight
to get things into the backlog and next sprint, rather than grabbing a
developer directly). It discards out of the blue time estimates ("oh, maybe 3
months?"), by rejecting everything longer than the sprint. It also foster
better developer-tester communication inside the team, already during
development, which kills bugs earlier.

We're currently 3 teams with 5-6 developers and 1-2 testers each, soon to
split into 4 teams and 2w sprints. So yeah, bigger company,

Agile killed a previous waterfall model with 2 month spec creation/review, 2-3
month development phase with developers being added and taken away during the
time, and 1-2 months of testing, followed by bug fixing by developers that
were taken out from other projects started by then.

------
arnorhs
Personally, if I was looking for a job and scrum/agile was mentioned in an ad,
it would be enough for me to not even consider the posting.

~~~
ukdm
I agree with this. I was lead designer in a team developing a multi-format
game about 3 years ago. We switched to using agile and it really hit
relationships and the way we worked in the team.

Rather than the lead programmer, artist, designer, and producer having a good
picture of the development process, the project manager was the only one who
had a view on where we were in the project. He was not from the games industry
which made it even more difficult.

We were only using a subset of agile, but it seemed to break up the team
rather than get them working together.

I'm not saying this is the fault of the agile method, or that agile is wrong
for games development, but in my experience it was enough never to want to use
it again.

~~~
mattmcknight
What did you switch from? Which agile method did you use?

~~~
ukdm
We switched from a system that had just worked organically over several
previous projects. Weekly meetings among the leads with the producer and
project manager. Each lead would work out the tasks, time limits, and take
into consideration other departments deliverables. Inter-departmental
communication was also handled by the leads, there was no pairing off, or
groups of different disciplines working together, although this did happen
when necessary throughout a project.

As for what Agile method we used, I have no idea what specifically the method
was called. We were told our team was going to experiment with Agile but keep
it very simple. Teams of 2 or 3 were formed for specific tasks from different
departments. Weekly time slots allocated, and reviews done at the beginning of
the following week.

------
pistoriusp
I work in a really small team of 2. So we just have a large todo list.

I work with my girlfriend so we talk about ideas, implementations and goals
almost all the time.

Even when we get bigger (And I hope we do), I would really prefer not to
abstract things too much, KISS.

~~~
noss
Sounds quite agile. Set a spring length, time estimate and prioritized the
todo list. Then you would get a pulse between developing and reviewing what
time is spent on and if you're developing the right things.

~~~
silentbicycle
If people call any simple style of development/review that works "agile", then
what about when developers go through the motions to do "real" Agile
Development (TM) and it doesn't? Is that not "agile" anymore?

That's like when TDD advocates claim credit for the benefits of doing _any
testing at all_ , but only acknowledge the costs of doing orthodox TDD (if
that). It's dishonest, and makes it harder for anyone to have any kind of
meaningful discussion about what does and doesn't work.

I'm not arguing that there's a benefit in having a development / testing /
review cycle, but when discussion turns to capital-m Methodologies, it tends
to become us-versus-them, more about following the methodology's branding and
other trappings to the letter than whether things actually work.

[Edited a bit for tone, and to make it less personal]

~~~
noss
I did nothing intentional there really. You seem to be making me defend some
brainchild of yours about what "Agile Development (TM)" is. I wont go there.
Nor will I be associated by TDD advocates that you don't like.

I just find pistoriusp to be quite agile in that they see themselves as a
team, and that they have a todo list of things to finish in some order
(backlog in agile terminology).

Since I am being down voted, there must be people that think it is a bad idea
to introduce a fixed sprint length and perform time estimates on todo list
items. For the conversation, I want to hear those arguments.

~~~
silentbicycle
First, it sounds like that wasn't your intention, so sorry for putting you on
the spot.

I don't care about Agile Development, proper. I want people to be able to
discuss what techniques increase agility (which needs a better word, now)
without the Agile people stepping in and derailing everything into being about
their personal ideology.

I just think the advocacy tactic of, "You've been unknowingly following my
Special Technique all along, and that's responsible for your success...do it
_right_ and you'll do even better" should be seen for what it is: taking all
of the credit and none of the blame.

And about, "You hate Agile, so you must think waterfall is better"? Don't get
me started.

------
thibaut_barrere
We (we're two) use some form of scrum which vary over time, to handle our mix
of billable work + self projects.

It's always extremely beneficial in our case (and not about motivation).

Things I really appreciate:

\- product-owner mindset is the most beneficial to us: things like theme
scoring <http://www.mountaingoatsoftware.com/tools/theme-scoring> or other
techniques advocated by Mike Cohn

\- writing user stories + role modelling is really helping us "go out of the
garage"

\- burn down charts and estimation techniques provided by Mike Cohn help us a
lot ensure we deliver on time/budget

\- we know where we stand (what's remaining, etc)

So my conclusion: a lot of people these days are avoiding scrum/agile because
they are used as buzzwords. It shouldn't make you miss the (extremely) useful
tools they provide...

In any case - yes, I'm very actively using all this!

------
angelbob
We have five engineers on our team, and eleven in the company (I think? I
forget if we hired one more in Colorado).

We use a somewhat-modified scrum. Stand-up meeting daily at 10am, board with
hour-estimated tasks divided into stories that migrate from on-deck to in-
progress to done. We also have a nice burn-down chart (on paper, updated with
markers by hand) that we update daily.

Overall, it works quite well for us. The businesspeople can easily check the
chart for a "where are we on this stuff?" question, so they like it. The task
board and chart are good for similar things for us.

We modify how we do it just a little every iteration, but it does keep working
better. For instance, how do we managed added tasks on the burndown chart? Do
we adjust the red and green lines and deadlines? Do we have a separate "tested
automatically" category on the task board to assess test coverage for the
story? But it's little stuff like that, window dressing, that we tend to
adjust. Overall it's working quite well for us.

------
dshupp
My company does outsourcing, mostly with startups. We use scrum (the
management framework) and lots of extreme programming (technical practices),
all of which fall under the broader "agile" (abstract concepts). We do these
on every one of our projects...from 2 person iPhone apps to year long, multi-
team projects.

For any group of people that's going to work together and produce, the ideas
in scrum and agile are super important. Apply them how you like, using
whatever names you like, but understand them and be aware of which ones you're
doing

To me, scrum is barely a process, and it won't solve any of a group's
problems...but if it's applied at all it will make those problems really
obvious, at which point it's up to people to fix them.

------
andrisig
I would not rely too much on these terms, every company has its own process
that evolves. Agile and Scrum can assist in finding out what kind of a process
you want to develop. There is nothing called "Scrum" that will fit all
software companies.

------
DanielBMarkham
It's helpful to distinguish between big-a "Agile and little-a "agile"

"Agile" is all about orthodoxy. You must do A, B, and C.

"agile" is all about time-boxing and inspect-and-adapt. You can use anything
you want.

I don't know why you wouldn't do agile, but I can imagine lots of folks will
tell you horror stories about Agile.

I'm a big agile fan. Make a post-it when I think of a new feature. Stick it up
on the wall. Every Wednesday I step back and take a look at the storyboard and
what got done that week.

I mean really, isn't this just common sense? You have to do _something_ that's
kind of project-management-y, why wouldn't you want to do the types of things
that are as lightweight as possible?

------
gacba
I'll add a contrarian view about Agile in big companies--I consulted for a
major media company in NYC that used Rally and "did Agile" but it was mostly
lip service and the daily scrum meetings were more like status reports. It was
their sheer size and the inability of their project managers to adapt to a
non-status-report mode of thinking that made the Agile methodology weak and
unsuccessful.

I'd say Agile is much more easily adopted in a startup where no prior culture
exists to inhibit it. Major companies with older systems in place don't change
overnight.

------
AmberShah
The methods are way useful anytime you're building software. The whole
agile/lean methodologies was actually a grassroots movement that started in
smaller teams and startups and had to be pushed into the enterprise world by
activists. I can understand your comment about shivers because by now it's
become a full on buzzword and lots of business people use them without having
any idea what they're talking about.

If you can ignore the empty hype, there is still a lot of value in the actual
practices. A lot of the practices are things that startups do naturally
because it fits well. Iterating quickly, continuous integration and
deployment, automated testing, user stories.

"Agile" is a movement, for lack of a better word, based on doing more of what
works (focusing on people and productivity) and less on what doesn't (bulky
processes). It was a reaction to the heavy waterfall, process-centric methods
used that were slowing productivity down to a halt. Now that people who love
paperwork have gotten their hands on it, they want to turn agile into
something it's not. Anyone who tells you that you HAVE to do X, Y, and Z
processes to be agile is wrong. It's about works best in your team and being
open to trying new things to find out what that best thing is.

------
tbone9992
Iterative development works and anything complex that works was built off a
series of small things that work. Agile is simply a set of core principles
like "satisfy the customer", "welcome changing requirements" and "working
software is the true measure of progress". Scrum is simply a framework of team
commitment and forces frequent communication (one of the principles).
Typically if people complain about agile or scrum it is because they really do
not understand that iterative development is and has been done for years and
recognizes that requirements are perishable and maintaining them expensive and
wasteful. The list goes on and on but if you understand agile as principles
and values you would be hard pressed to disagree with any of them. Most
managers do not get it though so the better question is "what practices do you
use to be agile?" and you'd better damn well hear TDD, XP, BDD, Continuous
Integration, etc.

------
ljf
I don't work in a start up (hope to one day).

We use Agile - had been using Scrum, just moving to Kanban.

I find Kanban A LOT better for a cross discipline team (editorial, UX and
tech) - but not been using it that long.

Yes it's working for us in a very large company, in a smaller privately owned
company, where everyone's ass is on the line, maybe it wouldn't be so useful.

I do see the boards (scrum/kanban) as being a great way to surface what is
happening in the team, to answer questions and show bottle necks. But in a
smaller team that should just happen.

I think it can be used 'wrongly' to try to control teams, but i see it as a
stakeholder management tool - "ok so you want that extra feature, lets go put
that in the backlog, hum now see how our dates move? Ok you do, great, so what
is your priority (considering we have fixed time)..."

------
devspade
I work for a startup and we scrum every morning. We have some people working
remotely so it's a good chance to get everyone on the same page.

Agile - I don't even know what that means. Different people use it
differently. So yeah - uh - we're agile.

------
jeremyjarrell
We use daily standups, user stories, CI, and TDD. We're NOT pairing, keeping a
burn down chart, or doing a great job of having regular retrospectives or
iteration planning.

Our customer rep is someone who worked in the industry for several years
before joining us as a salesman. He's now our fulltime customer rep/product
owner for the team. So far that's going well he's a new addition so there's
still time for it to go really good or really bad.

We're not an a startup, rather an established company with a successful line
of products. The project I'm thinking of however is a brand new product that's
been given a lot of leeway and autonomy.

------
sown
We use rally at work.

The best thing about rally is the short dev cycle and the often re-evaluation
of our progress, etc.

Everything else seems like management rah-rah stuff, though.

------
dannyr
I know a lot of startups that do Scrum. It's helpful getting everybody on the
same page and getting motivated.

Why do you get shivers? What's so bad about it?

Scrums and startups do mix.

[http://sfbay.craigslist.org/search/jjj?query=scrum+startup&#...</a>

------
pclark
Readness.com goes by the JFDI method:

Listen

Code

Ship.

