Ask HN: How many of you are actively using scrum/agile methods?
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?
40 comments
[ 4.2 ms ] story [ 87.4 ms ] threadRather 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.
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.
I'm just guessing that this was not a team led initiative. It really must be to be successful.
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.
+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.
would agile help as compared to not having agile then ? If yes, then what is the simplest methodology (books? blog post?) that is effective ?
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)..."
Agile - I don't even know what that means. Different people use it differently. So yeah - uh - we're agile.
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.
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 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.
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.
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.
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.
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.
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&#...
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 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.
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.
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.
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.
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...
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!
Listen
Code
Ship.
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.
"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?