Ask HN: How many of you are actively using scrum/agile methods? | Hacker News Reader

Ask HN: How many of you are actively using scrum/agile methods?

31 pointsarnorhs39 comments

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.

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?

View on HN

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.

Opposite experience here really. The team can pad up time estimate for a user story (or decrease total time available for user stories in the sprint) because the team wants to include time to get rid of some technical debt or other internal work.

I do not understand how agile allows for easier micro management as you say. If some team outsider tells our team how to work we tend to invite them as a member to the team for the next sprint, to show us what they mean. That usually sets the discussion in the right direction.

Since the backlog is highly visible, there is much better scrutiny of user stories for customers that have not yet signed a contract. There is also a built in stop of a sprint length before there is a review again of what the team has been ordered to do.

Basically, if the team took something off the backlog, we know who put it there. The team is doing exactly what it should be doing, taking items in priority order. Sales people have been fired at work, developers have not.

Amen. They are slave-driven development methodology.

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...

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.

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.

And why is that?

What do you base that opinion on? I'm certainly not a fan of huge amounts of process, but I think I'd be more frightened of going to work for a company that had no process at all.

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.

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

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.

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

I'm just guessing that this was not a team led initiative. It really must be to be successful.

What kind of process would you prefer to have in your company?

So you prefer waterfall ? Most of my gigs have been in big corporate environments where people are considered "resources" and agile has nothing but savior for me . Bad agile is always better than even good waterfall .

Ermm, one of the tenets of Agile is that all members of the team are interchangeable (i.e. anyone can take anything from the backlog).

But they are not to be taken away from the team during a sprint! There is absolutely no recommendation to change the teams between sprints for the sake of changing either.

The interchangeable part (although I have never heard it called that) is more that knowledge should be spread, so you don't end up with domain experts that end up "owning" part of the code.

"Individuals and interactions over processes and tools" ...people are more important than any process ..and considering them "resources" is not valuing people enough. What i said has nothing to do with team roles

You'll find once you start referring to PMs as "Powerpoint resources" they stop :-)

"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."

+1.

And I say this as someone who worked for a few years on very successful agile projects (at ThoughtWorks).

(As always) It turns out that the best teams at ThoughtWorks had really good people, who would have made good software even if left to their own instinctive "methodologies".

For TW, "agile" is a kind of marketing differentiator, but many agile projects did (and do) go down in flames there no matter what marketing says.

It doesn't help that the biggest proponents and gurus of such methodologies are mediocre developers, as illustrated by the Sudoku by TDD effort and the Prime Number "kata" and so on..

Fwiw what has survived from my agile days is the practice of writing lots of tests (but no TDD, touch wood), especially when using dynamic typed languages, and a build per check-in running all the tests (loosely, Continuous Integration).

(Imo)The rest of the practices add little value when working with small teams of smart people attacking interesting problems (vs large teams of mediocre developers working on bloated enterprise software).

In my opinion, Scrum is the most "scammy" of all the "Agile methodologies" [1] but the last time I mentioned this here someone making a living as a Scrum Master(TM) wrote me a series of angry mails on how his notion of importing wisdom at some of his clients was being resisted by some "code focused" developers "just like you" there so I'll say no more on that.

So my takeaway wrt mentioning agile,scrum etc in job posts = if you want to hire/ work with large teams of mediocre developers on "standard" projects, by all means insist on the specific process du jour in your job posting.

If you have/want to build a team of sharp developers, product managers etc, let them work out their own "methodology" without imposing practices, checklists, coaches etc on them. It just turns away good candidates.

I understand that people can get quite religious about their favorite methodologies so I'll conclude with

"Just my experience and opinion. YMMV."

[1] "Lean Software" is a close second.

The question is this - suppose you had to work with not-so-great developers or, more realistically, young freshers to software development ?

would agile help as compared to not having agile then ? If yes, then what is the simplest methodology (books? blog post?) that is effective ?

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.

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.

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]

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.

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.

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!

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.

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.

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.

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?

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.

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.

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.

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)..."

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.

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.

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.

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&#...

Readness.com goes by the JFDI method:

Listen

Code

Ship.

Reply on news.ycombinator.com